Re: kqemu inclusion in kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote:
 > On 6/16/07, Dave Jones <davej@xxxxxxxxxx> 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

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux