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?) > 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. > 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
