Andries.Brouwer@cwi.nl [Andries.Brouwer@cwi.nl] wrote:
> In principle the kernel could just number the devices it sees 1,2,...
> and export information about them, so that user space can choose
> the right number.
> The part about exporting information is good. User space needs to
> be able to ask if a certain beast is a CD reader, and if so what
> manufacturer and model.
> But the part about numbering 1,2,... may not be good enough, e.g.
> because it does not survive reboots. If we remain Unix-like and use
> device nodes in user space to pair a file name with a number, then
> it would be very nice if the number encoded the device path uniquely.
> Many programs expect this.
> It cannot be done in all cases, but a good approximation is obtained
> if the number is a hash of the device path. In so far the hash is
> collision free we obtain numbers that stay unique over a reboot.
>
> Andries
I disagree that the kernel should apply sequence numbers as devices are
found or hash path information into the device name.
I am unclear of the need for the hashing the path into the name.
In the ptx operating system I previously worked on we ID'd everything
that we could get a UUID from and one's that we could not we generated a
pseudo one. We also split the UUID space up on config type. This is
similar to the discussion in Andreas's mail. Non-id'd devices could
possibly slip, but ID'd ones did not. In user space we allowed the user
to select any name for a device (the user space to kernel connection was
made by UUID. The solution worked on SCSI and FC based devices (Linux
obviously deals with many more device name spaces).
I thought with devfs, devreg, and non allocated major, minors. A
similar capability would be possible. The "/dev" usage would not need
to know the path, but methods would be available to make the
relationship when needed.
-Mike
-- Michael Anderson mike.anderson@us.ibm.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:21 EST