From billt@pongo74.West Wed Jun 8 11:49 PDT 1994 Date: Wed, 8 Jun 1994 11:50:46 -0700 From: billt@pongo74.West (Bill Taylor) To: psarc-materials@sac Subject: 1994/196 overview PSARC 1994/196 PowerPC Header Files Bill Taylor @ West -------------------------------------------------------------------------------- 1. What specifically is the proposal that we are reviewing? ON Consolidation header files that will be used for Solaris on PowerPC. The modified (or new) files appear in the following source subtrees: usr/src/head usr/src/uts/common usr/src/uts/ppc usr/src/uts/prep Accompanying materials for this case present the following information about the above classes of files. ppc.headers.changes A file showing diffs of the files in usr/src/head and usr/src/uts/common that are expected to change. ppc.headers.new A list of files that are being added in the "ppc" instruction set architecture directory and the "prep" platform directory. ppc.dklabel Arguments for our choice of disk label. 2. What is the motivation for it? To have Solaris 2.x running on yet another "volume" platform. 3. What is its plan? The basic plan is to get Solaris on PowerPC to become part of the 495 train. 4. Are there related projects in Sun? Three other projects are closely related to this one. They are: Solaris Kernel for PowerPC Solaris Libraries for PowerPC Solaris Commands for PowerPC 5. What is the technical content of the project? Please provide diagrams that make the project's interfaces clear. The following is the list of interfaces and/or discussion points as viewed by me (Bill Taylor). ppc.headers.changes dklabel.h - PowerPC is using the same label as on Intel. See one of the attachments for discussion. syscall.h - architecture specific system call, or not? user.h - structure member added. Does this adversely affect existing interfaces? Should the function that uses this new member be implemented differently? 6. How is the project delivered into the system? Identify packages, directories, libraries, databases, ...? This project leads towards a full set of PowerPC packages built by the ON Consolidation. 7. What are the project's hardware platform dependencies? Is it expected to work on SPARC and Intel (and PowerPC)? What will be affected in porting? This is part of the foundation for Solaris on PowerPC, that should have no adverse effect on SPARC and Intel. 8. System administration: - How will the project's deliverables be installed and (re)configured? - How will the project's deliverables be uninstalled? - Does it use inetd to start itself? - Does it need installation within any global system tables? - Does it use a naming service such as NIS or NIS+? - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? N/A. 9. What is its UNIX operational environment: - Environment variables? - Exit status? Signals issued? Signals caught? (See "man(5) signal".) - Device drivers directly used (e.g. /dev/audio)? - .rc/defaults or other resource/configuration files or databases? - Does it use any "hidden" files (filename begins with ".") or temporary files? Does it use any locking files? Does it use Solaris locking facilities? - Command line or calling syntax: o What options are supported? o Does it conform to getopt() parsing requirements? o Is there support for standard forms, e.g. "- display" for X programs? Are these propagated to sub-environments? - What shared libraries does it use? (Hint: if you have code use "ldd")? Static libraries? - Which Solaris release does it run on? - Does it depend on kernel features not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? N/A 10. What is its window/desktop operational environment? - X resources, e.g. .Xdefaults: Supported? Propagated to sub- environments? - X properties: Which ones does it depend on? Which ones does it export, and what are their types? - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste,Drag and Drop, Props, Find, Stop? - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? - Which window-system toolkit/desktop does your project depend on? - Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? - Which X extensions does it use (e.g. PEX, SHM, DGA, Multi-Buffering..? (Hint: use "xdpyinfo") Does it use NeWS? - Will it work with XTerminals such as Sun's Hamlet? - How does it use colormap entries? What are your plans for sharing them? N/A 11. What are your project's other external interfaces (exported and imported)? - Exported Public Library APIs and ABI's - Protocols (public or private) - Drag and Drop - ToolTalk - Cut/Paste - Other interfaces - What other applications should it interoperate with? How will it do so? - Is it "pipeable"? How does it use stdin, stdout, stderr? - What are the significant file formats, names, syntax, and semantics? - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? - How are the interfaces documented clearly enough for a non-Sun client to use them successfully? - What is the classification of these interfaces in the Interface Tax- onomy (e.g. "Standard", "Public", "Uncommitted", etc.; see the inter- face taxonomy document in /net/benet/benet/SAC/doc/interface.taxonomy). N/A 12. What are its other significant internal interfaces (inter-subsystem and inter-invocation)? - Protocols (public or private) - Private ToolTalk usage - Files - Other N/A 13. How do the interfaces deal with applicable standards? - How is it ICCCM compliant? - Is it Look and Feel compliant? (See OL checklist, or the CDE checklist when available.) Discuss. - Are there any other standards it conforms to (or deviates from)--- (e.g. Sparc/Intel ABI, OMG/CORBA,POSIX, SVID, XPG (XOPen Portablity Guide), ...? N/A 14. Is the interface extensible? How is the interface expected to evolve? - How is versioning handled? - What was the commitment level of the previous version? Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? - What are the clients over which a change should be managed? How is transistion to a new version to be accomplished? What are the conse- quences to ISV's and their customers? N/A 15. How do the interfaces adapt to a changing world? - Will it migrate to DOE? What will need to be added (e.g., distributed operation)? What will need to be discarded? How easy will it be to encapsulate this application (e.g., access the data via DOE interface)? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? A networked filesystem model (i.e., a network-wide file manager)? - What are its COSE plans? - What security issues do you address in your project? N/A 16. What internationalization issues are involved? (if strings are used, how are they accessed? N/A 17. How will the project contribute (positively or negatively) to "system load" and "perceived performance": - What are the performance goals of the project? How were they evaluated? On what type of test platform? - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? - MT is standard with Solaris 2.2. What is your project's MT model? For example, is it MT Safe? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? Will it require large files/databases (for example, new fonts)? - Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? - What are the project's effects on boot time requirements? N/A 18. How does the project deal with failure and recovery? - How will it respond to failures? (Does it ever require reboot? Use of stop key? Can it lock up?) - How does your project deal with network failures (including partition and re-integration)? - Can it save/restore? Include? - Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? N/A 19. Issues? Please identify the issues which you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... See 5 above. 20. Appendices: - List of exported and critical imported interfaces with their prior and proposed classifications. - One-Pager. - Prototype specification. - References to other documents (copies to be places in case directory). See 1 above.