Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand

[DJ Delorie <dj at redhat dot com>]

>  > > 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.