discussion_week_08
ECE 391 Discussion Week 8
Copyright By Assignmentchef assignmentchef
Announcements
OFFICE HOURS ARE CHANGING!
Announcements
Students will be dequeued as a group
TAs will spend a maximum of 30 mins per student at a time
Students must try to debug their code by themselves before they
come to OH
TAs will ask you what you have done so far and can ask you to go back and
try by yourselves before they help you further
TAs will not debug with/for you but instead give you instructions on how
to proceed
Please be mindful of the TAs time and come prepared to Office
RTDC x 3
Look on Piazza if someone has had similar issues
Repeated Piazza questions will be ignored
Announcements & Reminders
MP3.1 due next Monday (October 19st) at 6pm in GitLab
At least 1 member needs to be at the demo (for checkpoints 1 ~ 5)
Everyone must be present for the Final Demos (Week of 12/7)
Start early!
Develop a system of working as a team (e.g. work together
at the same time, use separate branches for each feature,
MP3 Overview
10/12 to 10/19 CP1 (1 week) initializing the kernel
10/19 to 10/26 CP2 (1 week) device drivers
(keyboard/terminal, RTC, filesystem)
Normally drivers are separate from kernel, but for simplicity
the drivers in this MP will be built into the kernel
10/28 Exam 2!
10/26 to 11/9 CP3 (2 weeks) starting user program
execution (system calls)
11/9 to 11/16 CP4 (1 weeks) getting all user
programs and system calls working
11/20 to 11/28 Thanksgiving Break
11/16 to 12/5 CP5 (3 weeks) multiple terminals and
a scheduler
Groups of 3 will not be required to do scheduling
MP3 Overview (contd.)
MP3 is a group project, include everyone when working on it
There will be a peer evaluation at the end of the semester
Everyone must estimate what percentage of work the others did
Your final grade on MP3 will be affected by the peer evaluations
If you fall behind on one checkpoint, you still have to complete it
before the next one because the next checkpoint depends on the
functionalities you implement in the current one
If you have problems with your group, post private posts on Piazza or
email the professor ASAP
Half functionality points back for checkpoints at final demo
MP3 Checkpoint 1
Populate GDT/IDT
Look at the file x86-desc.S
Assembly file which contains GDT/IDT information and initial
paging structures
Must complete this step or your system wont boot at all
MP3 Checkpoint 1
Q. Why doesnt our OS boot?
The base code initially given wont boot up the system. You have to load the Global
Descriptor Table (GDT), which is already filled for you! You should take a look
at x86_desc.S (line 38) and x86_desc.h as well as boot.S (line 27). It is very similar to how
the IDT is done in that same file (x86_desc.S). Please dont just blindly copy paste.
Understand whats going on in this file.
Q. Our OS still isnt booting! (And we loaded the
There is a RUN_TESTS defined at the top of kernel.c. Follow what this macro does
through the code. It should lead you to the tests.c file. There is already one test written
in here for you. Read what it does in its function header.
So it should start to become obvious to you whats happening here. If you have not done
anything with setting up the IDT, this test will fail and your system will triple fault on
boot. Now you see what to expect when you do something really wrong in your code.
You can figure out from here what to do about that
After Loading GDT:
MP3 Checkpoint 1
Initializing and mapping for exception handling, exception handlers
Assembly linkage for both exceptions and interrupts is suggested (this will
make your life a lot easier in CP3)
Device initialization (PIC, keyboard, RTC)
Remember to send EOI for interrupts
Know the difference between trap gate and interrupt gate (which one to use
in different situations)
Last thing to do in CP1
Hardest thing to do in CP1
After step 1
Paging Layout
0 4 MB (virtual and physical)
4KB page (why?)
Video memory
4 8 MB (virtual and physical)
4MB page (why?)
Page Directories (PD) and Page Tables (PT) takes up space
Do not assign some random address to pointers
PDs and PTs can be allocated either in assembly or C
PDs and PTs must be aligned
Alignment spec is in MP3 doc
For CP1 no address after 8MB should be mapped
Example bugs
System crashes after turning on paging
Printing debugging information crashes system (with paging enabled)
Paging (contd.)
Write your own tests to show functionality for all checkpoints
For Checkpoint 1:
This table is not comprehensive
Also look at the hints document on the website
Functionality Test should show
GDT Loaded Correctly System does not boot loop
RTC Able to receive RTC interrupts
Paging Cannot dereference regions that should not be
Dealing with pointers
What about pointers?
Always check NULL
Check known values (a & b in
Check values on stack
Check values on heap (mallocd)
Check userspace pointers
Check kernel pointers
Check non-paged areas (unallocated
.but why?
Write more code to test existing code?
Sounds like a bad idea
Test code is usually separated from
production code.
If your tests are broken, production code
isnt affected
But what about GDB? Ive tested my
code there and it works!!!
Sure, but what if you come back and add
something?
Easier to re-run tests than debug with GDB
all over again
If you test functions against their
specification, adding more code shouldnt
require new test cases
How do I know Ive covered all cases?
Usually not possible to cover every
possible execution
But unit testing is not meant to only to
eliminate basic design and code bugs
Other methods exist to validate code to a
higher level of assurance, but require
more time and effort
How is this useful to writing an OS?
Working in teams
Sanity check your teammates work
Get to blame others when things fail
CS: assignmentchef QQ: 1823890830 Email: [email protected]
Reviews
There are no reviews yet.