[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFT,PATCH] Move embedding to appropriate partmap files

From: Vladimir 'phcoder' Serbinenko
Subject: Re: [RFT,PATCH] Move embedding to appropriate partmap files
Date: Fri, 16 Oct 2009 23:12:52 +0200
User-agent: Mozilla-Thunderbird (X11/20090701)

Robert Millan wrote:
> On Fri, Oct 16, 2009 at 12:58:42PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Robert Millan wrote:
>>> On Thu, Aug 13, 2009 at 10:53:23PM +0200, Vladimir 'phcoder' Serbinenko 
>>> wrote:
>>>>>> We may want to embed more in the future. Actually I think it's not
>>>>>> ad-hoc. Basically partition map defines a function which gives back
>>>>>> the sectors available for embedding.
>>>>> Is embedding useful elsewhere?
>>>> Yes. Consider a world of checksummed filesystems. In such world you
>>>> can't change the contents of the file by just writing to its blocklist
>>>> since it will break the checksum. Similar problems exist with RAIDs
>>>> and LVMs. On some systems we can't put grub-env in a file. For these
>>>> cases we can embed grub-env somewhere where we can write it with ease
>>> Ok.  Feel free to use partmap/ then.  But please make sure #ifdefs only
>>> enable those functions where they are going to be used.  That'd be
>>> GRUB_MACHINE_PCBIOS for now, if later code in other ports relies on them,
>>> this can be changed.
>> This patch fixes an important bug - namely overwriting extended
>> partition tables
> Is there a simpler way to resolve this?  I don't object to the
> restructuring you propose, but it seems too intrusive to do this
> just a few hours before we release 1.97.
Yes. It's my concern too. Solving this requires metadata info form
partition map which is normally hidden and new code may have
undiscovered bugs. On the other hand already present code has a bug but
which is unlikely to be triggered.
As a simple alternative one could keep current check + enumerte entries
in MBR - this should be enough.

Vladimir 'phcoder' Serbinenko
Personal git repository: 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]