Messages in this thread | | | Date | Mon, 21 Jun 1999 10:41:40 +0100 | From | Paul Jakma <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
> devfs uses the hardware address, which works for me...
But that means if you change order of how disks plug into a scsi bus, or you move a disk from one to another bus, names change. That's ok for you?
that's not a devfs issue. Linux currently doesn't any mechanism for attaching labels to volumes, which imo would be the cleanest way. what devfs (or rather the kernel) can currently provide, physical locations, is a damm sight better than the old way, order of detection.
Perhaps one problem here is that some folks are also thinking about how to handle this additional problem and how devfs will or will not interact with any solution.
it sounds like you've never really looked at devfs. Devfs merely implements a namespace, it doesn't determine the namespace. ie:
/dev/sd/c1b0t5u0
isn't determined within the devfs code. But rather the driver registers a name with devfs. Devfs is just a facilitator. how the name is determined is done mostly by the driver - not devfs! (if only people would grasp this...). Devfs just controls device entries, it knows nothing about what/where the devices actually are.
So if the (scsi?) disk driver was able to recognise volumes independantly of location, then it would be able to register a volume as a device. Unfortunately the driver doesn't have that capability, so the best it can do is register according to physical location, (which is better than boot order).
It's distressing that so many people focus on the namespace thereby totally missing the point of devfs.. if namespace is such a big issue it can be changed. The point is devfs provides a simple clean structure with which we can build a virtual /dev.
If people could point out weaknesses/problems/improvements with what devfs *provides* rather than on little nitpicks like names (which can easily be changed), then maybe we'd stop going round in circles about /dev/adaptect2940 this or /devices/whatever, and actually come to a sensible agreement.
regards,
-paul.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |