Re: [RFC] POSIX personality

[Michael Sinz]

Dave McCracken wrote:
> --On Tuesday, May 21, 2002 04:08:52 PM -0700 Linus Torvalds
> <[e-mail]> 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.

I would be worried about the future compatibility here.  It would be easier
to be compatible to start with a single bit and then add individual bits for
those features that need to be broken out when it is know to be needed.
Folding the bits back in is not as easy as you now have to still support
the individual but yet unneeded.

-- 
Michael Sinz ---- Worldgate Communications ---- [e-mail]
A master's secrets are only as good as
	the master's ability to explain them to others.