[Toybox] [PATCH] taskset: Document and add test for 0 PID

Fri Jul 4 13:38:30 PDT 2025

Well at least _you_ can email the list from a google.com address. :)

https://mstdn.jp/@landley/114794250451870476

(I am heavily jetlagged in Tokyo and catching up with friends, sorry if 
I'm only semi-communicado the next few days.)

On 7/3/25 10:12, Jesse Rosenstock wrote:
> Since util-linux/util-linux at 6c87a3a (taskset: Accept 0 pid for current
> process), util-linux's taskset has accepted a 0 PID for the taskset
> process.

Hmmm, that doesn't apply cleanly either. I saved the email to a file and 
did "git am today.eml" and it went:

Applying: taskset: Document and add test for 0 PID
error: corrupt patch at line 18
Patch failed at 0001 taskset: Document and add test for 0 PID

Which is not great error reporting on git's part. It can't be line 18 of 
today.eml (which was an email header line I deleted, but nothing 
changed). It presumably doesn't mean line 18 of the email body either, 
which is still in the description (which hasn't got a format it can 
really object to?), so it's presumably somewhere down in the actual diff 
hunks but relative to what...

Ok, working backwards from where your email client wordwrapped the 
patch, it starts counting from here:

> ---
>   tests/taskset.test   | 11 ++++-------
>   toys/other/taskset.c |  1 +
>   2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/taskset.test b/tests/taskset.test
> index acd2869fbc..06ba64f512 100755
> --- a/tests/taskset.test
> +++ b/tests/taskset.test
> @@ -14,16 +14,13 @@
>   MASK=$(printf %x $(((1<<CPUS)-1)))
>   LAST=$(printf %x $((1<<(CPUS-1))))
> 
> -# Yes, taskset -p gets the arguments backwards. Because gnu.
> +# pid 0 means the taskset process itself.
>   testing 'set mask to all' \
> -  '(taskset -p $MASK $BASHPID >/dev/null; taskset -p $BASHPID | sed
> "s/.*: //")'\

And that 18th line is split. Ok, I can fix the wordwraps up here, and... 
it still doesn't work.

$ git am today2.eml
Applying: taskset: Document and add test for 0 PID
error: patch failed: toys/other/taskset.c:26
error: toys/other/taskset.c: patch does not apply

What's going on with THAT. Hmmm...

 >  testing 'set mask to last' \
 > -  '(taskset -p $LAST $BASHPID >/dev/null; taskset -p $BASHPID | sed 
"s/.*: //")'\
 > -  "$LAST\n" '' ''
 > +  '(taskset $LAST taskset -p 0 | sed "s/.*: //")' "$LAST\n" '' ''
 >
 >  # alas procps-ng always says "-" for -o cpu so fetch the field from 
/proc
 >  testing 'run on first' \

vs

> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       24)testing 'set mask to last' \
> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       25)  '(taskset -p $LAST $BASHPID >/dev/null; taskset -p $BASHPID | sed "s/.*: //")'\
> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       26)  "$LAST\n" '' ''
> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       27)
> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       28)# alas procps-ng always says "-" for -o cpu so fetch the field from /proc
> 77cb95ab9       (Rob Landley    2025-06-23 14:59:16 -0500       29)testing 'run on first' \

Well it's not version skew again. You got that sorted.

Ok, run the patch through dos2unix to normalize, use tail -n +skip to 
line up starting lines that SHOULD MATCH and then pipe them through hd 
and diff the result ala:

