Subject: Re: Implementing interface media type autodetection?
To: John Hawkinson <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 06/09/1996 12:13:12
[ On Sat, June 8, 1996 at 17:34:40 (-0400), John Hawkinson wrote: ]
> Subject: Implementing interface media type autodetection?
> Having recently become a laptop-bearing fool, it would be nice to have
> NetBSD autodectect which connector on my 3C589B to use.
Indeed! For any multi-port card!
> I have code to check for the presence of link beat (for the ep(4)
> driver), and it shouldn't be too hard to extend that into more general
> autodetection code, but the question I have is where this should fit
> in the API.
There was some discussion about this in another thread recently....
> Options would seem to be:
> 1. Have the driver do autodetection at boot time, and assume
> that users who want to make use of autodetection won't explicitly
> modify the link flags. This certainly seems nondeterministic...
> 2. Since the link2 flag is currently unused, have the driver
> perform autodetection when epsetlink() is called with link2
> (and have it reset the link flags to appropriate state).
> 3. Add an ioctl() to have the driver perform autodetection
> and return the media type (either as link or as some
> opaque structure) without changing the current media type.
> 4. Add an ioctl() to have the driver perform autodection,
> set the current media type to the discovered type,
> and set the link flags as appropriate.
> 1) and 2) seem pretty lame. 3) might be aesthetically pleasing, but
> since autodection may (at least for the ep cards) involve changing the
> state of the media type on the card, it's sort of misleading.
I don't mind 2) actually. It's a bit poor in the sense that all of the
link* flags are, but it provides the most functionality with the least
impact on any other parts of the system.
> I currently favor 4), and would call the ioctl SIOCIFAUTO. Does this
> seem reasonable?
Yes, this might be OK, iff it were integrated into ifconfig in some way.
This is why I would rather see the most made of the link* flags as they
are. If they are used as a binary state indicator, we've got 8 possible
states to play with, which will be more than enough for most interfaces,
but will never be enough for all. Adding a "link3" would probably cover
another 90% of the remaining possibilities and might be easier than
changing the API completely.
I'm purposely ignoring many of the implementation details here and
thinking mostly how I as a systems administrator and user would expect
things to work given my current understanding of the interface.
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <firstname.lastname@example.org>; Secrets Of The Weird <email@example.com>