This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 11/11] Unplug emulated disks and nics

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 11/11] Unplug emulated disks and nics
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 27 May 2010 18:25:25 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Don Dutile <ddutile@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 27 May 2010 10:23:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19454.34430.471499.222290@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1005241615300.25605@kaball-desktop> <1274725657-1149-11-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <4BFC3390.4060503@xxxxxxxx> <alpine.DEB.2.00.1005261325110.25605@kaball-desktop> <4BFD8BB0.90301@xxxxxxxx> <m2n.s.1OHcBK-0018DA@xxxxxxxxxxxxxxxxxxxxxx> <19454.34430.471499.222290@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 27 May 2010, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] Re: [PATCH 11/11] Unplug emulated 
> disks and nics"):
> > On Wed, 26 May 2010, Jeremy Fitzhardinge wrote:
> > > Wow, this interface is perverse.  It reuses the same IO port but changes
> > > function depending on the size of the IO?  Again, wow.
> >  
> > Yeah, before you ask, I didn't write it :)
> Yes, neither did I :-).  However, I did document it and now I also
> maintain the "product number" registry.  Did you find the interface
> spec ?  Enclosed below in case not.
> I hereby allocate you ("pvops PV-on-HVM Linux, upstream") product
> number 3.  Does the kernel have a way to distinguish between upstream
> and other versions ?  Eg, there's the kernel version name suffix
> thingy if I remember rightly.  Perhaps we should allocate a different
> number for "some pvops pv-on-hvm Linux with a nonempty kernel version
> name suffix".  Please advise.
> You are welcome to use whatever you like for the "build number".
> Perhaps the best thing would a two-byte encoding of the kernel version
> number if that is possible.  As the purpose is logging and
> blacklisting, it's not that critical although it's better to reuse the
> same number for excessively similar builds than to use a random scheme
> which might generate accidental clashes between unrelated versions.

It seems reasonable to me.
Jeremy, what do you think?

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>