Re: [Xen-devel] Re: [PATCH 11/11] Unplug emulated disks and nics
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
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