Re: lib/53495: sched_get_priority_max/sched_get_priority_min not returning useful values

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR lib/53495; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
 returning useful values
Date: Fri, 3 Aug 2018 15:02:17 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx
 Content-Type: multipart/mixed; boundary="RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <71bf3c01-8975-8828-08ce-6636199d9f7a%gmx.com@localhost>
 Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
  returning useful values
 References: <12733.1533280044%splode.eterna.com.au@localhost>
 In-Reply-To: <12733.1533280044%splode.eterna.com.au@localhost>
 
 --RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 
 On 03.08.2018 09:07, matthew green wrote:
 >>  This is not a bug. It works as intended.
 >> =20
 >>  NetBSD behavior is compliant with POSIX and 3rd party program has to =
 be
 >>  fixed and handle the -1 case on its own, if there is need to distingu=
 ish
 >>  error and unsupported, there is an option to reset errno and check it=
 
 >>  after the call.
 >=20
 > this makes no sense to me.  opengroup says:
 >=20
 >    If unsuccessful, they shall return a value of -1 and set errno
 >    to indicate the error.
 >=20
 > so "-1" can not be a useful value by definition.  clearly our
 > implementation needs to map between internal values and ones
 > we return to these functions if "-1" is interanlly useful.
 >=20
 > it's also extremely awful to introduce more APIs that abuse errno
 > like you suggest, and should not be done any time.
 >=20
 >=20
 > .mrg.
 >=20
 
 I'm referring to a line documented from different pages:
 
 If the current scheduling policy for the target process is not
 SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option
 End]  the result is implementation-defined; this case includes the
 SCHED_OTHER policy.
 
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setparam.=
 html#
 
 For SCHED_OTHER, the affected scheduling parameters are
 implementation-defined.
 
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setsche=
 dparam.html
 
 And some other places with similar wording.
 
 Additionally:
 
 
 For threads executing under this policy, the implementation shall use
 only priorities within the range returned by the
 sched_get_priority_max() and sched_get_priority_min() functions when
 SCHED_OTHER is provided as the parameter.
 
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#=
 tag_15_08_04_05
 
 -1 indicated that no priority policy (or PRI_NONE one as an
 implementation specific type of NetBSD) can be used with SCHED_OTHER.
 
 PRI_NONE is not technically an error, so not errno set - but the result
 is the same as it cannot be changed.
 
 
 --RsaY29tubPQ1RDJLEhMFZjvjeIX2RK5Wu--
 
 --9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkUlkMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZskO8QALSYVqrDi/ND1QuUb14HrVJErUq+LC6KPOMsiljf
 c7wVSH+rnB0+eXIhw2bY96UYGHGFnPdDkUymSJ11r1a5brkVXmAH4Bnujw+yIpE9
 GGpAEV713vbT4LHCHQ05GvHypl6DYK80FibjO2PT5ST0wPzPAiji6dl0wikPbDwH
 evHLhoxoio1c/sJyKMaQ/8t7ycu68yhXw528F5nGjocoxNRGJO1fRm0hLFxOAdZN
 QUGiOmiGaH5Pokfsu+/+tog4AS0JQ/eFsEbJ1VrncFLJMKDqeFmLgeCApyJMMS+J
 3+ntcw+21dfmqv6p9xhOYR6Hwa0Ni2U+UI/RsMAUzezR7cEacRo00lhS4n2WsGq4
 wOATJKEXKy5vtWH0jSaJA5LV6x++68GhVg7X6L1g1950K9oTVRKFS1+24q4yUywV
 Rf9Y0AgbECKaX052sywipTwb0Yi/E4NWqWg3tQ168bBxjojh2fFsdz0UXLZ7aymJ
 pc8HZ3Em7KrrKiw2F4DeuEuo8EcW4hyNAM82QlVKjfxt5hpzTHyAOIs5jmmudYUf
 DZg1Mvx3cWJZom1AcNreKACLzzmJg8WyeDb9lZP2GTDMOWV6UPMJ+dlxnFyD8RjY
 jL21Z/dnV2r6f8r+UnoTwJ1Yf2IZn0DhYfxNg823snLHruqLWOoeEKxZtd6ibtbC
 pOs/
 =rUrR
 -----END PGP SIGNATURE-----
 
 --9YcmKHhE1o9XtOpZRZPeYiiHk59BIXaCx--