cpuset macro /vs/ inline implementation

[Daniel Hellstrom]

On 10/31/2013 01:34 PM, Sebastian Huber wrote:
> On 2013-10-31 13:21, Daniel Hellstrom wrote:
>> On 10/31/2013 12:38 PM, Sebastian Huber wrote:
>>> On 2013-10-31 12:30, Daniel Hellstrom wrote:
>>>> I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
>>>> probably a good reason for it but would it make sens to make it dependent on
>>>> the architecture? So that 64-bit machines have it sized to 64-bits. I'm not
>>>> sure there are 16-bit SMP machines :) .
>>>
>>> No, this should be a fixed size integer for all architectures to allow static
>>> initialization.  Anyway it will be a long way for RTEMS to support 33
>>> processors.
>>
>> So what is the point of having an array of 32-bits in the set? If there were a
>> 16-bit SMP CPU would not performance be better to describe it with a 16-bit
>> instead of an 32-bit word? Its probably not realistic with a 16-bit SMP machine
>> anyway, more realistic is a 64-bit SMP machine. Would the atomicity of having a
>> 64-bit word instead of 32-bit word on a 64-bit machine matter?
>
> Performance of the operations at this API level is completely irrelevant.  What the implementation does with these CPU sets internally is something different.
>
> Other operating systems don't have a static link-time configuration.
>
>> At this point we
>> haven't been discussing atomic cpusets, my guess is that other OSes have
>> definitions for that and in that case on a 64-bit machine it could make sens,
>> or what do you think?
>
> What do you mean with "atomic cpusets".

Should have said atomic set, there are atomic counters defined so haveing an atomic set is not that far off. If multiple-cpus wants to enable/disable CPUs independently one can do that with atomic 
sets. This is not important.

Daniel