Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
- From: David Howells <dhowells@xxxxxxxxxx>
- Date: Fri, 16 Mar 2007 14:15:46 +0000
Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
You wrote the code so there must be some reason for this, but these
changes look rather odd to me :)
The union is for use by the type in any way it sees fit, but it may not want to
use it as a list_head. So all I've done is to make it available as a pair of
arbitrary pointers or a pair of arbitrary numbers.
Maybe a better way would be to have an overlay struct that's private to the
type, sort of how sk_buff::cb works.
Having a type exported is really odd, how is this supposed to be a public API?
Keyrings are a special type.
It occurred to me whilst doing this that the best way to achieve what I wanted
was by dealing with rings of keys. What I needed was for the server app to
give the kernel a key for each security type it wanted to support, which the
kernel would then have to retain. It seems natural to use a keyring to do the
retension as that's its purpose.
Another way to look at it is that in the client I need just one key at once,
and I can get that from the process as it's setting up the connection.
However, in the server I need to have several keys, and I need them available
up front because the server app doesn't set up a connection, the kernel does,
and it needs the keys immediately.
I'll add a mention to Documentation/keys.txt to record this exportation.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
- From: Christoph Hellwig
- [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
- From: David Howells
- [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
- From: David Howells
- Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
- Prev by Date: Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
- Next by Date: Re: [PATCH 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2]
- Previous by thread: Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
- Next by thread: [PATCH 2/5] AF_RXRPC: Move generic skbuff stuff from XFRM code to generic code [try #2]
- Index(es):
Relevant Pages
|
