I did this for an OS class that I took back in grad school. It's not terribly hard to do. I would suggest developing the filesystem in user space as much as possible using a ramdisk or file as filesystem methodology. Realize that filesystems are a middle layer between the kernel file access primitives (open, read, write, seek, etc.) and the physical hard disk. So your goal is to transfer file requests from the kernel to commands to read or write a particular sector of the hard drive.
You can simulate the hard drive in software by using a ramdisk as follows: malloc a large chunk of memory, and "read" or "write" a block from it by memcpy'ing one "chunk" of it to/from a fixed sized buffer provided by the caller. The size of the buffer should be "block size" of the file system, whichg can be whatever you want. If you actually incorporate your system into the kernel, you'd need to make this code talk to the driver that controls the underlying IDE or SCSI hardware and make it accept input from the VFS layer of the kernel (VFS abstracts out filesystem I/O to a standard set of calls -- makes it modular), but this should not be too difficult to do once you have the actual mechanism working.
Depending on the class requirements, you may be able to keep it on simulated hardware anyhow.
|