[WikiReader] file system questions

[Doug Jones]

Christopher Hall wrote:
> On Fri, 30 Oct 2009 12:46:57 -0700
> Doug Jones <dj6mf at frombob.to> wrote:
> 
>> [snip]
>>> I like this approach, just remind that as far I see the code and by
>>> comments of the devs, the kernel implements the bare just enough to
>>> read files, so I think directories are not implemented at all that's
>>> why all is on root directory so at least basic hierarchical
>>> filesystem has to be implemented before we can do this solution.
>>> But directories will easy the organization of pictures too
>>
>> Good point.
>>
>> So two important questions to be answered, before we get any further 
>> into this:
>>
>> (1) Has OpenMoko made the policy decision that filenames will be
>> limited to 8.3?
> 
> I would prefer to keep it simple, the boot loader must run in under 7kB
> of internal RAM (actually it uses overlays) so adding more code
> here is not so easy.  
>>
>> (2) How complicated will it be to implement subdirectory support?
> The version of the file system supports directory access, but there
> is no support for "chdir"
> 
> we are using this:   http://elm-chan.org/fsw/ff/00index_e.html
> presently at version: R0.06
> 
> so all pathnames have to be absolute, I tried a couple of quick
> tests and I could create and read a file in the folder, but I am missing
> "mkdir" in forth, (just need to add the interface routine)
> 
> It looks like there is a new version with "chdir" support, but
> I have not investigated this yet
> 
> Hope this answers your questions 
> 


Yes, thanks for that.  Helps a lot.


This is what I've got in mind:


No changes to boot loader.  The only things to be changed are on the SD 
card.

Suppose the user wants two different wikis on the device.  To keep 
things simple, each wiki is independent and resides in its own 
directory.  Once a particular wiki is running, there is no way to access 
the other one without rebooting.  For backwards compatibility, we let 
the default wiki reside at root, just as in the current implementation.

A directory may contain a Wikipedia in a different language, or perhaps 
some entirely different wiki using the same WikiReader app, or perhaps 
some other app that is yet to be written.  (For convenience, we call 
each one an app here, even if the subdirectory actually contains 
multiple applications).


The boot loader runs /kernel.elf as before, but instead of the 
WikiReader app, it's just a menu system (the WikiReader app has been 
renamed something like wrkernel.elf).  It scans the subdirectories (only 
one level down) on the SD card, looking for a particular filename, say 
menu.png, which contains an image of the menu entry for that particular 
app.  By using pictures for the entries, we don't need any 
(multi-language!) font support in the menu app, kernel.elf.

If it finds no /*/menu.png then it loads /wrkernel.elf and the device 
works just as it does now, with everything at / on the card.  The user 
does not see anything different from what they see now.

If it does find some /*/menu.png, it displays a menu containing all of 
the bitmaps found (including the default one at /menu.png).  If the user 
selects one other than the default, say for example the one at 
/pt/menu.png, kernel.elf passes control to /pt/wrkernel.elf and the 
Português version of Wikipedia runs.  From that point on, the app 
doesn't need to know anything about what's at / or any other 
subdirectory.  All of the .bmf font files and Forth files and whatnot 
are in that subdirectory.

So kernel.elf needs to be able to do dir /*/menu.png, wrkernel.elf needs 
to be able to do chdir (once), and nobody needs to do mkdir.  All other 
filesystem operations happen within a single directory.


This initial menu system also is displayed if the user holds down a 
button while booting, so /pt/forth.elf or /pt/calc.elf or whatever will 
be run as appropriate.


With this scheme, the 8.3 filename limit is no problem.  And different 
language versions of Wikipedia can reside in directories named after the 
language designations used by Wikipedia.

If a user wants to add a wiki of their own, they just use the existing 
tools to build the pedia* files from an xml dump.  They put these into a 
folder along with the other files copied from / on a standard WikiReader 
SD card, add a menu.png file for the menu entry (we can give them a tool 
to generate one in their language), and then they copy the folder onto 
the SD card and put it into the device and off they go.

If somebody writes an entirely different app, all they have to do is 
name it wrkernel.elf, supply a menu.png, put it all in a folder and do 
as above.


And nobody has to flash the ROM.



>>
>> Note that only one subdirectory level is really needed to implement
>> what has already been suggested.
>>
>> The current implementation contains 81 files, totaling 4.2GB for the 
>> English version.  Nearly all of that is in the big wiki data files 
>> (pedia*).  The other files, the ones you get when you make install, 
>> comprise 49 files and only 18MB, and most of that is fonts (which are 
>> often different for different languages).
>>
>> We could adopt a brain-swap approach:  After bootup, the user selects 
>> one wiki and then the app switches to the selected subdirectory and 
>> considers that to be the root until the next cold boot.  All 81 files 
>> for that particular wiki and language would be in that subdirectory, 
>> including the big wiki data files and the fonts and the remaining
>> files (45 files, only 381KB, and this includes ALL of the
>> executables!)  While the single app is running, it would not have to
>> access (or even know about) anything outside its current directory,
>> so no filesystem calls relating to directory navigation would be
>> needed within that particular kernel.elf.  Only the initial wiki
>> selection app (we would have to write one) would have to understand
>> subdirectories, and only to one level deep.
>>
>>
>> _______________________________________________
>> Openmoko community mailing list
>> community at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>