lkml.org 
[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LANANA: To Pending Device Number Registrants

On Tue, 15 May 2001, Jonathan Lundell wrote:
> >
> >Keep it informational. And NEVER EVER make it part of the design.
>
> What about:
>
> 1 (network domain). I have two network interfaces that I connect to
> two different network segments, eth0 & eth1;

So?

Informational. You can always ask what "eth0" and "eth1" are.

There's another side to this: repeatability. A setup should be
_repeatable_.

This is what we have now. Network devices are called "eth0..N", and nobody
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".

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?

The location of the device is _meaningless_.

Linux gets this right. We don't give 100Mbps cards different names from
10Mbps cards - and pcmcia cards show up in the same namespace as cardbus,
which is the same namespace as ISA. And it doesn't matter what _driver_ we
use.

The "eth0..N" naming is done RIGHT!

> 2 (disk domain). I have multiple spindles on multiple SCSI adapters.

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.

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.

Your argument that names change if you add disks etc is complete crap. OF
COURSE they change. You cannot avoid it. Whatever scheme you use will
cause name-changes. The location-based one causes exactly the same kinds
of problems, except they are even worse - now you have to care which ID
your disk has etc.

The argument that "if you use numbering based on where in the SCSI chain
the disk is, disks don't pop in and out" is absolute crap. It's not true
even for SCSI any more (there are devices that will aquire their location
dynamically), and it has never been true anywhere else. Give it up.

Linus

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.288 / U:4.524 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site