Re: Q: status of kvm/ subdir in qemu-kvm tarball?

[Michael Tokarev <mjt@tls.msk.ru>]

23.02.2011 15:58, Jan Kiszka wrote:
> On 2011-02-23 12:42, Michael Tokarev wrote:
[]
>>> - kvm/include (latest kernel headers) *)
>>
>> This directory is always used (in configure)
>> unless -kerneldir is specified - who uses that
>> nowadays?  I dunno.
> 
> It may not be relevant to distros, provided they manage to keep their
> /usr/include/linux stuff in sync with the kernel they ship. But if you
> build qemu-kvm for a kernel (or kvm-kmod) that is more recent than your
> user space headers, this matters.

It only matters if you want to build qemu-kvm for OLDER
kernel without support of some features which are used by
the userspace you're building.  Provided 3 things:

 1) qemu-kvm userspace actually checks a feature before
    using it, and omits some code if the feature isn't
    available.  This means tons of #ifdefs, for a very
    little gain,

 2) kernel interface stays backward-compatible, and

 3) the headers included in qemu-kvm tarball actually
    matches the feature set in the userspace part.

Using more RECENT kernel headers to build userspace which
don't know about the more recent features anyway should
result in exactly the same binary, there's no reason to
use more recent headers.

>>> *) This should really be discussed upstream again: Carry private copy of
>>> kvm headers or rely on distro / kvm-kmod to provide required defines,
>>> types etc.? I'm more and more in favor of option 1.
>>
>> Yes indeed, having current defines of all the features
>> we actually support is a good idea.

That's the key: current features we actually support.
If kernel headers (be them embedded into the userspace
tarball or already installed on the system or headers
from just built kernel.org git tree) define less than
that, we either have tons of #ifdefs or just fail at
build/configure time telling "use more recent headers".
If kernel headers define more than we can understand,
we just ignore the rest...

> Would you like to propose this upstream in form of a patch series (that
> demonstrates its usefulness by dropping tones of #ifdefs)?

..unless I completely missed the point.  Which upstream
you're talking about -- qemu or kernel?  Where the #ifdefs
are, what they're for currently are they really needed?

Does qemu[-kvm] want to stay compatible with older kernels,
or kernel headers?  If yes, how old is old?

/mjt