JJean Delvare wrote:
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.
I wanted you to see this part... so I reformatted it for you. That's the idea of being able to build in what you need for boot as a minimum, but building things you need to *run* (beyond initial boot), into a single, contiquous, disk-block that can be mounted via unionfs (or similar) over /lib/modules. Something similar could probably be done for commonly used bin-utils, but might be tricker. ---reformatted from original--- If you really have a set of drivers you think or know you will need for normal function (function *after* initial boot). Put them on a tar (or disk) 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.... Suse 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