From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH 5/6] libxl: introduce libxl__alloc_vdev Date: Tue, 3 Apr 2012 14:15:57 +0100 Message-ID: References: <1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com> <20337.63133.683848.208682@mariner.uk.xensource.com> <20341.49280.31751.307404@mariner.uk.xensource.com> <20345.53429.51575.373166@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20345.53429.51575.373166@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, 2 Apr 2012, Ian Jackson wrote: > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev"): > > On Fri, 30 Mar 2012, Ian Jackson wrote: > > > Since we need to be able to allocate some vbds dynamically, the right > > > approach is to decree that some portion of the dom0 vbd space is > > > reserved for static allocations by the administrator, and that the > > > remainder is for dynamic allocations by software which picks a free > > > vbd. Naturally the static space should come first. > > > > When you hotplug a new disk on your system, for example a new USB disk > > to your native Linux box, usually Linux chooses the device name for > > you. I don't see why this should be any different. > > It is different because Xen vbds do in practice appear in dom0 with a > stable name. So this is something that people have reasonably come to > rely on. > > > The admin is going to call instead: > > xl block-attach 0 > > and then checkout dmesg. > > This is hardly automatable. Doing the same thing with udev rules is > quite hard work. I don't feel that strongly about this, but given that the naming scheme used in the guest is actually arbitrary at the moment (as in not document or well defined anywhere), I would start the dynamic space before the 26th device: I have the feeling that after "xvdz" the behavior is going to be even less "defined". I suggest "xvdm" as a starting point. > > > I don't think that is true. On each individual guest platform, the > > > relationship between vbd numbers (the actual interface between > > > frontend and backend), and whatever that guest has for device names, > > > needs to be statically defined. > > > > I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never > > specified what names the guest kernel is allowed to choose for a > > particular vbd encoding. See the following quote: > > > > "The Xen interface does not specify what name a device should have in the > > guest (nor what major/minor device number it should have in the guest, > > if the guest has such a concept)." > > This refers to the promises made by each side of the Xen VBD interface > to the corresponding other side. The host's environment is not > allowed to assume things about the guest's device naming conventions. > > However, that does not mean that the guest should not document its > naming conventions. Perhaps this needs to be clarified in the > document. Right, but unless I am missing something there isn't such a thing at the moment, at least in Linux. I'll try to come up with a linux devid to vdev function true to the original.