[WikiReader] file system questions
dj6mf at frombob.to
Mon Nov 2 08:14:13 CET 2009
Christopher Hall wrote:
> On Fri, 30 Oct 2009 12:46:57 -0700
> Doug Jones <dj6mf at frombob.to> wrote:
>>> 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
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
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
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
> Openmoko community mailing list
> community at lists.openmoko.org
More information about the community