[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] add setdefault X
From: |
Jim Cromie |
Subject: |
Re: [patch] add setdefault X |
Date: |
Wed, 12 Nov 2003 17:40:58 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 |
Yoshinori K. Okuji wrote:
On Thursday 06 November 2003 15:04, Robert Millan wrote:
Including Jim's, I have a bunch of separate patches that implement that
feature around. I was playing with them to see if any of them can be
integrated. Asides copyright stuff, is that feature ok for CVS?
Basically it is okay, as I understand there are some situations where boot
once is invaluable.
But I still hope more discussion. This kind of feature is not GRUB's way
actually -- GRUB is intended to manage things at run time rather than at
installation time. And, from my point of view, those who want the feature
look like thinking only of "how to mimic LILO". I feel there should be a good
way to mix the feature with GRUB's other parts smoothly.
Im not quite following. The 'savedefault N' feature is not
install-time, its (in my scenario) given in
the menu-entries, and activated at run-time. I want to use it to cycle
thru a series of different
OSs, and run a 'smoke-test' on each (where theres smoke, theres fire).
In this sense, 'savedefault N' is similar to `lilo -R`, except that its
self-contained within
grub.conf, not strung together by a series of hacks spread across shell
scripts in 4 or more different
OS installations.
in my patch-in-progress, I started to add
title test1
savedefault next
kernel ...
title test2
savedefault next
kernel ...
title test-last
savedefault 0
The intent was to get position independence, so N would be more abstract.
But your installation-time comment resonates with a concern I had,
but couldnt really decide whether it was a problem:
the default is saved into the stage2 file, which I understand to be
file-system
dependent, (hence the reason for the --stage2=foo option). If this is
the case,
using next doesnt get you there - the default must be written into a
file-system
dependent place, which is dependent on the next entry, not the current one.
OTOH - the FS dependency could be on the partition where /boot is stored,
and which doesnt depend on the OS being selected next. (this seems
like the simpler - more correct interpretation - now that Ive gotten here).
And you said you wanted discussion :-D
Btw, there's also a patch that adds a "showdefault" command.
As you know, we shouldn't accept any patch without any infomation on how it is
useful.
a 'showsettings' command might be better - all encompassing.
Id like this in both the command-line, and in a menu-entry.
Whether thats justification, or not, ...
BTW - shouldnt that be conf-entry, now that menu.lst seems to be grub.conf ?
If so, I'll work up a patch.
Okuji
.
- [patch] add setdefault X, Jim Cromie, 2003/11/04
- Re: [patch] add setdefault X, Yoshinori K. Okuji, 2003/11/06
- Re: [patch] add setdefault X, Robert Millan, 2003/11/08
- Re: [patch] add setdefault X, Yoshinori K. Okuji, 2003/11/12
- Re: [patch] add setdefault X, Robert Millan, 2003/11/12
- Re: [patch] add setdefault X, Yoshinori K. Okuji, 2003/11/13
- Re: [patch] add setdefault X, Robert Millan, 2003/11/13
- Re: [patch] add setdefault X, Yoshinori K. Okuji, 2003/11/15
- Re: [patch] add setdefault X, Robert Millan, 2003/11/15
- Re: [patch] add setdefault X, Yoshinori K. Okuji, 2003/11/15
- Re: [patch] add setdefault X,
Jim Cromie <=