[single quoting here is cgd; double quoting is multiple people.]

>> I'd also add a type which is, essentially, continuous autodetect -
>> if the box loses carrier on the current media, it should rotate
>> through the available media until it finds carrier again.

> I really don't think that doing this is a good idea, would would
> strongly discourage driver writers from implementing it.  Not only
> does it have the potential to add significant complexity, it's also a
> feature that I cannot imagine a competent system administrator
> wanting to use.  In the real world, people don't go connecting
> machines' single ethernet adapters to multiple wires and yanking them
> arbitrarily.

I don't know what real world you're from, but I have no trouble
imagining that.  If I were debugging network problems by carrying a
laptop around, I would _want_ it to media-hunt so I didn't have to give
it an explicit kick every time I plugged it into another port (which
might be on an AUI multiport in this room and a 10baseT hub in that
room and ghod-only-knows-what in the next).

Or for compatability; I've already seen one message from someone
(considering) switching from Solaris to NetBSD and wanting to know how
come it (NetBSD) doesn't media-hunt the way Solaris does.  (Granted,
most of this person's need would be solved with an "ifconfig auto" at
boot time.)

> I _can_ imagine situations (e.g. very busy networks) where enabling
> such a feature would lead to almost endless lossage.

Sure, so can I.  That's why I think it should be optional.

> Additionally, I don't see why an in-kernel solution is any better
> than an out-of-kernel solution.

If nothing else, there currently is no way for a user-land daemon to
detect "le0: no carrier" short of watching dmesg, or knowing a priori
where syslog.conf is configured to send the message and watching the
relevant file.

Now, if every network interface had a character-special device file for
control and status information, something you could select() on, for
such things...then I'd agree with you.  (My tun driver already does; it
needs a cdevsw interface anyway, so I stole a bit from the minor number
to make a control device.  See PR 2411, including the note I sent in
later.)

>> Of course, passing this [media-hunt] back through SIOCGIFMEDIA could
>> be interesting, perhaps it'd be a bit that got |ed into the returned
>> value...or were you considering making the SIOC[GS]IFMEDIA ioctls
>> use strings?
> I think that would be stupid, to be quite honest.

Which of the suggestions here are you referring to?  Not that I suppose
it matters, since I'm inclined to agree with you about putting in
if_flags.

>> I've promoted that field [ifr_flags] to an int [...], and haven't
>> seen any trouble short of [...] needing to recompile everything.
>> (And having a bit of a flag day, since before-and-after kernels and
>> userlands are compatible in neither direction.)
> A properly done (for the purposes of committing to the source tree
> 8-) fix would be binary compatible with old binaries.  It's just not
> very hard...

>> BTW, at the same time we probably should increase if_flags from a
>> short to an int.
> the if_flags short->int change causes binary incompatibility, since
> on many architectures there's no guarantee as to what's going to be
> in the other half of that short.

(er, other half of that int.)  Well, yeah...the simplest way to keep
compatability seems to me to be to rename the ioctls.  For example, we
now have

	#define SIOCGIFFLAGS _IOWR('i', 17, struct ifreq)

so this proposal would do something like

	#define OSIOCSIFFLAGS _IOW('i', 16, struct ifreq)
	#define SIOCSIFFLAGS  _IOW('i', 26, struct ifreq)

and have the OSIOCSIFFLAGS code do "ifr.ifr_flags = ifr.ifr_oflags" and
then switch to SIOCSIFFLAGS.  (ifr_oflags would be a "compatability"
short.)  OSIOCGIFFLAGS would of course do an SIOCGIFFLAGS and then
"ifr.ifr_oflags = ifr.ifr_flags" before returning.  Do any other ioctls
use ifr_flags?  I'd have to check....

>> Rah. Some piece of concensus. Let us also assume consensus is to
>> extend ifru_flags to an int as long as we're changing things.
> Short to int, you meant.

"to an int as long as" is not "from int to long". :-)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu