| Message ID | 1305644154-22027-1-git-send-email-bernhard.kohl@nsn.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2011-05-17 16:55, Bernhard Kohl wrote: > kvm-kmod-2.6.38.6 does not compile on Fedora kernels >= 2.6.35.11. > > Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com> > --- > configure | 8 ++++++++ > external-module-compat-comm.h | 5 ++++- > 2 files changed, 12 insertions(+), 1 deletions(-) > > diff --git a/configure b/configure > index a40c39f..b91587c 100755 > --- a/configure > +++ b/configure > @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then > depmod_version=$kernel_version > fi > > +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 > +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then > + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" > +else > + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" > +fi > + Is there no define set by fedora kernels themselves? > rm -f include/asm include-compat/asm > mkdir -p include > ln -sf asm-"$karch" include/asm > @@ -175,4 +182,5 @@ EOF > > cat <<EOF > kvm-kmod-config.h > #define KERNEL_EXTRAVERSION $kernel_extraversion > +$config_fedora_kernel > EOF > diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h > index 6b6bddb..b7d9b25 100644 > --- a/external-module-compat-comm.h > +++ b/external-module-compat-comm.h > @@ -881,7 +881,10 @@ static inline u32 hash_32(u32 val, unsigned int bits) > #define __rcu > #endif > > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \ > + (!defined(CONFIG_FEDORA_KERNEL) || \ > + LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && KERNEL_EXTRAVERSION < 11 || \ > + LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) > #include <linux/vmalloc.h> > static inline void *vzalloc(unsigned long size) > { Is this intentionally or accidentally targeting Fedora 2.6.35.x only? Because the commit log may imply some 2.6.36-fc could carry it as well (if they exist). Thanks, Jan
> -----Original Message----- > From: ext Jan Kiszka [mailto:jan.kiszka@siemens.com] > Sent: Tuesday, May 17, 2011 5:27 PM > To: Kohl, Bernhard (NSN - DE/Munich) > Cc: kvm@vger.kernel.org > Subject: Re: [PATCH] Account for Fedora kernels with backported vzalloc > > On 2011-05-17 16:55, Bernhard Kohl wrote: > > kvm-kmod-2.6.38.6 does not compile on Fedora kernels >= 2.6.35.11. > > > > Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com> > > --- > > configure | 8 ++++++++ > > external-module-compat-comm.h | 5 ++++- > > 2 files changed, 12 insertions(+), 1 deletions(-) > > > > diff --git a/configure b/configure > > index a40c39f..b91587c 100755 > > --- a/configure > > +++ b/configure > > @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then > > depmod_version=$kernel_version > > fi > > > > +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 > > +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then > > + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" > > +else > > + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" > > +fi > > + > > Is there no define set by fedora kernels themselves? No, there is nothing in the include/generated/autoconf.h to identify a Fedora kernel. I assume this is the place where CONFIG_SUSE_KERNEL comes from. > > > rm -f include/asm include-compat/asm > > mkdir -p include > > ln -sf asm-"$karch" include/asm > > @@ -175,4 +182,5 @@ EOF > > > > cat <<EOF > kvm-kmod-config.h > > #define KERNEL_EXTRAVERSION $kernel_extraversion > > +$config_fedora_kernel > > EOF > > diff --git a/external-module-compat-comm.h b/external-module-compat- > comm.h > > index 6b6bddb..b7d9b25 100644 > > --- a/external-module-compat-comm.h > > +++ b/external-module-compat-comm.h > > @@ -881,7 +881,10 @@ static inline u32 hash_32(u32 val, unsigned int > bits) > > #define __rcu > > #endif > > > > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \ > > + (!defined(CONFIG_FEDORA_KERNEL) || \ > > + LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && > KERNEL_EXTRAVERSION < 11 || \ > > + LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) > > #include <linux/vmalloc.h> > > static inline void *vzalloc(unsigned long size) > > { > > Is this intentionally or accidentally targeting Fedora 2.6.35.x only? > Because the commit log may imply some 2.6.36-fc could carry it as well > (if they exist). I assume Fedora 14 will stay with kernel 2.6.35 and Fedora 15 starts with kernel 2.6.38 where the problem does not exist anyway. > > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2011-05-17 17:44, Kohl, Bernhard (NSN - DE/Munich) wrote: >> -----Original Message----- >> From: ext Jan Kiszka [mailto:jan.kiszka@siemens.com] >> Sent: Tuesday, May 17, 2011 5:27 PM >> To: Kohl, Bernhard (NSN - DE/Munich) >> Cc: kvm@vger.kernel.org >> Subject: Re: [PATCH] Account for Fedora kernels with backported > vzalloc >> >> On 2011-05-17 16:55, Bernhard Kohl wrote: >>> kvm-kmod-2.6.38.6 does not compile on Fedora kernels >= 2.6.35.11. >>> >>> Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com> >>> --- >>> configure | 8 ++++++++ >>> external-module-compat-comm.h | 5 ++++- >>> 2 files changed, 12 insertions(+), 1 deletions(-) >>> >>> diff --git a/configure b/configure >>> index a40c39f..b91587c 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then >>> depmod_version=$kernel_version >>> fi >>> >>> +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 >>> +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then >>> + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" >>> +else >>> + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" >>> +fi >>> + >> >> Is there no define set by fedora kernels themselves? > > No, there is nothing in the include/generated/autoconf.h > to identify a Fedora kernel. I assume this is the place > where CONFIG_SUSE_KERNEL comes from. > >> >>> rm -f include/asm include-compat/asm >>> mkdir -p include >>> ln -sf asm-"$karch" include/asm >>> @@ -175,4 +182,5 @@ EOF >>> >>> cat <<EOF > kvm-kmod-config.h >>> #define KERNEL_EXTRAVERSION $kernel_extraversion >>> +$config_fedora_kernel >>> EOF >>> diff --git a/external-module-compat-comm.h b/external-module-compat- >> comm.h >>> index 6b6bddb..b7d9b25 100644 >>> --- a/external-module-compat-comm.h >>> +++ b/external-module-compat-comm.h >>> @@ -881,7 +881,10 @@ static inline u32 hash_32(u32 val, unsigned int >> bits) >>> #define __rcu >>> #endif >>> >>> -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) >>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \ >>> + (!defined(CONFIG_FEDORA_KERNEL) || \ >>> + LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && >> KERNEL_EXTRAVERSION < 11 || \ >>> + LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) >>> #include <linux/vmalloc.h> >>> static inline void *vzalloc(unsigned long size) >>> { >> >> Is this intentionally or accidentally targeting Fedora 2.6.35.x only? >> Because the commit log may imply some 2.6.36-fc could carry it as well >> (if they exist). > > I assume Fedora 14 will stay with kernel 2.6.35 and Fedora 15 starts > with kernel 2.6.38 where the problem does not exist anyway. > Ok, fine. I've merge it, just with a small reformatting. Jan
On 05/17/2011 05:55 PM, Bernhard Kohl wrote: > kvm-kmod-2.6.38.6 does not compile on Fedora kernels>= 2.6.35.11. > index a40c39f..b91587c 100755 > --- a/configure > +++ b/configure > @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then > depmod_version=$kernel_version > fi > > +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 > +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then > + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" > +else > + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" > +fi > + Curious, why are you targetting Fedora kernels at all? They have a really short shelf life. I though kvm-kmod was for people using longer term kernels like enterprise distros or long lived embedded projects. For Fedora, you can use the native kvm, or install a rawhide kernel, or an upstream kernel with 'make localmodconfig'.
> -----Original Message----- > From: ext Avi Kivity [mailto:avi@redhat.com] > Sent: Tuesday, May 17, 2011 7:30 PM > To: Kohl, Bernhard (NSN - DE/Munich) > Cc: kvm@vger.kernel.org; jan.kiszka@siemens.com > Subject: Re: [PATCH] Account for Fedora kernels with backported vzalloc > > On 05/17/2011 05:55 PM, Bernhard Kohl wrote: > > kvm-kmod-2.6.38.6 does not compile on Fedora kernels>= 2.6.35.11. > > > index a40c39f..b91587c 100755 > > --- a/configure > > +++ b/configure > > @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then > > depmod_version=$kernel_version > > fi > > > > +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 > > +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then > > + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" > > +else > > + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" > > +fi > > + > > Curious, why are you targetting Fedora kernels at all? They have a > really short shelf life. I though kvm-kmod was for people using longer > term kernels like enterprise distros or long lived embedded projects. Here at NSN a couple of developers and testers are using Fedora + kvm-kmod to run some of our systems (with in-house developed OS) on KVM. This works also without kvm-kmod since kernel 2.6.35 (Fedora 14). The number of users (which are not Linux experts at all) is growing since over a year. Usually I prepare and test new versions of kvm-kmod and then it's easy for these guys to install it on their machines. So I always keep track to be up-to-date with the upstream kvm-kmod. The next candidate for kvm-kmod usage here might be your patch set "KVM in-guest performance monitoring", but I think we need a complete kernel for this as major parts of these patches are outside KVM. Some people here are eager for this new feature. Accidentally my colleague Thomas started investigating the performance counter topic 2 weeks ago. Nevertheless I hope that kvm-kmod will live for a while. It is quite useful for our work. > > For Fedora, you can use the native kvm, or install a rawhide kernel, or > an upstream kernel with 'make localmodconfig'. Thanks for this hint. I did not yet try localmodconfig. Bernhard > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/18/2011 12:11 PM, Kohl, Bernhard (NSN - DE/Munich) wrote: > > > > Curious, why are you targetting Fedora kernels at all? They have a > > really short shelf life. I though kvm-kmod was for people using > longer > > term kernels like enterprise distros or long lived embedded projects. > > Here at NSN a couple of developers and testers are using Fedora + > kvm-kmod > to run some of our systems (with in-house developed OS) on KVM. This > works > also without kvm-kmod since kernel 2.6.35 (Fedora 14). The number of > users > (which are not Linux experts at all) is growing since over a year. > Usually > I prepare and test new versions of kvm-kmod and then it's easy for these > guys to install it on their machines. So I always keep track to be > up-to-date with the upstream kvm-kmod. > > The next candidate for kvm-kmod usage here might be your patch set > "KVM in-guest performance monitoring", but I think we need a complete > kernel for this as major parts of these patches are outside KVM. Some > people here are eager for this new feature. Accidentally my colleague > Thomas started investigating the performance counter topic 2 weeks ago. > > Nevertheless I hope that kvm-kmod will live for a while. It is quite > useful for our work. Yes, I can see how it helps your workflow. I guess the only viable alternative would be to prepare a full kernel rpm, but that is a lot more work. Regarding the PMU, the patchset modifies the core perf_event code and exports some symbols. We might be able to work around these issues but this isn't certain.
diff --git a/configure b/configure index a40c39f..b91587c 100755 --- a/configure +++ b/configure @@ -153,6 +153,13 @@ if [ -n "$no_uname" -a "$want_module" ]; then depmod_version=$kernel_version fi +# Check if it is a Fedora kernel, e.g. 2.6.35.13-91.fc14.x86_64 +if echo "$kernel_version" | grep -qE '[0-9.-]+\.fc[0-9]+\..+'; then + config_fedora_kernel="#define CONFIG_FEDORA_KERNEL 1" +else + config_fedora_kernel="#undef CONFIG_FEDORA_KERNEL" +fi + rm -f include/asm include-compat/asm mkdir -p include ln -sf asm-"$karch" include/asm @@ -175,4 +182,5 @@ EOF cat <<EOF > kvm-kmod-config.h #define KERNEL_EXTRAVERSION $kernel_extraversion +$config_fedora_kernel EOF diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h index 6b6bddb..b7d9b25 100644 --- a/external-module-compat-comm.h +++ b/external-module-compat-comm.h @@ -881,7 +881,10 @@ static inline u32 hash_32(u32 val, unsigned int bits) #define __rcu #endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \ + (!defined(CONFIG_FEDORA_KERNEL) || \ + LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && KERNEL_EXTRAVERSION < 11 || \ + LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)) #include <linux/vmalloc.h> static inline void *vzalloc(unsigned long size) {
kvm-kmod-2.6.38.6 does not compile on Fedora kernels >= 2.6.35.11. Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com> --- configure | 8 ++++++++ external-module-compat-comm.h | 5 ++++- 2 files changed, 12 insertions(+), 1 deletions(-)