<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 17, 2023 at 1:27 AM 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">Sorry for the radio silence, typing this in a very sleep deprived state from an<br>
airport. :)<br>
<br>
On 5/15/23 12:53, enh wrote:<br>
> On Sun, May 14, 2023 at 9:31 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> 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<br>
> order,<br>
> >> so just defining the table entries in that order (and reordering the<br>
> 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!) <br>
> <br>
> seriously? i'm guessing because it's sorted on the value of the constant?<br>
<br>
I mean the constants vary by architecture. Three architectures overload:<br>
<br>
$ grep -r RLIMIT_ arch/*/include | sed 's@[^/]*/\([^/]*\)[^:]*@\1@'<br>
alpha:#define RLIMIT_NOFILE 6 /* max number of open files */<br>
alpha:#define RLIMIT_AS 7 /* address space limit */<br>
alpha:#define RLIMIT_NPROC 8 /* max number of processes */<br>
alpha:#define RLIMIT_MEMLOCK 9 /* max locked-in-memory address space */<br>
mips:#define RLIMIT_NOFILE 5 /* max number of open files */<br>
mips:#define RLIMIT_AS 6 /* address space limit */<br>
mips:#define RLIMIT_RSS 7 /* max resident set size */<br>
mips:#define RLIMIT_NPROC 8 /* max number of processes */<br>
mips:#define RLIMIT_MEMLOCK 9 /* max locked-in-memory address space */<br>
sparc:#define RLIMIT_NOFILE 6 /* max number of open files */<br>
sparc:#define RLIMIT_NPROC 7 /* max number of processes */<br>
<br>
Which is why it wasn't already sorted by architecture with the value to feed<br>
into the syscall implicit in the table position.<br>
<br>
The generic is 5-9 are RSS, NPROC, NOFILE, MEMLOCK, AS.<br>
<br>
(Way back in the dark ages, Linux tried to be compatible with the the dominant<br>
existing unix's ABI on various architectures, so you could link their .o files<br>
into Linux executables, the same sort of silly thing lgpl calls for. This<br>
stopped being particularly interesting 20 years ago, but we're stuck with legacy<br>
architecture variation for backwards compatibility with _ourselves_ because of<br>
it...)<br>
<br>
> but that would have to be a run-time sort, no, to vary by architecture? how does<br>
> that even happen? did chet accidentally sort on the wrong field in a struct, and<br>
> no-one's reported the bug?<br>
<br>
It's why I _didn't_ do it, and on my current review going "this would b emuch<br>
simpler organized THIS way", I went and rewrote it all and then hit the comment<br>
inn the cleanup stage when I was mostly done and went "oh right"...<br>
<br>
(This is why mkroot needs to run the test suite, for regression testing across<br>
architectures...)<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>
> <br>
> including the "8m means 8*1024, not 8*1024*field-specific-multiplier" thing?<br>
> want me to send a patch/new revision of my current patch for that?<br>
<br>
The _input_ side is easy to do, especially since it doesn't break existing users.<br>
<br>
> 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>
> <br>
> that actually seems worse than just rejecting it? the only use i can see for<br>
> this functionality is what i was doing: "show me before and after around a set".<br>
<br>
So... display, change, display what you changed it to? (Except you know what you<br>
changed it to, there's no deltas, so it's just... reading back what you wrote to<br>
confirm it took?)<br></blockquote><div><br></div><div>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.)</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">
> i think the only reasonable alternative to that is "any given invocation<br>
> _either_ sets _or_ shows; no mixing".<br>
<br>
Ah, I wasn't clear. Yes, it would only set with one argument. 5) above was about<br>
display. Making "ulimit -d -e" show both: the easy way to do it is to still<br>
output in alphabetical order. Which is clear because more than one has display<br>
prefixes. One is machine parseable "just result". That part's true of bash now.<br>
<br>
The difference I was proposing is that bash produces different output for:<br>
<br>
$ ulimit -d -e<br>
data seg size (kbytes, -d) unlimited<br>
scheduling priority (-e) 0<br>
$ ulimit -e -d<br>
scheduling priority (-e) 0<br>
data seg size (kbytes, -d) unlimited<br>
<br>
And I was gonna let toybox just always produce the enabled outputs in<br>
alphabetical order.<br></blockquote><div><br></div><div>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!</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">
> and to be clear, i have no proof anyone's actually using this, and i'm not sure<br>
> what it's for beyond debugging. (which is why it was useful for me while<br>
> actually _testing_ ulimit, but probably useless to anyone just _using_ ulimit?)<br>
<br>
If the value is clamped to the hard limit and you didn't check what the hard<br>
limit was before trying to set it...<br>
<br>
Rob<br>
</blockquote></div></div>