On Wednesday, April 01 2009, Hans de Goede said:
[snip]
> 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.
*nod*
> 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
This feels fragile; the name collision thing is pretty real (a couple of
the weirdo cciss-things use the same naming scheme iirc, although I
don't know that any of them are still in actual use at this point).
> 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).
I like this option too. I see the first disadvantage as an advantage,
really -- being more explicit about checking that the names really match
would be a plus. And it could be handled with some sort of magic
__cmp__ method if we really want (I don't know that it's needed). Also,
it lines up well with how the rest of the world works around the
annoying nonsense that are these sorts of devices
Jeremy
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
