From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268029AbUIGNWM (ORCPT ); Tue, 7 Sep 2004 09:22:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268050AbUIGNWM (ORCPT ); Tue, 7 Sep 2004 09:22:12 -0400 Received: from mx1.redhat.com ([66.187.233.31]:5597 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S268029AbUIGNVt (ORCPT ); Tue, 7 Sep 2004 09:21:49 -0400 From: David Howells In-Reply-To: <20040907033255.78128ebd.akpm@osdl.org> References: <20040907033255.78128ebd.akpm@osdl.org> <20040907031856.58f33b99.akpm@osdl.org> <20040904032913.441631e6.akpm@osdl.org> <20040904022656.31447b51.akpm@osdl.org> <20040903224513.0154c1d3.akpm@osdl.org> <24752.1094234169@redhat.com> <12766.1094289316@redhat.com> <14279.1094293508@redhat.com> <13781.1094551789@redhat.com> <14622.1094552807@redhat.com> To: Andrew Morton Cc: arjanv@redhat.com, Christoph Hellwig , viro@parcelfarce.linux.theplanet.co.uk, linux-kernel@vger.kernel.org Subject: Re: Where's the key management patchset at? User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Sep 2004 14:21:23 +0100 Message-ID: <22970.1094563283@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > So > > a) Why should we merge keyfs? A bunch of people out there (viro, hch, jamesm for example) think they want it, and in fact think that there shouldn't be any other interface. I've also had emails of random people saying there absolutely has to be a filesystem interface so they can as administrators go and rummage around in the key database, though I suspect they're going to be disappointed in keyfs as it'll only let them see those keys they've a right to do something with. I'd like to dispense with keyfs. The semantics of the key database don't map to the VFS, hence the fact we have to present the key database as a flat directory and why I have to make use of a bunch of undocumented esoteric fs ops. I'd also like keyfs to remain optional at best. It's a large chunk of code that is completely unnecessary, and on an embedded system it's something you'd probably want to do without. It could be made a module, I suppose, to be loaded on demand. > b) Are people likely to use the APIs frequently enough for its > performance to matter? Now that's harder to judge... Performance is going to matter very much from the point of view of a filesystem that wants a key. It's probably going to be checking for a key on every open call. However, that's mostly taken care of by the internal kernel API, and the userspace interface has little impact upon that, except where the request-key callout is concerned. Performance may also matter from the point of view of userspace service programs (AFS requires a few of these), though in this case you should only need to do one lookup per invocation of the program. So, for most userspace operations wrt to keys, performance isn't a problem; however, for certain systems, size _is_ a problem and in those cases keyfs is a liability. And, before anyone asks, yes, the problem of kernel size is something I've had to contend with. David