Re: git: d9d5f2c042a5 - main - cpuset: add --count [changed/broken command line parsing]

On 2/15/23, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 14, 2023, at 23:08, Mateusz Guzik <mjguzik@gmail.com> wrote:
>
>> On 2/15/23, Mark Millard <marklmi@yahoo.com> wrote:
>>> Mateusz Guzik <mjg_at_FreeBSD.org> wrote on
>>> Date: Sat, 04 Feb 2023 17:51:27 UTC :
>>>
>>>> The branch main has been updated by mjg:
>>>>
>>>> URL:
>>>> https://cgit.FreeBSD.org/src/commit/?id=d9d5f2c042a51a9f0dd69eb1fc349efd81ffa483
>>>>
>>>> commit d9d5f2c042a51a9f0dd69eb1fc349efd81ffa483
>>>> Author: Mateusz Guzik <mjg@FreeBSD.org>
>>>> AuthorDate: 2023-02-04 17:47:41 +0000
>>>> Commit: Mateusz Guzik <mjg@FreeBSD.org>
>>>> CommitDate: 2023-02-04 17:50:41 +0000
>>>>
>>>> cpuset: add --count
>>>>
>>>> Can be used to count the number of hardware threads in the cpu set.
>>>>
>>>> For example:
>>>> $ cpuset -g -p $$
>>>> pid 2440 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
>>>> 16,
>>>> 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34,
>>>> 35, 36, 37, 38, 39
>>>> pid 2440 domain policy: first-touch mask: 0, 1
>>>> $ cpuset -g --count -p $$
>>>> 40
>>>>
>>>> The intent is to replace calls to sysctl hw.ncpu and kern.smp.cpus
>>>> which
>>>> can be found in the tree, which are not adequate given existence of
>>>> cpusets.
>>>>
>>>> Right now only -g -p combination is supported to reduce complexity.
>>>> As anything else errors out, this can be expanded later as needed.
>>>>
>>>> Differential Revision: https://reviews.freebsd.org/D36351
>>>
>>> This broke long standing commands sequences in some makefiles
>>> that I use to build and run some benchmarks, the commands
>>> at issue involve use of cpuset.
>>>
>>> However I can show the oddity in a much simpler context:
>>>
>>> # cpuset echo "text"
>>> text
>>>
>>> # cpuset echo "-text"
>>> usage: cpuset [-l cpu-list] [-n policy:domain-list] [-s setid] cmd ...
>>>       cpuset [-l cpu-list] [-n policy:domain-list] [-s setid] -p pid
>>>       cpuset [-c] [-l cpu-list] [-n policy:domain-list] -C -p pid
>>>       cpuset [-c] [-l cpu-list] [-n policy:domain-list]
>>>              [-j jailid | -p pid | -t tid | -s setid | -x irq]
>>>       cpuset -g [-cir]
>>>              [-d domain | -j jailid | -p pid | -t tid | -s setid | -x
>>> irq]
>>>       cpuset -g --count -p pid
>>>
>>>
>>> By contrast, in my stable/13 context, so, showing the old behavior:
>>>
>>> # cpuset echo "-text"
>>> -text
>
> FYI: the use of quotes was in my original text for other
> reasons. I should not have duplicated them into the above
> examples. (Same results without quotes.)
>
>> the idiomatic way to pass progs to spawn is to denote the end of any
>> opts with --
>
> The cpuset man page gives no indication that it requires such
> notation. Programs with that requirement normally document it
> explicitly. (Programs that do not require the ntoation often
> allow the notation without documenting it.)
>
> There may be a consideration of how long it has allowed such
> a lack of use of "--" and how many things might break because
> it worked before.
>
> Lots of programs taking commands do not require such. For
> example: "time echo -text", "truss echo -text", and "ktrace
> echo -text". These have not and are not being changed to
> require such. They do allow the "--" notation.
>
>
> If it stays as it is, the change should probably be in UPDATING
> or other such place(s) that note where changes are required to
> keep things working.
>
>> so in particular you would:
>> cpuset -- echo -text
>
> Yep.
>
>> the fact that previous version worked without it is kind of a bug
>
> I disagree with that last statement, given the many programs
> that do not require such. Some programs have some specific
> notational complication lead to making it required. But, from
> what I've seen,  most of the others do not make "--" required.
>
>

So I found that on Linux 'perf stat' et al don't require --.

Due to a just found bug in the change anyway I decided to just whack
it: https://cgit.FreeBSD.org/src/commit/?id=2924ae099a1e8ffc5b6040f3af5645aa54c0f629

-- 
Mateusz Guzik <mjguzik gmail.com>