All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.