<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/9/21 7:31 PM, enh via Toybox wrote:<br>
> No standard, but part of util-linux.<br>
<br>
Don't default y in pending.<br></blockquote><div><br></div><div>yeah, sorry. i realized that after i'd gone to bed. at least i'm consistent ... i *always* make that mistake.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
USE_TASKSET(NEWTOY(uclampset)) doesn't match.<br></blockquote><div><br></div><div>d'oh. _that's_ a new mistake though!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Does this require root?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From a UI perspective, do we ever _not_ want -a?<br></blockquote><div><br></div><div>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_.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Sigh. It's HARD to come up with a good terse description of -R.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
$ grep syscall\.h toys/*/*.c<br>
toys/other/chrt.c:#include <sys/syscall.h><br>
toys/other/insmod.c:#include <sys/syscall.h><br>
toys/other/ionice.c:#include <sys/syscall.h><br>
toys/other/nsenter.c:#include <sys/syscall.h><br>
toys/other/pivot_root.c:#include <sys/syscall.h><br>
toys/other/readahead.c:#include <sys/syscall.h><br>
toys/other/rmmod.c:#include <sys/syscall.h><br>
toys/other/taskset.c:#include <sys/syscall.h><br>
toys/pending/modprobe.c:#include <sys/syscall.h><br>
toys/pending/strace.c:#include <sys/syscall.h><br>
toys/pending/uclampset.c:#include <sys/syscall.h><br>
<br>
Is there a reason we haven't got sys/syscall.h in toys.h? Sure, it's not in<br>
posix but it apparently originated in BSD:<br>
<br>
<a href="https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=syscall&sektion=2&format=html</a><br>
<br>
So the header should at least _exist_ there, and including it not break the build?<br></blockquote><div><br></div><div>yeah, there's a <sys/syscall.h> on macOS too. (iirc it's the glibc <syscall.h> synonym that's less portable.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ah. My devauan kernel is 4.19+fixes, so this goes boing when I run it. Luckily,<br>
I created mkroot... Hmmm... Except when I tried your version (without any of my<br>
changes), it still went:<br>
<br>
Type exit when done.<br>
# uclampset<br>
uclampset: Need -p PID or CMD [ARG...]<br>
# uclampset -p $$<br>
sh (48) util_clamp: min: 0 max: 0<br>
# uclampset -p $$ -m 42<br>
uclampset: sched_setattr for pid 48: Not supported<br>
# uclampset -p $$ -M 42<br>
uclampset: sched_setattr for pid 48: Not supported<br>
# cat /proc/version<br>
Linux version 5.16.0-rc3 (landley@driftwood) (x86_64-linux-musl-gcc (GCC) 9.2.01<br>
<br>
Do I need a kernel config entry or something?<br></blockquote><div><br></div><div>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"].</div><div><br></div><div>i'm guessing it's these?</div><div><br></div><div>vsoc_x86_64:/# gzip -dc /proc/config.gz | grep UCLAMP<br>CONFIG_UCLAMP_TASK=y<br>CONFIG_UCLAMP_BUCKETS_COUNT=20<br>CONFIG_UCLAMP_TASK_GROUP=y<br></div><div><br></div><div>(i don't have /proc/config.gz on my laptop though, so i can't check.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>