On Sun Jun 04, 2000 at 06:06:55PM +0200, Andi Kleen wrote:
> Andries Brouwer <aeb@veritas.com> writes:
>
> > On Sun, Jun 04, 2000 at 01:35:51AM -0600, Erik Andersen wrote:
> >
> > > The following patch reinstates the traditional sysinfo(2) interface by
> > > returning bytes (not units of PAGE_SIZE) for memory values.
> >
> > > + /* These are in units of PAGE_SIZE, but this interface
> > > + * has always returned bytes. Make it return bytes */
> > > + val.totalram*=PAGE_SIZE;
> > > + val.freeram*=PAGE_SIZE;
> > > + val.sharedram*=PAGE_SIZE;
> > > + val.bufferram*=PAGE_SIZE;
> > > + val.totalswap*=PAGE_SIZE;
> > > + val.freeswap*=PAGE_SIZE;
> > > + val.totalhigh*=PAGE_SIZE;
> > > + val.freehigh*=PAGE_SIZE;
> >
> > You forgot setting mem_unit to 1.
> > Why can't your application multiply by mem_unit?
Because someone broke a long standing interface and retrofitted it with new
semantics. That is bad. If a new interface is needed to reflect new things
that the kernel can do, then the kernel should provide these new abilities via
a new interface (unless the old interface was obviously broken). The worst
thing about this change is that it breaks source code without making it obvious
that the source code has been broken (no compiler warnings at all -- code just
compiles the same as always but behaves differently), and it breaks binaries,
such that the binaries do not know they have been broken. A segfault would be
much more obvious.
Because my application needs to be able to be compiled under both 2.2 and 2.4,
and needs to run correctly under both 2.2 and 2.4. In order to add in the
multiply by mem_unit, I would need to copy the 2.2 and the 2.4 version of
struct sysinfo into my own code (since mem_unit is not available under 2.2) and
then check at runtime via uname which kernel is running to determine which
struct to use and whether a multiply is needed. This take a simple long
standing interface and turns it into a mess to use.
> > The present patch is no good, I suppose. For example, it wouldnt
> > allow more than 4 GiB memory or swap on a 32-bit machine.
>
> That shouldn't be changed binary incompatible though. Rather a
> ``sysinfo64'' call needs to be added.
I very much agre. ``sysinfo64'' is definately needed. I would be happy to
code it up if everyone is agreed that this is the Right Thing(tm).
Lacking vast amounts of Ram myself, I am curious how the extra memory beyond
4GiB shows up on a 32 bit platform such as x86? Does it all show up only as
highmemory or does it also increase the value of totalram and friends as well?
-Erik
--
Erik B. Andersen Web: http://www.xmission.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:19 EST