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

From: Stefan Bader <stefan.bader@canonical.com>
To: John Haxby <john.haxby@oracle.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: Re: Question on "xen-blkfront: handle Xen	major	numbers other than XENVBD"
Date: Thu, 14 Jul 2011 15:26:57 +0200	[thread overview]
Message-ID: <4E1EEEA1.9050102@canonical.com> (raw)
In-Reply-To: <4E1DD501.7030503@oracle.com>

On 13.07.2011 19:25, John Haxby wrote:
> On 13/07/11 17:19, Stefan Bader wrote:
>>
>> So for HVM they would be called hda in the cfg but sda in the domU.
> 
> Something like this caused a lot of confusion for folks around here:
> they were expecting the _name_ used in the cfg to be the name in the
> guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear in a
> Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all called
> sdX nowadays.
> 
> As Stefan said, the name actually only tells you what sort of emulated
> controller the disk is attached to: hd for IDE, sd for SCSI and xvd for
> PV disks (no actual controller as such).    It might have been better to
> have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest OS
> decide how to map those to names, much like it does for real hardware.
> 

That seems to be the sad root of the story. If it wasn't for the fact that some
naming convention (related to some real kernel names) gets translated into
(emulated) physical connections and the fact that the xvd driver did lie to the
domU (by using a IDE or SCSI major and name), there would be no need to meddle
around it. The faking major,minor,name thing probably was required in the
beginning when there was no other thing than hd* and sd*...

I will post a few patches as replies to this email, one to turn off the offset
and two other things I believe are wrong. But please, better check whether I am
really right there.

For future resolve of this issue, my feeling would be that a naming scheme of
xvsd*, for emulated scsi and xvhd* for emulated ide and xvd* for devices likely
would mean some confusion. Still it sounds like, after a bit of education, the
concept of how names get translated between the cfg and the guest should be
simpler to grasp.
In theory the minor numbers could be even dynamically allocated, but I guess
minors of partitions should always be an offset of the base device and minors of
devices in the same namespace should also be in a way sorted. So maybe a range
of minor numbers reserved for the ide emulated, one for the scsi emulated and
the rest for devices defined as virtual ones sounds like a simple approach.
Anyway, that is just my loud thinking. And maybe not completely thought through.

One other way would be to stop allowing ide or scsi disk names for defining
disks of the virtual controller... Though that might be a bit radical after
allowing it for so long.

-Stefan

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