Re: USB disk shows up late at boot
On Mon, 21 Dec 2009 20:50:15 -0600
Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Celejar put forth on 12/21/2009 8:22 PM:
>
> > 1) Faster booting, since irrelevant drivers aren't loaded and won't
> > spend time probing.
>
> Correct. And not just drivers. Prebuilt kernels usually include netfilter
> support (for iptables), which increases the size of the kernel substantially,
> along with mdraid support, and some other capabilities most desktop users don't
> need. Using a custom kernel allows you to eliminate the need for an initrd,
I run desktops / laptops, and I always build netfilter - I run
shorewall on all my boxes.
> speeds up the boot process by compiling all the drivers your hardware needs
> directly into the kernel, and cuts down the kernel's memory footprint. On
Hm, I tend to build everything that I possibly can (that I'm building
at all, that I plan to actually use) as modules. Perhaps I should try
building them into the kernel to see if there's a performance gain, but
one reason that I like modules is that it makes for easy resetting of a
driver - 'modprobe -r somemodule && modprobe somemodule'. Is there
generally a way to do this with built-in modules?
> current systems with multiple gigs of ram and large CPU L2/L3 caches,
> admittedly, the size of the kernel isn't a big issue for most desktop and server
> class systems these days. It most certainly is critical for embedded
> applications, where processors have relatively low performance, with tiny
> caches, and small system memories.
>
> > 2) Security - one of these null pointer dereferences that they keep
> > discovering can't hurt you if it's in code that hasn't been included.
>
> This is a valid point, though others would argue the opposite, that pre compiled
> kernels lacking modules can't easily have the driver code updated with a
> security fix, without compiling a new kernel. I personally will take my chances
> with my precompiled kernel.
I'm not sure that I understand this - how is it easier to provide a
security fix for a standard kernel than for a custom built one? In
both cases, one needs to obtain fixed code, build it, and replace the
bad code with the good. [I'm not arguing with you, just expressing my
confusion.] ...
> > 4) Flexibility and control
>
> Yes and no WRT flexibility. Yes because you an choose exactly what does and
> does not go into your kernel. No, because once it's built, if you want to add a
> new hardware device later, you might have to build a new kernel. With the
> modular prebuilt kernels, you can plug in just about anything and it'll likely
> be recognized. Then again, there's nothing keeping one from building his/her
> own kernel and including drivers in anticipation of future needs. The downside
> to this is kernel bloat for hardware you're not using "right now". I obviously
> agree that you have more control doing your own kernel.
Agreed, and I get bitten by this all the time. Worse, often I disable
some feature that I actually need, and then spend much time and
aggravation figuring out why something is suddenly broken ... Well, I
guess that's part of the valuable learning process that we discussed
earlier :/
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: