[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: kqemu is now GPLv2
- From: "Andreas Bierfert" <andreas bierfert lowlatency de>
- To: fedora-advisory-board redhat com
- Subject: Re: kqemu is now GPLv2
- Date: Thu, 8 Feb 2007 11:20:31 +0100 (CET)
On Wed, February 7, 2007 5:23 pm, Dave Jones said:
> I'm tired of hearing this 'user experience' as an excuse for this.
> What about the user experience when they hit a bug in the kernel, and
> upgrade to a fixed version because their module doesn't work on the new
> What about the user experience when they file bugs and the Fedora kernel
> team refuses to look at them unless the module is removed (which they
> don't want to do?)
> What about the user experience when equivalent functionality (but
> is merged upstream ?
Well interesting to call the an excuse. It seems to me that always when
this discussion comes up we get to the point where people say this is an
excuse and try to finish the topic. I don't think it is an excuse and you
certainly don't have to tell me what could go wrong... I might not be a
kernel guru but I have been using RHL for a long time and worked with
external modules and I know what can go wrong. The thing is this: All the
questions you bring forward are valid! These are things that can go wrong.
The point is: A lot of systems don't work or don't quiet work because of
this. I just had one of these cases a couple of days ago where a wlan
driver was missing for a system... If we would have had a way to install
this out of tree module there would be one fedora box more out there. This
might not be a justification but look at the bigger pictures: Why block
all attempts to get something going? Why not think together about the ifs
and whats and define a clear process on how support and issues will be
> What about the user experience when someone hoses their initrd, and their
> system doesn't boot any more? This part of the boot process is _really_
> so some bogus module can break this unintentionally very easily.
> See the disaster from FC3 era when livna shipped a horked nvidia module.
> (That particular event cost me a lot of hours over ~2-3 months, chasing a
> that a) I couldn't fix and b) wasn't even caused by anything I did, so
> I'm somewhat jaded by external modules)
Yes I remember this and that is why I think we need to find a solution
which will avoid such issues and if it would be great to have someone like
you helping with the planning. Keeping this out of Fedora will just lead
to more situations like this because 3rd party repos will do it anyway.
Building something under the fedora hood will give us the chance to at
least push it in the direction we want.
> > If the modules are free in the fedora sense
> > why should we keep our users away from them?
> How about increased workload for the kernel team for one?
> I don't see anyone doing much to improve *my* user experience.
> > In a sense they then still will be second
> > class fedora 'packages'
> This doesn't work. People take the attitude "You shipped it, you support
> We had this fiasco with RHEL3 when we shipped a 'kernel-unsupported'
Well first of all the RHEL audience is somewhat different then the Fedora
audience and if it we find a clear definition for what we support on this
matter and what we don't and make clear that people understand it.
> Or it could be seen as a clear sign "Why do I need to bother getting it
> upstream, it's in the distros". Lack of integration is a bargaining chip.
> Imagine if we'd taken the same stance with Xen, maybe it'd be upstream by
Actually I was going to bring up the Xen part to rant about it ;). I think
things here can probably go into both directions. It is sad that Xen still
is not part of the upstream kernel but I guess with KVM in the upstream
tree the Xen team will have no other choice as to integrate it before
people get used to other approaches and forget about Xen. It will be
interesting to see if the Xen folks react now. If they do I would say it
could be the example we can bring up at other upstream modules and to
stick with the original topic: I guess the addition of KVM is one of the
reasons why kqemu is GPLed now. Anyway this does however not mean that we
should ignore the stuff that is out there.
> 'where possible' basically comes down to "magic up some extra engineers"
> because unless someone with kernel knowledge is explicitly affected by it,
> this won't happen. The number of cases that this _has_ happened, has
> been very low. The only one that jumps to mind is bcm43xx when dwmw2
> cared about it until it got upstream, fixing it where it broke for him,
> and interacting with the upstream.
It was dwmw2? :D Than thanks had one of these a while back an not
knowingly profited from that. What do you mean with "magic up some extra
engineers"? I think if someone puts up a kernel module for review he/she
should at least have some basic kernel knowledge and know what he/she is
doing. I am no expert but if you look at the kernel source and some
articles on the web fixing stuff or at least analyze and report it is in
most cases not that difficult. Remember we are talking about free modules
for which we have the source code.
> I'm not a big fan of 'magic'.
Hm, thats sad I always liked it ;)
Well just something that came up while going over my reply: We always talk
about why certain things should be merged upstream. To me this is in the
same line as questions like why do we patch the kernel. Not in a Xen
regard where is serves as an extension but we also strip stuff from it
that is there in the original kernel. People could ask why we do that as
well as that stuff is upstream. Sorry if that is to much of topic but not
everything that is upstream is something we ship as well...
Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB
andreas bierfert lowlatency de | http://lowlatency.de | signed/encrypted
phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred
[Date Prev][Date Next] [Thread Prev][Thread Next]