CS452/652 For the Kernel Assignment: Description of all major - - PowerPoint PPT Presentation

▶
cs452 652
SMART_READER_LITE
LIVE PREVIEW

CS452/652 For the Kernel Assignment: Description of all major - - PowerPoint PPT Presentation

Aug 18, 2023 145 likes •291 views

Documentation Requirements CS452/652 For the Kernel Assignment: Description of all major components of the system, g Real-Time e.g. memory management, task management, context switching. Context switching should be Programming described in

slide-1
SLIDE 1

CS452/652 Real-Time Programming Course Notes

Daniel M. Berry, Cheriton School of Computer Science University of Waterloo

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 1

Documentation Requirements

For the Kernel Assignment: g Description of all major components of the system, e.g. memory management, task management, context switching. Context switching should be described in detail. g Description of kernel data structures and algorithms, e.g., task descriptors, scheduler, etc. g Description of syscall implementation, including parameter passing.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 2
  • Doc. Reqs., Cont’d

g Explain why your implementation meets real-time requirements, by giving the complexity of each kernel operation. g Description of test cases, including that they cover what should be tested. g User’s manual g Tour of source code.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 3

Hardware Interrupts

7 6 5 4 3 2 1 USART1 USART0 ICU1 8259 RTC PIT ICU0 8259 CPU INT BUS

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 4
slide-2
SLIDE 2

Acronyms

USART = Universal Synchronous Asynchronous Receiver/Transmitter ICU = Interrupt Control Unit RTC = Real Time Clock PIT = Programmable Interval Timer It bothers me that RTC and PIT are different, because

  • f the chances for drift.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 5

How A Device Speaks to CPU

  • 1. External event occurs.
  • 2. Device asserting interrupt asserts its interrupt line.
  • 3. Interrupts are priority ranked by the ICU, which

interrupts the CPU.

  • 4. CPU reads IRQ (interrupt request) level from ICU

data bus.

  • 5. CPU begins interrupt processing.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 6

Interrupt Numbers

0–31 Processor Internal (GPF, division by zero, etc.) 31–39 First ICU (IRQ0–IRQ7) 40–47 Second ICU (IRQ8–IRQ15) 48–255 Software Interrupts; ∴, for int n, be sure that n≥48!

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 7

To Make Interrupts Happen

g Enable Interrupts by setting IF (Interrupt Enable Flag), which is stored in EFLAGS register. g Instructions are: STI — set IF (enable) CLI — clear IF (disable)

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 8
slide-3
SLIDE 3

Happening, Cont’d

g Interrupts are: f enabled in non-kernel tasks, f disabled in the kernel, and f enabled at boot up. g Unmask interrupts of interest in ICUs. g Configure each device to generate interrupts.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 9

CPU’s response to an Interrupt

  • 1. Push EFLAGS, including current IF.
  • 2. Clear IF and TF (trap flag, to enable single-

stepping; in single-step mode, each instruction is an interrupt).

  • 3. Push CS
  • 4. Push EIP
  • 5. Load CS, EIP from IDT.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 10

Interrupt Service Routine

  • 1. Record interrupt number.
  • 2. Switch into kernel.
  • 3. Send non-specific EOI to ICUs, otherwise they

won’t generate any more interrupts:

  • utb(IO_ICU1,0x20)
  • utb(IO_ICU2,0x20)

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 11

Event Abstraction

An event abstraction is the representation of an external event at the task level. g More than one event can be associated with a physical device, e.g., as for serial input and output. g int AwaitEvent(int EventNumber) — block and wait for an instance of the specified event to occur. g Event may occur before int AwaitEvent is issued; therefore buffer at least one instance of each kind of event.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 12
slide-4
SLIDE 4

Event Abstraction, Cont’d

g Associate an event number with each hardware event. g Can have also software events. g int SignalEvent(int EventNumber) — signals an instance of the specified event, unblocking a task that is awaiting that event number.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 13

A Possible Application of Events

Block a task until the fulfillment of a condition, but allow more than one task to fulfill the condition and then unblock the the waiting task.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 14

Server Implementation

Receive() AwaitEvent()

N Client 1 Client Server HW . . .

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 15

Server Implementation, Cont’d

g On Receive(), server is RECEIVE_BLOCKED g On AwaitEvent(), server is EVENT_BLOCKED Cannot service clients while EVENT_BLOCKED. Cannot respond to events while RECEIVE_BLOCKED. ∴, one type of event starves the other. How can we prevent this starvation?

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 16
slide-5
SLIDE 5

Event Notifier Task

Notifier Event External N Client 1 Client Server . . .

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 17

Notifier

Notifier(){ while(1){ AwaitEvent(eventNumber); /* transform event to */ Send(Server,eventNumber,NULL); /* a message */ } } Then server needs to call only Receive(), and not AwaitEvent(). Notifier and clients are then serviced in the order in which they send.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 18

Server

Server(){ Initialize(); CreateNotifier(); RegisterAs(…); while(1){ (tid,msg) ← Receive(); if (tid==Notifier){ Reply(Notifier,NULL); serviceDevice(); } else { serviceRequest(); } } }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 19

Implementation

New state: EVENT_BLOCKED Event table: g indexed by event numbers g buffers event information g records waiting tasks if any

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 20
slide-6
SLIDE 6

Clock Server

Delay(int t): g Blocks caller for at least t ticks. g A tick is 1/20 of a second. g Implemented by sending a message to clock server. g Clock server replies after at least t ticks.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 21

