On Wed, Feb 16, 2011 at 3:55 PM, Jeffrey Hutzelman <[email protected]> wrote: > --On Wednesday, February 16, 2011 09:14:55 AM -0600 Andrew Deason > <[email protected]> wrote: > >> On Tue, 15 Feb 2011 22:59:23 -0500 >> Jeffrey Hutzelman <[email protected]> wrote: >> >>> On SPARC, there is virtually no advantage to building 64-bit versions >>> of most binaries, >> >> Virtual memory space? > > _Most_ binaries don't need more than 2GB of virtual address space. > The fileserver would likely benefit, on machines with enough RAM to make > this worthwhile. Most of our programs certainly would not. >
Hi Jeff, The new DAFS threaded salvager additionally falls into this category (as well as the standalone salvager when large volumes are involved, thanks to the--potentially enormous--vnode essence vectors). Furthermore, fssync-debug and salvsync-debug need to be 64-bit binaries as well (thanks to us directly marshalling pointers and other variable-width types, which is, admittedly, a design flaw for which I'll take responsibility). To simplify the build system (and avoid a few fssync protocol changes), this also means volserver should be a 64-bit binary... > I'd suggest building a 64-bit fileserver and 64-bit versions of most of the > libraries we export (in addition to the 32-bit versions, of course). But > that's about it. > I concur this would be ideal. However, then we get into the argument about whether our build system has any business twiddling CFLAGS. I suppose we could have a special configure switch to do this special behavior for people who want an optimal build, but that is likely to be quite contentious... > Of course, that needs to be selectable, but I think it's a fine default. > There are very few SPARC Solaris machines that are likely to run current > OpenAFS but are not 64-bit capable. I'm not sure current Solaris still even > supports anything that old. 32-bit (sparc) kernel support was dropped during development of Solaris 10. For how much longer do we want to support 8 and 9? -Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
