On Wed, May 17, 2023 at 1:27 AM Rob Landley <r...@landley.net> wrote:
> Sorry for the radio silence, typing this in a very sleep deprived state > from an > airport. :) > > On 5/15/23 12:53, enh wrote: > > On Sun, May 14, 2023 at 9:31 PM Rob Landley <r...@landley.net > > <mailto: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? > > I mean the constants vary by architecture. Three architectures overload: > > $ grep -r RLIMIT_ arch/*/include | sed 's@[^/]*/\([^/]*\)[^:]*@\1@' > alpha:#define RLIMIT_NOFILE 6 /* max number of open > files */ > alpha:#define RLIMIT_AS 7 /* address space limit */ > alpha:#define RLIMIT_NPROC 8 /* max number of processes > */ > alpha:#define RLIMIT_MEMLOCK 9 /* max locked-in-memory > address space */ > mips:#define RLIMIT_NOFILE 5 /* max number of open > files */ > mips:#define RLIMIT_AS 6 /* address space limit */ > mips:#define RLIMIT_RSS 7 /* max resident set size */ > mips:#define RLIMIT_NPROC 8 /* max number of processes > */ > mips:#define RLIMIT_MEMLOCK 9 /* max locked-in-memory > address space */ > sparc:#define RLIMIT_NOFILE 6 /* max number of open > files */ > sparc:#define RLIMIT_NPROC 7 /* max number of processes > */ > > Which is why it wasn't already sorted by architecture with the value to > feed > into the syscall implicit in the table position. > > The generic is 5-9 are RSS, NPROC, NOFILE, MEMLOCK, AS. > > (Way back in the dark ages, Linux tried to be compatible with the the > dominant > existing unix's ABI on various architectures, so you could link their .o > files > into Linux executables, the same sort of silly thing lgpl calls for. This > stopped being particularly interesting 20 years ago, but we're stuck with > legacy > architecture variation for backwards compatibility with _ourselves_ > because of > it...) > > > 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? > > It's why I _didn't_ do it, and on my current review going "this would b > emuch > simpler organized THIS way", I went and rewrote it all and then hit the > comment > inn the cleanup stage when I was mostly done and went "oh right"... > > (This is why mkroot needs to run the test suite, for regression testing > across > architectures...) > > > 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? > > The _input_ side is easy to do, especially since it doesn't break existing > users. > > > 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". > > So... display, change, display what you changed it to? (Except you know > what you > changed it to, there's no deltas, so it's just... reading back what you > wrote to > confirm it took?) > yeah, exactly. (your later "what if there's a hard limit in the way?" point is a non-testing example where you might want to do that.) > > i think the only reasonable alternative to that is "any given invocation > > _either_ sets _or_ shows; no mixing". > > Ah, I wasn't clear. Yes, it would only set with one argument. 5) above was > about > display. Making "ulimit -d -e" show both: the easy way to do it is to still > output in alphabetical order. Which is clear because more than one has > display > prefixes. One is machine parseable "just result". That part's true of bash > now. > > The difference I was proposing is that bash produces different output for: > > $ ulimit -d -e > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > $ ulimit -e -d > scheduling priority (-e) 0 > data seg size (kbytes, -d) unlimited > > And I was gonna let toybox just always produce the enabled outputs in > alphabetical order. > yeah, given that this is human-readable rather than machine-readable anyway, that seems like it should probably be fine? "good enough for now" anyway! > > 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?) > > If the value is clamped to the hard limit and you didn't check what the > hard > limit was before trying to set it... > > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
