Re: udev and devfs - The final word

Re: udev and devfs - The final word

[Shaheed]

Rob Landley wrote:

>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?

[Shaheed]

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