[RTEMS-gsoc2011] ISO9660 GSoC project report

[Chris Johns]

On 6/07/11 9:29 PM, Christophe Huriaux wrote:
> Hi,
>
>     I have good news concerning the iso9660 file-system implementation
> project as part of the GSoC. My test workbench is now able to mount an
> iso9660 volume, to navigate throughout the directory structure and to
> perform basic file operations (open/read/close) on the volume. The
> source device for the mount operation can be either a block device (and
> the device access is thus handled by a libblock bdbuf layer) or a
> regular file on another file-system (device I/O is handled with standard
> posix call in this case).
>

Great work and well done.

>    Until the GSoC mid-term deadline (next week), I will concentrate my
> efforts on finishing the file management part (the FS still miss some
> calls like seek() ), cleaning up the code and add the missing doxygen
> documentation.

Nice.

>    My further work will firstly be dedicated to the improvement of the
> cache for this file-system. Since it's a read-only FS I plan to
> implement a FIFO cache based on block access time : when a new block has
> to be put in the cache, the oldest (from an access time point of view)
> is uncached (the smallest entity in the ISO is called a sector and is
> 2,048 bytes long). This method should help often accessed blocks to stay
> in the cache while the less accessed will be discarded. However, I still
> need some comments on this point since I'm not a cache manager guru. :-)

How important is the need for an extra layer of cache over the libblock 
cache ? A CDROM is not a fast device so caching is important.

The libblock cache will cache at the sector size if configured to do so. 
The media block size for ATA(PI?) is 512 bytes how-ever the file system 
layer can specify the file system block size to the libblock cache.

>    Another point of the implementation on which I'd like some comments
> is the filename formatting. Currently the iso9660 implementation handles
> only the real ISO9660 standard-compliant volumes without extension,
> therefore filenames and directory names are limited to a tiny character
> set consisting of only capital letters, digits and underscore. If one
> mounts such an ISO volume under Linux, the names will be displayed and
> handled lowercase, while others OS leave them unchanged. I wonder how
> the RTEMS implementation should handle them : unchanged (uppercase),
> lowercase, case-insensitive, application-defined ?

Can this be a mount option ?

Chris