On Fri, 25 Feb 2005, David Howells wrote:
>
> The attached patch causes process and session keyrings to be shared properly
> when CLONE_THREAD is in force. It does this by moving the keyring pointers
> into struct signal_struct[*].
I do not see the point of associating keys with signal state.
And it _is_ signal state, even if some people mistakenly think that it's
about "processes". Linux still hasn't fallen into the trap of believing
that POSIX threads are somehow magical and the only way to do things.
The kernel very much believes in various shared resources. Signal state
(tty, resource limits, and actual signals handlers) is one such shared
thing, but so is VM state, file table state etc etc. Why would keys
logically be associated with signals, and not with the file table, for
example? Or the VM? Or just per-thread?
In other words, what does this buy us, if anything? From a logical
standpoint, I'd have said that it makes more sense to associate this with
the filesystem information, since keys would tend to mostly go together
with the notion of permissions on file descriptors.
Making keys be associated with signals just doesn't seem to make any
sense.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
