[ 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[01] flags to appropriate state).
> 
> 	3. Add an ioctl() to have the driver perform autodetection
> 	and return the media type (either as link[012] 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[012] 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. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>