I'm hacking on der Mouse's modified tun interface, and have a few
questions.

I'm addressing the two comments in the pr about it: mainly the
control-channel unit with the text-parsing is going away (it might
be a kernel option, but I think only programs are really going to
be frobing these atributes, so machine-readable flags are better)
and the prepending of the address family to a packet is becoming
optional.

Along the way, some questions have come up.

One question is: should we add an optional text field to an
interface which describes the underlying device? Examples
would be: a whole lot of different tun interfaces will show
up as tun pseudo-devices, pppd could register a descriptive name
when setting up the pseudo-device (either something about the
user logged in for a ppp server or the destination site for a
dial-up link when there are multiple destinations), and certain
(many?) ethernet drivers handle multiple card variants on the same
device type, and could thus describe which one is in use (if_ae
on mac68k is one example).

Such a thing would certainly be optional. If a driver chose not
to give some text, so be it. 

The other questions are all interrelated and not clear, but they
involve how to control what address families are present on the
interface. I can see uses for permitting multiple address families on
an interface (say for ppp on a connection which supports multiple
protocol families) and I can see uses for NOT permitting different
address families on an interface (there's no reason to permit an IP
address on an Appletalk tunnel, or ppp when only one PF was
negotiated).

The problem is that during a SIOCSIFADDR, by the time most address
families (well INET and NETATALK) get around to asking an interface
what it thinks of an address, they already have allocated an address
entry on the interface for the address. This entry is not deleted
on clean up after an error (say the interface not supporting that
address family). Or am I missing something?

One solution would be to add a mask (using netisr values) on an
interface. If, just before adding an address, a protocol family
didn't see it's flag in the mask, it would bail.

Though a properly configured system would have no problem, I
had problems with eon while porting Netatalk. eon is the iso-in-
ip tunnel (which could get turned int a tun process after the
tun driver gets changed). As it is a broadcast interface, netatalk
will, if no config is given, try to fire appletalk up on it. eon
didn't react with total style and grace (though I'm not sure if
that was eon's fault or netatalk's fault; probably netatalk's).

Basically it looks to me like we leave ourselves open to pilot
error. Or am I missing something.

Thoughts?

Take care,

Bill