[Bug 259787] sched.h: unknown type name 'cpu_set_t' after 160b4b922b6021848b6b48afc894d16b879b7af2
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 16 Dec 2021 19:53:56 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787 --- Comment #35 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Stefan Eßer from comment #34) There are some limitations how much can we do in base to not break existing third party software, which depends on 100% compatibility with Linux, while adding new APIs to FreeBSD. I think we need to stop somewhere, and claim that further issues needs to be fixed in that problematic third-party sources. It is not that FreeBSD change to add sched_get/setaffinity is unreasonable, right? The functionality is useful and simplifies porting a lot of stuff (I know this first-hand with ucx and tcmalloc examples), it is some cases where unreasonable assumptions are made that existence of that API implies Linux + glibc. I tried to get opinions of ports maintainers that are affected by the issue. I provided a mechanism like _WANT_CPU_SET_T that makes some incompatible API visibility optional. All I get in response was a silence. I do want to merge this sched.h changes and new API to stable/13, mostly because I want membarrier(2) and rseq(2). and sched changes a prerequisites. The MFC would clearly require some coordination with Stefan to also get the follow-ups merged right after the base merge. It is up to ports to handle fallouts now, I believe. -- You are receiving this mail because: You are on the CC list for the bug.