1 / 10

Building a Bootable OS: Basic Requirements and Interrupt Handling

Learn how to create a bootable OS by understanding the key elements like interrupt handling, user environment preservation, and error handling. Dive into the process of responding to interrupts and mastering context switching. Practice modifying and testing a Small Operating System in z/390 assembler language. Develop essential skills for booting and running your own OS.

vallari-karn
Download Presentation

Building a Bootable OS: Basic Requirements and Interrupt Handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bootable Programs Building an O/S

  2. Basic Requirements of any O/S • Respond to interrupts (all kinds) • Preserve user environment • Protect users and self from corruption • Handle I/O errors • Handle user errors

  3. Responding to ANY interrupt • Hardware loads a pre-defined state vector • Context switch occurs • NSI is inside kernel at primary interrupt handler • Primary handler determines type of interrupt • I/O completion • Service call • Program error • Paging/addressing exception • Save user’s environment (stack, registers) in process’s PCB or thread’s TCB • Branch to detail interrupt handler

  4. Detail interrupt handler • Take required action • All instructions valid • Must not cause another interrupt • Therefore must not do I/O - one exception: • Handling I/O errors may require I/O to device • Interrupt for this 2ndary I/O must be deleted • Must allow for all possible (and improbable) errors • Return to common return point

  5. Common return to user • Determine next thread/process to run • New user • Interrupted user • Locate PCB/TCB for selected user • Prep state vector, could be: • Old vector (in reserved RAM) from previously interrupted program • New vector data determined for a new program • Save kernel’s registers in reserved storage • Restore user’s registers & stack from PCB/TCB • Load prepared state vector for user • Context switch occurs

  6. SOS • A Small Operating System • “built-in” user command-line shell • Written in z/390 assembler language • 32-bit mode • Runs in a z/390 virtual machine • You will • Modify it to provide service call handling • Install it as a bootable program • Boot it • Test it

  7. SOS – bootable drive • Virtual device at address 222 • Preformatted as a CMS disk • Simplifies putting programs on the drive • Reserved space for the bootable program (SOS) • Boot loader (IBM supplied) installed by student • Allows seeing disk content from CMS shell

  8. SOS – original contents • Device address discovery • Operator’s terminal • Boot drive • Locate volume TOC • Locates file directory • Displays content of directory in hexadecimal • Terminates

  9. SOS - Lab 1 • Copy the SOSSAMP file to your “a-disk” • Rename it to: SOS • Assemble it using HLASM • Prepare the bootable drive • Boot it

  10. SOS – Lab 2 • Add “shell” code to the single compile • Add state-vector loading to “activate” shell • Shell displays your prompt, waits for input • Shell issues SVC n in response to input • 0<= n <= 7 • See lab assignment for details • SOS gets control and performs service “n” • SOS • returns control to shell • loads “terminate” state vector

More Related