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.
Also, I'm worried that this occupies core image size for non-critical
functionality.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
