jgd@csd4.csd.uwm.edu (John G Dobnick) (01/01/91)
Submitted-by: jgd@csd4.csd.uwm.edu (John G Dobnick) This is perhaps a silly question, but since I haven't used this year's quota of silliness yet... :-) 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 (But, with multiple processors, shouldn't we also get multiple serial numbers? Hmmm.) Processor option mask (I believe this is an 'extension') Memory interleave factor (also an extension, I believe) 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. b) If is was considered, why was it not included. 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.") Have a Happy New Year, folks! -- 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 51
henry@zoo.toronto.edu (Henry Spencer) (01/02/91)
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
schnoebe@convex.com (Eric Schnoebelen) (01/03/91)
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
jgd@convex.csd.uwm.edu (John G Dobnick) (01/03/91)
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
andrew@alice.att.com (Andrew Hume) (01/06/91)
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
rml@hpfcdc.fc.hp.com (Bob Lenk) (01/08/91)
Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk) In article <16480@cs.utexas.edu>, jgd@csd4.csd.uwm.edu (John G Dobnick) writes: > Was consideration given to including some mechanism to retrieve > hardware configuration information via 'standard' means? Not much. Remember that the purpose of POSIX.1 was to define interfaces for portable applications. There is little if any use that a portable application can make of such information. Through the trial use standard (1986) there was an appendix (Appendix H) requiring each system to supply some such information off-line. That appendix was dropped in the first draft following trial use; the portions deemed useful were made available via interfaces like sysconf(), pathconf(), <limits.h>, and <unistd.h>. Bob Lenk rml@fc.hp.com {uunet,hplabs}!fc.hp.com!rml Volume-Number: Volume 22, Number 65