1-second kernel

[Mikkel L. Ellertson]

Tim wrote:
> On Sun, 2008-12-21 at 01:26 -0800, NiftyFedora Mitch wrote:
>> There are two places to pay critical attention to first:
>>
>>   A.  hardware initialization.
>>
>> For a system to boot all hardware has to be known in advance.
>> NO probes that time out for this and that...  SCSI timers are LONG...
>> No probe of USB this and that.
>>
>> To that end building a kernel with "your" devices built in it
>> can help. Exclude any driver that you do not have hardware for.....
> 
> It strikes me that that sort of thing ought to be the default action any
> time you install a kernel - auto customising to suit your hardware,
> particularly the non-changing aspects of it (on board chipsets, and
> things plugged into them, like internal hard drives).
> 
Unless you want to compile a new kernel every time you install an
update, you are kind of stuck the way it is now - a kernel with the
minimum built in, and modules loaded as the system boots. The initrd
is set up with the modules you need at boot time.

> Though I tend to favour the microkernel approach:  The kernel has the
> bare minimum needed, you load extras as needed.  One motherboard with
> the usual peripherals ought to only load a handful of modules, which
> should be less elephantine than a kernel carrying hundreds of them.
> 
Isn't this what we have. The exception is that the modules loaded
tend to be more the a handful because of the different layers - but
it means that more then one hardware driver can use the same
mid-level drivers. That way, you are not building the same same
mid-level code into several drivers that may be loaded at the same
time. (SCSI hardware module, usb_storage module, etc all talking to
the same SCSI module.)

> But it should be something like:  Customise my system now (when
> installing a kernel, or whenever deliberately invoked).  Subsequent
> bootups will probably bootup the same way, so they can use your
> preconfigurations, and don't need so much probing next time (find my
> boot drive now, boot from it, poke around for other removable external
> drives while booting, but don't delay booting while you look, since I've
> already set what's needed to boot).  You still have various rescue
> options to handle a system that fails to boot, so customising shouldn't
> lock you out.
> 
>>   B. Network timers.
>>
>> Network timers are much longer than we all expect... Ensure that
>> all name servers and network knowledge that can be "hardwired" is. No
>> DHCP no discovery of name servers.   Snoop the net (dumb hub, second
>> machine) and watch for timeouts and other traffic you do not expect.
> 
> This shouldn't really be a major bottleneck.  Your DHCP servers ought to
> be quickly responsive.  If they aren't, then that's something else that
> should be tackled.
> 
It depends on the DHCP server. Most home router/firewalls I have run
into tend to be a bit slow in responding...

> Wireless is a pain, though.  It takes time for that to get organized,
> and for some annoying reason, it takes longer to discover my wireless
> router than it does to find the neighbor's.
> 
I tend to configure the default SSID, so it only has to do a search
if it can not find my router. On the other hand, it is more work
when I am out and about and need to connect.

>> For example X11 takes a lot longer to start than I expect.. in part
>> because the window manager desktop has all sorts of live buttons and
>> widgets.
> 
> I find I sit there looking at GDM spinning its "wait a moment" indicator
> for far longer than it should do.  Here, the full X starts faster than
> GDM does.  I'm inclined to be suspicious about the superfluous feature
> that loads different pictures at different times of day.  The previous
> GDM, which didn't do that, was easily and conveniently reconfigurable,
> and didn't drag its heels.
> 
>> Clean up as much as you can without X11 i.e. login on a simple text
>> window... and use 'startx'...
> 
> If you have to log in, then start X manually, that's adding a delay.  So
> I don't see a real benefit there.
> 
> I had considered the notion of not using GDM (thanks to *its* holding up
> delay), starting in a text mode, and scripting something to start X as
> soon as I log in.  However, my experience has been that without GDM and
> Gnome (i.e. forgo one of them), and you find you're using a system
> without sound, or network, or auto mounting, or something else that's
> become dependent on one or the other of them.
> 
Try XDM - it doesn't have all the fancy "bells and whistles", but I
believe it is Gnome or KDE that takes care of sound, network, and
auto mounting.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20081221/b0aa6785/attachment-0001.sig>