A half-baked approach to an embedded device driver framework in - PowerPoint PPT Presentation

� 1 A half-baked approach to an embedded device driver framework in Esterel Timothy Bourke and Leonid Ryzhyk School of Computer Science and Engineering, UNSW and National ICT Australia Arcot Sowmya Ihor Kuz UNSW Asia, Singapore National ICT Australia and UNSW Sydney

� � 2 Leonid’s problem: Reliable driver framework My interest: using synchronous languages? Evaluate feasibility and identify related work, so far: – More questions than answers – Ideas rather than implementations Today: criticisms, opinions, missing references

� � 3 Reliable I/O Framework: Aims Device drivers: 70% of systems code [Chou et al., 2001] 3 times more bugs per line of code

� � � � � � � � � 3-b Reliable I/O Framework: Aims Device drivers: 70% of systems code [Chou et al., 2001] 3 times more bugs per line of code fault avoidance structure framework and API to simplify development fault prevention fault removal reduce number of faults find and eliminate bugs in SW fault detection recognise bad states & behaviours fault tolerance fault isolation prevent faulty drivers from corrupting recover from faults OS and applications error recovery MINIX, NOOKS

4 sm: Ethernet protocol state machine enabled tx_busy txReady! txEnqueue? enableComplete! [SUCCESS ] enable_in_progress tx_ready enable? enableComplete! [ERROR ] disabled txDone! disableComplete! rx_full disable? disable_in_progress rxReady! rxEnqueue? rx_need_more_buffers rxAbortPacket! txAbortPacket! rxDone! Created with Poseidon for UML Community Edition. Not for Commercial Use.

� � � � � � � � � 5 Reliable I/O Framework: Protocol State Machines Constraints on the ordering and content of messages exchanged through a port fault avoidance precise specification fault prevention clarifies/documents API fault removal reduce number of faults static analysis of C analysis of implementation SMs fault detection observe protocol and driver fault tolerance fault isolation memory protection recover from faults graceful termination/recovery of pending requests error recovery recovery protocols(?)

� � � � � 6 Reliable I/O Framework: Extend ‘Iguana’ Framework L4 micro-kernel single-threaded – non-blocking user level drivers split events: shift complexity – request – buffering, – completion – memory allocation, – concurrency into the framework

� � � � � � � � 7 L4 microkernel [Liedtke, 1995] diagram credit: slides for Application CSE/UNSW COMP9242 s2/02 user sys. call mode VFS IPC, file system UNIX File . . . App. server server scheduler, virtual memory kernel IPC mode device drivers, dispatcher, . . . IPC, Virtual Memory hardware hardware Address spaces thin layer on top of hardware Threads Sydney version targeted at embedded systems Heavily optimised IPC Potential mismatch with IPC and architecture blank not real-time

8 Is Esterel suitable for such a subsystem?

8-b Is Esterel suitable for such a subsystem? (not answered!)

� 8-c Is Esterel suitable for such a subsystem? (not answered!) highly suitable? no research needed; just engineering answer: show efficient prototype using existing tools

� � 8-d Is Esterel suitable for such a subsystem? (not answered!) highly suitable? no research needed; just engineering answer: show efficient prototype using existing tools not suitable? give up! answer: reasons why, alternatives

� � � � 8-e Is Esterel suitable for such a subsystem? (not answered!) highly suitable? no research needed; just engineering answer: show efficient prototype using existing tools suitable. . . if what must be done? but what are the limitations? not suitable? give up! answer: reasons why, alternatives

� � � � � � � � � 9 Is Esterel suitable for such a subsystem? Advantageous properties: Notation for event-driven reactive systems Synchronous rounds may simplify recovery mechanisms Amenable to validation (interfaces, model-checking) Desirable properties: Able to exploit hardware memory protection Separate compilation of drivers Operate in a multi-tasking environment Tractable reasoning about execution within the system context Limited addition and removal of hardware Track user request state

10 Presentation Outline Reliable I/O Framework Possible Architectures Strictly event-driven modules Event-driven scheduling Example: IP Stack and Ethernet driver Other related work Summary

