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

Re: 1-second kernel

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.


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

Attachment: signature.asc
Description: OpenPGP digital signature

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