代做OS| 代做quiz | 代做assignment | 操作系统代做 – OPERATING SYSTEMS

2022-12-19

OPERATING SYSTEMS

代做OS| 代做quiz | 代做assignment | 操作系统代做 – 这道题目是利用操作系统编程代写任务, 是有一定代表意义的OS等代写方向, 这是值得参考的assignment代写的题目

web代写 代写web 网站代写

School of Computer Science

COMP 3000 (WINTER 2022 ) OPERATING SYSTEMS

assignment 4

This assignment consists of two parts. Part 1 is on Brightspace with 6 multiple-choice/multiple-select questions, worth 10 points (weight: 0.25) in total. Please complete it by 23:59 April 3 , 202 2 (for details see part 1 below).

For Part 2, please submit the answers to the following questions in Brightspace by the due time indicated in the submission entry. There are 10 points in this part and 6 bonus points (weight: 0.25).

Submit your answers as a gzipped tarball "username-comp3000-assign 4 .tar.gz" (where username is your MyCarletonOne username). Do NOT just submit a file of another format (e.g., txt or zip) by renaming it to .tar.gz. Unlike tutorials, assignments are graded for the correctness of the answers.

The tarball you submit must contain the following:

  1. A plaintext file containing your solutions to all questions, including explanations.
  2. A README.txt file listing the contents of your submission as well as any information the TAs should know when grading your assignment. Without this file, grading will be based on the TAs understanding.
  3. For each question, where applicable, a C file for your modified version of the provided source code. This should include all required changes for that question.
  4. Diff files showing the modifications, by comparing each submitted C file above and the original: for example, diff -c ones.c ones_modifiedQ 5 .c > Q 5 .diff. Avoid moving around or changing existing code (unless necessary) which may be distracting.

You only need to submit code for the following questions: Part 3 : Q 5 (ones), and if you want to attempt the bonus question Part 3 : Q 6 (ones)

You can use this command to create the tarball: tar zcvf username-comp3000-assign 4 .tar.gz your_assignment_directory. ****Dont forget to include your plaintext file!!****

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular, do not submit an MS Word, OpenOffice, or PDF file as your answers document!

Empty or corrupted tarballs may be given a grade of zero, so please double check your submission by downloading and extracting it.

Don’t forget to include what outside resources you used to complete each of your answers, including other students, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook or man pages.

Use of any outside resources verbatim as your answer (like copy-paste or quotation) is not allowed, and will be treated as unauthorized collaboration (and reported as plagiarism).

Please do NOT post assignment solutions on MS Teams or Brightspace (or other platforms not used in the course such as Discord) or it will be penalized. Moreover, posting the assignment questions to any external forums/websites is NOT permitted and will also be penalized/reported.

2

Questions part 1 [ 10 ]

Do the Brightspace quiz here (Assignment 4 – part 1) by 23:59 April 3 , 202 2.

Due to Brightspace restrictions, this quiz has a time limit of 24 hours once started. You will have to start
the quiz before the deadline above. There are 6 multiple-choice/multiple-select questions, allowing only
one attempt. You will be able to update your answers during the 24 hours as long as they are not

submitted.

Questions part 2 : Concepts and Code Reading [ 7 ]

No code submission for this part.

  1. [ 2 ] We said the major number of a special file (device node) determines and is mapped to a driver, e.g., ones.ko in Tutorial 7, while the minor number distinguishes an instance, e.g., from multiple ones devices. Now that we explicitly deal with the major number (ones_major on line 69 ), there should be no confusion. But how do we know which device instance we are processing requests for (as there is no ones_minor) from the code? Hint: check the arguments of the file operation functions.
  2. In Tutorial 8s 3000physicalview.c, we simulated the 5-level page table walk (which is also what the kernel does when needed), using pgd_offset(), p4d_offset(), pud_offset(), and pmd_offset(). However, as you may already be wondering, what will happen if the current OS is using 4-level paging? Will p4d_offset() crash the system? [ 2 ] Explain briefly what is actually done for this situation. You can search for any identifier on the website linked in Tutorial 7 (the three URLs).
  3. [2] What is the purpose of the last argument loff_t *offset of the read function (be specific and detailed)? For example, ones_read() in ones.c and newgetpid_read() in newgetpid.c of Tutorial 7. Alternatively, you can also describe the behavior of this argument instead.
  4. [1] What is the purpose of the function ones_devnode() (line 58 of ones.c in Tutorial 7) in this kernel module (do not just paste text from a manual/article).

Questions part 3 [ 3 + 6 BONUS]

The following questions (where applicable) will be based on the original ones in

Tutorial 7 :

Calling an external program explicitly in the code is not allowed.

  1. [ 3 ] Lets change /dev/ones to /dev/myrandom and make it behave like /dev/urandom. You can consider using function get_random_bytes(). If you need more information about it, feel free to search for it on the website linked in Tutorial 7 (the three URLs). Hint: you will need to add to your code: #include <linux/random.h> Note that your new /dev/urandom should not return the same repeated bytes (even with insufficient entropy this should not happen). To test it, you can cat /dev/myrandom | head -c100 > testfile; and then hexdump -C testfile to see if its random bytes (like garbles).
  2. [BONUS 6] A kernel mutex is represented by struct mutex, and can be initialized by mutex_init(the_mutex). Note that the_mutex is a pointer here. You can define it statically not as a pointer and use &the_mutex as the pointer or use kmalloc() before initialization. You can lock
3
and unlock just like what we learned in the class: mutex_lock(the_mutex) and
mutex_unlock(the_mutex).
Now, lets make our own simplified FIFO. Do the following:
  • Make the buffer of /dev/ones one word long (i.e., 16 bytes)
  • You will need to implement ones_write() to take the word and change ones_read() to output the word instead of 1
  • Only reads or writes of one word are supported (otherwise behavior unspecified)
  • Block reads if the buffer is empty
  • Block writes if the buffer is full Hints: You also need to somehow use wait_event(wq, condition) to simulate the condition variable. You will get 6 bonus marks (with the same 0.25 weight like other questions) only when the modified 3000pc-fifo (in Assignment 3 or you can download it here) works as before using your /dev/ones, for example: ./3000pc-fifo 20 0 0 /dev/ones No partial marks for non-working code.