> I entirely agree with this, but I would add one thing to what cgd says
> after that (which I deleted here): 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.

Actually, i'd say that _this_ could very well be a good candidate for
a 'link' flag, if someone were to implement it.  it has little or
nothing to do with the current media setting.

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 _can_ imagine situations (e.g. very busy networks)
where enabling such a feature would lead to almost endless lossage.

Additionally, I don't see why an in-kernel solution is any better than
an out-of-kernel solution.  (write a daemon that watches certain
stats... collisions, drops, etc., on your favorite interfaces, then
does a media detect when a threshold is passed.  that way not only
are people who want to avoid the bloat of having it in-kernel
satisfied, but you've also got the potential for setting more
interesting policies, or whatever.)


> Of course, passing this 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.



cgd