This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
> > > The patch makes use of physmem.c from GNU sort (textutils) as
> > > suggested by Andi Kleen to determine the amount of RAM on the system.
> > > I copied that into libiberty since it may be useful to other projects.
>
> I don't see why not. We've copied stuff from the GCC dir to libiberty
> before. Snarfing from textutils should be no different. DJ?
There are two legal considerations:
1. The disclaimer/assignment used to contribute that file to textutils
probably doesn't apply to libiberty. For the gcc->libiberty case
one could argue that libiberty is part of the gcc project and thus
a gcc assignment covers libiberty as well, but libiberty is not
part of textutils.
2. physmem.c is GPL, not LGPL or GPL-plus-exceptions. While there are
other GPL files in libiberty, there have been times when that has
caused problems, especially if there's a chance that the function
may eventually get used in any of the exported runtime libraries.
And two technical considerations:
1. 'double' is a poor choice for RAM, since you never have fractions
of a byte, and adding 'double' where it's not needed pulls in FPU
functions, perhaps emulators (djgpp on i386), and longer task
switching (linux).
2. Adding public headers to libiberty, IMHO, should not be done
without considerable thought to long term use and portability. I
really don't like changing the API in non-backward-compatible ways.