Hi All,
Today I've been looking in to how cciss and the new storage code
(theoretically) interact. Poking around on a cciss equiped
rhts system (with rhel-5 on it, which is showing its age).
So the story with cciss is:
It has sysfs entries like this:
/sys/class/block/cciss!c0d0
Where udev translates the ! to a /, leading to device nodes
like this:
/dev/cciss/c0d0
Basically udev will always translate an ! in a device name
to / before creating device nodes.
Partitioning is pretty normal, other then that it is living
under a subdir. But I've already tackled that in a generic
manner when adding support for dmraid partitions.
udev does use the untranslated name for the db file, so that
is:
/dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:1b.0......\x2fcciss!c0d0
And the N: entry in their (which results in our Device name attribute)
has the translation so that ends up as: cciss/c0d0
Since Device.name contains the /, things like Device.path will actually
do the right thing.
So things sort of work, except that we've got code in various places which
expects that Device.path.split("/")[-1] will get the device name, and
Device.updateSysfsPath() will mess things up (as it will not translate
the / to a !.
Given that things almost work, and we are likely to encounter more cases
like this, my proposal to fix this is to make the generic DiskDevice and
PartitionDevice classed handle this correct. I don't think that having an
cciss-disk class and then also a cciss-partition class is a good idea. Esp
having multiple partition classes has turned out to be a bad idea as dmraid
has shown.
Moving forward There are 2 ways to fix things:
1) Strip away the part before the / in the name we get from udev,
so that means instead of putting cciss/c0d0 in the name put in just
c0d0
Advantages:
-code which assumes that Device.path.split("/")[-1] == Device.name
stays working
Disadvantages:
-needs special _devpath handling
-needs *very* special updateSysfsPath handling, where we need
to come up with the prefix again
-may lead to non unique names esp with i2o, which if I've googled
correctly has i2o/hda, which will collide with plain hda on
for example ppc if we remove the prefixed dir from the name
2) Keep the name as seen / given by udev as is, so cciss/c0d0
Advantages:
-has non of the disadvantages of option 1.
-not doing anything to the name requires no code
Disadvantages:
-we need to fix the code which assumes that
Device.path.split("/")[-1] == Device.name
(one could actually call this an advantage)
-still need some special handling in updateSysfsPath
(replace / with !)
Option 2 gets my vote (it always helps to type mails like this,
then at the end you sort of have the answer to what you were to ask).
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