Delay

Delay(int t){ int clock = WhoIs("clockServer"); Send(clock,(char *)&t,sizeof(t),NULL,0); }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 22

Clock Server

Notifier Server Clock Event Clock N Client 1 Client . . .

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 23

A Problem

What if ALL tasks, other than the clock server and notifier, call Delay()? What happens between now and the next clock tick?

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 24
slide-7
SLIDE 7

What Happens if All Delay?

g Kernel has no tasks to run. g Kernel cannot wait for a hardware event to wake up a notifier, because interrupts are disabled! ∴ There needs to be a running task.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 25

Always Running Task

Create an idle task that never blocks, and runs at the lowest priority! IdleTask(){ while(1); }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 26

Clock Server

ClockServer(){ time = 0; InitializePIT(); notifier = CreateClockNotifier(); while(1){ Loop Body } }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 27

Loop Body

(pid,request) ← Receive(); if(pid == NOTIFIER){ time++; Reply(pid,NULL); while(nextWaitingTime() <= time){ pid = dequeueWaitingTask(); Reply(pid,NULL); } } else { /* assuming that only request is Delay */ enqueueWaitingTask(pid,time + timeRequest); }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 28
slide-8
SLIDE 8

Loop Body, Cont’d

This body assumes that there is only one kind of request, i.e., Delay. If there are others, the else part will have to have a case to separate out which request it is.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 29

Clock Notifier

ClockNotifier(){ while(1){ AwaitEvent(PIT_EVENT); Send(MyParentPid(),NULL,NULL); } }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 30

Programmable Interval Timer

The programmable interval timer (PIT), the Intel 8253: g Interrupt number 32 g Counter 0 g Mode 2 For interrupt number and counter, see Diagram on Page 4.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 31

Mode ?

Mode 1 = HW Interrupt or Exception in Virtual 8086 Mode Mode 2 = Maskable HW Interrupt in Virtual 8086 Mode Mode 3 = SW Interrupt in Virtual 8086 Mode

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 32
slide-9
SLIDE 9

More Clock Primitives

int getTime() — returns the current tick count DelayUntil(int t) — delay until a specified time t; the executing process is blocked to be awakened when tick count ≥ t. These are optional in your kernel.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 33

Delay vs DelayUntil

while (1){ Delay(x); doSomething(); } should have the same effect as t = getTime(); while (1){ t+=x; DelayUntil(t); doSomething(); }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 34

Delay vs DelayUntil, Cont’d

but they don’t. What’s the REAL Difference?

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 35

One Real Difference

The doSomething takes time. ∴, the period in the first case is x + time (doSomething), and the period in the second case is x.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 36
slide-10
SLIDE 10

Another Real Difference

Amount of delay ≥ x, say x+ε. These εs accumulate under successive Delays, but … These εs do not accumulate under successive DelayUntils. ∴, DelayUntil enforces stricter periodicity.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 37

Scheduling Options

time-slicing vs. run-to-completion fair efficient

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 38

When to Reschedule

Rescheduling when a task calls the kernel! Pass() must reschedule! Should interrupt currently executing task periodically, e.g., every k ticks, to force rescheduling for round- robin purposes? Preemption required when a task of a priority higher than that of the running task becomes READY due to an external event!

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 39

Serial Chip

Serial Chip, PC16550D, Universal Asynchronous Receiver/Transmitter (UART) (See Documentation from byterunner) Registers: Transmit Holding Register — for reading from the serial port Receiver Buffer Register — for writing to the serial port

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 40
slide-11
SLIDE 11

Registers, Cont’d

Interrupt Enable Register — for enabling and disabling interrupts Interrupt Types: g Received Data Available g Transmit Holding Register Empty g Receiver Line Status — for error conditions g Modem Status — not needed Interrupt Identification Register — to determine what kind of interrupt fired

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 41

Registers, Cont’d

Line Control Register — to initialize the chip with parity, stop bits, etc. Line Status Register — diagnostics, e.g., ready, error conditions, etc.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 42

Primitives for Kernel Part III

ClockServer required Delay(int t)

  • ptional

int GetTime() DelayUntil(int t)

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 43

Kernel Part III, Cont’d

SerialServer required byte=GetPort(port) Put(byte,port)

  • ptional

write(port,buffer,length) — atomically read(port,buffer,length) readLine(port,buffer,length) See Complete I/O Port List.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 44
slide-12
SLIDE 12

Serial Server

Reader M . . Notifier 1 . Notifier K . . . Writer 1 Writer N Serial Server UART

One notifier per port

1 . . . Reader

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 45

Serial Server, Cont’d

Like the producer–consumer problem, but with multiple producers and multiple consumers.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 46

What If?

Writer 3 Writer 2 Writer 100000000 . . . . . . Notifier Serial events Server Writer 1 Serial

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 47

Too Many Readers

Too many readers or writers or both could starve the notifier, … and the notifier could miss interrupts. How can we ensure that the notifier does not miss interrupts and answers them on time?

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 48
slide-13
SLIDE 13

Guard Process

1 Reader M . . . Writer 1 Writer N Notifier Serial events Serial Server Reader Guard Writer Guard Reader . . .

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 49

Guard

Guard(){ serialServer = MyParentPid(); while(1){ (tid,msg) ← Receive(); replyMsg ← Send(serialServer,msg); Reply(tid,replyMsg); } } Should there be a delay guard for the clock server?