Hi Linda, Le Thursday 06 June 2013 à 06:04 -0700, Linda Walsh a écrit :
ACPI and thermal drivers: * button # dont' need this one on any system * processor * thermal_sys # nor this one
Block device drivers * cdrom * scsi_dh #none of these are needed on my systems -- * scsi_dh_alua # I might be able to use sg & sr_mod * scsi_dh_emc * scsi_dh_hp_sw * scsi_dh_rdac * sg * sr_mod
Graphics helper drivers * drm # Don't need any of these * drm_kms_helper * i2c_algo_bit
Filesystem drivers: * fuse # might use these * lockd # I use smb not nfs -- its considerable * sunrpc # faster
CPU drivers: * microcode # it fits my HW, but have never used it
Sound drivers: * pcspkr # sure * snd # none of the rest * snd_page_alloc * snd_pcm * snd_seq * snd_seq_device * snd_timer * soundcore --------------------------- Those are my 3 computers -- 1 desktop, 1 server, 1 ancient celeron...
Thanks for the feedback, this is appreciated. I'm surprised by a few things though, if you could clarify... You claim that none of your systems has the "button" driver loaded? The processor driver depends on thermal_sys, so you can't have the former without the latter. No optical drive in any of your systems? sg is loaded automatically so you certainly have it. If you don't use drm, does it mean you have binary graphics drivers everywhere? If you use a non-trivial desktop environment, you certainly use fuse even if you don't know. At least Gnome and Xfce use it. Microcode loading is automatic, so you certainly have used it already but you didn't know.
Seriously... what need to be forced on for built-in are deviced needed to **BOOT** enough so 1 hard disk is loaded and anything else can be picked up off the first hard disk.
This isn't the current strategy for openSUSE kernels, sorry. This has been discussed several times in the past. Long story sort: loading modules takes time and uses extra memory, so building everything as a module is not optimal from a performance point of view. As a consequence, it was decided that non hardware-specific drivers which are needed on a large majority of systems should be built into the kernel - unless we have a good reason not to.
Anything more than that and you are hurting everyone by forcing everyone to include things they will never use. It keeps the kernel lean -- and memory use and overhead lower.
It's not about building everything into the kernel. I have established a list of modules loaded on all my machines. Each individual case has been discussed with the interested people and the conclusion is that about only 4 modules in the initial list could be built-in. This isn't a huge number, so I don't think there is anything to be afraid of. Also note that a few weeks ago I have modularized about 20 drivers which were built-in so far, for specific hardware most people do not have, so it was really wasted boot time and memory for everybody. But nobody (including you) had been paying attention to that before I looked into it. So please don't come and complain now.
Things needed for my main linux system to boot: megaraid_sas, maybe pcieport.
Pcieport is built-in already, megaraid_sas is hardware-specific so it goes to your initrd.
to come up all the way -- bnx, e1000e ehci-pci, ioatdma ixbge lpc_ich & uhci_hcd but those aren't needed to start the boot process.. (at least those are HW items). There are many other I can load -- some with more effect / usefulness than others. But none needed to be built in...even though many I will use -- I don't build them in because they aren't needed immediately at boot.
So you're building your own kernel? If so, you don't care at all about the changes being discussed here.
Think of MS's boot process -- they have things that boot "at boot", things that boot as the system comes up, things that boot only as needed" and things that start about 20-30 seconds after the rest (not needed for but but likely needed for full system functionality.
To be honest, I don't know a thing about how MS does it, and to be even more honest (if this is possible), I don't really care.
Doing that allows you to get booted to a point where you are responsive to the user.
Ah ah, let me laugh, really. You get booted to a point where you see your desktop and a totally unresponsive system because ten dozen services, programs, applets, whatever, are trying to load in the background in a totally uncontrolled way. That is how I'd describe my limited Windows experience (mainly on systems I do not own.)
So I would SERIOUSLY reconsider building modules in just because you think many people will eventually use them during their session -- that's the wrong "bar" -- the only ones, IMO that should at front is the minimal amount of drivers needed to get most people started.
Most modules get loaded by udev or systemd before the desktop environment is loaded. So built-in or modular make absolutely no different in that respect. Only a few kernel drivers can really be loaded on-demand, and these are obviously not candidates to being built-in.
Besides booting faster,
Experiments have shown this is exactly the other way around. Otherwise I wouldn't be doing what I'm doing...
it has the added advantage of few drivers loading will give a higher boot reliability. Too many times I have things that didn't need to come up at boot for me to have been able to get to the machine (and fix any outstanding problems), but the trend now is toward *not trying* and rolling over dead at the slightest hairs output place. VS. a fault tolerant machine that comes up in spite of errors in spme state that it can be remotely used to repair itself and come up to full function.
This is a completely different discussion. This is the point at which I stopped reading you, because really, if you want to send long long messages like that, you first should ensure they are properly formatted so that just reading them is not such a burden. Thanks nevertheless, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org