From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Improve ext2 driver to allow embedding of the boot loader code.
Date: Tue, 21 Jan 2014 12:03:58 +0100 [thread overview]
Message-ID: <52DE541E.2090600@gmail.com> (raw)
In-Reply-To: <CAA91j0WD4KKdUTEJbsi7JGaWqtduakeDuNMwt4gAm74AB6Ho9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
On 21.01.2014 09:41, Andrey Borzenkov wrote:
> On Tue, Jan 21, 2014 at 12:32 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko <phcoder@gmail.com> wrote:
>> On 21.01.2014 09:28, Andrey Borzenkov wrote:
>>> On Tue, Jan 21, 2014 at 12:14 PM, Vladimir 'φ-coder/phcoder'
>>> Serbinenko <phcoder@gmail.com> wrote:
>>>> On 10.01.2014 08:49, Dr. Tilmann Bubeck wrote:
>>>>>
>>>>> The blocklist is fixed and stable and will never change.
>>>> What guarantees that it won't change on grub-setup invocation? I'm under
>>>> impression that it will change on every grub-setup invocation as file
>>>> gets recreated.
>>>>
>>>
>>> If I read code correctly, it checks current size and if new core.img
>>> fits, space is reused. So we could effectively make it preallocate
>>> reasonable size (or even unreasonable - I guess 10MB will be enough
>>> for foreseeable future) the very first time it is done.
>>>
>> It still doesn't solve the problem that during operations file becomes a
>> normal file and OS is allowed to rearrange the blocks as it sees fit.
>
> Would this be acceptable - use external utility to allocate
> EXT2_BOOT_LOADER_INO space of sufficient size once (outside of grub at
> all) and allow embedding into extX if this space exists? Do not mess
> with with it in grub-setup itself?
>
This presents a problem with sync'ing. After this space was reserved it
won't appear when using block functions until next sync'ing. This would
result in install failure on a new filesystem.
> We could then speak with ext2 folks to add option to mke2fs/une2fs in
> the long run it it does not exist yet.
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]
next prev parent reply other threads:[~2014-01-21 11:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:07 [PATCH] Improve ext2 driver to allow embedding of the boot loader code Dr. Tilmann Bubeck
2014-01-09 22:52 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-10 7:49 ` Dr. Tilmann Bubeck
2014-01-21 8:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-21 8:28 ` Andrey Borzenkov
2014-01-21 8:32 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-21 8:41 ` Andrey Borzenkov
2014-01-21 11:03 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2014-01-21 19:55 ` Dr. Tilmann Bubeck
2014-02-01 7:23 ` Dr. Tilmann Bubeck
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=52DE541E.2090600@gmail.com \
--to=phcoder@gmail.com \
--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.