🚀 go-pugleaf

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

In article <16397@cs.utexas.edu> jgd@csd4.csd.uwm.edu writes:
>Our CONVEX system, which claims POSIX compliance, has a system call
>that returns "system configuration" information...

It is important to understand that "POSIX compliant" invariably means
"POSIX superset", since many significant functions are not part of the
current POSIX standard, 1003.1.  There is no POSIX `getsysinfo' call.
The closest you get is `sysconf()', which can be used to ask about a
few things like the maximum number of open files.  None of the things
you mention are in the list.

>	c) How does one interrogate the system, in a 'standard' way,
>	   to determine physical memory size?   (My initial guess is
>	   that the answer will be "You don't.")

Correct.  In any case, it is typically not a very useful piece of
information, since there is no simple correlation between the size of
physical memory and how much your program is allowed to use.
-- 
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 22, Number 52

Submitted-by: schnoebe@convex.com (Eric Schnoebelen)

jgd@csd4.csd.uwm.edu writes in <16397@cs.utexas.edu>:
-Submitted-by: jgd@csd4.csd.uwm.edu (John G Dobnick)
-
-Our CONVEX system, which claims POSIX compliance, has a system call
-that returns "system configuration" information.

	First off, getsysinfo(2) is not a POSIX standard routine.  It
is an extension to UNIX that Convex has supported for quite some time.
It is not available in the conforming modes of the C development
environment (compiler and libraries), only the extended/backwards
compatible modes.

	The features of getsysinfo(2) are available as part of the
uname(2) call as well, as an extension to the standard uname
structure.

-One item glaringly missing is the size of physical memory installed.
-The writeup for the function claims it returns "system information", not
-"CPU information".   In my book, a "system" includes processors AND
-memory.
-
-My question, to those of you who know what happened in the
-standardization process is threefold:
-
-	a) Was memory size even considered for inclusion in the
-	   'getsysinfo' (or whatever it's really named) call.

	According to the standard, the only things that have to be
returned by uname(2) are the system (implementation) name, the node
(host) name, the release name, the version name, and the hardware type
name. See page 77, section 4.4 of the little green book.

-	c) How does one interrogate the system, in a 'standard' way,
-	   to determine physical memory size?   (My initial guess is
-	   that the answer will be "You don't.")

	Correct!.  For the Convexen, you  might try contacting the TAC,
and asking them. I seem to remember a little program that determines
just that floating around.

--
Eric Schnoebelen		eric@cirr.com		schnoebe@convex.com
	Biology is the only science in which multiplication means the
			same thing as division.

Volume-Number: Volume 22, Number 54

Submitted-by: jgd@convex.csd.uwm.edu (John G Dobnick)

Following up on my own posting, which I _did_ say was silly, and which
a few kind people have assured me _was_ silly [I knew I shouldn't have
posted that thing New Year's Eve -- too much eggnog around],

>From article <16397@cs.utexas.edu>, by jgd@csd4.csd.uwm.edu (John G Dobnick):
> 
> Our CONVEX system, which claims POSIX compliance, has a system call
> that returns "system configuration" information.  If my memory serves
> (I'd check, but the books are at work, and the machine is being "PM"ed),
> the C-library function 'getsysinfo' retrieves this information.  Among
> the items retrieved are
> 
>     *	System type
>     *	Operating system type
>     *	Operating system level (or version number)
>     * Processor type
> 	Processor serial number
> 	number of Processors 
> 	Processor option mask 
> 	Memory interleave factor

(* -- uname fields.  All others are CONVEX extensions)

Memory didn't serve -- what I was thinking of was the "uname()" call,
which does _not_ include any hardware specific information -- only OS
related things.  [It's amazing how eggnog muddles the thought processes]

The hardware specific information another source and is an implementation
specific extension.

Please allow me to rephrase my question as:

    Was consideration given to including some mechanism to retrieve
    hardware configuration information via 'standard' means?

[I'll shut up now.  Besides, there's still some eggnog left. :-)]
-- 
John G Dobnick  (JGD2)
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: jgd@csd4.csd.uwm.edu             ATTnet: (414) 229-5727
UUCP: uunet!uwm!csd4.csd.uwm.edu!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

Volume-Number: Volume 22, Number 57

Submitted-by: andrew@alice.att.com (Andrew Hume)

	sometimes knowing physical memory size, or at least
what is left over for user programs, is useful. particularly
for user programs which manage their own memory. although
what is actually meant here is how much memory do i have
really quick efficent access to.

Volume-Number: Volume 22, Number 63