Input and Output

In Symbian OS
 Introduction
• Input / Output is the messiest part of any OS
– Wide variety of devices
– Wide variety of application of devices

• Symbian OS’s input and output structure

mirrors that of other OS designs
 Categories of I/O Devices
• Human readable
– Used to communicate with the user
– Printers and terminals, keyboards, mouse (?)
• Machine readable
– Used to communicate with electronic equipment
– Disk drives, USB keys
– Sensors, Controllers, Actuators
• Communication
– Used to communicate with remote devices
– Digital line drivers
– Modems
 Differences in I/O Devices
• Data rate
– May be differences of several orders of
magnitude between the data transfer rates
 Differences in I/O Devices
• Application
– Disk used to store files requires file management
software
– Disk used to store virtual memory pages needs
special hardware and software to support it
– Terminal used by system administrator may have a
higher priority than for ordinary user
 Differences in I/O Devices
• Complexity of control
• Unit of transfer
– Data may be transferred as a stream of bytes for a
terminal or in larger blocks for a disk
• Data representation
– Encoding schemes
• Error conditions
– Devices respond to errors differently
 I/O Devices
• Attached to the computer bus
• An input device is capable of transferring some
data into a register on the CPU, and the CPU
can then store it in primary memory
• The CPU can fetch data from primary memory
and write it over the bus to an output device
 Device controllers
• I/O devices have controllers which control the details
of operating the physical device
– so that the CPU and software don't have to be concerned
with it
– the controller takes constant care of the device
• The controller connects the device to the data and
address buses, and provides components that the CPU
can use to operate the device
 Device controllers
• The type and nature of devices varies, so the
software interface to the controller differs
• However, they do provide the same basic
interface
• As part of the goal of resource abstraction, the
OS hides differences between controllers and
devices behind a common interface
 Device controller/software
Application program
The device Software in
the CPU
manager: A Abstract I/O machine
program to
manage the
device controller.
Runs in
supervisor mode.

Device controller

Bus linking device

to controller
Devices
General device controller interface

... busy done error code ...

Command Status Data 0

Data 1

Logic
Data n-1
 Device controllers

• Two flags of status register: busy and done

• Used to signal events to the CPU as they occur
Busy Done Meaning
0 0 Idle
1 0 Working
0 1 Finished
1 1 Undefined
 Device controllers
• A status register holds an error code should a device
operation fail
• The controller buffers hold a small amount of data
that has been read from the device but not yet copied
by the CPU, or data that has yet to be written to the
device
• It allows I/O operations to overlap CPU processing by
another process more easily
 Device drivers
• Device drivers execute as kernel privileged
code to give user level code access to system-
protected resources
• Device driver split into two levels
– Logical device driver (LDD). Interface to upper
layers of software
– Physical device driver (PDD). Interacts directly
with hardware
 Device drivers
• Example: serial device
– Symbian defines generic serial LDD that defines
program interfaces for accessing serial device
– LDD supplies interface to PDD which provides
interface to serial devices
– PDD implements buffering and flow control
mechanisms to help regulate differences in speed
between CPU and serial devices
– Single LDD can connect to any PDD that may be used
to run serial devices
– E.g. IR port, or RS-232 port
 Kernel extensions
• Device drivers loaded by Symbian OS at boot
time
– Special cases that need to be treated differently to
normal device drivers
– Specifically targeted at certain devices, and
typically not paired with PDDs
– Built into boot procedure, and loaded and started
just after scheduler starts
 Kernel extensions
• Implement crucial function to OS
– DMA services
– Display management
– Bus control to peripheral devices (e.g. USB bus)
• Provided for two reasons
– Match OO design abstractions
– Allow separate platforms that Symbian OS runs to
run on specialised device drivers that enable
hardware platform without recompiling kernel
 Hardware Abstraction Layer
• HAL is set of variables and functions that
access system configuration and attributes
• API consists of series of C++ enumerations and
handler functions that mange group attributes
• HAL groups
– Hardware devices (e.g. displays or keyboards)
– General platform parameters (e.g. media driver
information, timers)
 Direct Memory Access
• Device drivers frequently make use of DMA
• DMA hardware supported by Symbian

• What is DMA?
 Performing a write operation
• Devices are much slower than the CPU
• The CPU keeps checking the status while the
device performs its operation
• It would be more efficient for the CPU to be
used for other processing
 Techniques for Performing I/O
