Andrey Borzenkov wrote:
On Fri, Jun 28, 2013 at 1:54 PM, Linda Walsh <suse@tlinx.org> wrote:
How would configuring a kernel via a similar script be any different than the current situation
By forcing full development environment on every system? By making it much harder for support to analyze kernel crash dump from customer system?
Perhaps, but not necessarily. I don't know how if linux has advanced to the features of 10-20 year old unix systems or not, but dedicated kernel module linker should be able to take pre-built modules and link them into an image that could be booted from instead of copying them into a separate file-image that the kernel uses it's own internal binary images to access indirectly. It would seem that, at **worst**, a simplistic 'non-filesystem' that marks where modules start and have been appended to a kernel would be at least as "doable" as what the kernel currently does. After all, it is reading in a contiguous set of blocks, to some place in memory, then it goes through *comparatively* complicated file-access drivers to access that memory "like a real disk". However, don't forget -- it's not a real disk you've simply gained complexity and the need to read it from a separate place on disk rather than reading the kernel and the modules in 1 large read. Those modules could be compiled at a factory if you wanted to distribute a fixed binary -- but kernel people are used to analyzing kernel crash dumps all the time and don't used 'fixed-at-a-factory' crash dump images. I've never had a vendor yet who wanted a kernel crash dump from a production kernel -- they always wanted me to reproduce the problem with soem 'debug' kernel that has the symbols turned on. In that "most primitive case", your development tools involve "cat" or "dd". Now, a step above that would be some type of real linker that would cut the need for some relocation steps at boot time maybe something like "prelink" -- again, not a complicated development tool -- and again, a set of modules to prelink with -- just like you can prelink binaries on your system with a factory-glibc, can be distributed. Again... all binary-from-factory images if that is a requirement. Beyond that you can have those users who really want to rebuild their kernel (that is why we provide "src" rpms, no? They can turn on full debugging and optimize it for their HW. It might not be a debug kernel, but it might give them better performance than a generic. All of those are benefits of going with booting from a single kernel image and not going through the overhead of emulating a file system. Unix vendors had tools that allowed such prelinking and optimization for the many customers who wanted to get the most from their hardware -- 20 years ago. It doesn't seem like linux should be "incapable" of doing the same or better. Instead we are copying an oversized floppy image into ram to boot from and going through virtual fakery to access that information like a file system -- which adds complexity and overhead to the boot process -- nto that it takes ALOT of time, but you could likely read the whole thing in as one large memory image if you really wanted to speed things up... a serial read off of contiguous blocks on my HW can go up to 1GB/s. But do it randomly it can drop below 100MB/s. So for the fastest boot possible, 1 image with your needed drivers seems like the the fastest and least failure-prone option. How many times have people complained about something not booting due to the initfs? It's almost NEVER the kernel. The failure rate is at least 400% higher, overall with the current method (not on any given system that is already working, but over all instances of people installing new initrd's and upgrades. *Almost*, the only people that have problems booting from a kernel are kernel and driver developers. It's hard for average users to install a bad kernel -- there are far more checks on such, but initrd's fail frequently. At least think about the benefits because with the current system there is a visible cost already. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org