From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD" Date: Wed, 13 Jul 2011 18:03:15 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <4E1DC57D.3010002@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: "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, 13 Jul 2011, Stefan Bader wrote: > 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. It is possible to have hd* and xvd* present at the same time in the config file: it means that you want emulated IDE disks and some PV only disks (no corresponding emulated interface). I was only saying that it doesn't make sense to write sda in an HVM config file because we don't currently emulate SCSI or SATA, but in the future it will become possible. > 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... Yeah, I am not opposed to it, it is just a matter of changing EMULATED_SD_DISK_MINOR_OFFSET and EMULATED_SD_DISK_NAME_OFFSET.