std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/29/86)
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