Christoph Hellwig <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
