Re: devfs

Richard Gooch (rgooch@atnf.CSIRO.AU)
Tue, 13 Jan 1998 11:08:19 +1100

Adam D. Bradley writes:
>
> > > I find this ugly and counter intuitive... IMHO...
> >
> > Exactly. I keep wondering how I would parse 1-1-1-1-1 bleary-eyed,
> > 3AM after about a dozen pots of coffee - that's when those little
> > letter "hints" about what it all means would come in *REAL* handy IMHO. :)
>
> This whole debate is just screaming "CONFIG OPTIONS!!!"
>
> Solaris SCSI Device Name Compatibility [y/N]:
> Linux Old-style SCSI Name Compatibility [Y/n]:
> Custom SCSI Naming [y/N]:
> Controller Preface: <string> "scsi-c"
> Bus Preface: <string> "b"
> Device Marker: <string> "d"
> LUN Preface: <string> "l"
> Partition Preface: <string> "p"
> Suffix: <string> (null)
>
> (and possibly some switches to aggregate fields, e.g. host+bus as one
> field, or to omit fields, e.g. LUN)
>
> Separators easily changes to dashes, or dots, or other letters, or
> random printable characters, or your girlfriend's name, or your
> favorite George Lucas film, or...
>
> And, of course, the naming schemes don't have to be mutually exclusive
> (although having multiple naming schemes in place does have overhead
> in terms of runtime memory consumption, etc...)

I think a standard naming scheme like sd_h0c0i0l0p2 will have to be
enforced (i.e. no config option), and the old scheme available as a
config option, and that's what I'll support. We need a simple,
understandable standard that works for everybody. It may not satisfy
everybody, but it will work.

Any other naming scheme: go ahead and write a patch and submit it to
Linus once devfs is in the mainstream kernel. I think any "custom"
naming scheme will have to be thrashed out on the list before sending
it to Linus. And he may discard it anyway.

Besides, and I'd like people to think about this, there is a way of
doing this in user-space. All that is needed is a way to find vendor
strings and such for each controller (possibly with a devfs entry,
rather than a /proc entry, given that I gather Linus would rather
/proc was just for processes). Once you have that information, you can
build symlinks in /dev as you wish.

This doesn't address the problem of mounting the root FS (yeah, I know
about initrd, but that seems messy to me), but if the UUID labelling
scheme takes off, that might be a better approach anyway.

Regards,

Richard....