Date: Thu, 16 Dec 2021 19:53:56 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 259787] sched.h: unknown type name 'cpu_set_t' after 160b4b922b6021848b6b48afc894d16b879b7af2 Message-ID: <bug-259787-12827-NHk6W16DOo@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259787-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-259787-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 --- Comment #35 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Stefan E=C3=9Fer 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 th= at 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 M= FC 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259787-12827-NHk6W16DOo>