1003.1 Appendix H. Additional System Characteristics
Moderator, John Quarterman
std-unix at ut-sally.UUCP
Mon Sep 29 07:22:47 AEST 1986
The POSIX(TM) Trial Use Standard has attached to it an Appendix H
whose purpose was to include parameters not in <limits.h> but
that might be of use to an application porter in determining
how well or if an application would run on a target system.
This appendix was removed from the working document at the Palo
Alto meeting of the working group on the grounds that while
a guide of this type for the application porter might well
be useful, Appendix H is not it. This is because the information
it requests is too arbitrary, too vague, and it was written by
representatives of vendors, not users.
A committee of representatives of users was appointed to produce
a proposal for a replacement appendix. It occurs to me that there
are a lot of users on USENET. It would be interesting to gather
comments on what should be in the new appendix.
A couple of caveats: I am not on the subcommittee just mentioned,
and they are under no obligation to pay attention to anything that
appears here. And minor modifications to the previous appendix
are not what is wanted: a plan for a complete new set of implementation
characteristics is needed. Given those constraints, I suspect someone
out there may still be able to make useful suggestions.
Since Appendix H is an appendix and not part of the Trial Use Standard
proper, I am permitted to post it to the network. Here is its full text
as it was before it was removed in Palo Alto:
H. Additional System Characteristics
In the header file <limits.h> we have placed parameters that
may vary from system to system and need to be used by
applications in a dynamic fashion. There is also a set of
parameters that can influence how an application program
runs (or if it will run) which are not dynamic application
parameters, but may be essential in matching an
implementation and application to make sure they work
together.
Should conforming implementations be required to provide
this in printed form on a product model basis? Should it be
recommended that application implementors define what
parameters from this list impact the ability to run their
application?
This would eventually go into the definitions section
(Ch. 2) or perhaps a section of its own. Feedback on these
items is sought in the trial use period to determine which
are considered to be of use in determining application
portability and capacity.
H.1 Conforming implementation characteristics
In addition to the parameters specified in the header file
<limits.h>, the following information shall be provided to
more clearly describe a conforming implementation. Vendors
of conforming applications should provide a similar
description indicating the required and preferred
characteristics of an implementation that might use an
application. Such a specification might include how these
parameters need to vary as application use varies (for
example, with increase in the number of users, in the number
of records, or in the transaction rates). Some of these
characteristics are simple numbers, others may be in the
control of a system manager within limits and some may
differ within limits of hardware configurations. In all of
these cases the limits shall be described. In any case
there are no specified range of values for these parameters
required by this standard. Some of these limit values may
be mutually exclusive for a given implementation or product.
Is sizeof(int)=sizeof(ptr)?
Maximum number of users logged in at one time
Maximum number of user IDs
Maximum number of active processes
Maximum number of processes connected by a pipe
Maximum number of groups
Maximum number of users in a group
Maximum number of hours until clock rollover
H.1 Conforming implementation characteristics 1
IEEE Std 1003.1 POSIX Appendix H Trial Use Standard
Calendar date/time when calendar rollover occurs
Maximum number of serial ports
Number of ports that support Modem Control
Maximum bit rate per serial port
Maximum aggregate character input rate
Maximum aggregate character output rate
Maximum aggregate character input & output rate
Maximum number of directories
Maximum number of levels of directory nesting
Maximum number of files per logical volume
Maximum number of logical volumes concurrently mounted
Maximum number of locks per logical volume
Maximum number of locks active at one time
Maximum number of files that can be opened concurrently
Maximum number of files a process can open concurrently
Maximum logical file size
Maximum physical file size
Maximum logical volume size
Maximum physical disk capacity (multi-spindles)
Maximum delay in writting modified buffers to disk
Minimum disk storage occupied by OS & essential tools
Maximum disk storage occupied by OS including tools
Implementation supports swapping of processes?
Implementation supports virtual memory paging?
Maximum physical memory capacity
Maximum physical memory address space per process
Maximum logical address space per process
Maximum text/instruction address space per process
Can text/instruction address space be shared?
Maximum local data space per process
Maximum size for a single array in bytes
Maximum global (shared) data space per process
Maximum stack space per process
Minimum RAM used by resident OS kernel
Maximum RAM used by resident OS kernel
Maximum number of characters significant in external C
variable and procedure names
Internal character representation (ASCII,...)
Number of bits used for internal character storage
Number of bits/character permitted in string I/O
Number of bits/character permitted in file names
Floating point format (IEEE, other)
Floating point mantissa range
H.1 Conforming implementation characteristics 2
IEEE Std 1003.1 POSIX Appendix H Trial Use Standard
Floating point exponent range
Number of bits per register
Number of registers that can be assigned to pointer variables
Number of registers that can be assigned to short variables
Number of registers that can be assigned to integer variables
Number of registers that can be assigned to long variables
Number of registers that can be assigned to float variables
Number of registers that can be assigned to double variables
Media classes supported:
1/2 in. tape, 9 track, 1600 bpi
1/2 in. tape, 9 track, 6250 bpi
Qic-11, 1/4 in. streamer tape
Qic-24, 1/4 in. streamer tape
5.25 inch floppy, 8 512-byte sectors/track, 96 tpi
5.25 inch floppy, 8 512-byte sectors/track, 48 tpi
Some number of these questions are configuration-specific
and may vary dynamically in execution (for instance, a
system has a theoretical maximum disk storage capacity, at
execution it has some maximum of connected storage, and at
any point in time the maximum amount available that is
mounted is in flux). This may call for three levels of
specifying some of this data:
1. Published theoretical maximum values
2. Static configuration files that may be read and
interpreted by an executing program
3. System calls that provide dynamic snapshots of key
information.
Please provide feedback on which of these may require the
second or third form of description.
H.1 Conforming implementation characteristics 3
Volume-Number: Volume 7, Number 5
More information about the Mod.std.unix
mailing list