Re: What still uses the block layer?

[david@lang.hm]

On Mon, 15 Oct 2007, Greg KH wrote:

> On Mon, Oct 15, 2007 at 05:08:36AM -0500, Rob Landley wrote:
> > On Monday 15 October 2007 4:06:20 am Julian Calaby wrote:
> > > On 10/15/07, Rob Landley <rob@landley.net> wrote:
> > > > I note that the eth0 and eth1 names are dynamically assigned on a first
> > > > come first serve basis (like scsi).  This never causes me a problem
> > > > because the driver loading order is constant, and once you figure out
> > > > that eth0 is gigabit and eth1 is the 80211g it _stays_ that way across
> > > > reboots, reliably. Yeah, it's a heuristic.  Hands up everybody relying on
> > > > such a heuristic in the real world.
> > >
> > > Umm, not quite, from my experiences with pre-production wireless
> > > drivers, (another story, another time) fancy stuff is being done in
> > > udev to make sure that your gigabit card is always assigned to eth0.
> >
> > I remember building a 2.4 kernel, statically linking in all the drivers, and
> > getting the ethernet devices showing up in a reliable order for years.  Where
> > does the need for fancy stuff come in?
>
> Because PCI devices reorder their bus numbers all the time.  And we have
> ethernet devices hanging off of USB connections now (yes, even built-in
> to the machine), and we have network connections on other hot-pluggable
> busses (remember, PCI is hot pluggable.)

do PCI devices reorder their bus numbers spontaniously, or only if you 
change the hardware?

> So, the distros need to name network devices in a persistant way, that
> is why the distros now do this.  If you don't like the distro doing it,
> complain to them, it's not a kernel issue :)

I have, at least the response was to tell me how to kill this 'feature' 
even if they won't change it.

David Lang

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/