From: Dave McCracken <dmccr@us.ibm.com>
To: Linus Torvalds <torvalds@transmeta.com>, Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] POSIX personality
Date: Wed, 22 May 2002 09:19:34 -0500 [thread overview]
Message-ID: <13860000.1022077174@baldur.austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0205211603340.15094-100000@penguin.transmeta.com>
--On Tuesday, May 21, 2002 04:08:52 PM -0700 Linus Torvalds
<torvalds@transmeta.com> wrote:
>>
>> One reason for it would be that it would be more efficient. All the
>> various shared state needed for POSIX thread group emulation could be
>> put into a single structure with a single reference count.
>
> Now, that's a separate issue - the issue of the exact _granularity_ of
> the bits, and how you group things together.
>
> On that front, I don't have any strong feelings - but I suspect that it
> almost always ends up being fairly obvious when it is "right" to group
> things together, and when it isn't.
>
> For example, we probably could have had just one bit for (FS | FILES),
> and the same is probably true of (SIGHAND | THREAD), but on the whole we
> haven't really had any gray areas when it comes to the grouping. And I
> don't see any coming up.
>
> Does that mean that we might have a CLONE_POSIXDAMAGE that just covers all
> the strange POSIX stuff that make no sense anywhere else? Maybe. But I'd
> want that to be just another bit with the same semantic behaviour as the
> existing ones, _not_ be some external "POSIX personality".
I've been thinking along those lines myself. At this point I'd suggest we
implement them as separate, then if in the future no one ever uses them
separately we can consider combining them. I know this can raise some
backward compatibility issues but in theory if anyone cares we wouldn't do
it.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dmccr@us.ibm.com T/L 678-3059
next prev parent reply other threads:[~2002-05-22 14:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0205211349100.3073-100000@penguin.transmeta.com.suse.lists.linux.kernel>
[not found] ` <72190000.1022014608@baldur.austin.ibm.com.suse.lists.linux.kernel>
2002-05-21 21:35 ` Andi Kleen
2002-05-21 23:08 ` Linus Torvalds
2002-05-22 14:19 ` Dave McCracken [this message]
2002-05-28 17:26 ` Michael Sinz
2002-05-28 17:31 ` Dave McCracken
[not found] <187597808@toto.iv>
2002-05-21 23:55 ` Peter Chubb
2002-05-21 20:27 Dave McCracken
2002-05-21 20:52 ` Linus Torvalds
2002-05-21 20:56 ` Dave McCracken
2002-05-23 14:10 ` Bill Davidsen
2002-05-23 17:09 ` Linus Torvalds
2002-05-25 0:02 ` jw schultz
2002-05-25 0:38 ` Alan Cox
2002-06-05 13:26 ` Bill Davidsen
2002-05-21 21:13 ` george anzinger
2002-05-21 21:21 ` Dave McCracken
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13860000.1022077174@baldur.austin.ibm.com \
--to=dmccr@us.ibm.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®