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

[phcoder <phcoder@gmail.com>]

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