On Sun, May 14, 2023 at 9:31 PM Rob Landley <r...@landley.net> wrote:
> 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!)
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?
> 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.
>
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?
> 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?)
>
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".
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?)
> 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
>
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
