Jean Delvare wrote:
Hi all,
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... 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. 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. Things needed for my main linux system to boot: megaraid_sas, maybe pcieport. 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. 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. Doing that allows you to get booted to a point where you are responsive to the user. 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. Besides booting faster, 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. It's rare that people design reliability in these days because its harder to do well, safely and responsibly. So now days most people don't even try. Admittedly, when I develop for myself, I want it to fail early and often -- but when it goes out into customer hands, the last thing I want it to do is die over some reason it could have proceeded with. Obviously value judgements must be made -- if you are about to delete contents of an HD, and you can't verify it is the right disk... ok.. not safe. But if your media/share/home partititions can't come up but the OS can, someone might be able to log in as root and fix the problem (as their home dir wouldn't be on /home most likely). For the kernel on my machine -- not building it for a large group, I take liberties and build in things I am 70% likely to want at some point (my systems usually stay up a while.. though recently 21 days is a long while on my bloody-edge server ... on the conservative celeron -- it;s at 203 days of uptime...(the other server has hit numbers like that in the past when I wasn't sitting on the edge)...So while I have about 883 config options ='y' (many forced and that I don't see), I have 378 modules in as 'optional'... which is a rather large number considering I'm only building this kernel for 1 machine. So don't build in multimedia... or specialized scientific and sensor devices -- those can be loaded on demand later. Focus on what will get people to the point of being about to mount their core OS disks.). From the systemd performance pages, something is wrong with your design if you can't boot a minimal kernel from your hard disk to bootstrap the rest of the process, but that's from the systemd people, and we know how much you listen to them... Even video drivers? Can't most use VGA/EGA, VESA or serial?? Then load the real driver when the disk comes (or off a ram disk -- though a ram disk is a custom boot image which would be nice to steer away from). Anyway -- you did ask... and though I'd through in my opinion. I just recompiled my kernel with everything possible as modules except for basic getting the kernal up w/it's main disk -- shrunk it from 5M->4M, w/ force modules at 804 and loadable modules @ 470... so I'm totally into the same tendency as others of piling in things I know I will likely need. However, that's in my custom kernel, not a general one -- the generall one should be as lean as possible and load functionality as needed will speed up boot, and time to first login or desktop prompt. If you really have a set of drivers you think or know you will need for normal function. Put them on a tar image in /lib/modules, - decompress it to a tempfs, and overlay it with mergefs on top of the rest of the modules -- then all your common place modules are already in memory and were read off of disk in 1 read (the tar). Sometime after boot... maybe 20-30 minutes later, a job goes off and unmounts the ram disk -- freeing the memory -- with all of those common files still being on the hard disk that was under the ram disk.... You could get this setup screaming. The other thing to look into might require some kernel support... and that would be the idea of dynamically linking in pre-compiled modules into the kernel image. So any HW specific modules could be loaded and linked in prior to the kernel being stored on disk, but then your kernel ships with main modules, and optional -- with support for doing as is done now -- including hardware specific modules on your boot image (the ramdisk being part of the custom boot image), except that instead of living unlinked on a ram disk, the linking would be done once as they user builds a pre-linked kernel with those modules instead of putting them on a ram disk that needs to have them linked later. Having them linked once per. boot-image-change, vs. everytime the user boots would have to be a win in, at least, some time. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org