This is an individual or group project, at your choice. You may collaborate with anybody else and search the web, as long as all the code and results you turn in are authored by you personally (and you mention any web resources that significantly facilitated your work). You may use any libraries that are part of any standard distribution of Minix.
The project is due Monday, December 6th 2004, any time. Submission is by email. Please send me the following:
As always, please send in your project on time -- late submissions will not be accepted, and I prefer to have partially-working projects rather than no project at all.
As usual, you are welcome to study any materials on the web (and you are requested to let me know what you did study).
One of the pleasures of working with non-Unix systems is the ease of access to files on removable media, especially floppy disks. As soon as you insert the medium, the files are available. You can remove the medium any time (as long as it is not actively being written) without any harm being done. On Unix-like systems, you have to mount the device before you can access files (although more modern systems do provide automounting), and unmounting devices ranges from easy (if you remember) to very uncomfortable (if you remove the floppy but forgot to unmount).
There is one relatively easy solution to this, and that is to automatically mount the device when opening a file, and unmount it when the last file is closed (could also mount and unmount whenever a file is read or written, but that would be a little more complex). This change (automatically mounting and unmounting) would only be applied to removable media, which in Minix means the floppy disk. Then, as long as no program keeps a file open on a floppy disk for any extended period of time, it would be possible to remove the floppy as soon as the access light goes out, without in any way disturbing the running system (Minix).
So I want you to implement this -- the ability to remove floppy disks whenever they are not active, and replace them with other floppy disks, and have the system still work flawlessly (you can always mount read/write, no need for read-only mounting). Note that this is much less than a complete specification -- there may be many ways of achieving the same effect, different strategies, different implementations. Some questions you may want to ponder (since they affect your solution):
In other words, I am expecting you to do the usual development work (as you have done for the past projects), but also some substantial design work. To do a good job of this, you might have to employ your own intuition and common sense. You are still welcome to ask me questions for clarification, but sometimes my answer will be that this point is for you to figure out.
I have not yet completed the project, and of course there are a few pitfalls to be avoided. I hope what you have learned from this course (so far) will help you avoid most of the pitfalls, and deal as effectively as possible with those pitfalls which you do encounter.
One thing that I will suggest is that you try to keep this simple. Only go for the most general solution if (a) it seems simpler to you, or (b) you already have the simpler, special-case solution working.
Also, I would suggest you make sure you are thoroughly familiar with the way the file system code works. You probably also want to make a copy of the existing file system code, in case you want to back out your changes or you want to run diff(1) to see what changes you have made or you want to start from scratch (which I decided to do).
One pitfall that I will mention is that you have to think about how you are going to install a new system if you are using the floppy disk to boot from. The boot process (make fdboot) will automatically mount the floppy to /fd0 (or /fd1), so you may have to figure out how to deal with this (it's not that hard -- I did it, but it did take me a little while).
Finally, some food for thought. There is some similarity between this project and locking. Just as a lock must be held whenever a global resource is accessed, the floppy disk must be made available for the whole time that it is accessed. Just as a lock must be released at the end of the access, so must the floppy disk be released at the end of an access. So the number of times the floppy is made available must exactly match the number of times the floppy is released (if there are no open files on the inode). There are also some differences -- there may be multiple open files on a floppy disk, whereas at most one process can hold a lock at a given time.