Subject: Re: Implementing interface media type autodetection?
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
Date: 06/09/1996 00:33:56
> 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.