1 |
On Tue, 15 May 2007 12:33:22 +1200 |
2 |
Mark Kirkwood <markir@××××××××××××.nz> wrote: |
3 |
|
4 |
> Grant wrote: |
5 |
> > I've been puzzling a bit lately over the best way to manage my |
6 |
> > kernel. I've always tried to keep it as minimal as possible, and I |
7 |
> > only enable things as I need them. I also don't build modules from |
8 |
> > the kernel at all. |
9 |
> > |
10 |
> > Is there a better way to go? I'm starting to think it might be |
11 |
> > better to build every single module and let the system load them as |
12 |
> > it needs |
13 |
> |
14 |
> A friend of mine does this for his production servers: |
15 |
> |
16 |
> 1/ builds the known needed things into the kernel |
17 |
> 2/ disables loadable modules completely |
18 |
> |
19 |
> This is probably not suitable for some use cases...(new raid card |
20 |
> ...ooops... redo kernel), but if you are deploying to known hardware |
21 |
> it is ok. |
22 |
> |
23 |
> Cheers |
24 |
> |
25 |
> Mark |
26 |
But Why? What's the benefit? If the code isn't being used, it isn't |
27 |
going to slow down the kernel is it? And the size of the kernel is |
28 |
irrelevant in my opinion -- the kernel is far from the predominant |
29 |
memory consumer on even a slow system. I think it's more likely that |
30 |
you'll have a problem with your kernel configuration than your kernel |
31 |
performance, and modules are the only way to add kernel support without |
32 |
rebooting. Furthermore, kernel modules have their own benefits -- |
33 |
increased run-time configuration, for example (as opposed to a boot |
34 |
parameter). No, I agree with volker: |
35 |
|
36 |
>everything needed for booting: in kernel |
37 |
>everything needed all the time: in kernel |
38 |
>everything that needs a good kicking once in a while (usb, sound): |
39 |
>modules everything that needs parameters: modules |
40 |
>everything that is not needed all the time: module |
41 |
|
42 |
that way, you can also build modules on-the-fly to suit your needs and |
43 |
then compile them into the kernel, if desired, the next time you |
44 |
rebuild it. |
45 |
-- |
46 |
gentoo-user@g.o mailing list |