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