From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD" Date: Thu, 14 Jul 2011 15:14:48 +0100 Message-ID: <1310652889.634.541.camel@zakaz.uk.xensource.com> References: <4E1D6A48.1020801@canonical.com> <1310554481.634.381.camel@zakaz.uk.xensource.com> <4E1D8C1C.1040200@canonical.com> <4E1DA16E.6020302@canonical.com> <4E1DC57D.3010002@canonical.com> <4E1DD501.7030503@oracle.com> <4E1EEEA1.9050102@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E1EEEA1.9050102@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan Bader Cc: John Haxby , "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Thu, 2011-07-14 at 14:26 +0100, Stefan Bader wrote: > 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. Have you seen docs/misc/vbd-interface.txt? It clarifies (or at least tries to) some of this stuff. If there are things which could be improved (esp. from the end-user perspective) there then patches would be gratefully accepted. > 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. Personally I think it would be great but I don't think its feasible. I've been trying to encourage the use of xvd* for years :-/. Ian. > > -Stefan > > > jch > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel