Although I suppose my continuing self-taught computer education attempts would be better spent learning the guts of an operating system like Linux (since the market demand for Linux seems higher than that of IRIX, and if you haven't noticed by now, I need a job), I much prefer learning on IRIX, despite having no access to the kernel sources and not having the wealth of books that one can find for Linux. Personally, I like IRIX better. I find it more robust and easier to work with, and less of a mess than Linux.
I finally reached a point in my tinkering where I decided I needed to branch out into something new, so I decided to try working on an operating system driver. First I attempted to port a driver written by someone else from IRIX 6.3 over to IRIX 6.5, which failed miserably. After feeling defeated for a bit, and reading over a book on operating systems, I decided to try again. This time I set my sights on the elusive IRIX ramdisk driver, since IRIX does not have one, nor does anyone want to create one. Fortunately for me, in the IRIX 6.2 Device Driver Programming Guide, there was an example of an IRIX ramdisk. I used this as a starting point, ported it to IRIX 6.5, and tried it out. It didn't work. But, not wanting to give up after putting so much work into the effort, I tried to fix it up and make it work.
This brings us to the software distributions you see listed here. This driver appears to be a more or less functioning "ramdisk" for IRIX. It does, however, lack certain important features; most notably, you can't make a filesystem on it and then mount it. I know, that seems sort of worthless, but here's the trick. If you take a pre-existing filesystem of the same size and use the dd(1M) command to copy the filesystem into the ramdisk space, you can then mount the filesystem. And there you have it, a working ramdisk. Again, yes, that sucks, but it's do-able.
From what I can tell, the inability to make a filesystem on the ramdisk exists when using mkfs(1M), but does not seem to exist when using mkfp(1M). As such, it looks like it may be possible to use mkfp(1M) to make a DOS or Macintosh formatted ramdisk and use it from there. Yes, this screams "dirty hack." I think I could fix the problem with mkfs(1M) if I could get a hold of its source code... fat chance of that, right? I might just be missing some tiny detail that would solve the problem, and I'll work on it, so hopefully I'll figure it out someday.
I will put each revision of the driver up here as I produce it, and I'll include some notes to indicate what's wrong/right with each version.
Bryan's Crap Ramdisk v0.01a - added Feb. 27, 2000
This is the first public release. Its biggest problem is with how the volume header is handled; since this driver emulates the existence of three partitions (7, 8, and 10), and since partition 8 (the volume header) records the partition information, it is possible to write some weird stuff into partition 8 that will trash things. As such, this version doesn't handle mkfp(1M) or FAT/HFS partitions properly, since they use partition 10 (the whole device). I think I have a fix for that though, which entails moving the volume header structure out of the overwritable partition 8 area and into an inaccessible memory space in the control structure. Which is basically how it was in the original SGI version of the driver, but I wanted to see if I could make dynamically changeable partitions that didn't require doing an ioctl() on the device. I succeeded, but in doing so, I took away some robustness. I'll put that in the next revision.