Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2] | Date | Fri, 16 Mar 2007 14:15:46 +0000 |
| |
Christoph Hellwig <hch@infradead.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |