* setpriority typo @ 2013-04-01 13:54 Justin Cormack 2013-04-01 14:05 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Justin Cormack @ 2013-04-01 13:54 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 241 bytes --] cat ./src/misc/setpriority.c #include <sys/resource.h> #include "syscall.h" int setpriority(int which, id_t who, int prio) { return syscall(SYS_getpriority, which, who, prio); } ^ should be set! Justin [-- Attachment #2: Type: text/html, Size: 520 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: setpriority typo 2013-04-01 13:54 setpriority typo Justin Cormack @ 2013-04-01 14:05 ` Rich Felker 2013-04-01 14:30 ` Justin Cormack 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2013-04-01 14:05 UTC (permalink / raw) To: musl On Mon, Apr 01, 2013 at 02:54:18PM +0100, Justin Cormack wrote: > cat ./src/misc/setpriority.c > #include <sys/resource.h> > #include "syscall.h" > > int setpriority(int which, id_t who, int prio) > { > return syscall(SYS_getpriority, which, who, prio); > } > > ^ should be set! This is definitely a bug, but I need to look at whether changing it will fix the problem. getpriority is doing some transformation on the prio value and I don't remember why, but it seems likely setpriority might need to do the same. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: setpriority typo 2013-04-01 14:05 ` Rich Felker @ 2013-04-01 14:30 ` Justin Cormack 2013-04-01 15:19 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Justin Cormack @ 2013-04-01 14:30 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1228 bytes --] On Mon, Apr 1, 2013 at 3:05 PM, Rich Felker <dalias@aerifal.cx> wrote: > On Mon, Apr 01, 2013 at 02:54:18PM +0100, Justin Cormack wrote: > > cat ./src/misc/setpriority.c > > #include <sys/resource.h> > > #include "syscall.h" > > > > int setpriority(int which, id_t who, int prio) > > { > > return syscall(SYS_getpriority, which, who, prio); > > } > > > > ^ should be set! > > This is definitely a bug, but I need to look at whether changing it > will fix the problem. getpriority is doing some transformation on the > prio value and I don't remember why, but it seems likely setpriority > might need to do the same. > > Rich > From the man page: Within the kernel, nice values are actually represented using the corresponding range 40..1 (since negative numbers are error codes) and these are the values employed by the setpriority() and getpriority() system calls... The glibc wrapper functions for these system calls handle the translations between the user-land and kernel repre‐ sentations of the nice value according to the formula unice = 20 - knice. So to be compatible with glibc there should be an adjustment. Justin [-- Attachment #2: Type: text/html, Size: 2195 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: setpriority typo 2013-04-01 14:30 ` Justin Cormack @ 2013-04-01 15:19 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2013-04-01 15:19 UTC (permalink / raw) To: musl On Mon, Apr 01, 2013 at 03:30:06PM +0100, Justin Cormack wrote: > On Mon, Apr 1, 2013 at 3:05 PM, Rich Felker <dalias@aerifal.cx> wrote: > > > On Mon, Apr 01, 2013 at 02:54:18PM +0100, Justin Cormack wrote: > > > cat ./src/misc/setpriority.c > > > #include <sys/resource.h> > > > #include "syscall.h" > > > > > > int setpriority(int which, id_t who, int prio) > > > { > > > return syscall(SYS_getpriority, which, who, prio); > > > } > > > > > > ^ should be set! > > > > This is definitely a bug, but I need to look at whether changing it > > will fix the problem. getpriority is doing some transformation on the > > prio value and I don't remember why, but it seems likely setpriority > > might need to do the same. > > > > Rich > > > > >From the man page: > > Within the kernel, nice values are actually represented using the > corresponding range 40..1 > (since negative numbers are error codes) and these are the values > employed by the setpriority() and getpriority() system > calls... The glibc wrapper functions for these system calls handle > the translations between the user-land and kernel repre‐ > sentations of the nice value according to the formula unice = 20 - > knice. > > So to be compatible with glibc there should be an adjustment. Reading the kernel source, apparently the adjustment is just required with getpriority to avoid it returning negative values on success. setpriority takes the unmodified value as an argument. BTW, these interfaces are badly nonconforming on Linux; they're affecting threads, not processes... I'm not clear what the conforming behavior would be on a system like Linux that does not support system scheduling scope, but unfortunately it's probably not what anybody wants or expects... Anyway I'll fix the bug for now, then we can discuss whether these interfaces need changing. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-01 15:19 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-01 13:54 setpriority typo Justin Cormack 2013-04-01 14:05 ` Rich Felker 2013-04-01 14:30 ` Justin Cormack 2013-04-01 15:19 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).