[PATCH] Cygwin: Implement CPU_SET(3) macros

[Corinna Vinschen]

On Jul 30 02:25, Mark Geisert wrote:
> 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.

Well, the files are already there, just in the rtems subdir instead of the
generic one.  They just have to be moved, and the _cpuset.h file needs
a duplicate in cygwin's include dir to account for the Cygwin-specific parts.
It's not that you generate a lot of new files.

> 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.

They won't.  The rtems/FreeBSD implementation is CPU agnostic so the stuff
could go into the generic tree.  If your platform doesn't implement it,
just don't include it in your target code.

However, it sounds like you're pretty uncomfortable with the rtems/FreeBSD
implementation.  If so, combining them is not required.  It would just
be a nice-to-have since it also leads to more people interested in keeping
it in a good shape.

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

Great!


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20190730/8893f228/attachment.sig>