I suggested:

>> How about link0 says use UTP, link1 says use AUI, neither says don't
>> meddle with the way it comes up, and both says dynamically switch as
>> necessary to cure lost carrier?

Someone else responded:

>> I for one really like mouse's idea, and humbly suggests that the
>> other ethernet card drivers be modified in this way too.

(Thank you!)

and thorpej replied

> ...except, at least for one card, the semantics of the hardware don't
> allow for Mouse's idea...rather, it works something like:
> 	-link0		aui
> 	link0		transciever
> 	-link1		transciever port is bnc
> 	link1		transciever port is utp

Well, pretty obviously, my idea works only if you have only two
possible connectors...though it could be extended to more connectors
(up to six) by swiping the third of the link* bits - though see below
about cgd's objection.

(Also obviously the interpretation of the link* flags is up to the
driver; that statement looks as though you're saying the _hardware_ is
doing this handling of the link* flags, which is so obviously bogus I
hesitate to mention it, except that someone is bound to get confused if
I don't.)

cgd also replied (to my suggestion)

> Gee, too bad that's COMPLETELY DIFFERENT than all other ethernet
> drivers in the source tree that support multiple media connectors...

So?  If "it's not done that way elsewhere" becomes a reason to not even
try it, progress will never happen.  I'm suggesting that as an _idea_,
something to _experiment_ with, something to be modified and/or
discarded based on what people find in real use.  If I had any
opportunity to play with machines that have multiple media capability
switchable from software, I'd implement something, anything, and
experiment with it myself.  But my NetBSD/sun3 machine has AUI and
nothing else, and "my" NetBSD/sparc machine, while I think it has both
AUI and 10base2, AFAIK can't be software-switched.

> Not only that, it becomes impossible to tell (in software, from
> user-land, without special hacks) N weeks after you've booted you're
> system, which connector you're using...

Only if you use -link0 -link1, meaning "use what the roms left it as",
or link0 link1, meaning "use whatever you can get to work", and you
presumably wouldn't use either of those for a machine you can't just
look at the connectors on.  If you use link0 -link1 or -link0 link1,
then you know which connector is in use....

Actually, if I may be permitted a brief excursion into theory, if we
have N different connectors and we want to be able to configure it
hardwired to any one of them, to "leave it as you found it", or to
"look for a working one", _and_ we want to be able to tell in the last
two cases via software which connector is currently in use, then we
have 3N states and hence need ceil(lg(3N)) bits.  3N+2 instead of 3N
might be nice so that one can have "leave as you found it" and "look
for a working connector" states without associated connector
information, which would be aesthetically nice (but not actually
necessary) for passing to the "set state" interface.

With three bits, this restricts us to only two connectors; if we were
to add IFF_LINK3, this could handle up to five connectors, without the
two extra states, or four, with.

Perhaps using the IFF_LINK* flags is not the right way to go about
this.  If something like it eventually happens generally, it will
probably want to be a separate piece of interface state, generic across
various drivers, so I would tend to skip using the link* flags for it,
even for experimentation purposes, and go right to making it another
piece of interface state.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu