Page MenuHomeFreeBSD

Add p10031b_sched feature so code can test for POSIX sched support at runtime
AbandonedPublic

Authored by ngie on Jan 4 2017, 8:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
May 29 2024, 2:39 AM
Unknown Object (File)
May 8 2024, 6:36 PM
Unknown Object (File)
May 8 2024, 6:27 PM
Unknown Object (File)
May 8 2024, 1:34 PM
Unknown Object (File)
Jan 3 2024, 3:38 PM
Unknown Object (File)
Dec 22 2023, 3:32 AM
Unknown Object (File)
Sep 8 2023, 8:10 PM
Unknown Object (File)
Jun 3 2023, 11:31 PM
Subscribers

Details

Reviewers
kib
markj
jilles
Summary

Add p10031b_sched feature

This is so code can test for POSIX sched support at runtime instead of
running syscalls like sched_yield and ending up with -1/ENOSYS

MFC after: 1 week

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 6557
Build 6779: arc lint + arc unit

Event Timeline

ngie retitled this revision from to Add p10031b_sched feature so code can test for POSIX sched support at runtime.
ngie updated this object.
ngie edited the test plan for this revision. (Show Details)
ngie added reviewers: kib, markj.
kib requested changes to this revision.Jan 4 2017, 10:54 AM
kib edited edge metadata.

Almost right and sufficiently portable way to check for this feature is to do

 if (sysconf(_SC_POSIX_PRIORITY_SCHEDULING) > 0) {
       /* supported, execute tests */
} else {
      /* not supported */
}

In other words, there is already POSIX-mandated way of checking the feature presence and I do not see why we need non-portable way to report the same thing.

I said that this variant is 'almost' right and correct since POSIX allows the compile-time definitions for the feature to be absent, and also allows to detect at compile time that the feature is guaranteed to be always present. Both of these variants are not possible on freebsd and would only make the code clumsier.

This revision now requires changes to proceed.Jan 4 2017, 10:54 AM
In D9041#186780, @kib wrote:

Almost right and sufficiently portable way to check for this feature is to do

 if (sysconf(_SC_POSIX_PRIORITY_SCHEDULING) > 0) {
       /* supported, execute tests */
} else {
      /* not supported */
}

In other words, there is already POSIX-mandated way of checking the feature presence and I do not see why we need non-portable way to report the same thing.

I said that this variant is 'almost' right and correct since POSIX allows the compile-time definitions for the feature to be absent, and also allows to detect at compile time that the feature is guaranteed to be always present. Both of these variants are not possible on freebsd and would only make the code clumsier.

Unfortunately this is always enabled with sys/sys/unistd.h:

68 #define _POSIX_PRIORITY_SCHEDULING      200112L

I think you're on the right track though -- this should be fixed.

In D9041#186947, @ngie wrote:
In D9041#186780, @kib wrote:

Almost right and sufficiently portable way to check for this feature is to do

 if (sysconf(_SC_POSIX_PRIORITY_SCHEDULING) > 0) {
       /* supported, execute tests */
} else {
      /* not supported */
}

In other words, there is already POSIX-mandated way of checking the feature presence and I do not see why we need non-portable way to report the same thing.

I said that this variant is 'almost' right and correct since POSIX allows the compile-time definitions for the feature to be absent, and also allows to detect at compile time that the feature is guaranteed to be always present. Both of these variants are not possible on freebsd and would only make the code clumsier.

Unfortunately this is always enabled with sys/sys/unistd.h:

68 #define _POSIX_PRIORITY_SCHEDULING      200112L

I think you're on the right track though -- this should be fixed.

Wait.. this is confusing:

228 #if _POSIX_PRIORITY_SCHEDULING == 0
229 mib[0] = CTL_P1003_1B;
230 mib[1] = CTL_P1003_1B_PRIORITY_SCHEDULING;
231 goto yesno;
232 #else
233 return (_POSIX_PRIORITY_SCHEDULING);
234 #endif

So... if it's set to 0, then it'll try to detect the support in the kernel -- otherwise it will always assume that it's on...? This seems really broken :(.

In D9041#186948, @ngie wrote:

So... if it's set to 0, then it'll try to detect the support in the kernel -- otherwise it will always assume that it's on...? This seems really broken :(.

Yes, I think the bug in the code which you cited is that sys/sys/unistd.h defines _POSIX_PRIORITY_SCHEDULING as 200112L, instead of 0. From the code in sys/kern/p1003_1b.c and lib/libc/gen/sysconf.c, changing that define to 0 should fix the problem and you would be able to use the intended interface.

I added Jilles so that he could state the POSIX view on this.

Defining _POSIX_PRIORITY_SCHEDULING as 0 in sys/sys/unistd.h will tell applications that compile-time support is available but run-time support needs to be verified using sysconf(), and will tell lib/libc/gen/sysconf.c to query for support using sysctl. Therefore, that seems the right solution to me.

There seems no reason to add a FEATURE since the existing sysctl mechanism works fine.

Note that POSIX does not specify the compile-time only support level for the option group _XOPEN_REALTIME, since XBD 2.1.5.2 XSI Option Groups simply specifies that _POSIX_PRIORITY_SCHEDULING be defined to 200809L when _XOPEN_REALTIME is defined to a value other than -1. This is irrelevant for us at this time because we define _XOPEN_REALTIME to -1.

Abandoning the revision because https://reviews.freebsd.org/D9055 looks like the right solution!