Adam,
I just got the module dependencies of fs/partistions/msdos.c against IDE
fixed.........cutting patches now........
On Sun, 19 Mar 2000, Adam J. Richter wrote:
> 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/
>
Andre Hedrick
The Linux ATA/IDE guy
-
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 : Mon Mar 20 2000 - 00:39:00 EST