diff -u <(tail -n+68 today2.eml | hd) <(tail -n+26 toys/*/taskset.c | 
sed 's/^/ /' | hd) | less

Well, for one thing your email client strips trailing spaces, so the 
lines with just a single space on them (which is how patch indicates 
"keep this blank line": the first character being - says remove it, if 
it's + it says add it, and if it's " " it says match it as context) also 
got corrupted. (The other question is whether the "help" blocks have 4 
leading spaces on their blank lines to maintain the indent level for 
kconfig, but it looks like they do not in this instance...)

But even going in and manually fixing THAT up, it's still complaining... 
Aha:

> -00000000  20 0a 20 20 20 20 20 2d  70 20 53 65 74 2f 67 65  | .     -p Set/ge|
> +00000000  20 0a 20 20 20 20 20 2d  70 09 53 65 74 2f 67 65  | .     -p.Set/ge|

The help text has a tab after options (so the indent takes fewer bytes 
to print out, this is consistent through all the toybox help text), and 
your email client converted that tab into a space. (And my brain just 
glossed it over in visual inspection, this is why I use the diff of 
hexdumped trimmed input trick.)

(FYI I don't mind you sending me patches as attachments. It's the 
linux-kernel guys who insist that you put them inline in the message 
body without corrupting them, which is always a challenge with modern 
email software. Heck, they taught "git am" to read that weird = mime 
syntax for gluing stuff together because that's what it does rather than 
being 8 bit clean so you can do utf8.)

As long as I'm manually editing the patch file anyway, I'm gonna tweak 
your description slightly. Not to put words into your mouth, but:

> Since util-linux/util-linux at 6c87a3a (taskset: Accept 0 pid for current
> process), util-linux's taskset has accepted a 0 PID for the taskset
> process.
> 
> https://github.com/util-linux/util-linux/commit/6c87a3ac5ee96194e0e461db24b1bbfe369bdb59

Could just be:

> Since util-linux at 6c87a3ac5ee9 (taskset: Accept 0 pid for current
> process), util-linux's taskset has accepted a 0 PID for the taskset
> process.

My logic being (and maybe I need to figure out how to update either 
design.html, code.html, or the FAQ):

1) I try to consistently use 12 digits to uniquely identify a commit 
because that's what Linus recommended switching to when his initial 
default of 7 digits started to have collisions in large codebases:

https://lkml.org/lkml/2010/10/28/287

You can never GUARANTEE collision avoidance, any hash could 
theoretically collide, but 12 digits balances "human readable" with 
"sufficiently unique". For modern numbers, my merged "one big 
repository" that goes back to 0.0.1  (ala 
https://landley.net/kdocs/fullhist/ and 
https://github.com/mpe/linux-fullhistory ) currently has 1.43 million 
commits:

   $ git log | grep ^commit | wc
   1426246

And presumably https://en.wikipedia.org/wiki/Birthday_attack has the 
math to say how likely that is to have a collision with 12 digits of 
hexadecimal hashes. Um hex digit is 4 bits, 1<<(12*4) is 
281474976710656, probability of a collision existing is 1 - range! / 
(range-count)!*range^count so:

   x=1<<(12*4)
   y=1426246
   print 1-x!/(x-y)!*(x^y)

Which very much wants a bignum library to calculate, and presumably 
that's what bc is for:

$ bc -c $'x=1<<(12*4)\ny=1426246\nx!/(x-y)!*(x^y)'
File x=1<<(12*4)
y=1426246
x!/(x-y)!*(x^y) is unavailable.

Pity bc's syntax sucks more than my patience at trying to beat one lie 
of calculation out of it. Oh well. Presumably if 12 digits wasn't still 
"good enough" we'd have heard by now.

Note that since git's plumbing has always allowed fairly arbitrary hash 
truncation, all the web repositories let you do it too:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ff41df1cb26

So even if you ARE going to do A url, you can use 12 digits. (Which is 
what I do in my blog.)

2) "util-linux" is sufficiently identifying if it's the package name the 
distros use in all the repositories:

$ dpkg-query -S $(which taskset)
util-linux: /usr/bin/taskset

So you probably don't really NEED a repo for a "well known" package that 
has the same name in debian, redhat, alpine...

3) The Microsoft Github repository isn't official for that project, it's 
just a mirror. The project's primary repository is on kernel.org:

https://pkgs.alpinelinux.org/package/edge/main/x86/util-linux

$ aptitude show util-linux | grep -i homepage
Homepage: https://www.kernel.org/pub/linux/utils/util-linux/

Similarly busybox's git repo is on git.busybox.net and QEMU's is at 
gitlab.com/qemu-project/qemu and the various FSF projects live on the 
FSF's various https://xkcd.com/927/ attempts at "standardization" ala 
glibc and binutils-gdb are on sourceware.org/git, gcc is on 
gcc.gnu.org/git, bash is on cgit.git.savannah.gnu.org/cgit/bash.git and 
so on.

Most established projects don't seem to trust Microsoft Github.

4) I prefer to avoid treating Microsoft Github as special the same way I 
try to avoid treating gnu implementations of things as special.

Partly this is because they're _not_ special: by the time gnu was 
writing commands circa 1987-1993 there were usually at _least_ Unix 
Version 7, BSD, System V, Coherent, and possibly separate AIX and 
Solaris implementations of the command already existing. And then I 
often did a fresh from-scratch implementation for busybox before writing 
a toybox version.

And partly because I don't trust the specific would-be dictator 
organization to be a good steward of the technology or userbase. 
Microsoft wanting github/linkedin to become a category killer the same 
way facebook wanted to replace the rest of the internet is not a secret: 
they documented their "embrace, extend, extinguish" strategy all the way 
back in 1998 (https://en.wikipedia.org/wiki/Halloween_documents) and 
have never actually STOPPED trying to do that. I personally consider it 
a bad thing.

(Ok, previously microsoft had said MSN would "replace the internet" or 
similar in a 1995 internal memo: 
https://www.wired.com/2010/05/0526bill-gates-internet-memo/ and the 1998 
one was specifically about trying to kill what became known as the "LAMP 
stack" plus the browser to convert the market niche into microsoft 
proprietary technology. Really the 1995 one was about how they could eat 
AOL and the 2008 one was about how they could eat Netscape, they've 
never really understood open community projects as anything other than 
some kind of wildlife infestation they could spray for and I'm not 
convinced they do even today, it's just now they're trying to eat IBM 
and Valve. (They can't eat Sun, it's dead.) Just as the catholic church 
can't imagine NOT believing in gods (you can't just never think about 
santa claus, you must HATE him, that means you think about him even 
MORE, actual unbelievers can't REALLY exist...) microsoft can't imagine 
a motivation OTHER than capitalism for getting out of bed in the morning...)

Rob

P.S. yes I over-explained because I feel guilty about editing your patch 
while still having the metadata crediting you as the author when it 
wasn't EXACTLY what you said. Taking credit away is bad, putting words 
in people's mouth is bad, but I want a good commit message. But given 
how much manual fixing up I had to do to get your patch to apply 
(verbatim), I think I've earned a little commit message tweaking in this 
instance. :)