Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

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

On 15.07.2011 12:20, Stefano Stabellini wrote:
> On Fri, 15 Jul 2011, Stefan Bader wrote:
>> On 14.07.2011 19:34, Stefano Stabellini wrote:
>>> On Thu, 14 Jul 2011, Stefan Bader wrote:
>>>> Before this a block device defined as hda1 in the configuration files
>>>> would be mapped to hda, as well as hda2.
>>>>
>>>
>>> Don't you mean xvda and xvda2?
>>>
>> Bah, yes, you are right. I had a "hda1" in a PVM guests definition and within
>> the guest it had become "xvda". Basically it seems that the current code would
>> map any minor number between 0-63 to 0.
> 
> That would be correct because hda1 is not allowed, the closest thing to
> a valid configuration would be hda and therefore xvda.
> 
I see. So sort of fixing up when there is an invalid HVM configuration.

> 
>>> Besides hda1 doesn't mean anything for an HVM guest, it is not an
>>> allowed disk configuration.
>>> It is also a bug in the toolstack that propagates such nonsense to
>>> xenstore so I would rather fix xend and/or libxenlight.
>>>
>> Which seems actually to be something that could be intentional for HVM guests.
>> As you say, "hdaX" does make no sense there... Unfortunately this is shared for
>> PVM and HVM. So my change may make sense with the first but not the latter... :(
> 
> I see. The source of the problem is ancient disk configuration lines in
> PV config files: like Ian wrote before, people should be using xvd* only
> in PV guests config file, rather than hd* or sd*...
> I think the best thing to do here would be to catch the error at the
> toolstack level.

In that case it was not even a real use-case. I was just trying to see what
happens. Though I assume if you _can_ do it, there _will_ be someone doing so...

Sounds like both cases would be candidates for the toolstack. But for the kernel
patch I made, there is no reason and it should be ignored. Breaking one case for
another is not that much of use.