Hi folks,
I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel).
Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa.
Regards Chris
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
Dave
On 6/16/07, Dave Jones davej@redhat.com wrote:
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first
thing
I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It
was
GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
On 08/02/2007 02:20 PM, dragoran wrote:
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't?
Chuck Ebbert wrote:
On 08/02/2007 02:20 PM, dragoran wrote:
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't?
Acceleration of non-hardware-virt guests.
On 8/2/07, Chuck Ebbert cebbert@redhat.com wrote:
On 08/02/2007 02:20 PM, dragoran wrote:
well but kqemu seems not to break that often I just recompile it after
each
kernel release and it just works. the code might be big but it does not depend on (fast) changing
interfaces.
Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't?
when your cpu does not support HVM kvm is useless ... kqemu does not use hvm for acceleration so it works on this hw too.
On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote:
On 6/16/07, Dave Jones davej@redhat.com wrote:
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
I've started playing around with virtualization at work and the first
thing
I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It
was
GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline.
not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity.
If not then can it be backported for Fedora kernels.
It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest.
well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces.
I'm really against merging more 'not upstream' things. We make a big deal about how close to upstream we are, and frankly in the last year or so, we've _sucked_ at keeping that statement true. Whilst some stuff is likely to end up in upstream at some point (utrace for eg), other stuff is perpetual baggage that is a pita when it comes to rebasing. Each release, we're getting closer though, as more and more old stuff gets thrown away. For eg, for F7, no-one cared enough about tux to really keep it maintained. Result - gone. Xen became such a hindrance it ended up having to go to its own package. The wireless stuff seems to be a sliding patchset, where the stuff it contains ends up upstream, but at the same time, a new batch of not yet upstream stuff arrives. I'm hoping eventually that too will settle down, but adding a driver here and a driver there is a path that I'd really rather we didn't travel due to the ongoing maintainence headache that it involves.
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Dave
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Paul
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
Rahul
Rahul Sundaram wrote:
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
On Fri, Aug 03, 2007 at 03:02:37PM +0200, dragoran wrote:
listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
Simple observation: kqemu has not been discussed on the kernel list. This is a public list so not a single person since the start of 2007 and maybe before has raised it. That seems to make it less of a priority to the world than some ancient 8bit ISA controller cards
dragoran wrote:
Rahul Sundaram wrote:
Paul Wouters wrote:
On Thu, 2 Aug 2007, Dave Jones wrote:
A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there.
Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all.
Who even submitted these patches upstream to start engaging in a discussion?
in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this.
So all the harping on about whether Red Hat developers are involved upstream or not, kernel politics etc is irrelevant. Red Hat kernel developers wouldn't prefer discussing patches to the kernel here either.
If anyone is really interested in getting Kqemu in the Fedora, encourage the Kqemu developer to submit his patches to LKML instead of focusing on getting the Fedora kernel maintainers to patch the kernel.
Rahul
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote:
Hi folks,
I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods
kmods? Heaven forbid, no. ;)
it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel).
No offense taken. Last summer I tried to get the kmdl mechanism into Fedora proper but the usual suspects didn't let it happen. If we had nice working kmdls in Fedora it would be a matter of a day to get it in there.
But replicating a kmod pair out of the kmdl would just make it more difficult to "bolt on another repo".
I also know that the main kernel packagers don't really like the idea of any added kernel modules outside the kernel (partly for good reasons, they can't really make a proper QA/bug diagnosis if they don't know how many and which kmdls you have installed in addition to what they packaged into the kernel rpm, although until now it was never really a significant issue in practice).
Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa.
We're both everywhere. Trimming to the kernel list.
kernel@lists.fedoraproject.org
-
Alan Cox -
Axel Thimm -
Christopher Brown -
Chuck Ebbert -
Dave Jones -
drago01 -
Jarod Wilson -
Paul Wouters -
Rahul Sundaram