Re: New storage code and cciss

[David Lehman <dlehman redhat com>]

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

Right. I was thinking maybe a cciss disk class, but certainly no special
class for the partitions.

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

I wish this first option were viable, but it just doesn't seem to be.
The name collision thing is a deal-breaker.

> 
> 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 !)

This is ugly, but it's the one that will work.

Dave