After a slow start due to schedule conflicts with school, the ISO9660 filesystem is almost fully implemented in RTEMS. My implementation choice was to write this filesystem from scratch, rather than porting it from an other OS.
For recall ISO9660 is a read-only filesystem used in optical devices like CD-ROM and is also used as the file format of “ISO images”. Both use-cases are implemented, one can either mount a device or an ISO file located on an other volume.
At what level is ISO9660 implemented? First of all the whole original standard describing the legacy filesystem ISO9660 (also available as ECMA-119) is working, as well as the later ISO9660:1999 revision, which means that every single ISO file should be readable in RTEMS (or at least in a degraded fashion). The major disadvantages of this filesystem are the various limitation on filenames : only uppercase characters, digits and hyphens. A mount options can tweak the way the filesystem expose the filenames : either untouched (uppercase) or lower-cased (for compatibility purpose with the default Linux implementation).
I’ve also managed to implement Joliet and Rock Ridge extensions. The first one is widely used on Windows platform to let an ISO9660 volume use a wider character set thanks to the use of UCS-2 encoded filenames. If the ISO9660 stack is compiled with iconv support (which is highly experimental ATM, I thank Ralf Corsepius for providing the iconv enabled toolchain !) it can do the character-set conversion at run-time, from Joliet’s UCS-2 to a user-defined character-set (iso-8859-15 by default).
Rock Ridge gives the most benefit to RTEMS since it brings a lot of POSIX things to the ISO9660 volume : detailed timestamps, owner’s UID and GID, POSIX file modes and others node type (device, symbolic link). Some other features are currently not implemented : deeper directory structure (ISO9660 allows only a depth of 8 directories) and sparse files support.
The filesystem implementation has been tested under the i386 platform, I’m currently fixing endianness and structure alignment issues to let the stack run well under the SPARC SIS simulator. ISO9660 records most of the multi-byte data in bi-endian format (little and big endian), it’s thus beneficial to take part of the volume ability. After consulting Chris Johns, my GSoC mentor, I will file a PR and the associated patches as soon as these issues are fixed in order to merge andhave public reviews of the ISO9660 stack. Chris also pointed me to others fields of RTEMS on which I could contribute after that.