Re: Proposal for savedefault implementation

[Bean]

On Thu, Mar 20, 2008 at 4:09 PM, Pavel Roskin <address@hidden> wrote:
> Hello!
>
>  I cannot promise I'll do the coding myself, but I've been thinking of
>  a safe approach to savedefault implementation, and I'd like to share
>  some of my thoughts.
>
>  GRUB should support only one kind of writing to the disk, namely
>  writing to one sector at a specified offset.  Even that is not
>  trivial, as we should try to support BIOS, openfirmware and ATA.  And
>  maybe we should try to support RAID at some point.
>
>  There should be a utility capable of creating a "blessed sector" where
>  GRUB would be allowed to write.  Choosing the location is up to that
>  utility and the user running it.  It could be a bootloader area of a
>  partition, a sector on the first track of the hard drive or a file on
>  the filesystem.
>
>  The utility must ensure that GRUB can write to that sector safely at
>  the boot time.  In particular, it should be indeed aligned at the
>  sector boundary, it should not be compressed or fragmented.  If it's
>  on RAID, the bootloader should know what to do.  Only GRUB and the
>  utility should ever write to that sector.  Using any other tools
>  should be discouraged.
>
>  What could be in the "blessed sector":
>
>  version of the utility that created it
>  minimal version of GRUB allowed to write
>  sector size
>  sector number on the drive
>  data length
>  modification time?
>  counter, which is incremented on write?
>  drives and sectors to write copies to?
>  settings, perhaps stored as 0-terminated strings in the format key=value
>
>  GRUB should read the sector first, perhaps using the filesystem.  It
>  should check that its version is at least the required one.  Then it
>  should re-read the sector by the sector number.  The data should be
>  exactly the same.  That should allow writing by the sector number.
>
>  The command for writing should save variables from the environment.
>  Likewise, reading from the file should copy variables to the
>  environment.

Hi,

I think using a separate sector to store the information is not very
practical. First of all, we need to modify all of the file system
modules  to support this new feature, which require non trivial work
and testing. Besides, some file system doesn't have space for extra
sector, for example, fat12/fat16. It would be annoying if this
function can't be used on such fs.

Perhaps we can just embed the information in core.img itself. We use
blocklist to find out the disk location and write to it. As core.img
is normally too big to fit within a filesystem cluster, we don't have
to worry about inline data. Also, we can read from the sector and
verify its content first, so that we won't overwrite other area even
if blocklist give incorrect result.

About the format, i think storing key=value pairs is all we need.
Other information can be converted to such form. Inside grub2, we can
add a command to mark some variable as persistent, so that its value
will be written to disk automatically (or manually).

-- 
Bean