Re: [PATCH] Cygwin: Implement CPU_SET(3) macros

[Mark Geisert <mark at maxrnd dot com>]

On Fri, 26 Jul 2019, Corinna Vinschen wrote:
> On Jul 25 14:15, Mark Geisert wrote:
> > Corinna Vinschen wrote:
> > > Hi Mark,
> > >
> > > On Jul  1 01:55, Mark Geisert wrote:
> > > > Corinna Vinschen wrote:
> > > > > On Jun 30 15:59, Mark Geisert wrote:
> > > > > > This patch supplies an implementation of the CPU_SET(3) processor
> > > > > > affinity macros as documented on the relevant Linux man page.
> > > > > > ---
> > > > > >    winsup/cygwin/include/sys/cpuset.h | 62 +++++++++++++++++++++++++++---
> > > > > >    winsup/cygwin/sched.cc             |  8 ++--
> > > > > >    2 files changed, 60 insertions(+), 10 deletions(-)
> > > > > > [...]
> > > > > > +#define CPU_SETSIZE  1024  // maximum number of logical processors tracked
> > > > > > +#define NCPUBITS     (8 * sizeof (__cpu_mask))  // max size of processor group
> > > > > > +#define CPU_GROUPMAX (CPU_SETSIZE / NCPUBITS)  // maximum group number
> > > > > > -#define __CPUELT(cpu)   ((cpu) / __NCPUBITS)
> > > > > > -#define __CPUMASK(cpu)  ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
> > > > > > +#define CPU_WORD(cpu) ((cpu) / NCPUBITS)
> > > > > > +#define CPU_MASK(cpu) ((__cpu_mask) 1 << ((cpu) % NCPUBITS))
> > > > >
> > > > > I wouldn't do that.  Three problems:
> > > > > [...]
> > > > > There's also the request from Sebastian on the newlib list to
> > > > > consolidate the cpuset stuff from RTEMS and Cygwin into a single
> > > > > definition.
> > > > > [...]
> > > > I've also found that taskset isn't working properly on my build system with
> > > > the new CPU_SET code, though my other testcases are.  So even as submitted,
> > > > and fixed per your comments here, there's a bit more to be done.
> > > >
> > > > ..mark
> > >
> > > any chance to pick this up again?

I've been looking at this suggestion to consolidate the cpuset stuff from 
RTEMS and Cygwin.  There is no location common to both platforms to put 
this stuff other than Newlib's libc directory or maybe a non-sys subdir 
of libc.  If situated there, it could impact other newlib platforms, 
possibly.  It also seems a little messy to me to have to put four include 
files there.. cpuset.h, _cpuset.h, bitset.h, and _bitset.h.  Maybe I'm 
overthinking it.

RTEMS' cpuset.h is built on bitset.h, which is fine but the cpuset.h I 
wrote is self-contained and makes use of gcc builtins rather than C 
library calls for malloc, free, popcount, etc.  Mine is 32/64 agnostic, I 
believe RTEMS is too but I'm not totally sure; it depends on the length 
of 'long' items.

RTEMS' implementation includes some code modules needing to be linked into 
libc while the one I wrote is all in header files with some inline code.

These are all just minor implementation differences but I'm still hung up 
on the question of just where a common implementation could be placed in 
the source tree so both RTEMS and Cygwin can use them but other newlib 
platforms won't be tripped up.

..mark

P.S. IRC would be better for this kind of discussion. I'm waiting for my 
freenode registration to be processed.....