Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263355AbTEIR2N (ORCPT ); Fri, 9 May 2003 13:28:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263358AbTEIR2N (ORCPT ); Fri, 9 May 2003 13:28:13 -0400 Received: from 237.oncolt.com ([213.86.99.237]:47607 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S263355AbTEIR2H (ORCPT ); Fri, 9 May 2003 13:28:07 -0400 To: Derrick J Brashear cc: David Howells , openafs-devel@openafs.org, linux-kernel@vger.kernel.org Subject: Re: Adding an "acceptable" interface to the Linux kernel for AFS In-Reply-To: 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: Fri, 09 May 2003 18:40:33 +0100 Message-ID: <525.1052502033@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3222 Lines: 76 > > I'm wondering how attached OpenAFS is to this interface? Can OpenAFS be > > altered to use the following access points instead: > > Generally I think this interface will work. It would be nice, though, not to have to worry about differentiating between pioctls that take a path and those that don't inside of the core kernel. > > (1) setpag(pag_t pag) > > If you don't specify a pag it should allocate you one, and for > non-priviledged users this should be the only allowed mode. Thinking about it, this shouldn't take an argument at all, and should just put its caller into a completely new PAG with a unique ID. > I assume: > fs is a text representation of whose filesystem you're doing this for? > ("openafs", "arla", etc) > domain is what's typically referred to as an afs cell Yes. After all, you might need the key to be available before you can mount. This may be useful for samba too... The mount command for samba typically requires authentication data to be passed as options (workgroup, username, password). > I'd also like to see a priviledged "unsetpag()", e.g. I no longer wish to be > in a pag. "I" being the calling process? That can be done. I could just define that it is permissible for the PAG pointer to be NULL. This makes support for the init process easier, as I don't have to compile in a PAG for it. > Currently it's possible to set a token when you have no pag, and these > become associated with the uid that set them. (The pag number is not the uid; > Instead any process without a pag but with a uid that has tokens associated > with it gets those tokens.) As long as the above don't bind tightly to a pag, > sure. So you'd have a list of tokens associated with the user too? I suppose I could give both the PAG and the user lists, and search the PAG first, then the user, but what detemines the user? The PAG, the opener of a file or the current process? > As to pioctl, will it be able to handle things where path cannot be stat'd > in advance? For instance, the prefetching hint (VIOCPREFETCH), if you > could stat it, it wouldn't be a prefetch. Another concern there would be > dangling mount points (a mount point you still have to a volume that's > been deleted) when calling VIOC_AFS_DELETE_MT_PT or VIOC_AFS_STAT_MT_PT. The latter pair of pioctls you've mentioned both require the directory holding the mount point to be locally available as a kernel inode, and both of them require the path to that directory to be supplied as the path argument to pioctl rather than the path of the mountpoint, so I don't see that there'd be a problem there. I don't have documentation on VIOCPREFETCH, but if it's anything like the other two, then it shouldn't be a problem either. > To the extent we can we'd avoid relying on this (8), but I think we'll need > it for now. > > > (8) fsctl(const char *fs, const char *cmd, struct fsctl_buf) > > It may be possible to do this through the sysfs filesystem in 2.5 instead. 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/