All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFT,PATCH] Move embedding to appropriate partmap files
Date: Fri, 16 Oct 2009 23:12:52 +0200	[thread overview]
Message-ID: <4AD8E1D4.7090101@gmail.com> (raw)
In-Reply-To: <20091016210722.GA8866@thorin>

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.

-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 




      reply	other threads:[~2009-10-16 21:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 13:33 [RFT,PATCH] Move embedding to appropriate partmap files Vladimir 'phcoder' Serbinenko
2009-08-12  0:38 ` Robert Millan
2009-08-12  9:39   ` Michal Suchanek
2009-08-13 20:34     ` Robert Millan
2009-08-12 12:52   ` Vladimir 'phcoder' Serbinenko
2009-08-13 20:37     ` Robert Millan
2009-08-13 20:49       ` Seth Goldberg
2009-08-13 20:53       ` Vladimir 'phcoder' Serbinenko
2009-08-13 21:05         ` Robert Millan
2009-10-16 10:58           ` Vladimir 'phcoder' Serbinenko
2009-10-16 21:07             ` Robert Millan
2009-10-16 21:12               ` Vladimir 'phcoder' Serbinenko [this message]

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=4AD8E1D4.7090101@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.