from the Internet including $($discord or other group messaging apps$)$ or discussing,

sharing ideas, code, configuration, text, or anything else or getting help from

anyone in or outside of the class. Failure to abide by this requirement will result in

penalty as described in our course syllabus.

Your internship is going great. You have gained experience with C programming,

you have experienced your first segmentation faults, and you$$ve come out on top.

You are brimming with confidence and ready to handle your next challenge.

Implementing mdadm$\_$write

Your next job is to implement write functionality for mdadm and then thoroughly

test your implementation. Specifically, you will implement the following function:

int mdadm$\_$write

$($uint$32\_$t start$\_$addr, uint$32\_$t write$\_$len, const uint$8\_$t write$\_$buf$)$

Recall that the command for writing is JBOD$\_$WRITE$\_$BLOCK $($see

ReadMe$\_$Lab$2.$pdf from Lab $2).$

As you can tell, it has an interface that is similar to that of the mdadm$\_$read

function,which you have already implemented. Specifically, it writes

write$\_$len bytes from the user$-$supplied write$\_$buf buffer to your storage

system, starting at address start$\_$addr. You may notice that the write$\_$buf

parameter now has a const specifier. We put the const there to emphasize that it is

an in parameter; that is$,$ mdadm$\_$write should only read from this parameter

and not modify it$.$ It is a good practice to specify const specifier for your in

parameters that are arrays or structs. Similar to mdadm$\_$read, writing to an

out$-$of$-$bound linear address should fail. Write larger than $1024$ bytes should fail; in

other words, write$\_$len can be $1024$ at most. On success return the amount of

bytes written.

There are a few more restrictions that you will find out as you try to pass the tests.

Once you implement the above function, you have the basic functionality of your

storage system in place. We have expanded the tester to include new tests for the

write operations, in addition to existing read operations. You should try to pass

these write tests first.

Implementing mdadm$\_$write permissions

The cryptocurrency startup that you are interning at is also very concerned about

the security of their storage systems. To ensure that data is written by the correct

people and at the correct times, you will also be required to write the following

functions to set the write permissions of the storage system:

int mdadm$\_$write$\_$permission$($void$)$;

int mdadm$\_$revoke$\_$write$\_$permission$($void$)$;

As you can see, there are no parameters for these functions. Each of these will tell

your storage device whether writing is allowed at that point.

mdadm$\_$write$\_$permission will tell the system that writing is now allowed.

mdadm$\_$revoke$\_$write$\_$permission will $$turn off$$ write permissions to the

system; that is$,$ it will tell the system that writing is no longer allowed.

As you might expect, you must turn write permission ON before writing to the

system. You should also always check if this permission is on each time you write

to the system.

Just as all other functions that you have been required to implement, you will need

to use jbod$\_$operation$($op$,*$block$)$ to interact with the storage system.

The following ENUM commands are provided to you:

JBOD$\_$WRITE$\_$PERMISSION: sets the write permission to $1$ so that writing will

be allowed. When the command field of op is set to this, all other fields in op are

ignored by JBOD driver. The block argument is passed as NULL.

JBOD$\_$REVOKE$\_$WRITE$\_$PERMISSION: sets the write permission to $-1$ so that

writing will no longer be allowed. When the command field of op is set to this, all

other fields in op are ignored by JBOD driver. The block argument is passed as

NULL.

$**$HINT: check your write permission in your code before writing.

Testing using trace replay

As we discussed before, your mdadm implementation is a layer right above JBOD,

and the purpose of mdadm is to unify multiple small disks under a unified storage

system with a single address space. An application built on top of mdadm will

issue a mdadm$\_$mount, mdadm$\_$write$\_$permission and then a series of

mdadm$\_$write and mdadm$\_$read commands to implement the required

functionality, and eventually, it will issue mdadm$\_$unmount command. Those

read$/$write commands can be issued at arbitrary addresses with arbitrary payloads

and our small number of tests may have missed corner cases that may arise in

practice.

Therefore, in addition to the unit tests, we have introduced trace files, which

contain the list of commands that a system built on top of your mdadm

implementation can issue. We have also added to the tester a functionality to replay

the trace files. Now the tester has two modes of operation. If you run it without any

arguments, it will run the unit tests:

$ $./$tester

If you run it with $-$w pathname arguments, it expects the pathname to point to a

trace file that contains the list of commands. In your repository, there are three

trace files under the traces dir