On Sun, 2006-10-22 at 18:02 +0200, Michiel de Bruijne wrote:
> On Sunday 22 October 2006 16:24, Chris Gianelloni wrote:
> > I've started maintaining the genkernel kernel configs pretty much
> > exclusively. I see no problem with iptables support being added. The
> > best would be if you attached a patch against the current configs, as it
> > would be easier on me, as I actually have to apply them to two places
> > (genkernel SVN, and releng kconfigs for 2007.0) for the next release.
> > The main change is that (for at least x86/amd64) we're trying to make
> > the default kernel, which is also used on the LiveCD, as generic as
> > possible and as feature filled as possible.
> That's good to read.
> Currently there are two kernel configs used for (2.4 and 2.6).
> Features/modules are added and removed with every kernel release. Or entire
> sections are moved to different parts in the kernel dependency hierarchy
> (e.g. netfilter/iptables). There is also the problem that some modules wont
> build in a specific kernel version but build/run fine in another version of
> the kernel.
> I think if we want genkernel/livecd as feature filled as possible we should
> extend the default configs to a x.y.z scheme. A new kernel version is
> released about four times a year so this shouldn't be to hard to maintain.
> I'm willing to do the work (creating patches and maintaining future kernel
> configs), but do you agree and are willing to apply it?
What would be best is if it looked for x.y.z first, then fell back to
x.y, in the case of us not being as fast with the config as the kernel
team with the kernel. ;]
Another thing to realize is that while I will apply new configs/patches,
I'm not planning on making a genkernel release for changes as minor as a
new config. What I would suggest is that we make the "2.4" and "2.6"
configs be equal to the latest config, with the x.y.z being preferred,
if it exists. That way, when a new kernel comes out, it will start out
using the last good config, until it gets updated with its own x.y.z
> The next thing on my annoyance list is I need to put too many items in
> modules.autoload.d that should be handled in init-scripts (e.g. acpid and
> cpufreqd), but I deal with those later.
Those should have bugs filed on their own. Truthfully, that stuff
should all be loaded by the kernel automatically when the service is
run. I don't have any ACPI/cpufreq stuff in my modules.autoload.d on
this laptop, and both work fine for me.
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee