[WikiReader] file system questions

David Reyes Samblas Martinez david at tuxbrain.com
Fri Oct 30 22:40:11 CET 2009


2009/10/30 Doug Jones <dj6mf at frombob.to>:
> David Reyes Samblas Martinez wrote:
>> 2009/10/30 Doug Jones <dj6mf at frombob.to>:
>>> [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?
>>>
>>>
>>> (2) How complicated will it be to implement subdirectory support?
>>>
>>>
>>>
>>> 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.
>>
>> mmm this aproach will not complicate too much if after more apps than
>> a reader are implemented? It would not be better to have a even a one
>> level dir fs? nevertheless you will implement it for the starting
>> menu, why not do it directly in the kernel and allow other apps take
>> advantage of this implementation?
>> Again talking from the most totally inexperience.
>
>
> These are good questions.  But first we need to answer question #1
> above.  If we do indeed limit ourselves to 8.3 file names, that also can
> complicate a lot that we might want to do later, especially if we are
> limited to a flat directory.
>
>
> When we are thinking about future apps to put on this device, we ought
> to be careful to keep in mind its current limitations, and what it would
> take to go beyond them.  It has no actual operating system, as most
> people understand this term.  Each app has to be almost completely
> self-contained.  There are no services to allow apps to talk to each
> other, and indeed only one app can run at a time.  When the WikiReader
> app is running, it is in complete control of the device and nothing else
> can run until you reboot the device.  (The WikiReader app is called
> kernel.elf for a reason.)
>
> Changing this would require putting something resembling a real
> operating system on there.  This is certainly possible, but I suspect it
> is way, way beyond the scope of anything we have been talking about so far!

Yes, I had missed the point of the monolitic app, so then an easy
approach to make different apps (menus,calculator, note taking, basic
drawing, ...) is to enrich  it in the reader app itself this way maybe
some services (read services as already implemented functions in the
code of the reader app) can be used by the little apps, understanding
than this little apps are not independent apps but just another screen
of the same big app.

>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable & embedded solutions
Openmoko, Openpandora,  Arduino
Hey, watch out!!! There's a linux in your pocket!!!



More information about the community mailing list