> > 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)
> 
> Well, personally, when I used it I had an echo command in the boot
> scripts to configure the interface.  It was a lot easier than
> allocating a bunch more ioctls and writing a little command-line
> interface to them.  Obviously, if you make them ioctls, _necessarily_
> only programs are going to be frobbing them. :-)

Config option it will be. :-)

> > One question is: should we add an optional text field to an interface
> > which describes the underlying device?
> 
> Without standardized strings, this would be of use only to humans; with
> standardized strings, you will inevitably find that a whole lot of
> useful information gets lost because the standardization didn't take
> into account future new uses. :-)
> 
> There may be no single "the underlying device", and if there is the
> software that sets up the tun link may not know what it is.  For
> example, if I encapsulate IP encrypted over a TCP channel, "the
> underlying device" would probably be the real network interface that
> carries the TCP connection...but finding out what that is is
> nontrivial.

Hmm. I meant the interface (tun for tunnels) gets to decide what
(if anything) gets printed. For a tun, I'd envision the tun saying
something about what it's tunneling, like "encrypted IP link" or
"IPTalk Apletalk tunnel". Also, there are multiple Appletalk
tunnels, like IPTalk (used by CAP since the begining), ARNS (used by
CAP from the folks in Australia), and ARA (Appletalk Remote Access).
So they represent a case where just having a tunnel w/ an atalk
address wouldn't be enough to know what's up.

> Why would you want this information?  When would it be useful to do
> anything with it?  I'm not clear on this.

Mainly for reference. Also, ethernet interfaces could attach a string
saying what they are, more specifically than just the interface type
will say. Thus I can sit down at your machine and quickly tell what
each card is, with neither having to frob /kern/msgbuf or syslog's
output, nor worry that the config info overflowed the msgbuf before
syslogd fired up.

> > The other questions are all interrelated and not clear, but they
> > involve how to control what address families are present on the
> > interface.
> 
> Yeah, I never implemented anything but INET, so that part was easy for
> me. :-|
> 
> I think you'd have to specify this info somehow as part of setting the
> tun interface up, preparatory to bringing it up for real and handling
> packets.  If the MI SIOCIFADDR code doesn't properly handle
> EPFNOSUPPORT from the driver (I would assume that's the right error to
> return), that seems like a bug to me.

I agree that for a tun, the process should say what kind of address
families are acceptable. If I understand the code right (questionable :-),
though, the invalid address will get left lingering on the interface.
Or will ifconfig clean things up?

I think the cleanest solution is to never let the address get there in
the first place.

> > [...]  As it is a broadcast interface, [...]
> 
> Personally, it is important to me that tun interfaces be capable of
> being point-to-point interfaces.  Did this comment mean you have
> dropped this aspect of what I did, or were you simply referring to one
> particular configuration, or what?

Here I'm refering specifically to eon. I think tun's being able to
decide if they are a p2p or broadcast interface is important. I'm
most interested in broadcast, but you seem to have handled the
two options well, so there's no need to change.