-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:
On Saturday 2009-09-05 23:32, Greg KH wrote:
On Sat, Sep 05, 2009 at 09:59:34PM +0200, Jan Engelhardt wrote:
On Saturday 2009-09-05 21:51, Greg KH wrote:
Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch.
Anyway, what's the problem of having these drivers built into the kernel and not a module? That your kernel grows when doing that, and ipv6 itself already contributes like 230K. scsi_mod another 140K, just to name two. Even if you end up using them, it seems fancier having them as modules But it's slower to boot. And 99% of all systems that we ship load both of those modules.
Yes, for _these two_ I would agree. But the other "99%" of options changed - I do not. Basically because there are far fewer than 99% running all that specific hardware at the same time.
* CONFIG_ATA_PIIX, CONFIG_SATA_AHCI - tho my chip is PATA_SIS, or PATA_ALI/PATA_VIA, whichever comes around
* CONFIG_HID - tho periph is PS2 keyboard/mouse
* CONFIG_HWMON, CONFIG_I2C - for one desktop I always get bogus values with sensors(8), so I am counting it towards "not using hwmon/i2c"
* CONFIG_LEDS_CLASS - have not seen this on x86 at all
* CONFIG_LIB80211 - wireless is done by a dedicated device
* CONFIG_RTC_CLASS - only seen this on x86; and I wonder if anything on a desktop besides mplayer & co, and hwclock(8) uses the rtc.
* CONFIG_SOUND - well I dunno, I commonly keep servers without sound.
* CONFIG_USB_[EOU]HCI_HCD - I am guaranteed to not have at least one of those HCIs.
* CONFIG_USB_STORAGE - also something I may not be using
* CONFIG_X86_MSR, CONFIG_X86_CPUID - never ever used. Never seen it in lsmod, hence there seem to be no programs using it.
All reasons for me to not have them =y at all times.
And, by building them into the kernel, you actually save a bit of space, as the kernel can throw away the __init section, which it does not for kernel modules.
Why is that, what requires __init sections of modules?
It's actually the __exit sections that get dropped, since a statically linked driver can't be unloaded.
[N.B. Over the past year, the amount of modules loaded in a Linux system rose near the number of the modules loaded in a Solaris 11beta system.] Does it actually affect overall performace and is it faster than the increase in processor power and memory sizes?
I dunno, I just used it for a specific development task some year ago.
I've heard reports that a modular kernel wastes some memory because of some page alignment issues, but that seems like a trivially small amount of memory compared to the size of main memory. The other thing was the use of indirect calls, but I don't really buy that argument either. I share your opinion of wanting a modular kernel, but not your reasons. The drivers that are now statically linked are common enough to be on a significant majority of systems, waste little enough memory so as not to be a real concern, and are proven to decrease kernel initialization time substantially. If there was a one-size-fits-all image then we wouldn't need a modular kernel at all. Unfortunately, when we're targetting a fast boot time and don't have another solution, we're left with the static driver approach. I had been working on a "megamodule" implementation where the modules are linked against each other and then loaded as a blob without an initrd, but I haven't had time to persue it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqkah4ACgkQLPWxlyuTD7JyuACeMdJNBVSD6F1wFoEouhyawahA HIwAn2i6BZARhMzSAN7pLd3DIRvzP0IY =lGTj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org