� � � � � � � � � 11 Possible Architectures: monolithic Wristwatch [Berry, 1989] Most straight-forward application of Esterel Utilise standard tools application Responsible for interface code Reasoning about system: hardware Behaviour of the underlying transition system Meaning of signals (depends on interface) or, For driver framework: Fast execution (almost no run-time overhead) hardware No memory protection Relatively inflexible

� � � � � � � 12 Architectures: HW/SW Interface (single driver) app. HDLC Protocol [Berry and Gonthier, 1989] . . . Utilize standard tools i/face Application side: may need to avoid blocking hardware Reasoning about system: e.g. As per normal global serializing relation Queueing in application queuing app. For driver framework: HDLC Driver Memory protection possible Communication between drivers? line instantaneous view

� � � � � � 13 Architectures: Application subsystem AT&T 5ESS switch [Jagadeesan et al., 1995] app. Part of TCP/IP stack [Castelluccia et al., 1996] . . . Utilize standard tools OS hardware Ad hoc interfacing code Reasoning about system: and/or, Dependent on application environment app. For driver framework: . . . Less suitable for micro-kernel with user-level drivers OS hardware

14 Architectures: Driver Framework . . . App 1 App n file system IP stack Media Dev. Dev. Hub HD CDR ATA USB HC Eth PCI L4 micro-kernel hardware

14-b Architectures: Driver Framework . . . App 1 App n file system IP stack Media Dev. Dev. Scheduler Hub HD CDR ATA USB HC Eth PCI L4 micro-kernel hardware

14-c Architectures: Driver Framework . . . App 1 App n file system IP stack Media Dev. Dev. Scheduler Hub HD CDR ATA USB HC Eth PCI L4 micro-kernel hardware

� � � � � � ✁ ✁ � ✁ ✁ � 15 Two-level architecture Dynamically scheduled level: flat calculus [Berry and Sentovich, 2001] run comp1[connections] ... run compN[connections] permit (initially): Memory protection for top-level modules – signal S in ... end Trade-off cost of dynamic scheduling – loop ... end ? against safety/flexibility – weak abort ... when S? More constructs for recovery features? Feasiblity uncertain! Component level: strictly event-driven modules Block waiting for events (as per usual) Minimise computation/context-switching

16 Presentation Outline Reliable I/O Framework Possible Architectures Strictly event-driven modules Event-driven scheduling Example: IP Stack and Ethernet driver Other related work Summary

✂ ✂ ✂ 17 Triggering Multiform time [Berry, 2000] application requests General form [Caspi, 2001] driver framework Whatever the structure: hardware interrupts monolithic multi-threaded . . . event-driven rather than sample-driven

18 Strictly event-driven modules Modules where observable behaviour and state changes occur strictly in response to events listed in the input/output interface and are otherwise independent of reaction triggering. statement strictly event-driven? await A; emit O pause ; emit O await A; pause ; emit O loop pause end ( halt )

18-b Strictly event-driven modules Modules where observable behaviour and state changes occur strictly in response to events listed in the input/output interface and are otherwise independent of reaction triggering. statement strictly event-driven? await A; emit O yes pause ; emit O await A; pause ; emit O loop pause end ( halt )

18-c Strictly event-driven modules Modules where observable behaviour and state changes occur strictly in response to events listed in the input/output interface and are otherwise independent of reaction triggering. statement strictly event-driven? await A; emit O yes pause ; emit O no await A; pause ; emit O loop pause end ( halt )

18-d Strictly event-driven modules Modules where observable behaviour and state changes occur strictly in response to events listed in the input/output interface and are otherwise independent of reaction triggering. statement strictly event-driven? await A; emit O yes pause ; emit O no await A; pause ; emit O no loop pause end ( halt )

18-e Strictly event-driven modules Modules where observable behaviour and state changes occur strictly in response to events listed in the input/output interface and are otherwise independent of reaction triggering. statement strictly event-driven? await A; emit O yes pause ; emit O no await A; pause ; emit O no loop pause end ( halt ) yes