[Toybox] [PATCH] ulimit: actually use the units we claim.

[Rob Landley]

On 5/12/23 00:58, Rob Landley wrote:
> On 5/11/23 22:54, Rob Landley wrote:
>> Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed order,
>> so just defining the table entries in that order (and reordering the flags to be
>> in that order) makes a chunk of the logic drop out...
> 
> Except that -a outputs the results in alphabetical order...

And it varies by architecture (left myself a note!) so I went and implemented
the alphabetical one, got to the note about WHY I hadn't done that last time,
and ripped it out again.

Meanwhile, looking at prlimit:

1) it outputs bytes.
2) it outputs stuff in a completely different (non-machine-readable) order.
3) it consumes hard:soft limits with hard: and :soft being independently
specifiable and a limit _without_ a colon setting both at the same time. (Wheee!)

None of which the current toybox prlimit implementation is doing, although in my
defense when I added prlimit it wasn't actually present in my distro yet. There
still isn't a _bash_ prlimit, and ulimit() was only built into bash because
getrlimit/setrlimit only applied to the current process, prlimit() was just the
same thing with both get and set arguments in one syscall plus a pid argument so
you could getppid() it and thus implement everything with the same codepath
(which I did).

So after some head scratching and false starts, what I'm currently leaning
towards doing is:

1) add units to ulimit like you did.
2) keep prlimit mostly like ulimit, but have it show/accept bytes.
3) have prlimit with no arguments default to -a (show all)
4) Add the HARD:SOFT parsing (to both). Keep ulimit's no-colon default to soft
and make prlimit's no-colon default be "both".
5) Remove the multi-argument exclusions, go ahead and output all the enabled
ones (with -a enabling all), but output them in alphabetical order instead of
command line order. (This means the ulimit -c -c -c thing... ain't gonna?)

Yeah, there's a fundamental simplifying design assumption in lib/args.c which is
that we care about what got specified but not the _order_ in which it was
specified, and that winds up with some corner cases (as we're seeing). It
wouldn't be that hard to add an option for it to populate a linked list:

struct args_seen {
  struct args_seen *next;

  long long flag;
  char *arg;
};

And then we could just traverse that in the cases we care about order, I'm just
not sure it's worth it? Then again, there's code in sed that cares, and tar
cares, and now this sort of cares... but I'm already proposing keeping prlimit
way different than ulimit because the table prlimit outputs with no arguments is
just silly...

Writing code is easy. Figuring out what it should DO is hard.

Rob