grub-devel
[Top][All Lists]
Advanced

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

Re: Proposal for savedefault implementation


From: Pavel Roskin
Subject: Re: Proposal for savedefault implementation
Date: Thu, 20 Mar 2008 12:26:02 -0400

On Thu, 2008-03-20 at 20:28 +0800, Bean wrote:

> 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.

I'm afraid you misunderstood something.  Are you talking about the
bootloader or about the utility for creating the sector?  The bootloader
should write only by the block number.  No filesystem code is involved.

The utility only needs to know which filesystems are safe to write to.
It should also know the sector number, but I think LILO can do it
somehow without any filesystem support.  Even GRUB should be able to do
it if it doesn't embed the core image.  The worst case scenario is that
we add some tracing code to our filesystem implementation (userspace
only), which would record the last sector accessed for reading.  This
way we'll know the location of the file by reading from it.

>  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.

What extra space are you talking about?  I actually think FAT is one of
the easiest filesystems to support because it has no checksums, no
compression, no tail packing and no sparse files.  A 512-byte long file
would always occupy exactly one sector.

> 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.

I don't see much difference between using core.img and a separate file,
except that using a separate file gives more flexibility.

By the way, you are inconsistent here.  If writing a separate file
requires changes to all filesystems, how come writing to core.img
doesn't require it?

The only difference in my proposal is to have the blocklist (consisting
of one sector) in the writable file itself, not in the bootloader.

> 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).

OK, fine with me.

-- 
Regards,
Pavel Roskin




reply via email to

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