udev and devfs - The final word
Quoted 4 lines · Rob Landley
Combine that with hotplug and you have a world of pain. Generating a number from a device is just a fancy hashing function, but as soon as you have two devices that generate the same number independently (when in separate systems) and you plug them both into the same system: boom.
If one has two otherwise identical devices, the only thing that distinguishes them to the system is their point of attachment. Even from a user's point of view, the only difference is the connector it is plugged into. That implies that the hash resolution value ought to be based on the point of attachment.
It seems to me that the key to making this system as transparent as possible is to make these source value of the hash and the attachment point visible and navigable by userspace/humans. Perhaps something like this:
- every driver exports its name and some driver-or-devicetype-dependant value (serial number, MAC address, disk WWID, pty number, kernel address of kobject or whatever) to /sbin/hotplug. The userspace logic gets to hash+uniquify the value as required, and then create a sysfs tree node ("/uid/xxx") whose leaves contain the point of attachment.
- At the bottom of the sysfs tree for the device add a leaf that points back to the entry into "/uid" tree.
Thus, userspace can navigate in either direction between the point of attachment, and the identifiying characteristic of the deivce.
Thanks, Shaheed
How to structure a driver for a IDE controller with hardware RAID support?
Hi,
I have a device called an IT8212 IDE RAID controller. It comes with a Linux 2.4 driver which emulates a SCSI interface and supports both JBOD and hardware RAID (0 and 1) modes of operation.
I don't quite understand the relationship between drivers/ide/... and RAID support. Why for example, would the existing driver be written as a SCSI driver and not an IDE driver?
Thanks, Shaheed