001 Title: Industry standards for the Linux and UNIX operating systems. 002 Source: Andrew Josey 003 Unapproved Draft: 27 Feb 2003 004 ------------------------------------------------------------------- 005 Section 1 006 1. Introduction 007 1.1 Purpose 008 This paper gives a commentary on the key standards and specifications 009 relating to the Linux and UNIX operating systems. This includes a look 010 at the formal IEEE POSIX standards, and industry led efforts such as 011 The Open Group's Single UNIX Specification, the Free Standards Group 012 Linux Standard Base Specification and the Embedded Linux Consortium 013 Platform Specification. 014 Particular emphasis is placed on the coverage of each specification, 015 often in the context of a so-called "Profile". 016 1.2 Scope 017 This document offers a guide in understanding compliance to various 018 standards applicable to Linux and UNIX systems, including real-time 019 and embedded systems. Detailed information about the contents of the 020 standards and specifications is outside of the scope of this document. 021 1.3 Intended Audience 022 This document is intended to be used by systems engineers, technical 023 managers and procurement officers. 024 1.4 Document Overview 025 This document is organized in the following ways: Section two provides an 026 overview of the IEEE POSIX Standards. Section three provides an overview 027 of related industry specifications. Section four looks at Profiles. 028 ------------------------------------------------------------------ 029 Section 2 030 2. IEEE POSIX Standards 031 This section provides an overview of the IEEE POSIX standards, 032 notably IEEE Std 1003.1 and IEEE Std 1003.13. 033 2.1 The Portable Application Standards Committee (PASC) 034 The IEEE Computer Society's Portable Application Standards Committee 035 (PASC) is the group that has and continues to develop the POSIX family 036 of standards. Historically, the major work has been undertaken within 037 Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 038 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of 039 the PASC standards has been to promote application portability at the 040 source code level. 041 More Information about the Portable Application Standards Committee 042 (PASC) is available from: 043 http://www.pasc.org 044 2.2 IEEE POSIX 1003.1 System Application Interface (C API) 045 Historically, this has been the base standard upon which the POSIX 046 family of standards has been built. In keeping with its original focus 047 on the UNIX system, it is aimed at interactive timesharing computing 048 environments. The latest version of this standard was produced by the 049 Austin Group (see later). 050 The first edition of IEEE Std 1003.1 was published in 1988. Subsequent 051 editions were published in 1990, 1996 and 2001. The 1990 edition was a 052 revision to the 1988 edition and became the stable base standard onto 053 which further amendments were added. The 1990 edition was also approved 054 as an international standard, ISO/IEC 9945-1:1990. 055 The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, 056 and 1003.1i-1995 amendments to the base standard, keeping the stable core 057 text unchanged. The 1996 edition of IEEE Std 1003.1 was also approved 058 as an international standard, ISO/IEC 9945-1:1996. 059 In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was 060 published, enabling POSIX to address embedded real-time applications 061 and smaller footprint devices (see Profiles). 062 In 1999 the decision was taken to commence the first major revision to 063 the core base standard in ten years, including a merger with the 1003.2 064 standards for Shell and Utilities which had been a separate standard 065 up to this point . It was agreed that this work be undertaken by the 066 Austin Group (see later ). As part of this decision the PASC decided 067 to cease rolling amendments to the base standard after completion of 068 IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. 069 These projects were rolled into the 2001 edition of IEEE Std 1003.1. 070 It was decided to convert other projects in progress to standalone 071 documents. 072 2.3 IEEE POSIX 1003.2 Shell and Utilities 073 This standard defines a standard source level interface to the shell 074 and utility functionality required by application programs, including 075 shell scripts. This standard has been incorporated into the IEEE Std 076 1003.1-2001 produced by the Austin Group. 077 2.4 IEEE POSIX Standards for Real-time 078 The PASC Real-time System Services Working Group (SSWG-RT) has developed 079 a series of standards that amend IEEE Std 1003.1-1990 and a profile 080 standard (IEEE Std 1003.13-1998). 081 The Real-time amendments to IEEE Std 1003.1-1990 are as follows: 082 IEEE Std 1003.1b-1993 Realtime Extension 083 IEEE Std 1003.1c-1995 Threads 084 IEEE Std 1003.1d-1999 Additional Realtime Extensions 085 IEEE Std 1003.1j-2000 Advanced Realtime Extensions 086 IEEE Std 1003.1q-2000 Tracing 087 These have all been folded in as options within the revision project 088 undertaken by the Austin Group (see below) in producing IEEE Std 1003.1-2001. 089 The Real-time profile is known as IEEE Std 1003.13-1998. This is discussed 090 in further detail in another section of this document. At the time 091 of writing there is a revision to IEEE Std 1003.13-1998 in progress to 092 align it with IEEE Std 1003.1-2001. 093 2.5 The Austin Group 094 The Austin Group is the working group that manages the POSIX.1 095 specificaton. It is a joint working group of members of the IEEE Portable 096 Applications Standards Committee, members of The Open Group, and members 097 of ISO/IEC Joint Technical Committee 1. 098 The Austin Group arose out of discussions amongst the parties which 099 started in early 1998, which led to an initial meeting and formation 100 of the group in September 1998. The purpose for this group has 101 been to revise, combine, and update the following standards: ISO/IEC 102 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the Base 103 Specifications of The Open Group Single UNIX Specification. 104 After two meetings, an agreement was signed in July 1999 between The 105 Open Group and the Institute of Electrical and Electronics Engineers 106 (IEEE), Inc., to formalize the project with the first draft of the 107 revised specifications ("the revision") being made available at the 108 same time. Under this agreement, The Open Group and IEEE agreed to share 109 joint copyright of the resulting work. 110 The base document for the revision was The Open Group's Base volumes 111 of its Single UNIX Specification, Version 2. These were selected since 112 they were a superset of the existing POSIX.1 and POSIX.2 specifications 113 and had some organizational aspects that would benefit the audience for 114 the new revision. 115 The approach to specification development has been one of "write once, 116 adopt everywhere", with the deliverables being a set of specifications 117 that carry the IEEE POSIX designation, The Open Group's Technical 118 Standard designation, and an ISO/IEC designation (see below). This set of 119 specifications also forms the core of the Single UNIX Specification, Version 3. 120 The Open Group and the IEEE approved the Austin Group specifications in 121 late 2001, as The Open Group Base Specifications, Issue 6, and IEEE Std 122 1003.1-2001 respectively. ISO/IEC approval followed about twelve 123 months later. 124 The Austin Group Specifications consist of the following : 125 * Base Definitions, Issue 6 (XBD) 126 * Shell and Utilities, Issue 6 (XCU) 127 * System Interfaces, Issue 6 (XSH) 128 * Rationale (Informative) 129 The revision has tried to minimize the number of changes that 130 implementations which conform to the earlier versions of the approved 131 standards would require to bring them into conformance with the current 132 standard. Specifically, the scope of the project excluded doing any 133 ``new'' work, but rather collecting into a single document what had 134 been spread across a number of documents, and presenting it in what 135 had been proven in practice to be a more effective way. Some changes 136 to prior conforming implementations were unavoidable, primarily as a 137 consequence of resolving conflicts found in prior revisions, or which 138 became apparent when bringing the various pieces together. Also, since 139 the revision now references the 1999 version of the ISO C standard, 140 there are a number of unavoidable changes that have been made which will 141 affect applications portability. 142 More information on the Austin Group, including how to join and 143 participate is available from its web site at 144 http://www.opengroup.org/austin/ 145 A html version of the specification is freely available from 146 The Open Group's Single UNIX Specification web site at 147 http://www.unix.org/version3/ 148 2.5.1 Relationship to the ISO C Standard 149 The most recent revision to the ISO C standard occurred in 1999. 150 The ISO C standard is itself independent of any operating system in so 151 much as it may be implemented in many environments including 152 hosted environments. 153 The POSIX and Single UNIX Specification have a long history 154 of building on the ISO C standard and deferring to it where applicable. 155 Revisions of POSIX.1 prior to the Austin Group specification built upon 156 the ISO C standard by reference only, and also allowed support for traditional 157 C as an alternative. The Single UNIX Specification in contrast, 158 included manual pages for the ISO C interfaces. 159 The Austin Group took the latter approach. The standard 160 developers believed it essential for a programmer to have a single 161 complete reference place. They also recognized that deference to the formal 162 standard had to be addressed for the duplicate interface definitions 163 which occur in both the ISO C standard and their document. 164 It was agreed that where an interface has a version in the ISO C standard, 165 the DESCRIPTION section should describe the relationship to the ISO C 166 standard and markings added as appropriate within the manual page to 167 show where the ISO C standard has been extended. 168 A block of text was added to the start of each affected reference 169 page stating whether the page is aligned with the ISO C standard or 170 extended. Each page was parsed for additions beyond the ISO C standard 171 (that is, including both POSIX and UNIX extensions), and these extensions 172 are marked as CX extensions (for C Extensions). 173 2.6 ISO/IEC 9945:2002 174 In late 2002, the ISO/IEC Joint Technical Committee approved the joint 175 revision to POSIX and the Single UNIX Specification as an International 176 Standard. Designated as ISO/IEC 9945:2002, the joint revision forms 177 the core of The Open Group's Single UNIX Specification Version 3 (IEEE 178 1003.1-2001, POSIX.1). 179 The combining of the IEEE POSIX specifications and the Single UNIX 180 Specification into ISO/IEC 9945:2002 Parts 1 to 4 replaces the existing 181 ISO/IEC 9945-1:1996 (IEEE 1003.1, 1996 version), and ISO/IEC 9945-2:1993 182 (IEEE Std 1003.2, 1992 version). 183 ISO/IEC 9945 consists of the following parts, under the general title 184 Information technology Portable Operating System Interface (POSIX): 185 Part 1: Base Definitions 186 Part 2: System Interfaces 187 Part 3: Shell and Utilities 188 Part 4: Rationale 189 ------------------------------------------------------------------ 190 Section Three 191 3. Related Industry Standards 192 This section looks at related industry standards initiatives that 193 have built on or taken similar approaches to the IEEE POSIX standards. 194 3.1 The Single UNIX Specification 195 The Open Group has been the custodian of the specification for the UNIX 196 system and the trademark since 1993. This is a source level API 197 specification which has traditionally built upon the formal IEEE POSIX 198 standards. It is vendor neutral and not tied to any particular 199 implementation. 200 The project that led to the creation of the Single UNIX Specification 201 started when several vendors (Sun Microsystems, IBM, 202 Hewlett-Packard, Novell/USL, and OSF) joined together to provide a 203 single unified specification of the UNIX system services. By 204 implementing a single common definition of the UNIX system services, 205 third-party independent software vendors (ISVs) would be able to more 206 easily deliver strategic applications on all of these vendors' 207 platforms at once. 208 A two-pronged approach was used to develop the Single UNIX 209 Specification. First, a set of formal industry specifications was chosen 210 to form the overall base for the work. This would provide stability, 211 vendor neutrality, and lay a well charted course for future application 212 development, taking advantage of the careful work that has gone into 213 developing these specifications. It would also preserve the portability 214 of existing applications already developed to these core models. 215 The XPG4 Base was chosen as the stable functional base from which to 216 start. XPG4 Base supports the POSIX.1 system interface and the ISO 217 C standards at its core. It also provided a rich set of 174 commands 218 and utilities. 219 To this base was added the traditional UNIX System V Interface Definition, 220 (SVID) Edition 3, Level 1 calls, and the OSF Application Environment 221 Specification Full Use interface definitions. This represented the stable 222 central core of the latter two specifications. 223 The second part of the approach was to incorporate interfaces that were 224 acknowledged common practice but had not yet been incorporated into 225 any formal specification or standard. The intent was to ensure existing 226 applications running on UNIX systems would port with relative ease to a 227 platform supporting the Single UNIX Specification. A survey of real world 228 applications was used to determine what additional interfaces would be 229 required in the specification. 230 Fifty successful application packages were chosen to be analyzed using 231 the following criteria: 232 - Ranked in International Data Corp's. 1992, 'Survey of Leading UNIX 233 Applications', 234 - The application's domain of applicability was checked to ensure that no 235 single application type (for example, databases) was overly represented, 236 - The application had to be available for analysis either as source code, 237 or as a shared or dynamic linked library. 238 From the group of fifty, the top ten were selected carefully, ensuring 239 that no more than two representative application packages in a particular 240 problem space were chosen. The ten chosen applications were: 241 AutoCAD; Cadence; FrameMaker; Informix; Island Write/Paint; Lotus 1-2-3; 242 SAS (4GL); Sybase; Teamwork; WordPerfect 243 APIs used by the applications that were not part of the base 244 specifications were analyzed: 245 - If an API was used by any of the top ten applications, it was considered 246 for inclusion. 247 - If an API was not used by one of the top ten, but was used by any 248 three of the remaining 40 applications, it was considered for inclusion. 249 - While the investigation of these 50 applications was representative 250 of large complex applications, it still was not considered as a broad 251 enough survey, so an additional 3500 modules were scanned. If an API 252 was used at least seven times in modules that came from at least two 253 platforms (to screen out vendor specific libraries), then the interface 254 was considered for inclusion. 255 The goal was to ensure that APIs in common use were included, even if 256 they were not in the formal specifications that made up the base. Making 257 the Single UNIX Specification a superset of existing base specifications 258 ensured any existing applications should work unmodified. 259 The Single UNIX Specification has evolved through several iterations; 260 Version 2 in 1997 incorporated updates to the formal standards, 261 as well as industry driven additions such as large file handling, 262 dynamic linking, datasize neutrality and extended threads functionality. 263 Together with the specification, The Open Group has provided a 264 certification program, the latest instance of which is UNIX 98 for the 265 Single UNIX Specification Version 2. This is supported by a family 266 of test suites providing over 95% coverage of the specification. 267 The certification program has been cited in many major procurements 268 including NASA SEWP III. 269 The Open Group also makes a number of test tools for the UNIX System 270 freely available for measuring conformance to its specifications, 271 see 272 http://www.opengroup.org/testing/downloads.html 273 The majority of the latest version of the Single UNIX Specification, 274 Version 3, was produced by the Austin Group (see earlier), and comprises 275 the Base Specifications, Issue 6 , plus X/Open Curses, Issue 4, Version 2. 276 Detailed information on the Single UNIX Specification, including 277 accessing the version 3 specification in html 278 is available at 279 http://www.unix.org/ 280 HTML and PDF versions of the many of the specifications for 281 the Single UNIX Specification are available from The Open Group's 282 online publication catalog at 283 http://www.opengroup.org/publications/ 284 Information on the UNIX certification program which operates under 285 The Open Group's Open Brand, can be found at 286 http://www.opengroup.org/openbrand/ 287 The Practical Guide to the Open Brand is available at 288 http://www.opengroup.org/openbrand/Certification_Guide/ 289 The register of Certified Products is available at 290 http://www.opengroup.org/openbrand/register/ 291 3.2 The Linux Standard Base Specification 292 The Linux Standard Base (LSB) Specification is an application binary 293 interface standard for shrink-wrapped applications. The LSB draws 294 on the source standards of IEEE POSIX 1003.1-1990 and The Open Group 295 Single UNIX Specification Version 2 for many of its interfaces although 296 does not formally defer to them preferring to document any differences 297 where they exist. It also extends the source standards in other areas 298 (such as graphics), and includes the necessary details such as the binary 299 execution file formats to support a high volume application platform. 300 Although in theory the LSB is not tied to the GNU/Linux operating system, 301 in practise the binary definitions are tightly coupled to Linux and 302 the GNU C compiler. 303 The LSB is available as a family of specifications supporting a number 304 of processor architectures including IA32, PPC32 and IA64. There is a 305 generic specification, common to all the processor architectures known 306 as the "generic LSB" (or gLSB), and for each processor architecture an 307 architecture-specific specification ("archLSB") describing the details 308 that vary by processor architecture. 309 To support the specification, the LSB includes a number of 310 development tools, including test suites, and a set of reference 311 conforming applications. Binary versions of the test suites and 312 reference applications are used for formal LSB certification of runtime 313 environments. All the major Linux vendors today have certified LSB 314 systems. 315 Detailed information on the LSB Certification Program is available 316 from the LSB Certification Authority at 317 http://www.opengroup.org/lsb/cert/ 318 The Guide to LSB Certification is available at: 319 http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html 320 The LSB Certification Register can be viewed at: 321 http://www.opengroup.org/lsb/cert/register.html 322 3.3 The Embedded Linux Consortium Platform Specification 323 The Embedded Linux Consortium Platform Specification (ELCPS) is a profile 324 specification built upon the Linux Standard Base Specification. This 325 is a source level API profile and is not intended to specify a binary 326 interface. This is discussed in further detail in the next section 327 on profiles. 328 ------------------------------------------------------------------ 329 Section Four 330 4. Profiles. 331 Profiles are an important concept in procurement of systems based on 332 IEEE POSIX. They address multiple problems, firstly the proliferation 333 of standards, which can lead to confusion and sometimes conflicting 334 standards; secondly, they overcome some of the generality of the base 335 standards, which include multiple options and have a large range of 336 applicability; thirdly, they provide ability to subset the base standard 337 into smaller building blocks which can be combined to more closely fit 338 specific smaller footprint devices and systems. 339 4.1 What is a Profile? 340 A profile is a collection of one or more specifications, or in the 341 case of IEEE Std 1003.13 and the Embedded Linux Consortium Platform 342 Specification a collection of certain subsets of a standard, that can 343 be used to define a certain application environment. A profile may be 344 specified at various different levels of detail, for example, the Linux 345 Standard Base Specification profiles over thirty other specifications; 346 the UNIX 98 Workstation profile collects the UNIX 98 requirements and the 347 Common Desktop Environment requirements together without much details 348 and is thus a "thin profile". The converse of this is a detailed 349 or so-called "thick profile", such as IEEE Std 1003.13 and ELCPS, 350 which select certain options and collections of functions within an 351 individual standard. 352 4.2 Profile Selection 353 If you are considering a procurement you have several options in stating 354 your conformance requirements: 355 1. Select an existing profile 356 2. Tailor an existing profile -- reusing existing building blocks, 357 either reducing functionality in a profile, or adding functionality 358 to a profile 359 3. Build your own profile 360 There are tradeoffs you might want to consider, for example selection 361 of an existing profile should yield higher applications portability 362 and increase the probability of multiple vendors being able to supply 363 systems meeting that profile, thereby increasing your choice of solutions. 364 4.3 IEEE Std 1003.13 Profiles 365 IEEE Std 1003.13-1998 is a family of four related real-time profiles 366 ranging in size from the very small through a full-featured platform 367 conforming to essentially all of IEEE Stds 1003.1, 1003.1b (real-time), 368 and 1003.1c (threads), and the parallel Ada binding 1003.5b, with realtime 369 options chosen. The smaller profiles specify just that subset of POSIX 370 interfaces needed to "clothe" widely-used small kernels such as pSOS 371 (from ISI), VxWorks (from Wind River), and VRTX32 (now from Mentor), 372 and the ORKID interface standard (from VITA), which although very similar 373 in approach and function, differ greatly in interface details. 374 Standardization of these interfaces is expected to yield the same benefits 375 for embedded and real-time systems as standardization of the UNIX system 376 interfaces did for workstations. In addition, the P1003.13 interfaces 377 are chosen to allow multi-computer distributed systems to be built, 378 such as those used in factory automation. Such systems are typically 379 set up as a hierarchy, with a few large-profile machines at the top, 380 and a large number of smaller profile machines at the bottom controlling 381 this or that piece of machinery, perhaps with an intermediate layer of 382 supervisory machines between top and base, and all communicating with 383 peers, superiors, and subordinates, as needed. 384 4.3.1 Minimal Real-time System Profile IEEE Std 1003.13 PSE51 385 This profile is intended for embedded systems, with a single 386 multi-threaded process, no file system, no user and group support and 387 only selected options from IEEE Std 1003.1b-1993. 388 4.3.2 Real-time Controller Profile IEEE Std 1003.13 PSE52 389 This profile is an extension of the minimal real-time system profile with 390 added support for a file system. There is only a single multi-threaded 391 process. Files and directories are supported, there is no user and group 392 support, and all options from IEEE Std 1003.1b-1993 are supported except 393 the process related ones. 394 Note: The above two profiles, PSE 51 and PSE 52 assume that the entire 395 computer is the "process", with one or more POSIX threads running within. 396 This supports hardware lacking the memory-management features that are 397 needed to implement POSIX processes. 398 4.3.3 Dedicated Real-time Profile IEEE Std 1003.13 PSE53 399 This profile is an extension of the minimal real-time system profile with 400 the addition of support for multiple processes. There is no file system, 401 and no user and group support. All options from IEEE Std 1003.1b-1993 402 are supported except for the file-related ones. 403 4.3.4 Multi-Purpose Real-time Profile IEEE Std 1003.13 PSE54 404 This profile is intended for multi-purpose real-time applications as well 405 as interactive users. It includes multiple processes, each of which may 406 be multi-threaded. All base 1003.1 functionality is incorporated including 407 a file system and user and group support. All the options from IEEE 408 Std 1003.1b-1993 are supported. Support for IEEE Std 1003.2-1992 is 409 also required. 410 Note: The above two profiles, PSE 53 and PSE 54 assume that the hardware 411 is capable of implementing multiple processes. 412 4.4 The Austin Group Subprofiling Considerations 413 The Austin Group considered including a set of options similar to the 414 "Units of Functionality'' contained in IEEE Std 1003.13-1998. However, 415 as the development of IEEE Std 1003.1-2001 continued, the standard 416 developers felt it premature to fix these in normative text. 417 The approach instead was to include a general requirement in 418 normative text regarding subprofiling, which allows subprofiles to 419 subset both mandatory and optional functionality required for POSIX 420 Conformance or XSI Conformance. Such profiles are required to organize 421 the subsets into Subprofiling Option Groups. An informative section, 422 Appendix E, is included in the Austin Group specifications, containing 423 a representative set of subprofiling options applicable to specialized 424 realtime systems. The Austin Group specification does not require that 425 the presence of Subprofiling Option Groups be testable at compile-time (as 426 symbols defined in any header) or at runtime (via sysconf() or getconf). 427 4.4 The Embedded Linux Consortium Platform Specification (ELCPS) 428 The ELCPS takes a similar approach to IEEE Std 1003.13, although does 429 not address any realtime functionality. Its purpose is to define embedded 430 applications environments based on the Linux Operating system. 431 It draws on the subprofiling considerations outlined in the Austin 432 Group specifications, and provides forty-four function groupings and 433 three so-called System Environments (SE), the Minimal Environment, 434 the Intermediate Environment and the Full Environment . Each SE is a 435 superset of the one below it. An SE may optionally provide functionality 436 not required. 437 4.4.1 The Minimal System Environment 438 The Minimal SE is intended for deeply embedded systems, with requirements 439 only for a single multi-threaded process, no file system, no interactive 440 users support and only selected function groupings from the LSB. It 441 requires 371 functions from 7 function groupings. 442 4.4.2 The Intermediate System Environment 443 The Intermediate SE is an extension of the Minimal SE with the addition of 444 required support for multiple processes, file system, asynchronous I/O and 445 dynamic linking. It requires 667 functions from 27 function groupings. 446 4.4.3 The Full System Environment 447 The Full SE provides a rich multipurpose Linux operating system 448 environment, with the omission of any utilities. It requires 1121 449 functions coming from 44 groups. 450 4.5 FIPS Profiles 451 The Federal Information Processing Standards (FIPS) are a series of 452 U.S. government procurement standards managed and maintained on behalf 453 of the U.S. Department of Commerce by the National Institute of Standards 454 and Technology (NIST). During the 1990s NIST produced a number of FIPS 455 profiles (FIPS 151-1, FIPS 151-2 and FIPS 189) to support compatibility 456 and interoperability among US Government systems implementing POSIX. 457 FIPS 151-2 superseded FIPS 151-1 and profiled IEEE Std 1003.1-1990 458 selecting certain options from the base standard and raising certain 459 minimum values for implementation defined constants. The FIPS 151-2 460 requirements only mapped to the base standard (IEEE Std 1003.1-1990) 461 and these have now been folded into the revision of 1003.1. 462 FIPS 189 was based on IEEE Std 1003.2-1992. 463 FIPS 151-2 and FIPS 189 have now been withdrawn. 464 4.6 UNIX System Profiles 465 The Open Group UNIX System profiles build upon the POSIX standards using 466 them as building blocks. Three profiles are included for UNIX 98 which is 467 the mark for systems conforming to the Single UNIX Specification, Version 2. 468 UNIX 98 is the base profile standard providing a rich programming environment. 469 UNIX 98 Workstation is the base standard plus the Common Desktop 470 Environment (CDE) graphical interface and programming libraries. 471 UNIX 98 Server is the base standard plus server related functionality 472 for internet/intranet services and Java support. 473 Since these build upon the base standard they are multi-user, 474 timesharing systems and not directly suitable as an embedded solution. 475 Some applicability for real-time systems can be obtained by procuring 476 a UNIX 98 platform supporting the Real-time Feature Group, thereby 477 providing a development environment supporting all the features and 478 options in IEEE Std 1003.1b-1993 and IEEE Std 1003.1c-1995. 479 A future profile supporting Version 3 of the Single UNIX Specification 480 is being developed and will be announced during 2003. 481 Appendix A. Feature Matrix 482 This matrix summarizes the requirements of the profiles mentioned above. 483 Feature PSE PSE PSE PSE Min Int Full FIPS UNIX LSB 484 51 52 53 54 SE SE SE 151-2 98 1.2 485 Processes - - X X - X X X X X 486 Pipes - - X X - X X X X X 487 Files and Directories - X - X - X X X X X 488 Basic I/O X X X X X X X X X X 489 Signals X X X X X X X X X X 490 Users and Groups - - - X - - X X X X 491 File Synchronization X X X X X X X - X X 492 Memory Mapped Files - X - X - X X - X X 493 Memory Protection - - X X - X X - X X 494 Process Priority - - X X - - - - o - 495 Scheduling 496 Memory Locking X X X X - - - - o - 497 Synchronized I/O X X X X - - - - o - 498 Asynchronized I/O - X X X - X X - o o 499 Hi Resolution Clocks X X X X - - - - o - 500 & Timers 501 Realtime Signals X X X X - - - - o - 502 Semaphores X X X X - - - - o - 503 Shared Memory X X X X - - - - o - 504 IPC Message Passing X X X X - - - - o - 505 Threads X X X X * * * - X o 506 Thread Safe Functions X X X X * * * - X - 507 Thread Attribute X X X X * * * - X - 508 Stack Address 509 Thread Attribute X X X X * * * - X - 510 Stack Size 511 Thread Process Shared - - X X * * * - X - 512 Thread Priority X X X X * * * - o - 513 Scheduling 514 Thread Priority X X X X * * * - o - 515 Inheritence 516 Thread Priority X X X X * * * - o - 517 Protection 518 Feature PSE PSE PSE PSE Min Int Full FIPS UNIX LSB 519 51 52 53 54 SE SE SE 151-2 98 1.2 520 Sockets - - - - - - X - X X 521 XCURSES - - - - - - - - X X 522 ISO C89 - - - - - - X X X X 523 ISO C99 - - - - - - - - - - 524 Shell & Utilities 525 _POSIX2_C_BIND X X X X - - - - X X 526 _POSIX2_C_DEV X X X X - - - - X - 527 _POSIX2_CHAR_TERM - - - X - - - - X - 528 _POSIX2_FORT_DEV - - - - - - - - o - 529 _POSIX2_FORT_RUN - - - X - - - - o - 530 _POSIX2_LOCALEDEF - - - - - - - - X - 531 _POSIX2_SW_DEV X X X X - - - - o - 532 _POSIX2_UPE - - - X - - - - X - 533 o=option 534 *=optional if LSB threads supported, otherwise mandatory 535 ------------------------------------------------------------------ 536 Draft: 27 Feb 2003