Re: devfs

Richard Gooch (rgooch@atnf.CSIRO.AU)
Tue, 13 Jan 1998 17:58:22 +1100


Leonard N. Zubkoff writes:
> From: Richard Gooch <rgooch@atnf.CSIRO.AU>
> Date: Tue, 13 Jan 1998 11:08:19 +1100
>
> 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.
>
> I agree that a single convention is a good idea. I personally would prefer to
> see "t" for Target ID rather than "i", since that's more common on other
> systems. I'd also rather avoid "l" for LUN (logical unit) since it is easily
> confused with the number one. How about "u" (for unit)? The above example
> would then become sd_h0c0t0u0p2. Using "u" also has the advantage that the
> letters chosen are all shorter than digits, making it easier to spot the
> pattern, even at a distance from the screen.

OK then. I can cope with that. So, people: you have a choice between:

h0c0i0l0p2 current scheme: no changes required :-)

h0c0t0u0p2 new scheme: requires people to change compatibility
symlinks and /etc/fstab (if you've gone that far)

Leonard: what's your view on the placement of these devices:

/dev/sd_h0c0t0u0p2 OR:
/dev/disc/sd_h0c0t0u0p2

I don't think deep directory trees are a good idea. At least not for
the standard names. We can always create other trees/names later.

> One interesting problem with this scheme: with the current module
> system, host adapter numbers monotonically increase. Unloading a
> SCSI driver and reloading it will change the host number, thereby
> making any device names incorrect. I understand that some people
> actually do this unload/reload process and have certain devices only
> available when they actually need them.

What happens if I have sdb on host 1, sdc on host 2 and then remove
host 1? Is sdc still a valid name?

I think your point argues in favour of additional naming schemes that
use UUIDs or vendor strings. Whether those solutions belong in kernel
space or user space is yet to be determined.

Regards,

Richard....