Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Nov 2021 00:36:03 +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-icxQpkliAC@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 #18 from Konstantin Belousov <kib@FreeBSD.org> ---
I definitely want/need a feedback from ports maintainers.  In particular:
1. Should sched_getaffinity(3), sched_setaffinity(3), and sched_getcpu()
prototypes
be available regardless of _WANT_CPU_SET_T?  I suppose that yes, but need a
direct
answer.
2. Should cpu_set_t typedef available under _WANT_CPU_SET_T or just under
_BSD_VISIBLE?  I do not have an opinion there, and suspect that removal of
_WANT_CPU_SET_T could indeed simplify some ports.

This is also some plan to stop exposing BIT_* API to userspace, so that it
gets less conflicts with namespace poluution just by pulling sched.h.  But =
this
require some time to materialize.

Is there anything else src can help ports?  There is more stuff planned, see
D32360 and D32505, but I expect these be much less problematic
(sched_getaffinity()
problems were indeed a surprise to me).

--=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-icxQpkliAC>