Re: [PATCH] Improve ext2 driver to allow embedding of the boot loader code.

["Dr. Tilmann Bubeck" <tilmann@bubecks.de>]

Vladimir,
Andrey,

is there any chance, that you integrate this patch? As you probably 
know,there is a huge demand for embedding grub2 into ext4 filesystems.

Is it ready for integration or should anything be changed?

Thanks!
  Tilmann

Am 21.01.2014 20:55, schrieb Dr. Tilmann Bubeck:
>
> The allocated space is reused every time on grub-setup execution. It
> does not change, as long as it is big enough. As Andrew said, by
> allocating 10 MB in the first run, it will be big enough for the
> foreseeable future (currently core.img on my system is 30k).
>
> After issuing the ioctl(EXT4_IOC_SWAP_BOOT) it is not a file anymore. It
> is only a (reserved) inode with data blocks. There is no filename
> associated in any directory. So user tools have no way to manipulate the
> data.
>
> fsck is aware of this and will not change anything or report any error.
>
> I do not see, why we need another user space tool for the initial
> allocation. The initial reservation and subsequent use of the data
> blocks can be done by grub-setup very easy and is already part of the
> patch.
>
>
> Tilmann
>
>
> On 01/21/2014 12:03 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> 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
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Mit freundlichen Gruessen,
   Tilmann Bubeck


//// dr. tilmann bubeck, it professional & geek
////
//// till@bubecks.de       /  http://www.bubecks.de
//// mobile: 0172-8842972  /  fon: 0711-7227719     /  fax: 0711-7227734
//// widmaierstr. 58       /  70567 stuttgart       /  germany