DOCSLIB.ORG

Writing Drivers for Netbsd

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Writing Drivers for Netbsd Writing Drivers for NetBSD Jochen Kunz Version 1.0.1e August 25th, 2003 An introduction into NetBSD’s autoconfig(0) system and the basics of de- vice drivers under NetBSD. 1 CONTENTS 2 Contents 1 Preface 4 2 The autoconf(9) system 6 2.1 config(8) . 6 2.2 ioconf.c and cfdata . 6 2.3 sys/kern/subr autoconf.c . 8 2.4 Attributes and Locators . 9 2.5 Where are my children? . 10 2.6 bus space(9) and bus dma(9) . 12 3 The autoconf(9) part of the rf(4) driver 14 3.1 Configuration files . 14 3.1.1 The kernel configuration file . 14 3.1.2 sys/dev/qbus/files.uba . 14 3.1.3 The device numbers . 15 3.2 Data structures for autoconf(9) . 17 3.3 Functions for autoconf(9) . 18 3.3.1 rfc match() . 18 3.3.2 rfc attach() . 21 3.3.3 rf match() . 24 3.3.4 rf attach() . 25 4 The core of the driver 27 4.1 Data structures of the driver . 27 4.1.1 Data structures per controller . 27 4.1.2 Data structure per drive . 28 4.2 The necessary functions . 29 4.2.1 rfdump() . 31 4.2.2 rfsize() . 31 4.2.3 rfopen() . 31 4.2.4 rfclose() . 35 4.2.5 rfread() and rfwrite() . 36 4.2.6 rfstrategy() . 37 4.2.7 rfc intr() . 41 4.2.8 rfioctl() . 48 LIST OF FIGURES 3 A rf.c 51 B rfreg.h 80 C License 83 D Version History 84 E Bibliography 85 List of Figures 1 device tree . 8 2 calling chain of autoconf(9) functions . 11 3 rf(4)’s interal states. 41 1 PREFACE 4 1 Preface This document is intended to teach the basics of Unix-Kernelprogramming to a beginning Programmer with basic C knowledge. As an example, a device driver for a floppy drive under NetBSD was chosen, as the hardware and necessary doc- umentation was available but the driver itself missing. NetBSD was chosen as the target operating system, as it lends itself perfectly as a teaching example due to its clearly structured source code and well defined interfaces. Unfortunately, there is hardly any specific documentation on Unix- Kernelprogramming under NetBSD apart from references to the functions in sec- tion 9 of the NetBSD manual pages. These manual pages are however miss- ing an introduction, a document that clarifies the connection between the various functions. This document attempts to provide such an introduction, to act as the necessary glue between the individual parts. Therefore, I will reference external documents, particularly section 9 of the NetBSD manual pages in many places. This document is mainly based on the experiences I made when I wrote the driver rf(4)1 for the UnixBus / QBus RX211 8” floppy controller. 8” floppy? Those things existed? Yes. Those were the first floppies, built at the end of the 60s / beginning of the 70s. UniBus / QBus? Whatsdat? That’s the most common bus found in VAXen2. The VAX was the machine of the late 70s up until the beginning of the 90s. Then it was obsoleted by the Alpha architecture. BSD Unix has a long and glorious history on the VAX. [McK 99] But why am I writing a driver today for such antiquated technology? In the end, it doesn’t really matter if I explain the necessary steps using the latest 1GBit/s Ethernetcard for a PCIX Bus or anything else. The underlying principles are the same. Besides, the hardware used in this example is relatively simplistic, so that we can see the essential aspects instead of being hindered by PeeCee idiocrasy. The following chapter gives a short overview of the autoconf(9) concept in NetBSD. Some details have been omitted, and I refer to the according manual pages to avoid duplication of information. The third chapter documents the implementation of the autoconf(9) inter- face of rf(4). The fourth and last chapter covers the actual driver, i.e. the functionality of the driver carrying the data from and to the physical device. In the appendix, you will find the complete source code of the driver as well 1RX01/02 Floppy 2plural for VAX 1 PREFACE 5 as a copy of the referenced manual pages. Future prospects: In its current form, this document represents only a be- ginning. A description of a network device driver, the internal functionality of bus space(9) and bus dma(9) or what is required to port NetBSD to a new ar- chitecture would be possible extensions. Similarly, a discussion of the UVM / UBC internals or a file system interface would be of interest to implement a new file system for example. But at least the last example goes a bit too far away from the initial intent of giving an overview or an introduction to device driver pro- gramming and would be more suitable for a more extensive document on NetBSD Kernel internals, which one day may evolve out of this text. Thanks to Hubert Feyrer and Marc Balmer, who took the time to proof-read my mental outpourings and provided incitement for some diagrams. 2 THE AUTOCONF(9) SYSTEM 6 2 The autoconf(9) system The kernel configuration file is based on three pillars: ioconf.c / cfdata and sys/kern/subr autoconf.c. This concept has become known as autoconf . But what exactly is going on behind the curtain? 2.1 config(8) There is one central file which declares the kernel configuration for a BSD Unix Kernel. Under NetBSD, this file is located in sys/arch/<arch>/conf. <arch> represents the appropriate machine- / processor architecture. In our example, this is vax, i.e. d.h. sys/arch/vax/conf. In this folder, you can find the kernel con- figuration file GENERIC, which contains all the drivers and options supported by this architecture. You can create a user-defined configuration file by copying the file to a new name in this directory and editing it. Usually, this means commenting out all the drivers for devices not available in the particular machine. This process can be automated by using the tool pkgsrc/sysutils/adjustkernel. After calling config(8), it reads the kernel configuration file to determine which drivers / functionality should be included in the kernel. Some ”‘files.*”’ files assign the .c- and .h-files to the various drivers and functionality. Us- ing these dependencies, config(8) creates a compilation directory containing a Makefile as well as a range of .c- and .h-files. The .h-files usually contain defines with parameters such as the max. number of driver instances (for exam- ple PseudoTTYs, BPF, ...), kernel options such as KTRACE, ... The file param.c also falls into this category. The compilation directory is named after the kernel configuration file and is located in sys/arch/vax/compile. After changing into said directory, the actual compilation is started by the command make depend netbsd. See config(8) and http://www.netbsd.org/Documentation/kernel/ for details. 2.2 ioconf.c and cfdata The file ioconf.c in the compilation directory contains the data structure, marking the central point of access of the entire autoconf process. This configuration data table shows all the devices supported by the kernel. Let’s start with an excerpt of the kernels configuration file: mainbus0 at root 2 THE AUTOCONF(9) SYSTEM 7 ibus0 at mainbus0 # All MicroVAX sbi0 at mainbus0 # SBI, master bus on 11/780. vsbus0 at mainbus0 # All VAXstations uba0 at ibus0 # Qbus adapter ze0 at ibus0 # SGEC on-board ethernet le0 at ibus0 # LANCE ethernet (MV3400) le0 at vsbus0 csr 0x200e0000 # LANCE ethernet ze0 at vsbus0 csr 0x20008000 # SGEC ethernet si0 at vsbus0 csr 0x200c0080 # VS2000/3100 SCSI-ctlr asc0 at vsbus0 csr 0x200c0080 # VS4000/60 (or VLC) SCSI-ctlr asc0 at vsbus0 csr 0x26000080 # VS4000/90 SCSI-ctlr uda0 at uba? csr 0172150 # UDA50/RQDX? qe0 at uba? csr 0174440 # DEQNA/DELQA rlc0 at uba? csr 0174400 # RL11/RLV11 controller rl* at rlc? drive? # RL01/RL02 disk drive scsibus* at asc? scsibus* at si? sd* at scsibus? target? lun? st* at scsibus? target? lun? cd* at scsibus? target? lun? We quickly realize that the organization of the device drivers can be repre- sented in a treelike structure as in figure 1. Attached to the imaginary root (which appears “out of nowhere”) we find the first child, the abstract mainbus. This mainbus is parent to the children ibus, sbi and vsbus. These children in turn are parent to uba, le, asc, ... These relationships represent the above men- tioned cfdata table found in the file ioconf.c. The programmer does not need to know or care about this table, as it is automagically created by config(8) . It is important to realize that each device (node) has a parent (except for root, due to the old chicken-or-the-egg problem). A node that has children, is a Bus or a controller. The actual devices are the leaves of the tree. Each leaf and each node represent a device driver. That of course means, that there must be drivers for the 2 THE AUTOCONF(9) SYSTEM 8 uda0 uba0 qu0 rlc0 rl* ibus0 ze0 le0 root mainbus sbi0 le0 ze0 vsbus0 si0 sd* ... scsibus0 st* asc0 cd* Figure 1: device tree bus systems as well. The bus drivers are, especially in this context, responsible for locating the devices attached to the bus (i.e. the “busscan”). Another important realization lies in the fact that there are several different ways of arriving at the same driver! For example le0: root => mainbus0 => ibus0 => le0 or root => mainbus0 => vsbus0 => le0.
Load more

