<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 14, 2023 at 9:31 PM 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 5/12/23 00:58, Rob Landley wrote:<br>
> On 5/11/23 22:54, Rob Landley wrote:<br>
>> Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed order,<br>
>> so just defining the table entries in that order (and reordering the flags to be<br>
>> in that order) makes a chunk of the logic drop out...<br>
> <br>
> Except that -a outputs the results in alphabetical order...<br>
<br>
And it varies by architecture (left myself a note!) </blockquote><div><br></div><div>seriously? i'm guessing because it's sorted on the value of the constant? but that would have to be a run-time sort, no, to vary by architecture? how does that even happen? did chet accidentally sort on the wrong field in a struct, and no-one's reported the bug?</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">so I went and implemented<br>
the alphabetical one, got to the note about WHY I hadn't done that last time,<br>
and ripped it out again.<br>
<br>
Meanwhile, looking at prlimit:<br>
<br>
1) it outputs bytes.<br>
2) it outputs stuff in a completely different (non-machine-readable) order.<br>
3) it consumes hard:soft limits with hard: and :soft being independently<br>
specifiable and a limit _without_ a colon setting both at the same time. (Wheee!)<br>
<br>
None of which the current toybox prlimit implementation is doing, although in my<br>
defense when I added prlimit it wasn't actually present in my distro yet. There<br>
still isn't a _bash_ prlimit, and ulimit() was only built into bash because<br>
getrlimit/setrlimit only applied to the current process, prlimit() was just the<br>
same thing with both get and set arguments in one syscall plus a pid argument so<br>
you could getppid() it and thus implement everything with the same codepath<br>
(which I did).<br>
<br>
So after some head scratching and false starts, what I'm currently leaning<br>
towards doing is:<br>
<br>
1) add units to ulimit like you did.<br></blockquote><div><br></div><div>including the "8m means 8*1024, not 8*1024*field-specific-multiplier" thing? want me to send a patch/new revision of my current patch for that?</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">
2) keep prlimit mostly like ulimit, but have it show/accept bytes.<br>
3) have prlimit with no arguments default to -a (show all)<br>
4) Add the HARD:SOFT parsing (to both). Keep ulimit's no-colon default to soft<br>
and make prlimit's no-colon default be "both".<br>
5) Remove the multi-argument exclusions, go ahead and output all the enabled<br>
ones (with -a enabling all), but output them in alphabetical order instead of<br>
command line order. (This means the ulimit -c -c -c thing... ain't gonna?)<br></blockquote><div><br></div><div>that actually seems worse than just rejecting it? the only use i can see for this functionality is what i was doing: "show me before and after around a set". i think the only reasonable alternative to that is "any given invocation _either_ sets _or_ shows; no mixing".</div><div><br></div><div>and to be clear, i have no proof anyone's actually using this, and i'm not sure what it's for beyond debugging. (which is why it was useful for me while actually _testing_ ulimit, but probably useless to anyone just _using_ ulimit?)</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">
Yeah, there's a fundamental simplifying design assumption in lib/args.c which is<br>
that we care about what got specified but not the _order_ in which it was<br>
specified, and that winds up with some corner cases (as we're seeing). It<br>
wouldn't be that hard to add an option for it to populate a linked list:<br>
<br>
struct args_seen {<br>
  struct args_seen *next;<br>
<br>
  long long flag;<br>
  char *arg;<br>
};<br>
<br>
And then we could just traverse that in the cases we care about order, I'm just<br>
not sure it's worth it? Then again, there's code in sed that cares, and tar<br>
cares, and now this sort of cares... but I'm already proposing keeping prlimit<br>
way different than ulimit because the table prlimit outputs with no arguments is<br>
just silly...<br>
<br>
Writing code is easy. Figuring out what it should DO is hard.<br>
<br>
Rob<br>
</blockquote></div></div>