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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:28 EST