Patch for pthread get and set affinity

[Sebastian Huber]

On 2014-03-05 15:58, Joel Sherrill wrote:
>
> On Mar 5, 2014 8:33 AM, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>  >
>  > On 2014-03-05 15:21, Joel Sherrill wrote:
>  > > We discussed this privately when you raised this to me. It should not be part
>  > > of the scheduler per thread data. lf you do then the data just disappears from
>  > > the API perspective when the scheduler doesn't support affinity. It will
> create
>  > > a new class of odd errors at the API level which no other implementation of
>  > > this type of API has. From an API perspective, it is the same as the preempt
>  > > and timeslicing flags.
>  >
>  > It is the responsibility of the scheduler set/get thread affinity operation to
>  > validate/return the affinity sets.  Storing this stuff in an arbitrary format
>  > in the Thread_Control structure makes no sense since the thread affinity
>  > support is entirely scheduler dependent.
>  >
>  > >
>  > > It is disabled in non-smp configurations, so doesn't impact minimum footprint.
>  > >
>  > > I seriously considered this and decided it was a bad idea. I don't know if I
>  > > have veto power :) but if I did, I would invoke it here.
>  > >
>  > > We can revisit this when we have a scheduler with affinity. As it stands now,
>  > > there is absolutely no way to test any of this code if we move the affinity
>  > > data to the scheduler.
>  > >
>  >
>  > You can test the code if you add the scheduler set/get affinity operations.
>  > The default implementation is trivial.  We have only global schedulers, so
>  > simply check that the affinity set is the set of all processors in the system.
>  >   For the get simply return the set of all processors.
>
> I don't disagree with this statement but you are being short sighted for
> iterative development.
>
> If we do this, then the tests can't set an arbitrary affinity and return it.
> We can commit this set will full passing tests.
>
> We will move the set when we touch the schedulers. We were very open and public
> and getting the APIs in and tested with data consistency and no scheduler
> changes as step one. Step two moves the information into the schedulers.
>
> If we make this change, we will commit nearly all broken tests
>

Its fine if you move the information into the schedulers later.  This wasn't 
obvious from the current patch set.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.