[RFC]swapfso and "ioctl" function for filesystems

[RFC]swapfso and "ioctl" function for filesystems

[phcoder]

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. So I suggest to add to grub_fs a
pointer to an array in which fs module can put custom functions.
Also in many filesystems it's quite difficult to add a new file or
remove already existing one it's often quite easy to exchange 2 files or
directories. So I intend to implement a call "swapfso" (FSO=File System
Object) at least for fat and ext2. Such a call could be useful to have
multiple OS on the same partition or to have multiple configurations of
the same OS (e.g. normal and backup). Then I think to have this function
in this extended list (even if this function can be implemented for more
FS) unless maintainers suggest that such function should be a part of
grub_fs. In this case a good idea would be to have 2 modules for
fat,ext2,...: one with swapfso and one without for core image.
Vladimir 'phcoder' Serbinenko

Re: [RFC]swapfso and "ioctl" function for filesystems

[Robert Millan]

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.

> [...]. So I intend to implement a call "swapfso" (FSO=File System
> Object) at least for fat and ext2.

Do you mean a filesystem write that swaps two file references?

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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

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.
With FAT: suppose you have let's say DR-DOS and windows on the same
partition. Great their boot files have different names so they shouldn't
 conflict. But in fact they do because both require their boot files
(io.sys/msdos.sys or ibmbio.com/ibmdos.com) to be first entries in root
directory. So fat module can provide a call like
fat_put_rootfile_to_slot (char *filename, int place);

Then a module "dosprep.mod" can do something like:
put_rootfile_to ("io.sys",0);
put_rootfile_to ("msdos.sys",0);

>> [...]. So I intend to implement a call "swapfso" (FSO=File System
>> Object) at least for fat and ext2.
> 
> Do you mean a filesystem write that swaps two file references?
> 
Exactly. It's easy to implement (just exchange inode numbers and
filetype fields in dirent). It's also another usage case for first part
of my email.
Vladimir 'phcoder' Serbinenko

Re: [RFC]swapfso and "ioctl" function for filesystems

[Robert Millan]

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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

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

Re: [RFC]swapfso and "ioctl" function for filesystems

[Robert Millan]

On Thu, Sep 04, 2008 at 11:27:20PM +0200, phcoder wrote:
> > 
> > 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.

We intentionally don't support filesystem writing.  This was discussed before,
I think.

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

Yes, but what if it does?

> may be implemented in an extra module
> (like ntfscomp) or there could be 2 modules for the same filesystem:
> basic and advanced one.

2 modules for the same filesystem can lead to trouble;  I don't think GRUB
can handle this situation properly (for example, if you need ext2.mod to
access $prefix, how to you replace it with the new module, which needs to be
loaded precisely from $prefix?).

An extra module would be saner, IMO.

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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

Robert Millan wrote:
> On Thu, Sep 04, 2008 at 11:27:20PM +0200, phcoder wrote:
>>> 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.
> 
> We intentionally don't support filesystem writing.  This was discussed before,
> I think.
> 
Well I see no reason why not to allow such feature to be made by
external modules. Another usage case is ext3cow snapshots. Even if the
snapshot can be chosen by a variable to list the snapshots you need a
function.
>>> 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.
> 
> Yes, but what if it does?
> 
then for registering the functions it needs 4+(4+d)*n bytes. Where n is
the number of functions and d the size of identifier. As such we can
choose: a 4-byte enum, a string or a GUID-like system with 8,12 (my
preferance) or 16-byte long identifier. Also if module is split into 2
(essential and not-essential) then the registering of functions can be
handled by not-essential module
>> may be implemented in an extra module
>> (like ntfscomp) or there could be 2 modules for the same filesystem:
>> basic and advanced one.
> 
> 2 modules for the same filesystem can lead to trouble;  I don't think GRUB
> can handle this situation properly (for example, if you need ext2.mod to
> access $prefix, how to you replace it with the new module, which needs to be
> loaded precisely from $prefix?).
I checked module loading code: it loads the module completely to the
memory and only then launches it. So basically it's not a problem
> 
> An extra module would be saner, IMO.
> 

I also think so

Vladimir 'phcoder' Serbinenko