1 |
Well, all mileage may vary. |
2 |
|
3 |
Personally, I prefer to not have things loaded into the kernel when |
4 |
I'm not using them. It's not really a performance or a memory saving |
5 |
thing, but more of an OCD thing. I'm sure that, in the grand scheme |
6 |
of things, the little time/power/whatever I save by keeping them out |
7 |
of the kernel is far outweighed by the amount of time it takes to type |
8 |
"modprobe x" when i remember I need to load the thing. Afterall, my |
9 |
time at the command prompt is significantly more valuable than a few |
10 |
extra cycles, or an extra 70-500K memory footprint. |
11 |
|
12 |
The thing is, it really depends on how clean you keep your kernel |
13 |
config. If you seriously go through the kernel config an make sure |
14 |
that you only select the things which are appropriate for your system, |
15 |
then you're fine. I've known people who just have almost everything |
16 |
built as a module, and let kernel autoloading take care of figuring |
17 |
out which one they need for their system (yes, terribly stupid and |
18 |
inelegant, but it does solve the problem when you don't know how else |
19 |
to do it). Also, compiling a whole tree of modules can be a simple |
20 |
way of figuring out exactly which set of code corresponds to your |
21 |
chipset, but that is not relevant to the current discussion. |
22 |
|
23 |
Basically, I'd say that if it doesn't matter how the thing is loaded |
24 |
into the kernel (I.E., no outside code relies on it being a module), |
25 |
and if it's going to be loaded more than some threshold percentage of |
26 |
time, just build it in. Unless you are facing some weird constraints, |
27 |
anything resembling modern hardware can handle the slightly larger |
28 |
kernel, and if you are facing those constraints, you probably already |
29 |
know what you're doing much better than I'll ever be able to say. |
30 |
|
31 |
As a side question for the list, when you load a module, you can pass |
32 |
module options to it (at least, last I checked, this could be done to |
33 |
specify things like the name of the interface on an internet driver, |
34 |
debugging level, etc...). When you build something into the kernel, |
35 |
is there an easy way to pass such options off to it? boot time |
36 |
options? anyone know? |
37 |
|
38 |
--Mike |
39 |
|
40 |
On 6/12/06, Steven Susbauer <stupendoussteve@×××××.com> wrote: |
41 |
> |
42 |
> |
43 |
> On Mon, 12 Jun 2006, Anthony E. Caudel wrote: |
44 |
> |
45 |
> > I was wondering what gentoo-users think and practice about kernel |
46 |
> > modules. Do most compile them in the kernel or load them at boot-up. |
47 |
> > |
48 |
> > Note that I'm _NOT_ talking about those modules that have to be compiled |
49 |
> > in such as for your filesystem. This is about the other ones. |
50 |
> > |
51 |
> > I generally like to load them at boot-up. One reason is that I have |
52 |
> > heard that for suspend or hibernate to work, some modules have to be |
53 |
> > unloaded. |
54 |
> > |
55 |
> > On the other hand, compiling them in results in faster boot times. |
56 |
> > |
57 |
> > So, what do gentoo-users think? |
58 |
> > |
59 |
> > Tony |
60 |
> > |
61 |
> |
62 |
> |
63 |
> I have never used any modules that I didn't have to. At this point, I use |
64 |
> none. They are all compiled into the kernel, because I don't have a point |
65 |
> to unloading or loading. The only point for modules in any of my |
66 |
> experience is if you're often changing hardware (possibly a laptop with a |
67 |
> base station... or something?) |
68 |
> -- |
69 |
> gentoo-user@g.o mailing list |
70 |
> |
71 |
> |
72 |
-- |
73 |
gentoo-user@g.o mailing list |