Linux compatible setaffinity.

[Daniel Eischen]

On Tue, 19 Feb 2008, Jeff Roberson wrote:

> On Sat, 12 Jan 2008, Jeff Roberson wrote:
>
>> On Sat, 12 Jan 2008, Daniel Eischen wrote:
>> 
>>> On Sat, 12 Jan 2008, Jeff Roberson wrote:
>>> 
>>>> Now, there is one problem with the linux api that I want to discuss 
>>>> before I commit it.  The current patch always works on curthread. 
>>>> However, the api allows for setting the binding of a pid.  I believe, 
>>>> although I'm not certain, that pids and tids in linux are in the same 
>>>> number space.  It's not clear to me whether you can set an affinity for 
>>>> an entire process and have it effect an individual thread or whether you 
>>>> set it on a thread by thread basis.  When supplying a non-curproc pid do 
>>>> you bind all threads in the target process?
>>>> 
>>>> Are our tids and pids in the same number space?  And are they available 
>>>> to application programmers?  I haven't followed that very carefully.
>>> 
>>> I believe marcel made tids and pids disjoint so that any pid is
>>> never equal to any tid.  But regardless, I don't think we want
>>> to rely on that.  I would prefer the Solaris approach of specifying
>>> what we want (pid, tid, jail id, etc) as an argument in the API
>>> so there is no confusion.
>> 
>> Yes, I would prefer that as well I believe.  So I'll add an extra parameter 
>> and in the linux code we'll use whatever their default is.  Of course the 
>> initial implementation will still only support curthread but I plan on 
>> finishing the rest before 8.0 is done.
>
> So what does everyone think of something like this:
>
> int cpuaffinity(int cmd, long which, int masksize, unsigned *mask);
>
> #define AFFINITY_GET	0x1
> #define	AFFINITY_SET	0x2
> #define	AFFINITY_PID	0x4
> #define	AFFINITY_TID	0x8
>
> I'm not married to any of these names.  If you know of something that would 
> be more regular please comment.

I take it 'cmd' is either AFFINITY_GET or AFFINITY_SET, and which
is AFFINITY_PID or AFFINITY_TID.  Is there a reason why, for 2 different
arguments to cpuaffinity(), the flags are disjoint?  It almost seems
like you wanted:

 	int cpuaffinity(int flags, int masksize, unsigned *mask)

I prefer the API you specified, keeping 'cmd' and 'which' as
separate arguments.

Is masksize in bytes or in units of unsigned?  Do we need helper
functions/macros for the mask?  Like sigemptyset, sigaddset, etc?

-- 
DE