Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader <stefan.bader@canonical.com>]

On 13.07.2011 17:34, Stefano Stabellini wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
>> Yeah, I understand the problem now that I thought of the possibility of having
>> both name types in the configuration. Though I could imagine that in reality
>> there will be no one having that done as it would have caused problems...
>> As you say, the only way to avoid any clashed is to have seperate namespaces.
>> But that again is unexpected now and people would complain.
>> The 4 letters offset probably still can get busted if someone decides to use hde
>> and sda. Detecting clashes at allocation time and then using another name for
>> the duplicate is likely to result in a random of the two to be the secondary.
>> My feeling would be that trying to map two namespaces into one will always be
>> confusing and/or failing to some degree. The reason to go back would only be
>> that this was broken before, so it can probably be expected that people have
>> avoided that mix.So it would be as it has been before. But I bet there are other
>> people that thought of it as a bug... Not an easy decision at all.
> 
> Indeed.
> In any case the "sd" namespace shouldn't be used much in HVM guest
> config files considering that SCSI emulation doesn't actually work at
> the moment.
> In fact there is no reason for having sda in an HVM config file, maybe
> we should print an error in that case?
> 
If it would not be possible to have sd or hd to be present in parallel with xvd
(which is the case with HVM), the xvd driver could just use the names as requested.
So for HVM they would be called hda in the cfg but sda in the domU.

Wonder whether the simplest approach is not just to try mapping all the old way
starting with xvda and if there is a clash detected bail out complaining and
just call the mix unsupported. Its not as there is a price difference there
using one or the other...

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel