Re: Proposal for savedefault implementation

[Bean]

On Fri, Mar 21, 2008 at 12:26 AM, Pavel Roskin <address@hidden> wrote:
> 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.

I'm sorry, i do misunderstand your point. i thought you mean saving
the information in some reserved sector of file system.

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

Yes, using core.img and a separate file is not that different. but if
we use normal file, we must create a large enough one.

-- 
Bean