From: Hollis Blanchard <hollis@penguinppc.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Scripting - write to HD support?
Date: Fri, 06 Oct 2006 14:13:05 -0500 [thread overview]
Message-ID: <1160161986.23837.31.camel@basalt.austin.ibm.com> (raw)
In-Reply-To: <87fye11dzy.fsf@xs4all.nl>
On Fri, 2006-10-06 at 20:43 +0200, Marco Gerards wrote:
> "Markus Laire" <malaire@gmail.com> writes:
>
> > On 10/5/06, Marco Gerards <mgerards@xs4all.nl> wrote:
> >> I'm looking forwards to your ideas, questions, suggestions, criticism
> >> and bug reports. :-)
> >
> > Will there be any support for writing data to HD? Even a simple
> > support for writing some data to HD would allow quite a lot of ideas
> > to be implemented in grub which would be impossible with read-only
> > access.
I agree this would be a great feature.
> The disk support in GRUB 2 supports writing to disk. However, it is
> not used.
>
> > Full support for writing to filesystems is likely far too much to ask.
>
> Right.
>
> > But what about a possibility to create a certain file in advance (e.g.
> > /boot/grub/mydata filled with e.g. 1MB of zeroes) and then an ability
> > to write to that file without changing the size of the file.
>
> Writing zero's reliable. For example, filesystem implementations
> might change this into a sparse file. Another problem could be
> reiserfs, which stores metadata and data in the same sectors, IIRC.
>
> So instead of using zero's, we could of course use ones. For reiserfs
> we would have to look how big the file has to be to make sure metadata
> won't share this sector.
>
> But still, it is something we have to be extremely careful with. And
> a more important question is: Why do you want this, do you have
> specific uses for such feature in mind? I can think of things like
> fallback, etc.
Yeah, we should focus on enabling some specific features.
> > Alternative idea would be to create a partition (without any
> > filesystem) specifically for saving some data from grub, and then grub
> > would just give a read/write access to that partition as a single
> > block of data.
>
> I don't like this, it will make it hard or impossible to install GRUB
> on certain systems.
I like this; it's nice and simple. It's also similar to the situation
with Open Firmware and NVRAM. This approach could extend to NVRAM on
other systems as well...
Systems without a free partition just wouldn't be able to take advantage
of the feature.
-Hollis
next prev parent reply other threads:[~2006-10-06 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-06 17:18 Scripting - write to HD support? Markus Laire
2006-10-06 18:43 ` Marco Gerards
2006-10-06 19:13 ` Hollis Blanchard [this message]
2006-10-07 9:36 ` Markus Laire
2006-10-07 9:48 ` Markus Laire
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=1160161986.23837.31.camel@basalt.austin.ibm.com \
--to=hollis@penguinppc.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.