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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
