On Sun, Mar 24, 2002 at 09:43:18PM -0800, Andrew Morton wrote: > Theodore Tso wrote: > > > > And just to be clear ---- although in the past I've been really > > annoyed when glibc has made what I've considered to be arbitrary > > changes which have screwed ABI, compile-time, or link-time > > compatibility, and have spoken out against it --- in this particular > > case, I consider the fault to be purely the fault of the kernel > > developers, so there's no need having the glibc folks get all > > defensive.... > > So... Does the kernel need fixing? If so, what would you > recommend? 1) Created a new syscall for the unsinged setrlimit, not just for getrlimit. This should have been done from the very beginning, IMHO. 2) If the old value of RLIM_INFINITY is passed to the old setrlimit, translate it to the new value of RLIM_INFINITY. (This would not have been strictly necessary of glibc wasn't playing RLIM_INIFITY capping games; as it turns out, if you pass the "new" version of RLIM_INIFITY to an "old" 2.2 kernel, the right thing happens. So there really is no need for glibc to cap the limit of RLIM_INFINITY to the old value.) 3) RLIMIT_FILESIZE should not apply to block devices!!! - Ted
