To: Jan Harkes <jaharkes@cs.cmu.edu>
cc: David Howells <dhowells@cambridge.redhat.com>,
       Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org,
       linux-fsdevel@vger.kernel.org, openafs-devel@openafs.org
Subject: Re: [PATCH] in-core AFS multiplexor and PAG support 
In-Reply-To: <20030513182950.GB30766@delft.aura.cs.cmu.edu> 
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: Tue, 13 May 2003 19:53:22 +0100
Message-ID: <9828.1052852002@warthog.warthog>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2786
Lines: 69


> On Tue, May 13, 2003 at 06:42:49PM +0100, David Howells wrote:
> > I have a further suggestion for some new system calls specifically for
> > managing tokens. I'd like to add the following:
> > 
> >  (1) settok(const char *fs, const char *key, size_t size, const void *data)
> > 
> >      Present data to the named filesystem as being the authentication
> >      token for the specified key (eg: an AFS cell). If accepted, this
> >      token should be stored in the PAG to which the calling process
> >      belongs.
> 
> Tokens are very filesystem specific, with Coda the kernel really doesn't
> know in which 'realm' any object is located. So it will always just pass
> the PAG to the cache manager which will associate the right token to
> access the file.

OTOH, since settok wouldn't modify the PAG ring directly, but would rather
jump through a vector in the file_system_type object, it could deside to
confer with userspace and possibly not add a token at all.

Of course then the other calls would also have to vector through the
file_system_type object rather than affecting the PAG directly, but I'm happy
to do that.

> A minimal kernel implementation really only has a single newpag()
> systemcall and internal 'getpag()' that can be used by filesystems. All
> the token handling can be done by a (possibly filesystem specific)
> userspace daemon that is given a (pag,realm/key) tuple and returns a
> token.
>
> But ofcourse Coda is a 99% userspace implementation, so I'm already
> assuming that there are one or more userspace daemons.

This would just be a "standardised" way of communicating authentication info
to a filesystem. What the filesystem then did with it would be up to that
filesystem. Storing a token in a PAG or attached to a struct file would then
just be one option.
 
> >  (2) gettok(const char *fs, const char *key, size_t size, void *buffer)
> > 
> >      Get a copy of an authentication token.
> 
> Not sure what the use of this is for userspace. I can see how your
> kernel module would use it.

OpenAFS has it, but I'm not sure what uses it.

> btw. is the 'size_t size' the size of the key, or the size of the buffer?

Actually the buffer size. I was assuming the key would be a NUL terminated
string, but it's probably best not to assume that, and I should add an extra
argument for the key size.

Filesystem name can remain a NUL terminated string as I'd have to search the
file_system_type structures.

> >  (4) cleartoks(const char *fs)
> 
> Isn't this simply deltok(fs, NULL)?

Probably.

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/