[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :/

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: