> 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. :-)

> 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.

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

> 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.

> [...]  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?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B