It stops to be repetable unless you are able to define *which* interface
become eg. eth0 after boot. Think of hotplug...
> This is what we have now. Network devices are called "eth0..N", and nobody
Not true. I did. Once :)
> is complaining about the fact that the numbering is basically random. It
> is _repeatable_ as long as you don't change your hardware setup, and the
> numbering has effectively _nothing_ to do with "location".
Consider the following situation:
- you have three ethernet adapters supported by a single driver; assume
they are *significantly* different
- you hotplug a spare adapter, supported by the same driver
- your spare adapter become eth0 after reboot...
- you need access to a NFS server on former eth2 during boot
How would you configure the system to boot regardless the spare adapter is
plugged in or not?
> You don't say "oh, I have my network card in PCI bus #2, slot #3,
> subfunction #1, so I should do 'ifconfig netp2s3f1'". Right?
ifconfig eth-00:20:12:34:ab:cd ?
I'd prefer using MAC address here, but it is also not good as MAC need not
to be unique.
> The location of the device is _meaningless_.
Unfortunately sometimes it is. Rare cases. I used to hit one.
> So? Same deal. You don't have eth0..N, you have disk0..N.
> What's the problem? It's _repeatable_, in that as long as you don't change
> your disks, they'll show up the same way. But the 0..N doesn't imply that
> the disks are anywhere special.
Not good comparison. You can mount filesystems on disks by UUID.
You should be independent on disk names then.
> Linux gets this _somewhat_ right. The /dev/sdxxx naming is correct (or, if
> you look at only IDE devices, /dev/hdxxx). The problem is that we don't
> have a unified namespace, so unlike eth0..N we do _not_ have a unified
> namespace for disks.
-- ======================================================================= Andrzej M. Krzysztofowicz email@example.com phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/