Redesigned file system handling on the Apple2:
The general idea is to have only as much file i/o code in the resident Contiki kernel as it is absolutely necessary to load apps and provide additional file i/o functionality only to the apps needing them. This approach works out nicely because the largest app (the web browser) doesn't do file i/o at all but delegates this on demand to the wget app.
Unfortunately the paradigm of file system services doesn't help at all to implement the approach outlined above because the (presumably small) inital file system get's at some point replaced by a fullblown one but there's no trigger to revert to the small one i.e. before loading the web browser.
Therefore I opted against file system services altogether, but used two distinct file systems:
One is custom made (only 123 bytes) and linked statically with the Contiki kernel and therefore called "kernel file system (kfs)". It provides just enough functionality to load apps/drivers etc. The module loader code is customized on the Apple2 to make use of the kfs.
The other is linked statically with the apps which require it. Instead of implementing yet another file system the posix file i/o library from the cc65 C library is used here. Because the code resides in a library this has the nice side effect being linked in on demand.
Because the exsisting apps use the "Contiki file system (cfs)" calls typically implemented by file system services a custom cfs.h file is used that maps the cfs calls via macros to the posix calls.
The obvious downside of this approach is that the code is multiplied in memory if several apps using it are running simultaniously - but after all there isn't enough memory to run more than one "big" app anyway.
A less obvious downside is the the more code from the cc65 C library we link to apps the more we run into the issue of not executing cc65 C libray constructors / destructors. Maybe the Contiki app loading infrastructure should be enhanced to do so...
5 files changed