From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kc7sm-0005gV-Lm for mharc-grub-devel@gnu.org; Sat, 06 Sep 2008 20:12:00 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc7sl-0005gQ-TU for grub-devel@gnu.org; Sat, 06 Sep 2008 20:11:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc7sl-0005gE-DC for grub-devel@gnu.org; Sat, 06 Sep 2008 20:11:59 -0400 Received: from [199.232.76.173] (port=59952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc7sl-0005gB-BC for grub-devel@gnu.org; Sat, 06 Sep 2008 20:11:59 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:50014) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kc7sk-0004Dc-Qc for grub-devel@gnu.org; Sat, 06 Sep 2008 20:11:59 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1100870fgb.30 for ; Sat, 06 Sep 2008 17:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Tyh3wDfXDeO5RNES+mKMER7O2DFeHlkvjQBdYBZLVB8=; b=jcen9BY4w9ld//7Ix8MINTMhhcxRBfWAz3ToRVCUGeilyvSuKgYDWIWOOK+LmDy1i1 GPP+ZvXMptEmKlb2OYoU5ZgAIwJwmDOR+3O5ftNdeBBP7pi4cocsBvXgBeeuLDSv+ViN yW5wiDHMd+vJex3H1ZVka2PlzkSIcoq+hScE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=dqwVhzodjWgJ28UDkYE9j6Cf36P4uxtzcSgFsuH7aJOfmih7kaW0uN5WNHkXhpHJL+ uP74QKigveM9nRFFDL8O2Fw2byOknUUmYrECMUT3kemR4wL9c2Yh6w+cyJEOiJ3ixYB9 kR+1gAgXdSAE+bk8/slWSfGXJymVXcjlT1NzE= Received: by 10.86.79.19 with SMTP id c19mr10034575fgb.5.1220746317353; Sat, 06 Sep 2008 17:11:57 -0700 (PDT) Received: from ?192.168.1.15? ( [85.1.148.39]) by mx.google.com with ESMTPS id e20sm2722477fga.1.2008.09.06.17.11.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Sep 2008 17:11:56 -0700 (PDT) Message-ID: <48C31C49.5050207@gmail.com> Date: Sun, 07 Sep 2008 02:11:53 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: The development of GRUB 2 References: <48BE5C14.3000105@gmail.com> <20080903103139.GB29762@thorin> <48BE824F.2040007@gmail.com> <20080904192617.GC9133@thorin> <48C052B8.1000007@gmail.com> <20080905095614.GA5220@thorin> In-Reply-To: <20080905095614.GA5220@thorin> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: [RFC]swapfso and "ioctl" function for filesystems X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 00:12:00 -0000 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