On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <r...@landley.net> wrote:
> On 12/9/21 7:31 PM, enh via Toybox wrote: > > No standard, but part of util-linux. > > Don't default y in pending. > yeah, sorry. i realized that after i'd gone to bed. at least i'm consistent ... i *always* make that mistake. > USE_TASKSET(NEWTOY(uclampset)) doesn't match. > d'oh. _that's_ a new mistake though! > Does this require root? > as you can tell from the previous mistake, i took taskset as a basis for this. it seemed plausible to me that if taskset needed STAYROOT (which i assume is what you're asking about here), this would too? but i've no idea. > From a UI perspective, do we ever _not_ want -a? > i wondered that too, but this is what the util-linux one does. (which is presumably just because that's what taskset does. so -- like me with `default y` at least they're _consistent_.) > Sigh. It's HARD to come up with a good terse description of -R. > yeah, as you can see, i gave up: "you're going to want to read a man page --- here's what you should search for" was all i was going for there. > $ grep syscall\.h toys/*/*.c > toys/other/chrt.c:#include <sys/syscall.h> > toys/other/insmod.c:#include <sys/syscall.h> > toys/other/ionice.c:#include <sys/syscall.h> > toys/other/nsenter.c:#include <sys/syscall.h> > toys/other/pivot_root.c:#include <sys/syscall.h> > toys/other/readahead.c:#include <sys/syscall.h> > toys/other/rmmod.c:#include <sys/syscall.h> > toys/other/taskset.c:#include <sys/syscall.h> > toys/pending/modprobe.c:#include <sys/syscall.h> > toys/pending/strace.c:#include <sys/syscall.h> > toys/pending/uclampset.c:#include <sys/syscall.h> > > Is there a reason we haven't got sys/syscall.h in toys.h? Sure, it's not in > posix but it apparently originated in BSD: > > https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html > > So the header should at least _exist_ there, and including it not break > the build? > yeah, there's a <sys/syscall.h> on macOS too. (iirc it's the glibc <syscall.h> synonym that's less portable.) > Ah. My devauan kernel is 4.19+fixes, so this goes boing when I run it. > Luckily, > I created mkroot... Hmmm... Except when I tried your version (without any > of my > changes), it still went: > > Type exit when done. > # uclampset > uclampset: Need -p PID or CMD [ARG...] > # uclampset -p $$ > sh (48) util_clamp: min: 0 max: 0 > # uclampset -p $$ -m 42 > uclampset: sched_setattr for pid 48: Not supported > # uclampset -p $$ -M 42 > uclampset: sched_setattr for pid 48: Not supported > # cat /proc/version > Linux version 5.16.0-rc3 (landley@driftwood) (x86_64-linux-musl-gcc (GCC) > 9.2.01 > > Do I need a kernel config entry or something? > i think so, yes. i got similar results to you on my laptop, but running on an x86-64 [virtual] device everything worked [to the extent that "i got back the values i put in, and plausible looking numbers from other stuff"]. i'm guessing it's these? vsoc_x86_64:/# gzip -dc /proc/config.gz | grep UCLAMP CONFIG_UCLAMP_TASK=y CONFIG_UCLAMP_BUCKETS_COUNT=20 CONFIG_UCLAMP_TASK_GROUP=y (i don't have /proc/config.gz on my laptop though, so i can't check.) Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net