From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Don Dutile <ddutile@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH 11/11] Unplug emulated disks and nics
Date: Thu, 27 May 2010 10:51:25 -0700 [thread overview]
Message-ID: <4BFEB11D.9080805@goop.org> (raw)
In-Reply-To: <19454.34430.471499.222290@mariner.uk.xensource.com>
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...
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Don Dutile <ddutile@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: Re: [PATCH 11/11] Unplug emulated disks and nics
Date: Thu, 27 May 2010 10:51:25 -0700 [thread overview]
Message-ID: <4BFEB11D.9080805@goop.org> (raw)
In-Reply-To: <19454.34430.471499.222290@mariner.uk.xensource.com>
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...
J
next prev parent reply other threads:[~2010-05-27 17:51 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 18:25 [PATCH 0 of 12] PV on HVM Xen Stefano Stabellini
2010-05-24 18:25 ` Stefano Stabellini
2010-05-24 18:27 ` [PATCH 01/11] Add support for hvm_op Stefano Stabellini
2010-05-24 18:27 ` [PATCH 02/11] early PV on HVM Stefano Stabellini
2010-05-24 18:27 ` [PATCH 03/11] evtchn delivery " Stefano Stabellini
2010-05-24 18:27 ` [PATCH 04/11] Fix find_unbound_irq in presence of ioapic irqs Stefano Stabellini
2010-05-26 18:26 ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-05-27 14:49 ` Stefano Stabellini
2010-05-27 15:36 ` Konrad Rzeszutek Wilk
2010-05-27 15:36 ` Konrad Rzeszutek Wilk
2010-05-24 18:27 ` [PATCH 05/11] Xen PCI platform device driver Stefano Stabellini
2010-05-28 8:55 ` [Xen-devel] " Zhigang Wang
2010-05-28 14:18 ` Stefano Stabellini
2010-05-28 14:18 ` Stefano Stabellini
2010-05-24 18:27 ` [PATCH 06/11] Add suspend\resume support for PV on HVM guests Stefano Stabellini
2010-05-25 20:20 ` Jeremy Fitzhardinge
2010-05-25 20:20 ` Jeremy Fitzhardinge
2010-05-24 18:27 ` [PATCH 07/11] Allow xen platform pci device to be compiled as a module Stefano Stabellini
2010-05-24 18:27 ` [PATCH 08/11] Fix possible NULL pointer dereference in print_IO_APIC Stefano Stabellini
2010-05-24 18:27 ` [PATCH 09/11] __setup_vector_irq: handle NULL chip_data Stefano Stabellini
2010-05-24 18:27 ` [PATCH 10/11] Support VIRQ_TIMER and pvclock on HVM Stefano Stabellini
2010-05-25 20:24 ` Jeremy Fitzhardinge
2010-05-25 20:24 ` Jeremy Fitzhardinge
2010-05-26 13:08 ` Stefano Stabellini
2010-05-24 18:27 ` [PATCH 11/11] Unplug emulated disks and nics Stefano Stabellini
2010-05-25 20:31 ` Jeremy Fitzhardinge
2010-05-26 12:27 ` Stefano Stabellini
2010-05-26 20:59 ` Jeremy Fitzhardinge
2010-05-27 12:29 ` Stefano Stabellini
2010-05-27 12:29 ` Stefano Stabellini
[not found] ` <m2n.s.1OHcBK-0018DA@chiark.greenend.org.uk>
2010-05-27 14:49 ` [Xen-devel] " Ian Jackson
2010-05-27 14:49 ` Ian Jackson
2010-05-27 17:25 ` [Xen-devel] " Stefano Stabellini
2010-05-27 17:51 ` Jeremy Fitzhardinge [this message]
2010-05-27 17:51 ` Jeremy Fitzhardinge
2010-05-27 18:10 ` [Xen-devel] " Stefano Stabellini
2010-05-27 18:10 ` Stefano Stabellini
2010-05-24 18:29 ` [PATCH 0 of 12] PV on HVM Xen Stefano Stabellini
2010-05-24 18:30 ` Boris Derzhavets
2010-05-24 19:06 ` [Xen-devel] " Stefano Stabellini
2010-05-25 6:14 ` Boris Derzhavets
2010-05-25 9:55 ` [Xen-devel] " Stefano Stabellini
2010-05-25 11:15 ` Boris Derzhavets
2010-05-24 18:36 ` Boris Derzhavets
2010-05-28 10:25 ` Boris Derzhavets
2010-05-28 10:45 ` Pasi Kärkkäinen
2010-05-28 11:06 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BFEB11D.9080805@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Jackson@eu.citrix.com \
--cc=ddutile@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.