Recommended publications
  • Introduction to Debugging the Freebsd Kernel
    Introduction to Debugging the FreeBSD Kernel John H. Baldwin Yahoo!, Inc. Atlanta, GA 30327 [email protected], http://people.FreeBSD.org/˜jhb Abstract used either directly by the user or indirectly via other tools such as kgdb [3]. Just like every other piece of software, the The Kernel Debugging chapter of the FreeBSD kernel has bugs. Debugging a ker- FreeBSD Developer’s Handbook [4] covers nel is a bit different from debugging a user- several details already such as entering DDB, land program as there is nothing underneath configuring a system to save kernel crash the kernel to provide debugging facilities such dumps, and invoking kgdb on a crash dump. as ptrace() or procfs. This paper will give a This paper will not cover these topics. In- brief overview of some of the tools available stead, it will demonstrate some ways to use for investigating bugs in the FreeBSD kernel. FreeBSD’s kernel debugging tools to investi- It will cover the in-kernel debugger DDB and gate bugs. the external debugger kgdb which is used to perform post-mortem analysis on kernel crash dumps. 2 Kernel Crash Messages 1 Introduction The first debugging service the FreeBSD kernel provides is the messages the kernel prints on the console when the kernel crashes. When a userland application encounters a When the kernel encounters an invalid condi- bug the operating system provides services for tion (such as an assertion failure or a memory investigating the bug. For example, a kernel protection violation) it halts execution of the may save a copy of the a process’ memory current thread and enters a “panic” state also image on disk as a core dump.
    [Show full text]
  • Process and Memory Management Commands
    Process and Memory Management Commands This chapter describes the Cisco IOS XR software commands used to manage processes and memory. For more information about using the process and memory management commands to perform troubleshooting tasks, see Cisco ASR 9000 Series Aggregation Services Router Getting Started Guide. • clear context, on page 2 • dumpcore, on page 3 • exception coresize, on page 6 • exception filepath, on page 8 • exception pakmem, on page 12 • exception sparse, on page 14 • exception sprsize, on page 16 • follow, on page 18 • monitor threads, on page 25 • process, on page 29 • process core, on page 32 • process mandatory, on page 34 • show context, on page 36 • show dll, on page 39 • show exception, on page 42 • show memory, on page 44 • show memory compare, on page 47 • show memory heap, on page 50 • show processes, on page 54 Process and Memory Management Commands 1 Process and Memory Management Commands clear context clear context To clear core dump context information, use the clear context command in the appropriate mode. clear context location {node-id | all} Syntax Description location{node-id | all} (Optional) Clears core dump context information for a specified node. The node-id argument is expressed in the rack/slot/module notation. Use the all keyword to indicate all nodes. Command Default No default behavior or values Command Modes Administration EXEC EXEC mode Command History Release Modification Release 3.7.2 This command was introduced. Release 3.9.0 No modification. Usage Guidelines To use this command, you must be in a user group associated with a task group that includes appropriate task IDs.
    [Show full text]
  • Active-Active Firewall Cluster Support in Openbsd
    Active-Active Firewall Cluster Support in OpenBSD David Gwynne School of Information Technology and Electrical Engineering, University of Queensland Submitted for the degree of Bachelor of Information Technology COMP4000 Special Topics Industry Project February 2009 to leese, who puts up with this stuff ii Acknowledgements I would like to thank Peter Sutton for allowing me the opportunity to do this work as part of my studies at the University of Queensland. A huge thanks must go to Ryan McBride for answering all my questions about pf and pfsync in general, and for the many hours working with me on this problem and helping me test and debug the code. Thanks also go to Theo de Raadt, Claudio Jeker, Henning Brauer, and everyone else at the OpenBSD network hackathons who helped me through this. iii Abstract The OpenBSD UNIX-like operating system has developed several technologies that make it useful in the role of an IP router and packet filtering firewall. These technologies include support for several standard routing protocols such as BGP and OSPF, a high performance stateful IP packet filter called pf, shared IP address and fail-over support with CARP (Common Address Redundancy Protocol), and a protocol called pfsync for synchronisation of the firewalls state with firewalls over a network link. These technologies together allow the deployment of two or more computers to provide redundant and highly available routers on a network. However, when performing stateful filtering of the TCP protocol with pf, the routers must be configured in an active-passive configuration due to the current semantics of pfsync.
    [Show full text]
  • Post Mortem Crash Analysis
    Post Mortem Crash Analysis Johan Heander & Magnus Malmborn January 14, 2007 Abstract To improve the quality and reliability of embedded systems it is important to gather information about errors in units already sold and deployed. To achieve this, a system for transmitting error information from the customer back to the developers is needed, and the developers must also have a set of tools to analyze the error reports. The purpose of this master thesis was to develop a fully functioning demon- stration system for collection, transmission and interpretation of error reports from Axis network cameras using the Linux operating system. The system has been shown to handle both kernel and application errors and conducts automatic analysis of received data. It also uses standard HTTP protocol for all network transfers making it easy to use even on firewalled net- works. i ii Acknowledgement We would like to thank our LTH supervisor Jonas Skeppstedt for all he has taught us about computer science in general and operating systems and the C programming language in particular. We would also like to thank Mikael Starvik at Axis Communications for quickly providing us with all hardware and information we needed to complete this thesis, and for providing us with support during our implementation and writing. Finally we thank all the developers working at Axis Communications, many of whom have provided input and reflections on our work. iii iv Contents 1 Introduction 1 1.1 Problem description . 1 1.2 Problem analysis . 1 2 Background 3 2.1 Kernel crashes . 3 2.2 User space crashes .
    [Show full text]
  • Linux Core Dumps
    Linux Core Dumps Kevin Grigorenko [email protected] Many Interactions with Core Dumps systemd-coredump abrtd Process Crashes Ack! 4GB File! Most Interactions with Core Dumps Poof! Process Crashes systemd-coredump Nobody abrtd Looks core kdump not Poof! Kernel configured Crashes So what? ● Crashes are problems! – May be symptoms of security vulnerabilities – May be application bugs ● Data corruption ● Memory leaks – A hard crash kills outstanding work – Without automatic process restarts, crashes lead to service unavailability ● With restarts, a hacker may continue trying. ● We shouldn't be scared of core dumps. – When a dog poops inside the house, we don't just `rm -f $poo` or let it pile up, we try to figure out why or how to avoid it again. What is a core dump? ● It's just a file that contains virtual memory contents, register values, and other meta-data. – User land core dump: Represents state of a particular process (e.g. from crash) – Kernel core dump: Represents state of the kernel (e.g. from panic) and process data ● ELF-formatted file (like a program) User Land User Land Crash core Process 1 Process N Kernel Panic vmcore What is Virtual Memory? ● Virtual Memory is an abstraction over physical memory (RAM/swap) – Simplifies programming – User land: process isolation – Kernel/processor translate virtual address references to physical memory locations 64-bit Process Virtual 8GB RAM Address Space (16EB) (Example) 0 0 16 8 EB GB How much virtual memory is used? ● Use `ps` or similar tools to query user process virtual memory usage (in KB): – $ ps -o pid,vsz,rss -p 14062 PID VSZ RSS 14062 44648 42508 Process 1 Virtual 8GB RAM Memory Usage (VSZ) (Example) 0 0 Resident Page 1 Resident Page 2 16 8 EB GB Process 2 How much virtual memory is used? ● Virtual memory is broken up into virtual memory areas (VMAs), the sum of which equal VSZ and may be printed with: – $ cat /proc/${PID}/smaps 00400000-0040b000 r-xp 00000000 fd:02 22151273 /bin/cat Size: 44 kB Rss: 20 kB Pss: 12 kB..
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump
    Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump Thesis submitted in partial fulfillment of the requirements for the degree of MS in Computer Science & Engineering by Research by Shubham Tripathi 201407646 [email protected] International Institute of Information Technology Hyderabad - 500 032, INDIA March 2018 Copyright c Shubham Tripathi, March 2018 All Rights Reserved International Institute of Information Technology Hyderabad, India CERTIFICATE It is certified that the work contained in this thesis, titled “Exniffer: Learning to Rank Crashes by Assessing the Exploitability from Memory Dump” by Shubham Tripathi, has been carried out under my supervision and is not submitted elsewhere for a degree. Date Adviser: Prof. Sanjay Rawat “Contemplate and reflect upon knowledge, and you will become a benefactor to others.” To my parents Acknowledgments I would like to express my gratitude to my adviser, Dr. Sanjay Rawat. Sanjay sir helped me staying focused on problems and provided new directions to approach them. Working with him, I have devel- oped my problem solving skills, learnt about research, about life in general. I would be thankful to him for all my life, for providing me the guidance on various matters, always motivating and boosting me with confidence, which really helped me in shaping my life. I must also thank all my lab-mates who are working or have worked earlier in CSTAR - Vijayendra, Spandan, Satwik, Charu, Teja, Ishan and Lokesh. I really enjoyed working with them in the lab. I would like to thank all my friends in IIIT, for making my stay in the campus a memorable one.
    [Show full text]
  • Chapter 2: Operating-System Structures
    Chapter 2: Operating-System Structures Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Chapter 2: Operating-System Structures Operating System Services User and Operating System-Interface System Calls System Services Linkers and Loaders Why Applications are Operating System Specific Operating-System Design and Implementation Operating System Structure Building and Booting an Operating System Operating System Debugging Operating System Concepts – 10th Edition 2.2 Silberschatz, Galvin and Gagne ©2018 Objectives Identify services provided by an operating system Illustrate how system calls are used to provide operating system services Compare and contrast monolithic, layered, microkernel, modular, and hybrid strategies for designing operating systems Illustrate the process for booting an operating system Apply tools for monitoring operating system performance Design and implement kernel modules for interacting with a Linux kernel Operating System Concepts – 10th Edition 2.3 Silberschatz, Galvin and Gagne ©2018 Operating System Services Operating systems provide an environment for execution of programs and services to programs and users One set of operating-system services provides functions that are helpful to the user: User interface - Almost all operating systems have a user interface (UI). Varies between Command-Line (CLI), Graphics User Interface (GUI), touch-screen, Batch Program execution - The system must be able to load a program into memory and to run that program, end execution, either normally or abnormally (indicating error) I/O operations - A running program may require I/O, which may involve a file or an I/O device Operating System Concepts – 10th Edition 2.4 Silberschatz, Galvin and Gagne ©2018 Operating System Services (Cont.) One set of operating-system services provides functions that are helpful to the user (Cont.): File-system manipulation - The file system is of particular interest.
    [Show full text]
  • Comparing the Robustness of POSIX Operating Systems
    Comparing the Robustness of POSIX Operating Systems http://www.ices.cmu.edu/ballista Philip Koopman & John DeVale ECE Department [email protected] - (412) 268-5225 - http://www.ices.cmu.edu/koopman ,QVWLWXWH IRU &RPSOH[ (QJLQHHUHG 6\VWHPV Overview: Ballista Automated Robustness Testing ◆ Generic robustness testing • Based on data types ◆ OS Testing results • Raw results for 15 Operating Systems • System calls vs. C Library ◆ Exception Handling Diversity • Does everyone core dump on the same exceptions? (no) ◆ Approximating “Silent” failure rates (missing error codes) A Ballista is an ancient siege ◆ Conclusions/Future work weapon for hurling objects at fortified defenses. 2 Ballista: Software Testing + Fault Injection Ideas ◆ SW Testing requires: Ballista uses: • Test case “Bad” value combinations • Module under test Module under Test • Oracle (a “specification”) Watchdog timer/core dumps SPECIFIED INPUT RESPONSE BEHAVIOR SPACE SPACE ROBUST SHOULD VAL I D OPERATION WORK INPUTS MO DULE REPRODUCIBLE UNDEFINED UNDER FAILURE TEST SHOULD INVALID INPUTS UNREPRODUCIBLE RETURN FAILURE ERROR ◆ Ballista combines ideas from: • Domain testing ideas / Syntax testing ideas • Fault injection at the API level 3 Scalable Test Generation API write(int filedes, const void *buffer, size_t nbytes) FILE MEMORY SIZE TESTING DESCRIPTOR BUFFER TEST OBJECTS TEST OBJECT TEST OBJECT OBJECT FD_CLOSED BUF_SMALL_1 SIZE_1 FD_OPEN_READ BUF_MED_PAGESIZE SIZE_16 FD_OPEN_WRITE BUF_LARGE_512MB SIZE_PAGE FD_DELETED BUF_XLARGE_1GB SIZE_PAGEx16 FD_NOEXIST BUF_HUGE_2GB SIZE_PAGEx16plus1
    [Show full text]
  • Freebsd and Netbsd on APM86290 System on Chip
    FreeBSD and NetBSD on APM86290 System on Chip Zbigniew Bodek Semihalf [email protected] Abstract Single chip computers conquered not only the world of mobile devices, but are extensively be- This paper covers recent development ing used in the modern telecommunication sys- work on porting FreeBSD/powerpc and tems as they provide high performance data NetBSD/evbppc to the new APM86290 processing and a large number of capabilities system-on-chip from AppliedMicro. The combined with the low energy consumption and APM86290 is a dual core device compliant reasonable price. PowerPC is a superscalar, with the Book-E definition of the PowerPC RISC-like computer architecture, originally in- architecture, presenting a number of periph- troduced by Apple-IBM-Motorola (AIM) al- erals integrated in a single chip and labour liance. Initially designed for personal comput- efficiency improved by implementation of a ers, it became popular for embedded systems, message passing architecture. servers, super-computers, and gaming. The article focuses on presenting the dif- Fast evolving telecommunication industry ferences and similarities between FreeBSD and demands from the modern chips more and more NetBSD systems in the context of porting them packet processing power, along with the so- to an embedded architecture. The material phisticated capabilities concerning packet clas- briefly describes the influence of the innova- sification, security extensions, and acceleration tive inter-circuit communication architecture, subsystems designed to offload CPUs from the and data flow in the APM86290 chip on de- compute-intensive data servicing. vice drivers development. In particular the pa- per talks about the new architecture’s impact Every processor, even the most sophisti- on the FreeBSD’s and NetBSD’s drivers infras- cated one, is just an empty vessel without an tructure in example of the networking driver.
    [Show full text]
  • HP C User's Guide for Openvms Systems
    HP C User’s Guide for OpenVMS Systems Order Number: AA–PUNZM–TK January 2005 This guide describes using the HP C compiler on OpenVMS systems. It contains information on HP C program development in the OpenVMS environment, HP C features specific to OpenVMS systems, and cross-system portability concerns. Revision/Update Information: This revised guide supersedes the Compaq C User’s Guide for OpenVMS Systems Order No. AA–PUNZL–TK, Version 6.5. Operating System and Version: OpenVMS I64 Version 8.2 or higher OpenVMS Alpha Version 7.3-2 or higher Software Version: HP C Version 7.1 for OpenVMS Systems Hewlett-Packard Company Palo Alto, California © Copyright 2005 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered trademark of The Open Group. X/Open is a registered trademark of X/Open Company Ltd. in the UK and other countries. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
    [Show full text]
  • Chapter 2 Operating System Structures
    Operating Systems Associate Prof. Yongkun Li 中科大-计算机学院 副教授 http://staff.ustc.edu.cn/~ykli Chapter 2 Operating System Structures 1 Objectives • Operating System Services – User Operating System Interface – System Calls • Operating System Structure • Operating System Design and Implementation • MISC: Debugging, Generation & System Boot 2 Operating System Services Services Overview, User Interface 3 Operating System Services • Operating systems provide – an environment for execution of programs and – services to programs and users • Services may differ from one OS to another • What are the common classes? – Convenience of the user – Efficiency of the system 4 Overview of Operating System Services 5 OS Services for Helping Users • User interface - Almost all operating systems have a user interface (UI). – Three forms • Command-Line (CLI) – Shell command • Batch – Shell script • Graphics User Interface (GUI) – Windows system 6 OS Services for Helping Users • Program execution – Load a program into memory – Run the program – End execution • either normally or • abnormally (indicating error) 7 OS Services for Helping Users • I/O operations - A running program may require I/O, which may involve a file or an I/O device – Common I/Os: read, write, etc. – Special functions: recording CD/DVD • Notes: Users usually cannot control I/O devices directly, so OS provides a mean to do I/O – Mainly for efficiency and protection 8 OS Services for Helping Users • File-system manipulation - The file system is of particular interest – OS provides a variety of file systems • Major services – read and write files and directories – create and delete files and directories – search for a given file – list file Information – permission management: allow/deny access 9 OS Services for Helping Users • Communications: information exchange between processes – Processes on the same computer – Processes between computers over a network • Implementations – Shared memory • Two or more processes read/write to a shared section of mem.
    [Show full text]