Messages in this thread | | | Date | Thu, 6 May 2010 08:37:11 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Resource limits interface proposal [was: pull request for writable limits] |
| |
On Thu, 6 May 2010, Alexey Dobriyan wrote:
> On Wed, May 5, 2010 at 6:08 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Ok, I'm not entirely sure we need to care specially about INFINITY, > > _especially_ since INF is really rather big in 64 bits. So to some degree, > > making things 64-bit is _less_ likely to make INFINITIES a problem. > > I'm _sure_, someone will mention bloat and performance degradation > on 32-bit, so there will be config option for 32-bit in-kernel limits. > And if there will be config option, infinities are better be separated.
Umm. Why?
Adding an INF field will make it essentially impossible to use that thing as a compatibility function, and/or together with the legacy rlimit() system call. And that is going to be 99.999% of all uses.
I don't think you understand how system calls work. People don't use Linux-only features. It's been shown over and over and over again. People use the standard interfaces, and they don't _have_ that INF field. We can extend ranges by just updating structures (see "stat()" and friends) and a recompile will make it use higher limits, but we can't make programs use new features.
So there is _no_ upside. There would be _no_ programs ever using it.
Whether the internal limits for the kernel are 32-bit or not makes absolutely zero difference. And my argument is that _if_ they are 64-bit, that makes the INF field even _less_ interesting. So they go from "zero practical difference" in 32-bit to "f*ck it, nobody can _possibly_ care even in theory" in 64-bit.
If the internal limits are 32-bit, then you just turn any 64-bit value larger than the (32-bit) RLIM_INFINITY into a RLIM_INFINITY. And that's as good as you can get with mixing with the legacy interface anyway.
Linus
| |