Re: scsi device names, symbolic names, devfs/sysfs

Frank Edwards <[email protected]> Fri, 22 Aug 2003 13:30:17 -0400 (EDT)
Newsgroups gmane.linux.hardware.sony
Message-ID <[email protected]>
On Fri, 22 Aug 2003 [email protected] wrote:
> From: Thomas Jakobi <[email protected]>
>
> hi,

Hi, fake.  (Say, is that your real name? <grin>)

> On Thu, Aug 21, 2003 at 10:29:50PM -0400, Frank Edwards wrote:
> > Unfortunately, this means that your device names can change depending on
> > what's hooked up to the box.  I never understood why partition names
> > aren't assigned to logical devices.  For example, on my circa 1986 Amiga
> > each partition was assigned a label by the OS (such as "Work:") and the
> > user could assign their own name as well (such as "Backup:").  Even if
> > drives were re-ordered on the scsi bus, they kept their user-assigned
> > names the same and if the user only used those names, they were isolated
> > from configuration changes on the machine.
>
> in devfs: /dev/scsi/hostX/busX/targetX/lunX/{disc|cd|generic|partX}
> same for ide, just replace scsi with ide ;)
>
> i can't understand why so few people use devfs, it solves not only this,
> but a whole other heap of 'flaws' of the old /dev-system.....

Devfs doesn't help.  What if the lun# changes?  Then the name of the
drive changes.  Or what if the target id should change?

No, the user should be given a way of autonomously naming their storage
devices.  For example, imagine naming your floppies:  Quicken1,
Quicken2, ScratchDisk, and so on.  Whenever you insert a floppy into the
drive, it automounts it and allows one to use the name "Quicken1:" to
access that drive.

In the Linux/Unix world, the same thing could be accomplished with
something akin to the automounter, in which the automounter determines
the label name and uses it to create a subdirectory under "/some/dir/path"
so that the same name is always used for that particular floppy.  If the
floppy were in use and you popped it out to insert another, the filesystem
just has to cache all writes until the original becomes available again,
possibly dumping the cache if memory starts to get constrained.

<soapbox>
IMNSHO, this should be the way every OS works.  I've only worked on
AmigaDOS, PCDOS, and Unix-like systems (no experience with System36,
OS/390, etc), but I can see no reason why it isn't done like this.  And
the real killer is that the new approach is completely backward
compatible.

Notice how NO / NEVER / NONE hardware changes can affect this scheme.
That's because the *USER* has assigned a *SYMBOLIC* name to a physical
resource and the system conforms to the user, not the other way around.
</soapbox>

Oh, and don't get too tied to devfs, as my understanding is that it
becomes sysfs in 2.6.  Although the programming API stays very similar
(devices still register via the register_devfs() function, for example),
the user-level interface was supposed to change.  I haven't played with
2.6 yet (I don't have enough time to adequately play with 2.4!), but my
understanding was that there was going to be a /sys and much of /proc
was going to move there (except user processes, of course) and /dev was
going to contain dynamic links to /sys.

I'm not the developer, though, so I really don't have a clue. :-)

> fake

Ciao.
--
Frank J. Edwards
Edwards & Edwards Consulting
sales-at-eec.com