8:56 p.m.
Good evening :)
I run a firewall server for my school using Fedora. I currently patch in
a l7-filter patch (http://l7-filter.sourceforge.net/) in by hand because
we need to block some stuff based on the network data (i.e. not port or
protocol). I think it would be a great benefit to other users to have
such kernels available from a repository rather than patching them by
hand since l7-filter is also of great help as far as traffic shaping is
concerned. Especially as the l7-patch only requires one extra kernel
config option means that the generic Fedora config could stay
essentially the same.
I already shared my idea of providing custom patched kernels in
RPMFusion with Thorsten and he said that it would be an interesting
thing to do. But I also, of course, want to know the opinion of the
other contributors as this is a decision that should be made by not only
a few people.
Do you think this is a thing we could/should do? How does our build
infrastructure like it to regularly be jammed by kernel builds? Or does
this raise your concern in any other way?
I'm really eager to hear your comments.
Felix
1:17 a.m.
Felix Kaechele wrote:
I already shared my idea of providing custom patched kernels in
RPMFusion with Thorsten and he said that it would be an interesting
thing to do. But I also, of course, want to know the opinion of the
other contributors as this is a decision that should be made by not only
a few people.
Some concerns I have:
* Some people will want to have more than one patch, so having separate
kernels with the separate patches won't make everyone happy, but patches
are often incompatible (or at least apparently incompatible, needing manual
merging), so making a single kernel with all the patches isn't going to
scale.
* What about kmods? Building those for all the patched kernels will quickly
lead to an explosion of kmods.
Kevin Kofler
4:09 a.m.
On Jan 08, 2009, at 20:17, Kevin Kofler wrote:
Felix Kaechele wrote:
> I already shared my idea of providing custom patched kernels in
> RPMFusion with Thorsten and he said that it would be an interesting
> thing to do. But I also, of course, want to know the opinion of the
> other contributors as this is a decision that should be made by not
> only
> a few people.
Some concerns I have:
* Some people will want to have more than one patch, so having
separate
kernels with the separate patches won't make everyone happy, but
patches
are often incompatible (or at least apparently incompatible, needing
manual
merging), so making a single kernel with all the patches isn't going
to
scale.
* What about kmods? Building those for all the patched kernels will
quickly
lead to an explosion of kmods.
I share Kevin's concerns and have some additional stuff to add:
-Where are bugs going to be filed for anything kernel-ish that goes
wrong when people are running these kernels? Good chance they'll get
filed at bugzilla.redhat.com. Trust me, Fedora kernel devs already
have their hands full trying to weed through the bugs filed against
the kernels they've built. Bugs for someone else's kernel: DO NOT WANT.
-Why are these patches not kmod-able or upstream-able? If they aren't
either of those, then why would we even want to touch them?
-If we *do* do a custom patched kernel, I think we should do a kernel-
rt before anything else... :)
--
Jarod Wilson
jarod(a)wilsonet.com
9:22 a.m.
Felix Kaechele wrote:
I already shared my idea of providing custom patched kernels in
RPMFusion with Thorsten and he said that it would be an interesting
thing to do. But I also, of course, want to know the opinion of the
other contributors as this is a decision that should be made by not only
a few people.
Strong -1, one kernel is more then enough. If you've got good reasons to want
extra patches in to the kernel you should take it up with Dave Jones (the
Fedora kernel maintainer), as long as there is a good chance of them getting
upstream eventually, he usually is quite willing to carry patches as long as
someone else does the work.
If they are not going upstream, it would be better to spend energy there
(getting it upstream) then building custom kernels IMHO.
The only exception I can see is having a kernel with the realtime patch set.
And maybe there are one or two more invasive patchsets which would be
interesting to have as alternate kernel, but in general for smaller patches I
say no!
Regards,
Hans
10:03 a.m.
On 09.01.2009 10:22, Hans de Goede wrote:
Felix Kaechele wrote:
> I already shared my idea of providing custom patched kernels in
> RPMFusion with Thorsten and he said that it would be an interesting
> thing to do.
I feel a bit misquoted ;-) To be precise, this is what I said on IRC:
"I'm not sure if that's a good idea or not, but yes, I have thought
about that as well; best to ask on the list"
> But I also, of course, want to know the opinion of the
> other contributors as this is a decision that should be made by not only
> a few people.
Strong -1,
For me it gets a -0.5; but there might be cases where I maybe might give
it a 0 or a +1
one kernel is more then enough.
Yes, one kernel should be the goal. The PAE, smp and (in the past) xen
kernels already created a lot of confusion and make kmod handling for
users and developers harder.
If you've got good reasons to want
extra patches in to the kernel you should take it up with Dave Jones (the
Fedora kernel maintainer), as long as there is a good chance of them getting
upstream eventually, he usually is quite willing to carry patches as long as
someone else does the work.
+1
If they are not going upstream, it would be better to spend energy
there
(getting it upstream) then building custom kernels IMHO.
I tend to agree, but OTOH:
The only exception I can see is having a kernel with the realtime
patch set.
Agreed. But this kind of opens the door to other kernel sets as well :-/
And maybe there are one or two more invasive patchsets which would be
interesting to have as alternate kernel,
OpenVZ anyone for example? They are working with upstream (just like the
rt guys), but that takes a while, thus I'd tend to say it might be
acceptable as well if a rt kernel is.
but in general for smaller patches I say no!
Agreed. But it's hard to draw the line.
Maybe it's really time to start a experimental repo for things like
that. People are interested in crazy things -- we don't stop them by
saying no. They instead will simply do it somewhere else, which it tend
to say is not ideal either.
Or, IOW: Not sure, but even getting the crazy/stupid things into some
special place within the RPM Fusion project might be better for everyone
involved.
CU
knurd
12:52 p.m.
Felix Kaechele wrote:
Good evening :)
I run a firewall server for my school using Fedora. I currently patch in
a l7-filter patch (http://l7-filter.sourceforge.net/) in by hand because
we need to block some stuff based on the network data (i.e. not port or
protocol).
[...]
As far as I know l7-filter provides also an userspace solution for this.
Felix
--
Marek Mahut https://fedoraproject.org/wiki/SIGs/Astronomy/
Fedora Project http://www.jamendo.com/
1:45 p.m.
As far as I know l7-filter provides also an userspace solution for this.
Marek Mahut https://fedoraproject.org/wiki/SIGs/Astronomy/
from http://l7-filter.sourceforge.net/HOWTO-userspace
For Linux 2.6.20 and newer, Netfilter has new "Layer 3 Independent
Connection tracking" which l7-filter is not yet compatible with (mostly due
to lack of library support from libnetfilter_conntrack). While the old
layer 3 dependent connection tracking is still available, it is not
selected by default, so you **will probably need to recompile your kernel**
with it.
EOQ
why it can't be made as a kmod ?
5586
days inactive
5588
days old
rpmfusion-developers@lists.rpmfusion.org
6 comments
7 participants
participants (7)
-
Felix Kaechele -
Hans de Goede -
Jarod Wilson -
Kevin Kofler -
Marek Mahut -
Thorsten Leemhuis -
مؤيد السعدي