Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:25:51PM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
>>>> Hello, all.
>>>> For some FS sometimes additional functions are needed. It could be some
>>>> type of control (e.g. in ZFS manage zpools) or preparation for OS
>>>> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
>>>> root directory). While theese functions are quite specific to FS
>>>> sometimes are important to implement.
>>> What would be the purpose of that? Please describe a use case.
>>>
>> With ZFS or ext3cow: Suppose you made a huge mistake and installed
>> unbootable kernel and have no backup in another file. But ZFS/ext3cow
>> has its own backup. So ZFS/ext3cow driver may provide a call something like
>> static grub_err_t zfs_timeback (int timeref);
>> And anounce it like:
>> add_funcs={
>> {"timeback", zfs_timeback},
>> {0, 0}
>> };
>> Then a module timeback.mod can suply a command like
>> timeback <device> <date>
>> which uses the function supplied by zfs and ext3cow.
>
> Could this be made more transparent? For example, with a variable.
>
Here perhaps it could be. But in other usage cases like putting the dos
boot files into the right place or doing swapfso it couldn't.
> Also, I'm worried that this occupies core image size for non-critical
> functionality.
>
If filesystem module doesn't use this feature it just adds a zero
pointer to grub_fs structure. It means 4 bytes (due to alignment often
it probably be 0 bytes increase). And it would answer to all
filesystem-specific needs. And non-essential parts of the FS module
(like swapfso, dos boot files,...) may be implemented in an extra module
(like ntfscomp) or there could be 2 modules for the same filesystem:
basic and advanced one.
Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
