From: Rusty Russell <rusty@rustcorp.com.au>
To: dcinege@psychosis.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PART1: Proposed init & module changes for 2.5
Date: Mon, 24 Sep 2001 15:31:58 +1000 [thread overview]
Message-ID: <E15lOLW-0000SC-00@wagner> (raw)
In-Reply-To: Your message of "Sun, 23 Sep 2001 23:57:24 -0400." <E15lMrA-0006ny-00@schizo.psychosis.com>
In message <E15lMrA-0006ny-00@schizo.psychosis.com> you write:
> is initialised. GRUB does a fantastic job of this on x86. It's the first
> bootloader I've seen 'get it right'.
>
> I don't suggest implementing the complete module loading in the boot loader,
> (I'm still not even sure I really like it in the kernel. ; > )
I was hoping someone would say this. (Note that my userspace tools
are not as complete as the current ones, so take a pinch of salt):
Old kernel:
$ wc -l kernel/module.c
1250 kernel/module.c
$ ls -l /sbin/insmod
-rwxr-xr-x 1 root root 99824 Aug 30 09:35 /sbin/insmod
$ find modutils-2.4.1/ -name '*.[ch]' | xargs cat | wc -l
20612
New kernel:
$ wc -l working-pmac-module/kernel/module.c
922 working-pmac-module/kernel/module.c
$ wc -l working-pmac-module/arch/ppc/kernel/module.c
253 working-pmac-module/arch/ppc/kernel/module.c
$ ls -l modult-init-tools/insmod
-rwxrwxr-x 1 rusty rusty 5240 Sep 24 15:23 insmod
$ find module-init-tools/ -name '*.[ch]' | xargs cat | wc -l
661
Convinced yet?
> only loading the modules themselves into memory for the kernel access during
> it's exec. (Like an initrd image is loaded) If a boot loader wants to
> understand and use modules.dep or do on the fly dependency checking, or have
> kernel userland utils to update it's conifg intelligently, that's it's
> business. I only want to see a way modules can be preloaded before kernel
> exec.
Why not just put them in the initrd image? The kernel is not going to
use the entire module as it is, so it will have to copy it anyway...
> All the parts are there but you can't. Your only option is to use an initrd
> that has the required modules *merged* into it. This is just disgusting and
> silly.
Um, how do you get the modules into grub then? If it can read ext2 at
boot, then it could create an initrd for me. Otherwise, how is it
different from creating an initrd?
It'd be easy to implement now. But it won't gain us anything, since
we'll all be using initrd-tng in 2.5 anyway.
Cheers,
Rusty.
PS. Am big fan of LRP: it rocks.
--
Premature optmztion is rt of all evl. --DK
next prev parent reply other threads:[~2001-09-24 5:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-23 6:37 [PATCH] PART1: Proposed init & module changes for 2.5 Rusty Russell
2001-09-23 7:12 ` David Cinege
2001-09-24 0:09 ` Rusty Russell
2001-09-24 3:57 ` David Cinege
2001-09-24 5:31 ` Rusty Russell [this message]
2001-09-24 8:14 ` Andrzej Krzysztofowicz
2001-09-24 9:44 ` David Cinege
2001-09-23 10:43 ` Ingo Oeser
2001-09-23 22:42 ` Rusty Russell
2001-09-24 1:01 ` Keith Owens
2001-09-24 4:35 ` Rusty Russell
2001-09-24 4:54 ` Keith Owens
2001-09-24 5:40 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E15lOLW-0000SC-00@wagner \
--to=rusty@rustcorp.com.au \
--cc=dcinege@psychosis.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox