MULTICS DESIGN DOCUMENT MDD-017 To: MDD Distribution From: George Gilcrease Date: December 3, 1987 Subject: The Multics I/O SysDaemon Abstract: An overview of the operation of the I/O SysDaemon. The scope of this document is a synopsis of the I/O SysDaemon software: a description of the primary associated databases, and a narrative of the order of events and communication between the I/O SysDaemon coordinator process and a representative driver process. _________________________________________________________________ Multics Design Documents are the official design descriptions of the Multics Trusted Computing Base. They are internal documents, which may be released outside of Multics System Development only with the approval of the Director. i MDD-017 The Multics I/O SysDaemon CONTENTS Page Section 1 The Multics I/O SysDaemon - an Overview . 1-1 1.1 Operation of the I/O SysDaemon . . 1-1 1.2 I/O SysDaemon Security Features . 1-1 1.2.1 The User IO.SysDaemon . . . . 1-2 1.2.2 Action at Request Submission 1-3 1.2.3 Access Checking at Printing . 1-3 1.2.4 Checks After Printing . . . . 1-3 Section 2 I/O SysDaemon Databases . . . . . . . . . 2-1 2.1 >daemon_dir_dir Contents . . . . . 2-1 2.1.1 >ddd>io_daemon_dir Contents . 2-1 2.1.2 >ddd>cards Contents . . . . . 2-2 2.1.3 >ddd>io_msg_dir Contents . . 2-3 Section 3 I/O SysDaemon Program Modules . . . . . . 3-1 3.1 Program Modules . . . . . . . . . 3-1 3.2 The I/O SysDaemon Queues . . . . . 3-2 3.3 The I/O SysDaemon Coordinator . . 3-2 3.3.1 Entries in iodc_. . . . . . . 3-2 3.3.1.1 iodc_$iodc_init entry . 3-2 3.3.1.2 driver_signal entry . . 3-3 3.3.1.3 free_device entry . . . 3-4 3.3.1.4 new_driver entry . . . . 3-4 3.3.1.5 driver_command . . . . . 3-4 3.3.1.6 proc_dies label . . . . 3-5 3.3.1.7 command_level entry . . 3-5 3.4 Driver Processes . . . . . . . . . 3-6 Section 4 I/O SysDaemon Test Run . . . . . . . . . 4-1 4.1 Test iod_tables.iodt . . . . . . . 4-1 4.2 Test printer_info.rqti . . . . . . 4-2 4.3 Test script . . . . . . . . . . . 4-2 ii The Multics I/O SysDaemon MDD-017 SECTION 1 THE MULTICS I/O SYSDAEMON - AN OVERVIEW The software that handles local and remote printing, punching, and card input is called the I/O SysDaemon. The I/O SysDaemon is organized into a coordinator process and a number of driver processes; a driver is associated with each local or remote device. _1_._1 _O_P_E_R_A_T_I_O_N _O_F _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N The I/O SysDaemon normally is run with system message coordinator terminals. For remote devices, partial control of the process is from the device itself, using its card reader or input keyboard. The system administrator sets up the environment in which this facility runs by creating and modifying the I/O SysDaemon databases, creating info segments or other information to inform the user community of what is available, and setting up special operator exec_coms or instructions. The operator runs the facilities according to the instructions given by the system administrator, taking care of the needs of the peripheral devices and following special requests made by the system. _1_._2 _I_/_O _S_Y_S_D_A_E_M_O_N _S_E_C_U_R_I_T_Y _F_E_A_T_U_R_E_S The I/O SysDaemon incorporates certain features in support of the access isolation mechanism (AIM). Every request processed by the I/O SysDaemon has an access class. The access class of the request is equal to the authorization of the process that submitted the request. Each piece of output normally has an access class banner: ox for print requests, the access class banner appears on the head sheet of each printout. ox for punch requests on the local punch, the access class banner appears in the flip cards at the beginning of each deck. 1-1 MDD-017 The Multics I/O SysDaemon However, if the access class of a request is system_low, and the access class name for system_low is set to a null string (defined in the installation_parms), then the access class banner is omitted. In the interest of security, it may be desirable to have requests of the same type automatically separated according to access class. The mechanism for separating output according to access class is the "device_class", defined in the iodt_tables.iodt source segment. Each request type can be partitioned into any number of separate device classes. One or more devices may be specified for each device class. When a driver process is initialized, the operator normally indicates the device to be run, and the request type. However, if device classes have been defined for the request type, the operator must also indicate a device class. This determines the access class range of requests that the driver processes. The interface with the AIM and processes using the I/O SysDaemon may be divided into four areas: process characteristics of the user IO on the project SysDaemon, action at the time a request is submitted, access checking at the time of printing, and processing after printing. _1_._2_._1 _T_h_e _U_s_e_r _I_O_._S_y_s_D_a_e_m_o_n The I/O software usually runs as the user IO on the project SysDaemon, but may sometimes be the user RJE for remote input/output, HASP for a hasp workstation, and in test mode may be a privileged user who is performing I/O SysDaemon tests. From a security view, the usual I/O SysDaemon users may be forced to login only as consoleless daemons (that is, only by privileged command from another process, and never as an interactive user) by administratively locking their passwords. IO.SysDaemon runs in ring 4, at system_high security level. Additionally, in the start_up command file for the user IO, segment and directory system privileges are set, but communications, interprocess communication, ring 1, RCP resource management, and security-out-of-service privileges are not given. Since the default ACL entry of r *.SysDaemon.* is placed on most segments when they are created, IO.SysDaemon has access to read most segments on the system. The only unreadable segments are those in rings 0 - 3, or those which explicitly deny access to IO.SysDaemon or *.SysDaemon. Security information for output files is audited by the I/O SysDaemon software at various stages in the processing of a request. 1-2 The Multics I/O SysDaemon MDD-017 _1_._2_._2 _A_c_t_i_o_n _a_t _R_e_q_u_e_s_t _S_u_b_m_i_s_s_i_o_n At the time a user requests a segment to be output by the I/O SysDaemon, a check is made in dprint_$access_check to determine if the IO driver process which will perform the request will have sufficient access to do so. The driver must have at least read access on the target segment, and have status access on the containing directory. In order to delete the segment after it has been printed, the driver must have modify access at the containing directory. In addition, a check is made to see if user can read the segment (has read access from ring brackets, and has an authorization equal to or greater than the classification of the segment). If not, the request is denied. At this time the printable string of the user's authorization level is saved for possible use as banner information. The user's authorization level is stored in the request entry for later re-verification, for it is possible for a user's authorization to be changed between the time of requesting a segment be outputted, and the actual time this request is satisfied. The user may specify the -access_labels control argument to the enter_output_request command, which will cause top and/or bottom security labels to appear on his output. If -access_labels is overridden by -label control, this overriding is audited. _1_._2_._3 _A_c_c_e_s_s _C_h_e_c_k_i_n_g _a_t _P_r_i_n_t_i_n_g A request has been enqueued, and the I/O Coordinator has selected the request queue entry for outputting. Before the segment is printed, the user's access to read the segment (ACL, ring and authorization stored with the request) is revalidated. If there is not sufficient access, the request is denied, and a security audit message is issued. If there is a difference in what authorization string is stored in the request for labels, and the users's authorization, or if authorization-level labels are supressed, an audit message is generated. _1_._2_._4 _C_h_e_c_k_s _A_f_t_e_r _P_r_i_n_t_i_n_g If the user had requested that the output segment be deleted after printing, the same regimen of access and security checks is performed, with the same audit output as when the deletion was requested, before the segment is deleted. 1-3 The Multics I/O SysDaemon MDD-017 SECTION 2 I/O SYSDAEMON DATABASES The Multics I/O SysDaemon software depends on the existence of certain directories and segments, the most important of which are created and initialized at a new Multics site by the acct_start_up.ec. The main node of the I/O SysDaemon file hierarchy is the directory named >daemon_dir_dir (>ddd). _2_._1 _>_D_A_E_M_O_N___D_I_R___D_I_R _C_O_N_T_E_N_T_S - io_daemon_dir (idd) directory, which holds all I/O SysDaemon databases. - cards directory, a storage pool for card deck images read by the local card input process, or a remote station. - io_msg_dir directory, containing mailboxes for each (station) for the driver to driver message facility. _2_._1_._1 _>_d_d_d_>_i_o___d_a_e_m_o_n___d_i_r _C_o_n_t_e_n_t_s - coord_comm.ms, a ring 1 segment in which driver processes place messages for the I/O SysDaemon coordinator. - coord_lock, a segment used by the process overseer of the I/O SysDaemon to prevent initialization of a driver process before an I/O SysDaemon coordinator has been created, and prevents creation of more than one coordinator. - iod_tables, the master control table for the I/O SysDaemon coordinator; compiled by the iod_tables_compiler command. - iod_tables.iodt, source segment for iod_tables. 2-1 MDD-017 The Multics I/O SysDaemon - iod_working_tables, the working copy of iod_tables used by device drivers and users; copied from iod_tables during the I/O SysDaemon coordinator initialization. - iodc_data, a segment containing the process identifier of the I/O SysDaemon coordinator and the event channel identifier to be used by a new driver for initial communication with the coordinator. - printer_notice, an optional segment containing information the site wishes to be printed on the page following the heading sheet of every printer listing. - xxx_n.ms, the ring 1 message segments for the I/O SysDaemon queues, one for each priority queue of a request type, xxx is the request type name, and n is the queue number (1 <= n <= 4). - coord_dir directory, working storage for the I/O SysDaemon coordinator, created and managed by the coordinator, having the access class of the authorization of the coordinator. - rqt_info_segs directory, which holds any request type info segments used by drivers, its access class is system_low. - directories, separate directories for each major device currently being run by a device driver. These directories are managed by the I/O SysDaemon coordinator and their names are site dependent. Each major device directory contains a driver status segment for each minor device associated with the major device. The access class is the authorization of the device driver. _2_._1_._2 _>_d_d_d_>_c_a_r_d_s _C_o_n_t_e_n_t_s The storage pool for card deck image segments consists of a subtree of the directory hierarchy, which is headed by >ddd>cards. One access class directory for each access defined access class is contained in the cards directory. Storage is allocated within the access class directory that corresponds the process' authorization. Person directories are contained in the appropriate access class directory, created for each person who needs temporary storage. A person directory contains all segments and multisegment files for a given person of a given access class. For example, if a user with the Person_id of Robertson is at system_low, the following directory is allocated for his card deck image segments: >daemon_dir_dir>cards>system_low>Robertson 2-2 The Multics I/O SysDaemon MDD-017 _2_._1_._3 _>_d_d_d_>_i_o___m_s_g___d_i_r _C_o_n_t_e_n_t_s This directory contains mailboxes in the form .mbx for each device and remote station that uses the driver to driver message facility. 2-3 The Multics I/O SysDaemon MDD-017 SECTION 3 I/O SYSDAEMON PROGRAM MODULES _3_._1 _P_R_O_G_R_A_M _M_O_D_U_L_E_S PROGRAM MODULES +--------------+ +-------------+ | REQUEST | | REQUEST | | QUEUE | | QUEUE | +--------------+ +-------------+ | | | | +--------------+ +-------------+ . +-------------+ . . | COORDINATOR | . . +-------------+ . . | | . . . . . . | | . . . . . . +-------------+ . . / | \ . . / | \ . . / | \ . . / | \ . +-------------+ +-------------+ +-------------+ | DRIVER | | DRIVER | | DRIVER | +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | +-------------+ +-------------+ +-------------+ | | | | | | +-------------+ +-------------+ +-------------+ | OUTPUT | | OUTPUT | | REMOTE | | DEVICE | | DEVICE | | OUTPUT | +-------------+ +-------------+ | DEVICE | | | | | +-------------+ | | | | | | +-------------+ +-------------+ +-------------+ 3-1 MDD-017 The Multics I/O SysDaemon _3_._2 _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N _Q_U_E_U_E_S The program create_daemon_queues creates the I/O SysDaemon message segments, normally under the >ddd>iod directory. Their format is described in the include file iod_tables_hdr.incl.pl1, and q_group_tab.incl.pl1. I/O SysDaemon program modules service these request queues. _3_._3 _T_H_E _I_/_O _S_Y_S_D_A_E_M_O_N _C_O_O_R_D_I_N_A_T_O_R This is the central procedure of the I/O SysDaemon software. Communication with driver processes and the coordinator process is managed through entry points in iodc_, the main control procedure of the coordinator. Most entries are enabled via event wakeups. _3_._3_._1 _E_n_t_r_i_e_s _i_n _i_o_d_c__ 3.3.1.1 IODC_$IODC_INIT ENTRY (Called by iodc_overseer_) Function: This is the main entry point for iodc_. It initializes the coordinator and waits for drivers. Tasks: (1) the saved list of queue entries left by the last coordinator is checked for segments to be deleted. (2) the coord_dir directory is deleted to make sure it gets recreated with the proper access class. (3) make a subdirectory to hold the coordinator's writable data segments (segments modified after initialization). This subdirectory will be upgraded, if necessary, with a quota 250 records. Twenty-five records will be assigned. (4) set up the needed data segments; make the coordinator's private copy of iod_tables. (5) complete the coordinator's initialization: - initialize table pointers and other static information. - set up message segment for new driver messages. - place userid for each queue group on message segment acl. - initialize other coordinator procedures. 3-2 The Multics I/O SysDaemon MDD-017 - delete all device directories and segments. - initialize the device class table. - set up the driver's event channels and the timer channel for freeing saved requests. 3.3.1.2 DRIVER_SIGNAL ENTRY (Wakeup from driver process) Function: This entry receives the wakeup from a driver process that has just finished a request, or otherwise become ready for work, or has just received a "restart", "save", or "logout" command. Contained in the event message is a signal-type code, 0-5, which identifies the drivers request. Process then, according to the value of the signal-type (signal_label): Tasks: signal_label 0: driver is done with a request. signal_label 1: driver wants a new request, and is done with a request. (1) If the request has not been placed in the saved list, place the request in the saved list. (2) If signal_label is 0, then exit. (3) If there is a request pending in the queues, or if a restart is in progress, flag the next entry to select in the queues the next time around. (4) If no new request is found, free the request descriptor area, and wakeup the driver, else fill in the request descriptor area for the driver to use in satisfying the request, and wakeup the driver. (5) If the series number of output requests has reached a multiple of 10,000, a new-series message is issued. (6) exit. signal_label 2: save the request signal_label 3: restart the request (1) For restart commands, record that requests for the device class have been restarted, and look for the request from which to restart. For save requests, scan through the requests, setting all the "saved" bits in all the requests done of the specified series. A restart or save of a given series is only allowed to be performed by a driver of the same device class that the series 3-3 MDD-017 The Multics I/O SysDaemon was originally done under. However, a driver with multiple minor devices has one device class for each minor device, so even if the minor device that actually sent the wakeup does not have the matching device class, the action will be allowed if one of the other minor devices does have the matching device class. (2) If the sequence id specified in the restart or save request is not found, a message is issued. (3) If the series restarted or saved is in use, give the driver a new series number. (4) Send an acknowledgement to the requesting driver. (5) Exit. signal_label 4: driver logout command. (1) The major device assigned to the driver proccess is freed; exit. signal_label 5: return driver command channel. (1) The driver needs the event channel to send commands to line drivers. Set the driver command channel; exit. 3.3.1.3 FREE_DEVICE ENTRY (Called by iodc_) Function: This entry frees a major device for use by another driver. Tasks: (1) The process id assigned to the device is zeroed, and each minor device is marked as inactive. The major device directory and all contained driver stauts segments are deleted. If an unfinished request is found for a minor device, that request is made pending for the associated device class, and marked as "continued". 3.3.1.4 NEW_DRIVER ENTRY 3.3.1.5 DRIVER_COMMAND (Wakeups from drivers) 3-4 The Multics I/O SysDaemon MDD-017 Function and Tasks: (1) If the driver command is restart, then go to the restart code in signal_label (3). (2) If the command is for a new driver, then initialize the new driver data variables, open any queues needed by the driver, modify the coordinator control databases to reflect the new driver, send a wakeup to the new driver, then exit. (3) If the command is to restart the queue, go to the head of the queue for the driver and flush any normal waiting entries from the waiting list, leaving priority requests, then exit. (4) If the command is for a next request, the queues for the driver are searched for a matching request, and that request is threaded into the priority queue (1) for the driver, then exit. (5) If none of the above commands, inform the requesting driver of the error, then exit. 3.3.1.6 PROC_DIES LABEL (Come here is process disaster) Function and Tasks: Issue message, all drivers will be reinitialized, then invoke the "new_proc" command. 3.3.1.7 COMMAND_LEVEL ENTRY (The coordinator command processor) Function and Tasks: (1) If the command is "help" then display the list of coordinator commands. (2) If the command is "start" then enable the coordinator. (3) If the command is "return" then return if in test mode. (4) If the command is "debug" then if in test mode, call debug. (5) If the command is "probe" then if in test mode, call probe. (6) If the command is "pi" then if testing, signal the program_interrupt condition. 3-5 MDD-017 The Multics I/O SysDaemon (7) If the command is "logout" then if in test mode, return, else call logout. (8) If the command is "print_devices" then print a list of drivers and devices. (9) If the command is "list" then print a list of active devices controlled by the coordinator. (10) If the command is "restart_status" then print a list of restartable requests. (11) If the command is "term" then terminate the requested driver. (12) If the command is "wait_status" then list all requests waiting for devices by device-class. (13) If the command is "driver" then if in test mode, reinitialize for driver. (14) If the command is none of the above, issue an error message, ask for command again. _3_._4 _D_R_I_V_E_R _P_R_O_C_E_S_S_E_S The initialization procedure for all IO SysDaemon drivers is iodd_$iodd_init. It is called (by iodc_) with two arguments: system_dir, which defines the directory which will contain common databases, and testing, which indicates the driver is being run in test mode. This procedure determines from the operator which device is being used, establishes communication with the coordinator, attaches the device control terminal if needed, and transfers to the driver control program specified in the iod_tables control file. iodd_$iodd_init entry: Function and Tasks: (1) Initialaize static/control variables. (2) Initialize the control terminal. (3) Find the tables in iod_working_tables so the requested device and device class can be validated. Set pointers to the proper tables. (4) Attach the line if a master console, and wait for slave dialup. 3-6 The Multics I/O SysDaemon MDD-017 (5) Find the major device in tables. (6) Find each associated minor device and save the device index and default device class from operator request: new_device, quit, default, or "". (7) Loop through the requested minor devices asking the coordinator to establish this process as the driver process. (8) If the coordinator allows this as a driver process, then locate the driver status segment. (9) Establish the accounting procedure to be used for each minor device driver. (10) If there is a request_type_info segment for the driver, then associate the minor device with the request type name for operator x command. (11) Set up the event channel to communicate with the coordinator. (12) Set the entry variable for calling the driver module. (13) Indicate to the coordinator that this driver is initialized. (14) Call the driver initialize entry in the static io daemon data to allow the driver process to begin work. 3-7 The Multics I/O SysDaemon MDD-017 SECTION 4 I/O SYSDAEMON TEST RUN To illustrate the flow of execution and the communication between the I/O SysDaemon coordinator process and a driver process, the following test run is provided. The test shows the establishment of a coordinator process, the logging in of a driver driver process, and the printing of two requests from a request queue. _4_._1 _T_E_S_T _I_O_D___T_A_B_L_E_S_._I_O_D_T This .iodt source segment will be converted by the iod_tables_compiler command into binary format. Time: 30; Max_queues: 1; Device: prta; Here, a line printer is defined. driver_module: printer_driver_; prph: prta; default_type: printer; Device: prtb; Another line printer is defined. driver_module: printer_driver_; prph: prtb; default_type: printer; Device: prtc; And another line printer is defined. driver_module: printer_driver_; prph: prtc; default_type: printer; (etc. to Device: prtg;) Request_type: printer; The printer queues furthur defined. generic_type: printer; driver_userid: Gilcrease.Multics; accounting: nothing; 4-1 MDD-017 The Multics I/O SysDaemon rqti_seg: printer_info; This request-type information will device: prta; be furthur defined in printer_info.rqti, device: prtb; printed on the next page. device: prtc; device: prtd; device: prte; device: prtf; device: prtg; End; _4_._2 _T_E_S_T _P_R_I_N_T_E_R___I_N_F_O_._R_Q_T_I rqti_seg: printer_info; This printer request type information source segment will be converted by driver_attributes: ^meter, ^auto_go; the cv_rqti_info command into binary form. It describes some physical driver_wait_time: 30; characteristics, and processing mechanisms for the printer request message: type. "New printer driver using MR11.0 and printer_info request type info seg. Please load regular paper stock. Check the alignment of the sample head sheet and give driver the go command when ready."; banner_type: standard; banner_bars: single; prt_control: auto_print, ^force_nep, ^force_esc; paper_width: 136; paper_length: 66; lines_per_inch: 6; line(1): 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16; end; _4_._3 _T_E_S_T _S_C_R_I_P_T ! dp -q 1 (test.output output.test) 1 request signalled, 0 already in printer queue 1 1 request signalled, 1 already in printer queue 1 ! ldr printer queue 1: 2 requests. 2 total requests. 204212.3 test.output 204213.4 output.test 4-2 The Multics I/O SysDaemon MDD-017 ! test_io_daemon iod_tables Enter command: coordinator, driver, or return: ! coord CALL# RECURSION/HIGHEST ENTRYPOINT -> 1 1/1 iodc_$iodc_init I/O Coordinator Version: 3.2 -> 1 1/1 iodc_$free_device <- 1 1/1 iodc_$free_device -> 2 1/1 iodc_$free_device <- 2 1/1 iodc_$free_device -> 3 1/1 iodc_$free_device <- 3 1/1 iodc_$free_device -> 4 1/1 iodc_$free_device <- 4 1/1 iodc_$free_device -> 5 1/1 iodc_$free_device <- 5 1/1 iodc_$free_device -> 6 1/1 iodc_$free_device <- 6 1/1 iodc_$free_device -> 7 1/1 iodc_$free_device <- 7 1/1 iodc_$free_device I/O Coordinator initialized -> 1 1/1 iodc_$command_level ! driver -> 1 1/1 iodd_$iodd_init -> 1 1/1 iodd_msg_ IO Daemon Driver Version: 5.7 Driver running in test mode. <- 1 1/1 iodd_msg_ -> 2 1/1 iodd_msg_ Enter command or device/request_type: <- 2 1/1 iodd_msg_ ! prtc printer -> 3 1/1 iodd_msg_ Requesting devices from coordinator. <- 3 1/1 iodd_msg_ New driver for device prtc, request type printer (series = 10000) -> 1 1/1 iodc_$driver_signal <- 1 1/1 iodc_$driver_signal -> 1 1/1 printer_driver_$init -> 4 1/1 iodd_msg_ New printer driver using MR11.0 and printer_info request type info seg. Please load regular paper stock. Check the alignment of the sample head sheet and give driver the go command when ready. <- 4 1/1 iodd_msg_ -> 5 1/1 iodd_msg_ 4-3 MDD-017 The Multics I/O SysDaemon prtc driver ready at 08/15/86 1343.0 mst Fri <- 5 1/1 iodd_msg_ -> 1 1/1 iodd_listen_ -> 1 1/1 iodd_get_cmd_ Enter command: ! go <- 1 1/1 iodd_get_cmd_ -> 1 1/1 iodd_command_processor_ <- 1 1/1 iodd_command_processor_ -> 2 1/1 iodd_get_cmd_ <- 2 1/1 iodd_get_cmd_ -> 2 1/1 iodc_$driver_signal <- 2 1/1 iodc_$driver_signal -> 1 1/1 printer_driver_$request -> 1 1/1 do_prt_request_ -> 6 1/1 iodd_msg_ Request 10001 printer q1: >udd>m>gg>ddd>idd>test.output from gg.m.a <- 6 1/1 iodd_msg_ -> 1 1/1 io_daemon_account_ <- 1 1/1 io_daemon_account_ -> 7 1/1 iodd_msg_ Charge for request 10001: $0.00 (71 lines, 2 pages) <- 7 1/1 iodd_msg_ <- 1 1 do_prt_request_ <- 1 1/1 printer_driver_$request -> 3 1/1 iodd_get_cmd_ <- 3 1/1 iodd_get_cmd_ -> 3 1/1 iodc_$driver_signal <- 3 1/1 iodc_$driver_signal -> 2 1/1 printer_driver_$request -> 2 1/1 do_prt_request_ -> 8 1/1 iodd_msg_ Request 10002 printer q1: >udd>m>gg>ddd>idd>output.test from gg.m.a <- 8 1/1 iodd_msg_ -> 2 1/1 io_daemon_account_ <- 2 1/1 io_daemon_account_ -> 9 1/1 iodd_msg_ Charge for request 10002: $0.00 (71 lines, 2 pages) <- 9 1/1 iodd_msg_ <- 2 1/1 do_prt_request_ <- 2 1/1 printer_driver_$request -> 4 1/1 iodd_get_cmd_ <- 4 1/1 iodd_get_cmd_ -> 4 1/1 iodc_$driver_signal <- 4 1/1 iodc_$driver_signal -> 10 1/1 iodd_msg_ prtc driver: No requests, driver is idle. <- 10 1/1 iodd_msg_ -> 5 1/1 iodd_get_cmd_ 4-4 The Multics I/O SysDaemon MDD-017 <- 5 1/1 iodd_get_cmd_ -> 5 1/1 iodc_$driver_signal <- 5 1/1 iodc_$driver_signal -> 6 1/1 iodd_get_cmd_ ! logout <- 6 1/1 iodd_get_cmd_ -> 2 1/1 iodd_command_processor_ UW 2 1/1 iodd_command_processor_ unwound UW 1 1/1 iodd_listen_ unwound UW 1 1/1 printer_driver_$init unwound -> 11 1/1 iodd_msg_ <- 11 1/1 iodd_msg_ <- 1 1/1 iodd_$iodd_init Enter command. -> 6 1/1 iodc_$driver_signal -> 8 1/1 iodc_$free_device <- 8 1/1 iodc_$free_device Driver logout for device prtc <- 6 1/1 iodc_$driver_signal ! logout UW 1 1/1 iodc_$command_level unwound <- 1 1/1 iodc_$iodc_init ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved