My turn on things...

The ifconfig naming convention gives us:
1) Hardware present in the system
2) Adherence to NetBSD conventions
3) Potentially the driver being used
(Other?)

So, by my reckoning, at a minimum, all NetBSD-based io-pkt drivers should
provide the NetBSD name, if only because we can point people at NetBSD docs
with a certain amount of comfort....

As soon as we have a naming convention that varies based on driver, this
means that the "en"X designation is no longer valid and must eventually go
away.  That being said, I mostly like the way that ifconfig works now in
that you can say enx and it will essentially pick the "x"'th driver that was
loaded in to work with (display order for numbering). Of course, this gets
quite confusing if you really DO have an enx device in the mix with multiple
cards, since it will properly select that one regardless of ordering, but
nothing's perfect.

So...  We have a naming convention that varies with driver and has "some"
sort of meaning.  Should this meaning be "hardware" or "software"?

Given a particular software driver, you can have different revs of the
driver and those won't be reflected in the ifconfig output, so it seems to
me that having the convention reflect software doesn't really work.  

From a debugging point of view, we'll always have to ask "what driver are
you running" given that it could be customized and we'll likely need to ask
what command line options are being passed anyway.

As a side note, we will indeed be shipping one and only one version of a
driver with product.  The fact that we have multiple drivers for some cards
now is an artifact of the driver research we were doing.  We don't intend to
duplicate existing work and what we will very likely do in the future is use
the NetBSD driver if it exists and fully port it.

We just had a quick over the wall conversation and that brought up the fact
that we also have to think about the io-net legacy drivers.  Ideally, if
we've decided that the naming convention refers to hardware then those
drivers should also register the same name to be completely consistent.
However, these drivers don't use the same ioctl interface that the others
do.  They register /dev/io-net/en? for devctls and if we change the name,
this will result in /dev/io-net/wm0 being registered instead.

On the one hand, these are legacy drivers and therefore should be wholly
consistent with their legacy operation.  If we change the names being
registered we will likely break existing code that users have in place
(they'll have to modify it to handle names other than enx).  If we don't,
then we've lost our consistent view.

Ideally, we'd like ifconfig to report the hardware name while the driver
still registers /dev/io-net/enx for compatibility, but that also strikes me
as confusing.  I'm thinking that legacy drivers are different and that as
little as possible should be done in terms of changing how they operate so
we live with what's there today.

So I'll stop there and see what the community has to say.  Any feedback on
how this should play out?  Any preferences?

One thing that we did talk about is adding a command line option that would
allow a user to register whatever name that they want for a driver.  Let us
know if that would be useful as well.


	Robert.






-----Original Message-----
From: Sean Boudreau [mailto:seanb@qnx.com] 
Sent: Sunday, January 06, 2008 9:49 PM
To: drivers-networking
Subject: Re: io-pkt native driver device names

On Sun, Jan 06, 2008 at 05:22:22PM -0500, Andrew Boyd wrote:
> > we shouldn't be supporting both a
> > NetBSD and native version 
> 
> I suspect that both will end up
> in use, for various reasons.
> 
> > if we have a native version there
> > should be a Makefile.dnm in the 
> > NetBSD version
> 
> That probably will not present an
> insurmountable obstacle for...