Messages in this thread | | | Date | Sun, 19 Mar 2000 20:58:28 -0800 (PST) | From | Andre Hedrick <> | Subject | Re: Tentative patch: modularized disk partition systems in 2.3.99-pre2-5 |
| |
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/
| |