[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25410.1174054546@redhat.com>
Date: Fri, 16 Mar 2007 14:15:46 +0000
From: David Howells <dhowells@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, herbert.xu@...hat.com,
linux-kernel@...r.kernel.org, arjan@...radead.org
Subject: Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2]
Christoph Hellwig <hch@...radead.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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists