From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: normal vs. rescue mode commands
Date: Wed, 9 Jun 2004 13:19:34 +0200 [thread overview]
Message-ID: <200406091319.34017.okuji@enbug.org> (raw)
In-Reply-To: <20040606105515.GA25078@artax.karlin.mff.cuni.cz>
On Sunday 06 June 2004 12:55, Tomas Ebenlendr wrote:
> > 1. Generate two versions for each loader from the same source code.
> >
> > This case compiles the same source code twice to generate two
> > different loaders for rescue mode and normal mode. Basically, the
> > version for rescue mode would be a subset of the version for normal
> > mode. This makes redundant binary code, but the maintainability is
> > not very bad.
>
> This looks like best solution for me, also the 'normal' mode loader
> may depend on 'rescue' mode loader and use some of its functions.
> This looks like most 'clean' way. If we want that users won't be
> confused by 2 modules doing the same, we can add 'automatic module
> load support' which will load modules-normal_mode_extensions of
> loaded loaders to normal mode.
Ok. As others seem to have no opinion, let's go in this way.
Then, how about the naming convention? We need to have a standard way to
distinguish between normal mode loaders and rescue mode loaders by file
names. That is why I prefixed loaders with '_'. But I don't think an
underscore is so good.
And, at the same time, I'd like to make all filenames fit into the
DOS-style (8.3 filenames), so that we don't need to use VFAT on FAT
filesystems. I think this is better, because Microsoft claims that they
have a software patent about the long filename extension... *sigh*
What do you think?
Okuji
next prev parent reply other threads:[~2004-06-09 11:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-01 12:17 ext2 find patch Tomas Ebenlendr
2004-06-01 20:13 ` Tomas Ebenlendr
2004-06-01 20:47 ` Marco Gerards
2004-06-01 21:09 ` Jeroen Dekkers
[not found] ` <20040602100915.GA1629@artax.karlin.mff.cuni.cz>
[not found] ` <1086176188.40bdbbbc4d86d@webmail.han.nl>
2004-06-02 14:43 ` normal vs. rescue mode commands Tomas Ebenlendr
2004-06-02 15:11 ` Tomas Ebenlendr
2004-06-02 16:10 ` Marco Gerards
2004-06-03 11:12 ` Yoshinori K. Okuji
2004-06-03 11:55 ` M. Gerards
2004-06-03 12:50 ` Tomas Ebenlendr
2004-06-04 11:24 ` Yoshinori K. Okuji
2004-06-06 10:55 ` Tomas Ebenlendr
2004-06-09 11:19 ` Yoshinori K. Okuji [this message]
2004-06-09 12:07 ` Jeroen Dekkers
2004-06-09 12:25 ` Yoshinori K. Okuji
2004-06-09 12:48 ` Jeroen Dekkers
2004-06-09 13:12 ` Yoshinori K. Okuji
2004-06-09 13:54 ` Jeroen Dekkers
2004-06-09 14:22 ` Yoshinori K. Okuji
2004-06-09 14:44 ` Jeroen Dekkers
2004-06-10 11:51 ` Yoshinori K. Okuji
2004-06-09 12:28 ` Tomas Ebenlendr
2004-06-09 12:31 ` Tomas Ebenlendr
2004-06-03 11:08 ` Yoshinori K. Okuji
2004-06-27 10:45 ` ext2 find patch Marco Gerards
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=200406091319.34017.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.