On Sun, Mar 24, 2002 at 01:28:19AM -0800, H . J . Lu wrote: > > The problem is not all arches use (~0UL) for RLIM_INFINITY. > > What should we do about it? I know e2fsprogs-1.26 doesn't work on mips > nor alpha because of this. I don't think it works on sparc. Yeah, I forced the release of e2fsprogs 1.27 because of this, back on March 8th. That was my fault, and I fixed it as soon as I discovered it. (1.26 was released on Feb 3, and I released 1.27 on March 8th). In e2fsprogs 1.27, I do the following: #ifdef __linux__ #undef RLIM_INFINITY #if (defined(__alpha__) || ((defined(__sparc__) || defined(__mips__)) && (SIZEOF_LONG == 4))) #define RLIM_INFINITY ((unsigned long)(~0UL>>1)) #else #define RLIM_INFINITY (~0UL) #endif Basically because I can't depend on the RLIM_INFINITY being "right". (Remember, I'm trying to make sure that e2fsprogs can compile on any arbitrary glibc, and then run on any other-not-necessarily-the-same glibc, which gets "challenging".) The problem now is that some older glibcs are capping RLIM_INFINITY with the older value, and so a combination of a new kernel, new e2fsprogs, and old glibc results in problems. My current feeling about how to fix this is to bypass glibc altogether, and simply call the setrlimit system call directly. This is ugly-ugly-ugly, but I can't see another way around this. 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.... - Ted
