kqemu inclusion in kernel

[Christopher Brown]

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

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Axel Thimm]

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.
-- 
Axel.Thimm at ATrpms.net

[drago01]

On 6/16/07, Dave Jones <davej(a)redhat.com&gt; 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.

[Chuck Ebbert]

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?

[Jarod Wilson]

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.

-- 
Jarod Wilson
jwilson(a)redhat.com

[drago01]

On 8/2/07, Chuck Ebbert <cebbert(a)redhat.com&gt; 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.

[Dave Jones]

On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote:
>  On 6/16/07, Dave Jones <davej(a)redhat.com&gt; 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

-- 
http://www.codemonkey.org.uk

[Paul Wouters]

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

[Rahul Sundaram]

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

[drago01]

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.

[Alan Cox]

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

[Rahul Sundaram]

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