From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Autoloading WAS: normal/cmdline bug & patch
Date: Sat, 19 Jun 2004 17:05:00 +0200 [thread overview]
Message-ID: <200406191705.01343.okuji@enbug.org> (raw)
In-Reply-To: <20040618191411.GA30179@artax.karlin.mff.cuni.cz>
So there are three ways for this approach:
A. Load all modules at the start-up time.
B. Load modules until a module succeeds to recognize a filesystem.
C. Load an appropriate module using signatures or magic.
A is very simple, but it always consumes memory unnecessarily.
B is also simple enough, but it also may consume memory unnecessarily.
C is very efficient, but it makes things a bit complex, because one
filesystem module must provide two different detection mechanisms.
I'd like to vote for B. I like this simplicity. How about these
procedures? This is a modified version of B:
for each loaded filesystem module:
try the filesystem with a specified partition/disk
return if successful
for each non-loaded filesystem module:
load the filesystem module
try the filesystem
return if successful
unload the filesystem module
This is memory-efficient (unless the dynamic loader has memory
leaks...), and this is slow only at the first attempt of the
partition/disk.
I prefer this to C, because I've seen the command "mount" in GNU/Linux
not maintained all the time very well. I guess this is because the
author of code for a filesystem may not use "mount -t auto ..." with
the filesystem. This would happen even in GRUB, since you wouldn't
notice that the autoload of your filesystem module is broken, if you
preload it in core or explicitly load it manually or in a config file.
Okuji
next prev parent reply other threads:[~2004-06-19 15:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-15 11:31 normal/cmdline bug & patch Tomas Ebenlendr
2004-06-15 11:39 ` Tomas Ebenlendr
2004-06-15 13:45 ` Tomas Ebenlendr
2004-06-15 14:16 ` Marco Gerards
2004-06-15 16:22 ` Tomas Ebenlendr
2004-06-15 18:03 ` Tomas Ebenlendr
2004-06-15 20:36 ` Marco Gerards
2004-06-16 8:48 ` Tomas Ebenlendr
2004-06-18 20:54 ` Marco Gerards
2004-06-18 21:27 ` Tomas Ebenlendr
2004-06-27 11:07 ` Marco Gerards
2004-06-16 9:17 ` Yoshinori K. Okuji
2004-06-16 11:32 ` Marco Gerards
2004-06-16 12:33 ` Marco Gerards <metgerards@student.han.nl> Tomas Ebenlendr
2004-06-16 12:36 ` sorry Tomas Ebenlendr
2004-06-15 19:06 ` normal/cmdline bug & patch Marco Gerards
[not found] ` <20040615191931.GA18736@artax.karlin.mff.cuni.cz>
[not found] ` <873c4wh6um.fsf@marco.marco-g.com>
[not found] ` <20040616084333.GA17615@artax.karlin.mff.cuni.cz>
[not found] ` <87pt7zag0e.fsf@marco.marco-g.com>
2004-06-16 11:50 ` Tomas Ebenlendr
2004-06-18 10:45 ` Yoshinori K. Okuji
2004-06-18 10:46 ` Tomas Ebenlendr
2004-06-18 10:52 ` Marco Gerards
2004-06-18 11:38 ` Tomas Ebenlendr
2004-06-18 11:44 ` Marco Gerards
2004-06-18 12:04 ` Autoloading WAS: " Tomas Ebenlendr
2004-06-18 13:51 ` Marco Gerards
2004-06-18 18:50 ` Marco Gerards
2004-06-18 19:16 ` Tomas Ebenlendr
2004-06-18 19:14 ` Tomas Ebenlendr
2004-06-19 15:05 ` Yoshinori K. Okuji [this message]
2004-06-19 16:01 ` Marco Gerards
2004-06-19 16:27 ` Jeroen Dekkers
2004-06-20 18:54 ` Yoshinori K. Okuji
2004-06-20 2:02 ` Tomas Ebenlendr
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=200406191705.01343.okuji@enbug.org \
--to=okuji@enbug.org \
--cc=grub-devel@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.