Gilles Chanteperdrix wrote:
> On 10/16/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>> after looking at the reason for the nkaffinity-vs.-POSIX issue 
>> again, I came to the conclusion that there is no way to apply the
>> current global affinity scheme on the POSIX skin. This scheme goes like
>> - If the user provides whatever thread affinity _explicitly_, use this
>> - If the user doesn't do so, apply the global nkaffinity.
>> In kernel space, is is simple to differentiate between both cases,
>> because all affinity fiddling for all skins go through Xenomai's hands.
>> But for the user space POSIX skin, we rely on the task affinity that is
>> set using standard Linux services, and that one has no "dirty-bit" to
>> tell both scenarios apart.
>> So my conclusion is that we should rather apply the nkaffinity always,
>> ie. logically AND it with the desired (or default) affinity. The
>> system's default behaviour will still be the same compared to earlier
>> Xenomai versions, as nkaffinity is ALL_CPUS by default. I also think
>> this behaviour is easier to understand for the user than the current
>> Any concerns about the (yet untested) attached patch?
> Well... Thanks for working in my stead. I had a look a the posix
> situation but could not find the place in the code where the affinity
> was set for user-space posix threads.
> But when looking at the way nkaffinity worked, I wondered why it was
> not set globally with a cpus_and on the tasks affinity. So, I
> basically agree with your patch (if it does what I think it does).
Tested, and I can confirm it works as it should do. Philippe, please apply.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list