Messages in this thread | | | From | "Adam J. Richter" <> | Date | Sun, 19 Mar 2000 16:55:22 -0800 | Subject | Re: Tentative patch: modularized disk partition systems in 2.3.99-pre2-5 |
| |
Russel King <rmk@arm.linux.org.uk> writes, regarding moving the inital ramdisk code to userland: >[...] By doing such a change:
>1. you immediately force everyone to use an initial ramdisk, > which requires the ramdisk code (which increases the kernel size > by about 16KB), plus the extra effort to get the initial > ramdisk into memory. [...]
Our system already relies on an initial ramdisk to support all sorts of hardware autoconfiguration.
>2. you reduce the kernel size by around 6-14KB by removing the > partition code.
I believe we reduce the kernel size by 20kB, since we previously included all of the partitioning systems so users do not have to recompile the kernel. So, even if we did not otherwise use an initial ramdisk, and even if we were only concerned with the size of a single copy of the kernel, moving the partitioning code out of the kernel would still be a win.
>I believe that your original argument for doing the change was to >decrease the size of the running kernel, and increase the loading >time by a couple of milliseconds? (please correct if this is wrong).
Per your request, I am correcting you. There are more significant advantages to having the partitioning code outside of the kernel, which I described in my previous email:
| it would not have to be released with every new kernel, [...] | it would be more flexible, and it could more easily share code | with fdisk-like programs.
Basically, partition parsing is a small instance of a wider phenomenon: there is a increasing variety of mechanisms that would be useful for systems to use to mount their root partitions. Examples of this include diskless booting controlled by DHCP, encrypted root, certain RAID roots, menu based selection of boot, smart card authentication, and various combinations of the preceding. Implementing most of these in the kernel is often: o duplicative of existing userspace facilities o less flexible to implement than in user space o harder to maintain than in user space (new version with every kernel, no shared effort with other free systems, etc.)
By having a single modularized kernel with as little code linked in as possible, we get the following advantages:
o The same binary for the vast majority of systems, with little memory wasted (this should improve further as more intermediate layers functionality are also modularized).
o Less duplication of software maintenance and enhancement for facilities such as DHCP client, partition table parsing, etc.
o Future: less fire fighting with each new kernel release means that kernel developers can focus more on development.
On the other hand, you are obviously free to run Linux any way you want to. I am not trying to stop you.
I realize I am starting to wander into a general discussion about software engineering strategy for the Linux kernel. So, unless there is some specific factual correction that I want to make, I think I've expessed my point, and will probably let you (Russel) have the last word now if you want.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |