Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262223AbTENNEY (ORCPT ); Wed, 14 May 2003 09:04:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262226AbTENNEY (ORCPT ); Wed, 14 May 2003 09:04:24 -0400 Received: from pub237.cambridge.redhat.com ([213.86.99.237]:41460 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S262223AbTENNEW (ORCPT ); Wed, 14 May 2003 09:04:22 -0400 To: Muli Ben-Yehuda cc: David Howells , Linux-Kernel Subject: Re: [PATCH] PAG support only In-Reply-To: <20030514123524.GK20083@actcom.co.il> User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 May 2003 14:17:07 +0100 Message-ID: <3269.1052918227@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1635 Lines: 44 > > No. We _don't_ know the type of the data. A filesystem entrusts us with a > > token to keep in the PAG on its behalf. However, since this is meant to be > > a generic mechanism, it's entirely dependent on the fs as to what's in the > > blob. > > But you do know the type of the data in the blob... it's char* fsname, > const void* key and const void* data, according to your code. We only partially know the data type (btw you should ignore the const's). > struct fsblob { > const char* fsname; > const void* key; > size_t keysize; > const void* data; > size_t datasize; > }; There shouldn't be any consts in there, or else the pointers have to be cast prior to freeing. So I'd have to do three kmalloc's instead of just the one (assuming struct fsblob was folded back into struct vfs_token)... > Your method loses on additional complexity, and wins on speed. Yours may use more memory overhead, though that's not easy to judge. Also yours is more complex in that there's more bits of memory to keep track of. OTOH, your suggestion may permit sharing of fsname and maybe also key under some circumstances. > However, unless it's really, really speed sensitive code, I would go for > KISS any day. OTOH, resources are very precious, and the complexity is actually straightforward and can be wrapped with macros or inline funcs. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/