MiniOS: an instructional platform
for teaching
operating systems labs
Rafael Román Otero
Supervisor: Dr. Alex Aravind
Committee Members: Dr. Balbinder S. Deo, Dr. David Casperson
University of Northern British Columbia. August 16, 2016
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
The problem
In computer science students typically learn by doing
The problem
In computer science students typically learn by doing
Data structures
The problem
In computer science students typically learn by doing
Data structures Computer programming
The problem
Programming is the fundamental activity of computing.
M. Ben-Ari
““
The problem
Programming is the fundamental activity of computing. […] Courses
should not be purely descriptive
M. Ben-Ari
“
The problem
Programming is the fundamental activity of computing. […] Courses
should not be purely descriptive; instead, they must require students
to construct implementations
M. Ben-Ari
“
”
The problem
Operating System (OS)
The software that sits between the machine and applications.
Machine
OS
Apps
The problem
Operating System (OS)
The software that sits between the machine and applications. Teaching
a course in OS must involve students (partially) writing one.
Machine
OS
Apps
The problem
Operating System (OS)
The software that sits between the machine and applications. Teaching
a course in OS must involve students (partially) writing one.
Student-built OS is the ideal
Machine
OS
Apps
The problem
Operating System (OS)
The software that sits between the machine and applications. Teaching
a course in OS must involve students (partially) writing one.
Student-built OS is the ideal
Machine
OS
Apps
Too complex to be written in one semester
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
Size
Sophistication
Two sources of complexity in OSes
Previous Work
Typical sizes are in the order of millions of LoC.Size
Sophistication
Previous Work
Two sources of complexity in OSes
Typical sizes are in the order of millions of LoC.
Previous Work
Android has over 10 Million LoC
Size
Sophistication
Two sources of complexity in OSes
Typical sizes are in the order of millions of LoC.
Previous Work
Larger systems are harder to understand
Size
Sophistication
Android has over 10 Million LoC
Two sources of complexity in OSes
The “parts” have been made sophisticated to account for
efficient use of memory and CPU, security, robustness,
fault tolerance, and reliability.
Previous Work
Size
Sophistication
Two sources of complexity in OSes
Previous Work
Size
Sophistication
Two sources of complexity in OSes
Instructional OSes
Smaller and simpler OSes, designed
specifically for instruction
Instructional OSes
Previous Work
Over 30,000 LoC
• Xinu
• Minix
Less than 15,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. A complete and functional system
2. Smaller target platform
3. A guide to its design
Instructional OSes
Solution
Complete and functionalOver 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Instructional OSes
Solution
Serve a function, and execute on hardware
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Complete and functional
Instructional OSes
Solution
Serve a function, and execute on hardware
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Complete and functional
Instructional OSes
Solution
Have most of the typical parts of a typical OS
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Complete and functional
Instructional OSes
Solution
Have most of the typical parts of a typical OS
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Complete and functional
Instructional OSes
Solution
Better suited for graduate instruction
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Complete and functional
Instructional OSes
Solution
Smallest yet complete
With 2,500 LoC
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Instructional OSes
Solution
Over 30,000 LoC
• Xinu
• Minix
Less than 20,000 LoC
• OS/161
• Kaya OS
• PintOS
• NachOS
• …
Our approach was to build the simplest
implementation we could think of for
each sub-system
Wayne et al
”
“
Minimality principle:
Smallest yet complete
With 2,500 LoC
Part 1
Solution
We propose to build a complete and functional
minimal instructional OS of even smaller size
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. A complete and functional system
2. Smaller target platform
3. A guide to its design
Solution
Observation
The system is not the only source of complexity.
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Working at the hardware level has two
main disadvantages. First, hardware
devices can be tricky to program
correctly. A more fundamental
problem is that debugging kernel code
running on real hardware is difficult,
even for experts.
Hovemeyer et al (GeekOS)
”
“
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Working at the hardware level has two
main disadvantages. First, hardware
devices can be tricky to program
correctly. A more fundamental
problem is that debugging kernel code
running on real hardware is difficult,
even for experts.
Hovemeyer et al (GeekOS)
”
“
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Working at the hardware level has two
main disadvantages. First, hardware
devices can be tricky to program
correctly. A more fundamental
problem is that debugging kernel code
running on real hardware is difficult,
even for experts.
Hovemeyer et al (GeekOS)
”
“
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Simulated Simpler
Machine
OS
Apps
Nachos
Solution
Observation
The system is not the only source of complexity. Hardware is also
complex.
Simulated Simpler
Machine
OS
Apps
Machine
OS
Apps
Abstraction
Most instructional systems
Nachos
Solution
Removing mysticism
OS
Apps
magic
Solution
Removing mysticism
Black’s OS
Chadwick’s OS
GeekOS
OS from the bare metal
OS
Apps
Machine
Solution
Removing mysticism
OS
Apps
Machine
Black’s OS
Chadwick’s OS
GeekOS
OS from the bare metal
Solution
Simpler machine
OS
Apps
Simpler Machine
Microcontroller (MCU)
Solution
Simpler machine
OS
Apps
Simpler Machine
Microcontroller (MCU)
CPU + Memory + IO
Solution
Simpler machine
OS
Apps
Simpler Machine
Microcontroller (MCU)
CPU + Memory + IO
Simpler architectures
Solution
Simpler machine
OS
Apps
Simpler Machine
Microcontroller (MCU)
CPU + Memory + IO
Simpler architectures
Majority of computers
Solution
Simpler machine
OS
Apps
Simpler Machine
Microcontroller (MCU)
CPU + Memory + IO
Simpler architectures
Majority of computers
Not that different from Desktop computers
Part 2
Solution
We propose to build an instructional OS
for a small MCU platform.
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. A complete and functional system
2. Smaller target platform
3. A guide to the system’s
construction
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
The use of the RTC, CPU
exceptions, context switching
OS implementations
The idea behind an event dispatcher thread,
why system calls are implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, how to return a value from a system
call.
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
The use of the RTC, CPU
exceptions, context switching
OS implementations
The idea behind an event dispatcher thread,
why system calls are implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, how to return a value from a system
call.
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
The idea behind an event dispatcher thread,
why system calls are implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, how to return a value from a system
call.
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
system calls implemented as traps, system calls
implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, how to return a value from a system
call.
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
system calls implemented as traps
Implementation of events,
Programming patterns
Use of callbacks to handle data coming from
interrupts, returning a value from a system call.
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
Implementation of events, system calls
implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, returning a value from a system call.
Problem:
• Too advanced to be left for discovery
• Not OS instruction per se
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
Implementation of events, system calls
implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, returning a value from a system call.
Problem:
• Too advanced to be left for discovery
• Not OS instruction per se
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
Implementation of events, system calls
implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, returning a value from a system call.
Problem:
• Too advanced to be left for discovery
• Not OS instruction per se
• Low success ratio
A guide to its construction
Technical details related to:
Compiler
Relocatable code, GCC calling
conventions, memory
segmentation.
Hardware
Context switching, the use of
the RTC
OS implementations
Implementation of events, system calls
implemented as traps
Programming patterns
Use of callbacks to handle data coming from
interrupts, returning a value from a system call.
Extra instruction necessary to write OS in one semester
A guide to its construction
Foundation
Insofar as there is any evidence from
controlled studies, it almost uniformly
supports direct, strong instructional
guidance […] during the instruction of
novice to intermediate learners
M. Guzdial
”
“
Part 3
A guide to its construction
An in-detail guide that instructs on
how to construct the system from the ground-up
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. MiniOS the system
2. The MCU hardware platform
3. The MiniOS book
MiniOS platform:
MiniOS Platform
The system
MiniOS Platform
The system
MiniOS Platform
The system
MiniOS Platform
The system
Gives lab instructors/students
the flexibility to pick from
available modules
MiniOS Platform
The system
MiniOS Platform
The system
MiniOS Platform
The system
MiniOS Platform
The system
MiniOS Platform
The system
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. MiniOS the system
2. The MCU hardware platform
3. The MiniOS book
MiniOS platform:
MiniOS Platform
The hardware platform
Atmel SAM4S Xplained Pro
MiniOS Platform
The hardware platform
ATSAM4S Microcontroller
• 160 KB RAM
• 2KB Cache
• ARM Cortex-M4 core @ 120 Mhz
Atmel SAM4S Xplained Pro
MiniOS Platform
The hardware platform
Available IO peripherals:
• Light sensor
• Temperature sensor
• SD card slot
• Micro SD Card slot
• 5 LEDs
• 3 Buttons
• OLED screen
• 256 MB Flash
• IEEE 802.15.4 radio
• USB Device port
• Common interfaces: UART, GPIO, PWM…Atmel SAM4S Xplained Pro
MiniOS Platform
The hardware platform
Available IO peripherals:
• Light sensor
• Temp sensor
• SD card slot, and microSD Card slot
• 5 LEDs
• 3 Buttons
• OLED screen
• 256 MB Flash
• IEEE 802.15.4 radio
• Common interfaces: UART, GPIO, PWM…
Atmel SAM4S Xplained Pro
Assumed hardware for
laboratory projects.
Good for student engagement
MiniOS Platform
Availability of third-party drivers
• Atmel drivers
• Hobbyists drivers
MiniOS Platform
Availability of third-party drivers
• Atmel drivers
• Hobbyists drivers
Typically available as bare-metal
MiniOS Platform
Debugging facilities
Development tools
On-board debugger chip
SAM4S board
ATSAM4S
MiniOS Platform
Debugging facilities
Development tools
On-board debugger chip
SAM4S board
Like debugging a
desktop application
ATSAM4S
MiniOS Platform
Debugging facilities
On-board debugger chip
Development tools SAM4S board
Capabilities not available without
additional hacking and cost in non-MCU platforms
Like debugging a
desktop application
ATSAM4S
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
1. MiniOS the system
2. The MCU hardware platform
3. The MiniOS book
MiniOS platform:
MiniOS Platform
The book PART I
(HW Architecture)
1. Introduction
2. ISA
3. Memory
4. IO
5. Stack
6. Interrupts
PART II
(SW System)
1. Basic IO and Booting
2. HAL
3. System calls
4. Fault manager
5. Scheduler
6. IO events
7. Thread synchronization
8. Network Stack
9. CLILatest version of book
MiniOS Platform
The book
Demo videos
Roadmap
1. The problem
2. Previous Work
3. Solution
4. Implementation
5. Evaluation
6. Conclusions
Evaluation
Goals:
• Complete
• Functional
• Smaller than Nachos
Evaluation
Goals:
• Complete
• Functional
• Smaller than Nachos
Size in LoC:
• Pintos 5,000
• MiniOS 3,700 (3,450 C + 230 assembly)
• Nachos 2,500
Evaluation
Goals:
• Complete
• Functional
• Smaller than Nachos
Size in LoC:
• Pintos 5,000
• MiniOS 3,700 (3,450 C + 230 assembly)
• Nachos 2,500
Mistake in thesis
“less than 500 lines of C code”
Evaluation
2013 2014 2015 Current
CPSC 321 (Operating systems)
Evaluation
2013 2014 2015 Current
CPSC 321 (Operating systems)
Evaluation
2013 2014 2015 Current
CPSC 321 (Operating systems)
Evaluation
Book Experiences
Evaluation
Book Experiences
• Video material became an important aspect of the tutorial
Evaluation
Book Experiences
• Video material became an important aspect of the tutorial
• More developed book allowed students to go further in projects
than students from previous years
Maze solver
Evaluation
Book Experiences
• Video material became an important aspect of the tutorial
• More developed book allowed students to go further in projects
than students from previous years
If the guide offers too many
details or too many steps, what
is left for the student to do?
Maze solver
More advanced things.
Evaluation
Project experience
Alarm Clock Pinto Pipes
Evaluation
Language experience
• Students consistently reported much of the struggle with
assignments came from inexperience with C.
Evaluation
Language experience
• Students consistently reported much of the struggle with
assignments came from inexperience with C.
We used the 1 hr weekly tutorial to teach C
Evaluation
Debugger experience
• On occasions, the debugger was the difference between students
completing an assignment or not.
Evaluation
Debugger experience
• On occasions, the debugger was the difference between students
completing an assignment or not.
• Often assistance was given in the form of debugging sessions, as
it allowed to demonstrate a concept that was otherwise not
being understood.
Evaluation
Students feedback
Strength:
“Code base is quite small and it is easy to hold entire system in
your head”
Weakness:
“Assignment are long. A lot of time is required to complete.”
Evaluation
Students feedback
Strength:
“Code base is quite small and it is easy to hold entire system in
your head”
Weakness:
Evaluation
Students feedback
Strength:
“Code base is quite small and it is easy to hold entire system in
your head”
Weakness:
“Assignments are long. A lot of time is required to complete”
Evaluation
Students feedback
Strength:
“Code base is quite small and it is easy to hold entire system in
your head”
“Interacting with real hardware is great”
Weakness:
“Assignments are long. A lot of time is required to complete”
Evaluation
Students feedback
Strength:
“Code base is quite small and it is easy to hold entire system in
your head”
“Interacting with real hardware is great”
Weakness:
“Assignments are long. A lot of time is required to complete”
“C is not something I am particularly familiar with”
Evaluation
MiniOS as an embedded prototyping platform
Built-in functionality
+
Ease of hardware integration
Evaluation
MiniOS as an embedded prototyping platform
Built-in functionality
+
Ease of hardware integration
Running MiniOS
Evaluation
MiniOS as a systems research testbed
Well-documented inner working
+
Simple architecture
Evaluation
MiniOS as a systems research testbed
Well-documented inner working
+
Simple architecture
System’s research testbed
Roadmap
1. The problem
2. Previous Work
3. Solution Rationale PI
4. Solution Rationale PII
5. Solution Rationale PIII
6. Platform
7. Evaluation
8. Conclusions
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
• System is complete, functional, and of small size (<4,000 LoC)
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
• System is complete, functional, and of small size (<4,000 LoC)
• MCU hardware platform
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
• System is complete, functional, and of small size (<4,000 LoC)
• MCU hardware platform
• Guide to its construction
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
• System is complete, functional, and of small size (<4,000 LoC)
• MCU hardware platform
• Guide to its construction
• The first one of its type
Conclusions
Contributions:
• MiniOS, an instructional platform for the delivery of OS
laboratories
• System is complete, functional, and of small size (<4,000 LoC)
• MCU hardware platform
• Guide to its construction
• The first one of its type
• Reported on delivering experiences
Conclusions
Limitations:
• MiniOS cannot replace more traditional desktop-centered
design approaches. (MCUs lack MMU)
Conclusions
Limitations:
• MiniOS cannot replace more traditional desktop-centered
design approaches. (MCUs lack MMU)
Other uses:
• Used as embedded prototyping platform and as system’s
research testbed.
Conclusions
Future Work:
• MiniOS IoT
Conclusions
Future Work:
• MiniOS IoT
• MiniOS Swarm
Conclusions
Future Work:
• MiniOS IoT
• MiniOS Swarm
• Results from CPSC 231 have not been published, and many
have not been discussed in this work.
Conclusions
Future Work:
• MiniOS IoT
• MiniOS Swarm
• Results from CPSC 231 have not been published, and many
have not been discussed in this work.
• Finished Book
Conclusions
Future Work:
• MiniOS IoT
• MiniOS Swarm
• Results from CPSC 231 have not been published, and many
have not been discussed in this work.
• Finished Book
Thank you
Conclusions
References
• Mordechai (Moti) Ben-Ari. In defense of programming. ACM Inroads,
7(1):44–46, February 2016.
• Wayne A. Christopher, Steven J. Procter, and Thomas E. Anderson. The
nachos instructional operating system. In Proceedings of the USENIX Winter
1993 Conference Proceedings on USENIX Winter 1993 Conference
Proceedings, USENIX’93, pages 4–4, Berkeley, CA, USA, 1993. USENIX
Association.
• David Hovemeyer, Jeffrey K. Hollingsworth, and Bobby Bhattacharjee.
Running on the bare metal with geekos. SIGCSE Bull., 36(1):315–319, March
2004.
• Mark Guzdial. What’s the best way to teach computer science to beginners?
Commun. ACM, 58(2):12–13, January 2015.
Conclusions
Image attribution (in order of appearance)
By Jason Scott - Flickr: IMG_9976, CC BY 2.0,
https://commons.wikimedia.org/w/index.php?curid=29457452
Honoré Daumier [Public domain or Public domain], via
Wikimedia Commons
By Wojciech Muła - Own work, Public Domain,
https://commons.wikimedia.org/w/index.php?curid=4878903
Conclusions
Image attribution (in order of appearance)
By Evan-Amos - Own work, Public Domain,
https://commons.wikimedia.org/w/index.php?curid=16128630
Public domain
Bruno Barral (ByB) [CC BY-SA 2.5
(http://creativecommons.org/licenses/by-sa/2.5)], via
Wikimedia Commons
Conclusions
Image attribution (in order of appearance)
CC BY-SA 2.5,
https://commons.wikimedia.org/w/index.php?curid=263864
By Jaksmata - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=4090797

MiniOS: an instructional platform for teaching operating systems labs

  • 1.
    MiniOS: an instructionalplatform for teaching operating systems labs Rafael Román Otero Supervisor: Dr. Alex Aravind Committee Members: Dr. Balbinder S. Deo, Dr. David Casperson University of Northern British Columbia. August 16, 2016
  • 2.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions
  • 3.
    The problem In computerscience students typically learn by doing
  • 4.
    The problem In computerscience students typically learn by doing Data structures
  • 5.
    The problem In computerscience students typically learn by doing Data structures Computer programming
  • 6.
    The problem Programming isthe fundamental activity of computing. M. Ben-Ari ““
  • 7.
    The problem Programming isthe fundamental activity of computing. […] Courses should not be purely descriptive M. Ben-Ari “
  • 8.
    The problem Programming isthe fundamental activity of computing. […] Courses should not be purely descriptive; instead, they must require students to construct implementations M. Ben-Ari “ ”
  • 9.
    The problem Operating System(OS) The software that sits between the machine and applications. Machine OS Apps
  • 10.
    The problem Operating System(OS) The software that sits between the machine and applications. Teaching a course in OS must involve students (partially) writing one. Machine OS Apps
  • 11.
    The problem Operating System(OS) The software that sits between the machine and applications. Teaching a course in OS must involve students (partially) writing one. Student-built OS is the ideal Machine OS Apps
  • 12.
    The problem Operating System(OS) The software that sits between the machine and applications. Teaching a course in OS must involve students (partially) writing one. Student-built OS is the ideal Machine OS Apps Too complex to be written in one semester
  • 13.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions
  • 14.
    Size Sophistication Two sources ofcomplexity in OSes Previous Work
  • 15.
    Typical sizes arein the order of millions of LoC.Size Sophistication Previous Work Two sources of complexity in OSes
  • 16.
    Typical sizes arein the order of millions of LoC. Previous Work Android has over 10 Million LoC Size Sophistication Two sources of complexity in OSes
  • 17.
    Typical sizes arein the order of millions of LoC. Previous Work Larger systems are harder to understand Size Sophistication Android has over 10 Million LoC Two sources of complexity in OSes
  • 18.
    The “parts” havebeen made sophisticated to account for efficient use of memory and CPU, security, robustness, fault tolerance, and reliability. Previous Work Size Sophistication Two sources of complexity in OSes
  • 19.
    Previous Work Size Sophistication Two sourcesof complexity in OSes Instructional OSes Smaller and simpler OSes, designed specifically for instruction
  • 20.
    Instructional OSes Previous Work Over30,000 LoC • Xinu • Minix Less than 15,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • …
  • 21.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. A complete and functional system 2. Smaller target platform 3. A guide to its design
  • 22.
    Instructional OSes Solution Complete andfunctionalOver 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • …
  • 23.
    Instructional OSes Solution Serve afunction, and execute on hardware Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Complete and functional
  • 24.
    Instructional OSes Solution Serve afunction, and execute on hardware Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Complete and functional
  • 25.
    Instructional OSes Solution Have mostof the typical parts of a typical OS Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Complete and functional
  • 26.
    Instructional OSes Solution Have mostof the typical parts of a typical OS Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Complete and functional
  • 27.
    Instructional OSes Solution Better suitedfor graduate instruction Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Complete and functional
  • 28.
    Instructional OSes Solution Smallest yetcomplete With 2,500 LoC Over 30,000 LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • …
  • 29.
    Instructional OSes Solution Over 30,000LoC • Xinu • Minix Less than 20,000 LoC • OS/161 • Kaya OS • PintOS • NachOS • … Our approach was to build the simplest implementation we could think of for each sub-system Wayne et al ” “ Minimality principle: Smallest yet complete With 2,500 LoC
  • 30.
    Part 1 Solution We proposeto build a complete and functional minimal instructional OS of even smaller size
  • 31.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. A complete and functional system 2. Smaller target platform 3. A guide to its design
  • 32.
    Solution Observation The system isnot the only source of complexity.
  • 33.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex.
  • 34.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex.
  • 35.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex. Working at the hardware level has two main disadvantages. First, hardware devices can be tricky to program correctly. A more fundamental problem is that debugging kernel code running on real hardware is difficult, even for experts. Hovemeyer et al (GeekOS) ” “
  • 36.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex. Working at the hardware level has two main disadvantages. First, hardware devices can be tricky to program correctly. A more fundamental problem is that debugging kernel code running on real hardware is difficult, even for experts. Hovemeyer et al (GeekOS) ” “
  • 37.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex. Working at the hardware level has two main disadvantages. First, hardware devices can be tricky to program correctly. A more fundamental problem is that debugging kernel code running on real hardware is difficult, even for experts. Hovemeyer et al (GeekOS) ” “
  • 38.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex. Simulated Simpler Machine OS Apps Nachos
  • 39.
    Solution Observation The system isnot the only source of complexity. Hardware is also complex. Simulated Simpler Machine OS Apps Machine OS Apps Abstraction Most instructional systems Nachos
  • 40.
  • 41.
    Solution Removing mysticism Black’s OS Chadwick’sOS GeekOS OS from the bare metal OS Apps Machine
  • 42.
  • 43.
  • 44.
  • 45.
    Solution Simpler machine OS Apps Simpler Machine Microcontroller(MCU) CPU + Memory + IO Simpler architectures
  • 46.
    Solution Simpler machine OS Apps Simpler Machine Microcontroller(MCU) CPU + Memory + IO Simpler architectures Majority of computers
  • 47.
    Solution Simpler machine OS Apps Simpler Machine Microcontroller(MCU) CPU + Memory + IO Simpler architectures Majority of computers Not that different from Desktop computers
  • 48.
    Part 2 Solution We proposeto build an instructional OS for a small MCU platform.
  • 49.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. A complete and functional system 2. Smaller target platform 3. A guide to the system’s construction
  • 50.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware The use of the RTC, CPU exceptions, context switching OS implementations The idea behind an event dispatcher thread, why system calls are implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, how to return a value from a system call.
  • 51.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware The use of the RTC, CPU exceptions, context switching OS implementations The idea behind an event dispatcher thread, why system calls are implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, how to return a value from a system call.
  • 52.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations The idea behind an event dispatcher thread, why system calls are implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, how to return a value from a system call.
  • 53.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations system calls implemented as traps, system calls implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, how to return a value from a system call.
  • 54.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations system calls implemented as traps Implementation of events, Programming patterns Use of callbacks to handle data coming from interrupts, returning a value from a system call.
  • 55.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations Implementation of events, system calls implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, returning a value from a system call. Problem: • Too advanced to be left for discovery • Not OS instruction per se
  • 56.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations Implementation of events, system calls implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, returning a value from a system call. Problem: • Too advanced to be left for discovery • Not OS instruction per se
  • 57.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations Implementation of events, system calls implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, returning a value from a system call. Problem: • Too advanced to be left for discovery • Not OS instruction per se • Low success ratio
  • 58.
    A guide toits construction Technical details related to: Compiler Relocatable code, GCC calling conventions, memory segmentation. Hardware Context switching, the use of the RTC OS implementations Implementation of events, system calls implemented as traps Programming patterns Use of callbacks to handle data coming from interrupts, returning a value from a system call. Extra instruction necessary to write OS in one semester
  • 59.
    A guide toits construction Foundation Insofar as there is any evidence from controlled studies, it almost uniformly supports direct, strong instructional guidance […] during the instruction of novice to intermediate learners M. Guzdial ” “
  • 60.
    Part 3 A guideto its construction An in-detail guide that instructs on how to construct the system from the ground-up
  • 61.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. MiniOS the system 2. The MCU hardware platform 3. The MiniOS book MiniOS platform:
  • 62.
  • 63.
  • 64.
  • 65.
    MiniOS Platform The system Giveslab instructors/students the flexibility to pick from available modules
  • 66.
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. MiniOS the system 2. The MCU hardware platform 3. The MiniOS book MiniOS platform:
  • 72.
    MiniOS Platform The hardwareplatform Atmel SAM4S Xplained Pro
  • 73.
    MiniOS Platform The hardwareplatform ATSAM4S Microcontroller • 160 KB RAM • 2KB Cache • ARM Cortex-M4 core @ 120 Mhz Atmel SAM4S Xplained Pro
  • 74.
    MiniOS Platform The hardwareplatform Available IO peripherals: • Light sensor • Temperature sensor • SD card slot • Micro SD Card slot • 5 LEDs • 3 Buttons • OLED screen • 256 MB Flash • IEEE 802.15.4 radio • USB Device port • Common interfaces: UART, GPIO, PWM…Atmel SAM4S Xplained Pro
  • 75.
    MiniOS Platform The hardwareplatform Available IO peripherals: • Light sensor • Temp sensor • SD card slot, and microSD Card slot • 5 LEDs • 3 Buttons • OLED screen • 256 MB Flash • IEEE 802.15.4 radio • Common interfaces: UART, GPIO, PWM… Atmel SAM4S Xplained Pro Assumed hardware for laboratory projects. Good for student engagement
  • 76.
    MiniOS Platform Availability ofthird-party drivers • Atmel drivers • Hobbyists drivers
  • 77.
    MiniOS Platform Availability ofthird-party drivers • Atmel drivers • Hobbyists drivers Typically available as bare-metal
  • 78.
    MiniOS Platform Debugging facilities Developmenttools On-board debugger chip SAM4S board ATSAM4S
  • 79.
    MiniOS Platform Debugging facilities Developmenttools On-board debugger chip SAM4S board Like debugging a desktop application ATSAM4S
  • 80.
    MiniOS Platform Debugging facilities On-boarddebugger chip Development tools SAM4S board Capabilities not available without additional hacking and cost in non-MCU platforms Like debugging a desktop application ATSAM4S
  • 81.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions 1. MiniOS the system 2. The MCU hardware platform 3. The MiniOS book MiniOS platform:
  • 82.
    MiniOS Platform The bookPART I (HW Architecture) 1. Introduction 2. ISA 3. Memory 4. IO 5. Stack 6. Interrupts PART II (SW System) 1. Basic IO and Booting 2. HAL 3. System calls 4. Fault manager 5. Scheduler 6. IO events 7. Thread synchronization 8. Network Stack 9. CLILatest version of book
  • 83.
  • 84.
    Roadmap 1. The problem 2.Previous Work 3. Solution 4. Implementation 5. Evaluation 6. Conclusions
  • 85.
  • 86.
    Evaluation Goals: • Complete • Functional •Smaller than Nachos Size in LoC: • Pintos 5,000 • MiniOS 3,700 (3,450 C + 230 assembly) • Nachos 2,500
  • 87.
    Evaluation Goals: • Complete • Functional •Smaller than Nachos Size in LoC: • Pintos 5,000 • MiniOS 3,700 (3,450 C + 230 assembly) • Nachos 2,500 Mistake in thesis “less than 500 lines of C code”
  • 88.
    Evaluation 2013 2014 2015Current CPSC 321 (Operating systems)
  • 89.
    Evaluation 2013 2014 2015Current CPSC 321 (Operating systems)
  • 90.
    Evaluation 2013 2014 2015Current CPSC 321 (Operating systems)
  • 91.
  • 92.
    Evaluation Book Experiences • Videomaterial became an important aspect of the tutorial
  • 93.
    Evaluation Book Experiences • Videomaterial became an important aspect of the tutorial • More developed book allowed students to go further in projects than students from previous years Maze solver
  • 94.
    Evaluation Book Experiences • Videomaterial became an important aspect of the tutorial • More developed book allowed students to go further in projects than students from previous years If the guide offers too many details or too many steps, what is left for the student to do? Maze solver More advanced things.
  • 95.
  • 96.
    Evaluation Language experience • Studentsconsistently reported much of the struggle with assignments came from inexperience with C.
  • 97.
    Evaluation Language experience • Studentsconsistently reported much of the struggle with assignments came from inexperience with C. We used the 1 hr weekly tutorial to teach C
  • 98.
    Evaluation Debugger experience • Onoccasions, the debugger was the difference between students completing an assignment or not.
  • 99.
    Evaluation Debugger experience • Onoccasions, the debugger was the difference between students completing an assignment or not. • Often assistance was given in the form of debugging sessions, as it allowed to demonstrate a concept that was otherwise not being understood.
  • 100.
    Evaluation Students feedback Strength: “Code baseis quite small and it is easy to hold entire system in your head” Weakness: “Assignment are long. A lot of time is required to complete.”
  • 101.
    Evaluation Students feedback Strength: “Code baseis quite small and it is easy to hold entire system in your head” Weakness:
  • 102.
    Evaluation Students feedback Strength: “Code baseis quite small and it is easy to hold entire system in your head” Weakness: “Assignments are long. A lot of time is required to complete”
  • 103.
    Evaluation Students feedback Strength: “Code baseis quite small and it is easy to hold entire system in your head” “Interacting with real hardware is great” Weakness: “Assignments are long. A lot of time is required to complete”
  • 104.
    Evaluation Students feedback Strength: “Code baseis quite small and it is easy to hold entire system in your head” “Interacting with real hardware is great” Weakness: “Assignments are long. A lot of time is required to complete” “C is not something I am particularly familiar with”
  • 105.
    Evaluation MiniOS as anembedded prototyping platform Built-in functionality + Ease of hardware integration
  • 106.
    Evaluation MiniOS as anembedded prototyping platform Built-in functionality + Ease of hardware integration Running MiniOS
  • 107.
    Evaluation MiniOS as asystems research testbed Well-documented inner working + Simple architecture
  • 108.
    Evaluation MiniOS as asystems research testbed Well-documented inner working + Simple architecture System’s research testbed
  • 109.
    Roadmap 1. The problem 2.Previous Work 3. Solution Rationale PI 4. Solution Rationale PII 5. Solution Rationale PIII 6. Platform 7. Evaluation 8. Conclusions
  • 110.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories
  • 111.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories • System is complete, functional, and of small size (<4,000 LoC)
  • 112.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories • System is complete, functional, and of small size (<4,000 LoC) • MCU hardware platform
  • 113.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories • System is complete, functional, and of small size (<4,000 LoC) • MCU hardware platform • Guide to its construction
  • 114.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories • System is complete, functional, and of small size (<4,000 LoC) • MCU hardware platform • Guide to its construction • The first one of its type
  • 115.
    Conclusions Contributions: • MiniOS, aninstructional platform for the delivery of OS laboratories • System is complete, functional, and of small size (<4,000 LoC) • MCU hardware platform • Guide to its construction • The first one of its type • Reported on delivering experiences
  • 116.
    Conclusions Limitations: • MiniOS cannotreplace more traditional desktop-centered design approaches. (MCUs lack MMU)
  • 117.
    Conclusions Limitations: • MiniOS cannotreplace more traditional desktop-centered design approaches. (MCUs lack MMU) Other uses: • Used as embedded prototyping platform and as system’s research testbed.
  • 118.
  • 119.
  • 120.
    Conclusions Future Work: • MiniOSIoT • MiniOS Swarm • Results from CPSC 231 have not been published, and many have not been discussed in this work.
  • 121.
    Conclusions Future Work: • MiniOSIoT • MiniOS Swarm • Results from CPSC 231 have not been published, and many have not been discussed in this work. • Finished Book
  • 122.
    Conclusions Future Work: • MiniOSIoT • MiniOS Swarm • Results from CPSC 231 have not been published, and many have not been discussed in this work. • Finished Book Thank you
  • 123.
    Conclusions References • Mordechai (Moti)Ben-Ari. In defense of programming. ACM Inroads, 7(1):44–46, February 2016. • Wayne A. Christopher, Steven J. Procter, and Thomas E. Anderson. The nachos instructional operating system. In Proceedings of the USENIX Winter 1993 Conference Proceedings on USENIX Winter 1993 Conference Proceedings, USENIX’93, pages 4–4, Berkeley, CA, USA, 1993. USENIX Association. • David Hovemeyer, Jeffrey K. Hollingsworth, and Bobby Bhattacharjee. Running on the bare metal with geekos. SIGCSE Bull., 36(1):315–319, March 2004. • Mark Guzdial. What’s the best way to teach computer science to beginners? Commun. ACM, 58(2):12–13, January 2015.
  • 124.
    Conclusions Image attribution (inorder of appearance) By Jason Scott - Flickr: IMG_9976, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=29457452 Honoré Daumier [Public domain or Public domain], via Wikimedia Commons By Wojciech Muła - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=4878903
  • 125.
    Conclusions Image attribution (inorder of appearance) By Evan-Amos - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=16128630 Public domain Bruno Barral (ByB) [CC BY-SA 2.5 (http://creativecommons.org/licenses/by-sa/2.5)], via Wikimedia Commons
  • 126.
    Conclusions Image attribution (inorder of appearance) CC BY-SA 2.5, https://commons.wikimedia.org/w/index.php?curid=263864 By Jaksmata - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4090797

Editor's Notes

  • #2 Hello, my name is Rafael Roman, and for the next 22mins I’ll be presenting my graduate thesis work
  • #3 I’ll start by introducing the problem, and elaborating on previous work Then in three parts I’ll present our solution Followed by the actual solution platform also in three parts Then I’ll proceed with its evaluation, And Lastly I’ll conclude with some remarks… Let us begin with the problem
  • #4 In computer science….
  • #5 For example, in a course in data structures students build trees and maps
  • #6 Similarly, in programming courses, we make students construct programs.
  • #7 In the words of.....
  • #9 Now, let us consider applying this to operating systems…
  • #10 Roughly speaking, an operating….
  • #11 From what I mentioned earlier it follows that teaching….
  • #12 In fact, a student-built OS is considered to be ideal
  • #13 The problem with this is that OSes are complex. Too complex to be built in one semester.
  • #14 This is not a new problem, and people has work on it previously. Now we’ll look at previous solutions. [1:50]
  • #15 To understand solutions first we have to understand what makes OSes complex.
  • #16 OSes are large pieces of software. Their sizes are typically in the order….
  • #17 For example the Android OS has over…
  • #18 This is a problem, because we know that, in general,….
  • #19 OSes are also sophisticated. The different parts conforming an OS are sophisticated…
  • #20 With this in mind, it is possible to design smaller and simpler OSes for instructional purposes. We call them Instructional OS
  • #21 Among others, some representative examples are Xinu and Minix with over…. And OS/161, Kaya…
  • #22 And that takes us to our solution, which is split in three parts. First I’ll describe the system we propose… [3:13]
  • #23 For the purposes of this presentation we’ll be using two terms to describe instructional systems. Namely, complete and functional.
  • #24 We call functional those systems that a) are developed to a degree that allows them to serve a function, and b) execute on actual hardware. For example, the system for a teller machine or a router.
  • #25 The only two systems that fulfil this description, among the entire set of instructional OSes, are…
  • #26 Complete are those systems that have most of the typical parts of a typical OS.
  • #27 From this description, the only complete ones are…
  • #28 Not surprisingly, Xinu and Minix are the only ones that are both complete and functional, but their larger size makes them better suit for graduate instruction, and we will not consider them further.
  • #29 From the remaining ones, NachOS is of our special interest, as it is complete, and yet the smallest with 2,500 LoC.
  • #30 This is due to their minimality principle, which Weyne et al state as follows….
  • #31 Continuing with this minimality principle, we propose for the first part of our solution….
  • #32 Now the second part of our solution…. [5: 10]
  • #33 This second part is based on the observation that the system…
  • #34 Present time computers are intricate pieces of hardware.
  • #35 At its lowest level, getting the machine to do anything can be challenging.
  • #36 Such difficulties have been recognized previously. Hovemeyer et al state…
  • #39 Two solutions exist in literature. The first one is to build the OS on top a simulated simpler machine… Nachos, for example, does this
  • #40 The second solution is to introduce extra layers of indirection as to avoid exposing students to the physical machine. Most instructional systems fit in this category.
  • #41 However, we are of the opinion that programming bare hardware is necessary to remove the mysticism surrounding the machine.
  • #42 We are not the only ones to think so. In fact, there exist, a class of instructional OSes that are meant to be built from the ground up, from scratch.
  • #43 The problem with this approach is that because of how complex hardware is, students dedicate most of their time to struggle with the machine, and end up writing a rudimentary OS with no resemblance to an actual OS. And Precisely to this problem we offer a solution.
  • #44 Our solution is to use a simpler machine: a microcontroller.
  • #45 MCUs are computers on a chip. Memory, CPU and IO peripherals are part of the same silicon die.
  • #46 They have simpler architectures
  • #47 And contrary to common appreciation, MCUs are relevant, as they make up the majority of computers that we are surrounded by. Specially with newer technologies such as internet of things.
  • #48 Also, some of them are not that different from Desktop computers.
  • #49 Therefore, as the second part of our solution we propose…
  • #50 Now, the last part of the solution… [8:05]
  • #51 The idea is to provide a guide demonstrating step by step the construction of the system. Such guide must cover all details related to...
  • #52 This includes topics such as ….
  • #53 
  • #54 
  • #55 Among several other details….
  • #56 The problem here is that some of this information is too technical or advanced to be left for discovery, and some does not pertain to OS instruction per se.
  • #57 For example, context switching is a very technical mechanical task. Students could easily spend two weeks going through the documentation, or even a lab assignment document on how to do it.
  • #58 Still there is little instructional value in it. Not to mention most of the class would fail to complete it.
  • #59 We argue that without this extra instruction, it is practically impossible for students to build an OS in one semester.
  • #60 As it turns out, this extra instruction policy has a foundation. Guzdial states that…
  • #61 Consequently, as the last part of our solution we propose….
  • #62 Now it’s time to look at the implementation of the solution platform. We’ll start with the system… [10:10]
  • #63 The system is composed of base modules and optional modules.
  • #64 Base modules constitute the functional foundation of the system, and they must be implemented. These include: A HAL with three abstractions… A system calls interface A user-level library called minilib An application loader A common system module
  • #65 On the contrary, optional modules add specific functionality to the system, and they may or may not be integrated. These modules are… A memory protection module A fault manager A kernel console A basic network stack An IO manager that handles interrupt IO A priority-based thread scheduler A file system An IO event dispatcher thread An a user-level CLI
  • #66 The idea of optional modules is to make implementation of the system flexible. Lab instructors or students start with a functional base and add modules to accommodate to their specific instructional objectives.
  • #67 To give you a better idea, here we have a sample program. In this program we have a main thread.
  • #68 When main executes it creates two more threads, Mariana and Cafe
  • #69 And then goes to print sensor information on the OLED screen, and blinks LED0 every half a second
  • #70 When Mariana and Café run, they print a salute with their names over the USB, around 5 times a second.
  • #71 Also, whenever a MAC frame is received over the wireless channel, this event handler executes and echoes whatever was received.
  • #72 Now let us consider the hardware platform… [12:35]
  • #73 As MCU platform we chose an….
  • #74 This is a prototyping board and uses an ATSAM4S MCU, which integrates…
  • #75 The functionality of the main board can be expanded by using expansion boards. Expansion boards plug into the main board and altogether supply a good number of IO peripherals:
  • #76 This is the hardware necessary to complete laboratory projects, and it is enough to make them interesting, which is good for engaging students….
  • #77 One benefit of using a MCU platform is the availability of third-party drivers. There are drivers available from the manufacturer itself, and from hobbyists.
  • #78 Third-party drivers are typically available as bare-metal, and this is exactly why we have at the very bottom this bare-metal firmware layer in the architecture. This layout allows us to take advantage of available firmware.
  • #79 Another benefit of using a MCU platform is the availability of debugging facilities. The SAM4S board has this on-board debugger chip that sits between the development tools and the MCU.
  • #80 It enables debugging of firmware running in the MCU as if it was a regular desktop application
  • #81 Such capabilities are not available in non-MCU platforms without extra effort and cost.
  • #82 As the last part of our implementation we have the MiniOS book… [15:00]
  • #83 The book is split in two parts. The first part is dedicated to the hardware, while the second part to the system. The first part includes the topics…. The second part has a near one-to-one correspondence with modules in the architecture
  • #84 In addition to text material we have prepared demo videos. Their purpose is to strengthen the text material, by visually demonstrating concepts, techniques, methods, examples, or even solutions to labs. We have found these videos to be quite helpful for students.
  • #85 Evaluation… [16:00]
  • #86 We mentioned MiniOS was meant to be complete, functional and even smaller than Nachos.
  • #87 With 3,700 LoC, MiniOS is complete and functional, but it’s not smaller than Nachos. The comparison is a little difficult because we do have more components, and we run on actual hardware. Still, technically, MiniOS is larger.
  • #88 Now, there is a mistake in the thesis. The thesis says… it should say…
  • #89 MiniOS has evolved over the years. From 2013 to 2015, previous versions of the system were used as the laboratory component for CPSC 321 here at UNBC.
  • #90 You can see the evolution from a very rudimentary 2013 to the present one.
  • #91 The book material has also changed drastically. Right now my supervisor and I are working on finishing the latest version.
  • #92 In any case, overall the delivery of the material went without problems, and in the process we gathered some experiences.
  • #93 Video material was well received, and it became….
  • #94 We noticed that, the more developed the book was, the more advanced projects students were able to make. For example, in the latest offering, students modified the OLED drivers to draw mazes.
  • #95 This answers the question of ….
  • #96 The type of projects student build are varied. For example, the project on the left is an alarm clock, and it required quite some wiring. The one on the right did not require any hardware, it is a simple implementation of a command-line that supports redirection (this is another example of what I mean by “more advanced project”).
  • #97 For most students CPSC 321 was their first serious encounter with the C language. Because of this they cons… Specially, pointers and pointer to pointers.
  • #98 We offered a 1h weekly tutorial, but it only mitigated it.
  • #99 The presence of debugging facilities showed to be very important…
  • #100 Due to the visual and interactive nature of the debugger…
  • #101 We asked students for strengths and weaknesses. The answers were many, but these are two of them.
  • #102 Strength…
  • #103 Weakness…
  • #104 Weakness…
  • #105 Weakness…
  • #106 The amount of functionality built-in, together with the ease of hardware integration, made MiniOS a good alternative for embedded systems prototyping.
  • #107 Those in the picture are two robots from a multi-robot research platform, running MiniOS.
  • #108 In the same manner, given that its inner working are well documented and are simpler that other systems.
  • #109 It could serve well as a system’s research testbed, where system designs can be tried in a smaller time frame.
  • #110 Lastly, I’ll conclude with some remarks…. [21:00]
  • #111 The main contribution of this thesis is
  • #112 Following on the steps of previous instructional OSes, it was implemented as a complete and functional system with less than 4,000 LoC
  • #113 It proposed and demonstrated the use of a MCU target platform for an instructional OS
  • #114 It proposed and demonstrated a book describing step-by-step its construction from the ground up
  • #115 To our knowledge, it’s the first one of its type.
  • #116 This thesis also reported on experience using the platform at UNBC
  • #117 Limitations! MiniOS cannot replace more… Specially when instructional objectives include topics related to the MMU, and OSes as they are built in industry.
  • #118 Instruction is not the only setting where MiniOS has found use. It has been used as an embedded prototyping platform, and has the potential of serving as a systems research test bed.
  • #119 Future Work! With additional work on internet connectivity, it is possible to customize MiniOS to work as an IoT OS.
  • #120 There’s no OS targeted specifically for swarm hardware platforms (not yet). These platforms are typically MCU platforms (so there’s space to do something).
  • #121 The material has been used in two occasions to deliver computer architecture labs. However, those results have not…
  • #122 Currently we are working on the latest version of the manual that we intend to publish like a small e-book.
  • #123 Currently we are working on the latest version of the manual that we intend to publish like a small e-book… [23:30]