ECE 391, Computer Systems Engineering
MP3 Checkpoint 2 Hints
General Guidelines
Copyright By PowCoder代写 加微信 powcoder
This document is intended to provide some clarity as to what is expected from your submission at demo. If you have
any feedback to make the document more clear and concise please let us know on Piazza.
1. During demo we will run your tests and only add tests if we determine that your tests are inadequate. You will
lose points for that if we have to add tests.
2. Remember that your tests are running as kernel code.
3. We will be testing different sections independently and will restart your OS multiple times with different tests
enabled each time. Ex: We might will test if you can read small files once and then large files the next time.
4. All your drivers must have the open, close, read and write functions defined, even if they don’t do any-
thing and just return a constant value. Likewise, all these functions must return an integer and follow the
interface provided for the corresponding systems calls.
5. Read ahead for the next checkpoint as a lot of the functionality there is dependent on features you implement in
this checkpoint.
6. Please look at the hints post on Piazza to find a gif of how test cases should look. Remember that this is not a
comprehensive list.
7. Remember to validate your input parameters!
8. Get comfortable with function pointers and writing assembly code in separate .S files as working with inline
assembly can get tricky and lead to subtle bugs in your code.
9. Remember to take advantage of all the main functionalities C and x86 Assembly offer you, code smart! For
example, use structs for the file system structures and use arrays for the terminal!
10. Remember to maintain your bug log! While we know that you are capable programmers, we know that everyone
has bugs. If you tell us that you had no bugs and hence have none in your bug log, we won’t believe you.
11. As always try to use your best style and document code as you write it.
RTC Driver
1. rtc open should reset the frequency to 2Hz.
2. Make sure that rtc read must only return once the RTC interrupt occurs. You might want to use some sort of
flag here (you will not need spinlocks. Why?)
3. rtc write must get its input parameter through a buffer and not read the value directly.
4. There is a one line formula that you can use to check if a number is a power of two. You do not need to use a
lookup table or switch statement to do so. Hint: Think binary or in terms of bits.
5. Your test cases should be able to demonstrate that you are able to change the rtc frequency through all frequen-
6. Though not required for the MP, it is highly recommended that you virtualize your RTC by the next checkpoint.
By virtualizing the RTC you basically give the illusion to the process that the RTC is set to their frequency when
in reality the RTC isn’t. Instead you set the RTC to the highest possible frequency and wait until you receive
x interrupts to return back to the process such that those x interrupts at the highest frequency is equivalent to 1
interrupt at the frequency the process wants.
Terminal Driver
1. All numbers, lower and upper case letters, special characters, the shift, ctrl, alt, capslock, tab, enter and
backspace keys should work as intended. You do not need to print anything on hitting a functional key such as
shift etc.
2. You need not care about mapping the arrow keys or the numpad. As long as pressing these keys does not crash
your kernel, you won’t lose points for not printing these keys, these keys should not be counted as part of
your input buffer either.
3. terminal read only returns when the enter key is pressed and should always add the newline character at the
end of the buffer before returning. Remember that the 128 character limit includes the newline character.
4. terminal read should be able to handle buffer overflow (User types more than 127 characters) and situations
where the size sent by the user is smaller than 128 characters.
5. If the user fills up one line by typing and hasn’t typed 128 characters yet, you should roll over to the next line.
Backspace on the new line should go back to the previous line as well.
6. terminal write should write the number of characters passed in the argument. Do not stop writing at a null
7. You may choose to not print the null bytes (recommended).
8. Both ctrl + l and ctrl + L should clear the screen and reset the buffer. You should not be resetting the read
buffer if the user clears the screen before pressing enter while typing in terminal read.
9. Your keyboard test can just be a calling terminal read, followed by terminal write in a while loop.
File System Driver
1. read dentry by name, read dentry by index and read data are NOT provided for you. The documen-
tation says that these functions are provided by the file system module, you are required to write the file system
2. You should have tests to demonstrate that you can read small files (frame0.txt, frame1.txt), executables
(grep, ls) and large files (fish, verylargetextwithverylongname.tx(t)).
3. directory read should only read one file name at a time.
4. The file names in the dentries need not be null terminated.
5. On reading executables, you should see “ELF” in the beginning and the magic string “0123456789ABCDE-
FGHIJKLMNOPQRSTU at the very end. If you’re printing null bytes you might not be able to see both at the
same time. If you’re using printf to print you might not be able to see the last magic string and will stop printing
at null bytes.
6. Your test for directory read should look like the output from ls, look at the gif for more information.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com