• Programmed I/O
– Process is busy-waiting for the operation to complete
• Interrupt-driven I/O
– I/O command is issued
– Processor continues executing instructions
• Direct Memory Access (DMA)
– DMA module controls exchange of data between main
memory and the I/O device
– Processor interrupted only after entire block has been
transferred
 Programmed I/O
• I/O module performs the action,
not the processor
• Sets the appropriate bits in the
I/O status register
• No interrupts occur
• Processor checks status until
operation is complete
 Interrupt-Driven I/O
• Processor is interrupted
when I/O module ready to
exchange data
• Processor saves context of
program executing and
begins executing interrupt-
handler
 Interrupt-Driven I/O
• No needless waiting
• Consumes a lot of processor
time because every word
read or written passes
through the processor
 Direct Memory Access
• So far, the device driver software running on
the CPU copies data from a process's address
space to the controller's buffer
– the CPU is involved for every block of data
transferred to the buffer
• DMA controllers can read and write data from
memory without using the CPU
 Direct Memory Access
• The controller doesn't necessarily need data
buffer registers any more
• The flags are still used in the same way
• Commands must include pointers to memory
from which data is to be read, or to which data
is to be written
 Direct Memory Access
• Transfers a block of data
directly to or from memory
– DMA module takes control of
bus
• An interrupt is sent when
the transfer is complete
• More efficient
 Direct Memory Access
• Processor delegates
I/O operation to the
DMA module
• DMA module
transfers data
directly to or form
memory
• When complete DMA
module sends an
interrupt signal to
the processor
 Direct Memory Access
• Performance is greatly improved:
– the CPU can do other work while the device is busy.
Far more so than the buffering of the device
controller allows
– the device doesn't have to wait for the CPU to
transfer more data into the buffer. i.e. the time
between signalling "done" and the next command
being initiated is reduced
 DMA and device drivers
• Device transmits data to memory and a
system interrupt is triggered
– DMA service provided by DMA hardware used by
PDD for the transmitting device
• Between PDD and DMA controller, Symbian
OS implements two layers of software
– Software DMA layer
– Kernel extension that interfaces with DMA
hardware
 Software DMA
• DMA layer split into platform independent
and dependent sections
• DMA layer is one of first device drivers to by
started by kernel during boot procedure
• Very complicated!
– Symbian supports many configurations, so no
single DMA configuration can be assumed
 Special Case: Storage Media
• Media drivers are a special form of PDD
– Used exclusively by file server to implement access to
storage media devices
• Smart phones contain both fixed and removable
media, so media drivers must recognise and
support variety of forms of storage
• Symbian OS support for media includes standard
LDD and interface API for users
– File server in Symbian can support up to 26 different
drives (distinguished by drive letters)
Relationship Among Techniques
 Blocking IO
• Active objects used to deal with blocking IO
– Weight of all threads waiting on an IO event
affects other threads in system
– Active objects allow blocking IO calls to be
handled by OS rather than process
– Active objects coordinated by single scheduler and
implemented as single thread
 Blocking IO
• When active object uses blocking IO call
– Signal OS and suspends itself
• When blocking call completes
– OS wakes up suspended process, and then process
continues execution (as if returned from function)
• Difference is in perspective
– Active object cannot call a function and expect a
return value
– Must call special function and let that function set up
blocking IO but return immediately
– OS takes over the waiting
 Removable media
• Different from other IO. Example:
– SD card inserted into reader slot
– It is a device like all others (therefore needs controller,
driver, bus structure, and will probably communicate
to CPU through DMA)
– Issue is that you can remove the media
• How does OS detect insertion / removal?
• How should device model accommodate absence
of a media card?
• What if reader slot can accommodate more than
one type of car (e.g. SD, mini SD, MMC)
 Removable media
• Symbian starts its implementation with
similarities of removable media
– All devices must be inserted and removed
– All removable media can be removed “hot” (e.g.
while being used)
– Each medium can report its capabilities
– Incompatible cards must be rejected
– Each card needs power
 Removable media
• Symbian OS provides software controllers that
control each supported card
• Controllers work with device drivers for each card
(in software)
– Socket object created when card inserted
– Object form channel over which data flows
• To accommodate changes in card’s state, Symbian
provides series of events that occur when state
changes happen
– Device drivers configured like active objects to listen
for and respond to events