This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Fri, Dec 10, 1999 at 07:39:57AM -0800, Ulrich Drepper wrote: > Thorsten Kukuk <kukuk@suse.de> writes: > > > > You haven't read the mail. This will change because it's completely > > > unnecessary for platforms like Alpha. > > > > In your first mail, your wrote that you have problems with Alpha. > > Now you write it is unnecessary. This is not the same. > > I have problems and because of those I went to see rth who said the > change is unnecessary and not welcome. This isn't so hard to > understand. You haven't even tried to compile on Alpha to see how > broken it was so don't complain. > > > What is with SPARC ? Andreas has made the patches because we need > > them on 32 bit SPARC (I haven't test it on SPARC64 yet). > > Wel, then make the changes to the SPARC tree. But since there is no > ugetrlimit syscalls the question is whether it was wanted there at > all. The x86 is a special case since it actually allows 4GB memory > and more. Is this true for SPARC? If not the kernel change is not > necessary at all and *will* (note: future tense!!!) be changed back. > All it does in this case is adding more core where it never serves any > purposes. There are sparc 32bit boxes (SC2000/SS1000) with up to 20GB or so, but we do not support them (at most 2GB). It should not be hard with the new kmap infrastructure but a) I have just .5GB in such a machine b) it is lame slowish machine so I think I'll better spent my time on something else I don't have SuS handy, but does it say anything about the RLIM_INFINITY value? E.g. on Solaris it is either 0x7FFFFFFF, or (unsigned long)-3, depending if it is non-LFS or LFS compilation. In 64bit, it is always (unsigned long)-3. I strongly vote for RLIM_INFINITY being architectural define, so that architectures can choose their constants. We can choose any value on sparc64 in fact, because the userland is not cast in stone yet (BTW: David, your merge is buggy because sys_sparc32.c still works with RLIM_INFINITY32 as 0x7FFFFFFF so the syscall change is completely unnecessary. I think we should go with 32bit RLIM_INFINITY 0x7FFFFFFF and 64bit RLIM_INFINITY can be easily 0xFFFFFFFFFFFFFFFF). But there should definitely not be two syscalls in sparc 64bit userland, that's stupid. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.26 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |