KC5TJA
Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA
PostPosted: Thu Apr 07, 2005 10:07 pm Post subject: Reply with quote
Just to let folks know, I'm continuing development on the implementation of FORMAT within my "ROSE" environment (Research OS Environment). It's currently employing SCons as the build environment, because I don't particularly feel like editing and maintaining Makefiles. It also improves portability, since it largely eliminates the need for me to make special-cases for different people's compiling environments, and produces a much cleaner directory hierarchy. It also integrates my unit test framework quite well, which is nice.
FORMAT currently writes the superblock and a null allocation bitmap to the device you specify for it. I'm currently implementing a simple volume management subsystem so that I can properly create the root directory for it and actually allocate sectors from the disk image. This ought to allow me to complete the FORMAT command. At this rate of pace, I expect the FORMAT utility and the concommitent(sp?) "OS" API it uses to be workably complete in two weeks time.
It's amazing how much effort has gone into FORMAT so far, over this past week. The software is evolving (I use test-driven development techniques) into a clean, exokernel-like environment, where applications link against a librose.so file (or, for those who prefer OS/2 naming conventions, ROSE.DLL), which constitutes "the OS" (as seen by the applications, of course). So far, it includes block device management, and volume management is coming soon. Right now, the needs of the formatter is driving the design. Currently, LEANFS is hardwired into the code. When it is time to support IFS, I will do so at that time. The API is clean enough to isolate this change for the most part.
The OS APIs are designed using an object oriented methodology, largely derived from CORBA specifications. API functions are named using the following convention:
Code: Select all
return = Module_ ... _Interface_MethodNameInCamelCaps(...);
It makes for some pretty verbose code, which some might find offensive. However, it equally makes for trivially easy-to-read and easy-to-maintain code too.
As much as possible, I try to follow the object oriented programming dictum of let the object with the state do the work for you instead of exposing state. Sometimes, this isn't always possible, but nonetheless, this will often explain why the BlockDevice "class" has both an IsLocked() and IsNotLocked() "method".
ROSE supports a concept that I've been working on for some time -- the idea of an OSI-like filesystem "stack." Basically, I've identified seven layers:
- Physical Layer -- the media itself.
- Sector Layer -- This is where most "low-level formatting" takes place, as it deals with reading and writing individual sectors to the media.
- Allocation Layer -- This is where we maintain which clusters are actually allocated or not. Note that a cluster need not be the same size as a sector.
- Fork Layer -- This is where individual streams of data start to materialize. However, forks are addressed only by their starting block number, or some other similarly primitive ID.
- Object Layer -- This is where we aggregate one or more forks into a thing we call "a file." E.g., OS/2 EAs and ACLs can be represented as individual forks, along with the normal file data. But in this layer, we treat all three forks as a unit.
- Naming Layer -- This is where directories and files as the user sees them become apparent. It's also where the volume label and other identifying information is maintained as well.
- Application Layer.
While the ROSE API doesn't directly expose the existance of these layers (just as the BSD sockets interface doesn't expose APIs for each of the TCP/IP layers), the software is nonetheless built with this layering structure in mind. It appears that OS/2 itself was built largely in recognition of this too, as FS_* functions rely on FSH_* functions, etc. Many of the FSH_* functions appear to resemble my current BlockDevice_* and future Volume_* functions.
At any rate, I'm very excited by ROSE, and the progress being made on it. Before I go to work tomorrow, I expect to have a tarball and/or Darcs repository online on my site for ROSE, with my current level of progress.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website
):