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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 27 May 2010 10:51:25 -0700
Cc: "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:52:25 -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: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-2.fc12 Lightning/1.0b2pre Thunderbird/3.0.4
On 05/27/2010 07:49 AM, 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.

Thanks.  We should probably start a Documentation/xen/ and put this in
there as part of the patch.

> 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.

We could include 2 bytes of the HEAD changeset or something, with some
risk of collision.  Or just choose a constant and stick with it until
some interesting qualitative driver change makes it worthwhile bumping
the version.

I guess I can see some value in this info for recording in a log to do
some diagnostics, but the whole blacklist concept seems highly dubious
to me.  Some kind of feature negotiation makes a lot more sense to me...


Xen-devel mailing list

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