Filesystem API (at last).
dom at i-cubed.co.uk
Mon Nov 24 20:15:06 UTC 1997
Finally got a few notes down about this.
PapFS - a file system for the Papyrus BSP
This was written as a special purpose filesystem. It was implemented using
two RTEMS tasks, one for the filesystem itself, and one for the IDE driver.
Filesystem calls are actually #defined calls as follows,
#define f_cache_write( force ) fs_sync_mesg( NULL, NULL, force, F_CACHE_WRITE)
where fs_sync_mesg puts the parameters into a message queue to the filesystem,
and then waits for an event back from the filesystem.
There is a special family of functions that operate asynchronously - the fragchain
functions. With these the memory is freed by the IDE task once it has been
written through to disk.
The disk allocation is done with a FAT. The system has been written with
robustness a very high priority: at power-up the system is checked and rebuilt.
Cross-linked files, unused clusters and so on, should be (almost) unknown.
Of course, if a file is being written to disk when the power fails, it
will be lost.
Files are identified uniquely by a Handle, and grouped together
through the use of Types. A certain amount of type-dependent
"info" is also available. (24 bytes, from memory).
The filesystem is flat: there are no directories. Communication with the
IDE driver is also done through a message queue: a message contains
parameters for cylinder, head, sector, number of sectors and buffer pointer.
The driver puts these parameters to the drive and waits for an interrupt.
In order to port some code that uses standard filesystem calls, it became
neccessary to slap some operating system type calls on top. The main limitation
is one of 12 characters for the file name: some attempt is made to strip out a
leading "./" or "/". "Dots" - periods to the USAns - are included in the
filename and are of no significance to the filesystem, e.g. "adosfile.ext"
uses all 12 characters. "tmp/tmp.tmp" uses 11. Given the way these calls
are patched on to the special purpose calls of the API, this is not
going to be the most efficient implementation of a "standard" filesystem.
I do not consider this lot ready for public release. If anyone is interested,
then get in touch and we can discuss porting / release.
PapFS - the API
/* "real" functions */
rtems_task file_task( rtems_task_argument ignored );
extern int papfs_init( unsigned int ramsize );
extern unsigned int papfs_time(void);
extern int conf_file_read(void);
extern int conf_file_write(void);
/* A variable which is non zero after the file system has started up */
extern volatile int papfs_ready;
/* #defined functions */
f_cache_write( force )
f_create( type, prealloc )
f_type_handle( FHandle )
f_open( FHandle )
f_seek( pFile, offset, origin )
f_write( pFile, pBuf, amount )
f_start_fragchain( job, type )
f_write_fragchain( job, pFrag )
f_stop_fragchain( job, pFrag, type)
f_kill_fragchain( job, blocking )
f_read( pFile, pBuf, amount )
f_set_type( pFile, type)
f_set_info( pFile, pInfo)
f_get_info( pFile, pInfo)
/* "extension" functions for special purposes */
fx_seek_sec( pFile, sec_offset )
fx_write_sec( pFile, pBuf, numsecs )
fx_read_sec( pFile, pBuf, numsecs )
fx_alloc_ch( pFile, numchunks )
fx_dealloc_ch( pFile, numchunks )
/* "OS" functions for use with "standard" code */
o_open(buf, flags, mode)
o_read(fd, buf, nbytes)
o_write(fd, buf, nbytes)
o_lseek(fd, offset, whence)
More information about the users