Inferno Implementation Notes

Issues

• pragmatic issues

1. fonts need to be bigger, so does toolbar icon
2. need "better" basic apps set in launch menu
3. would be nice to have "full screen" shortcut box on many apps (or default to full screen)
4. fix font selection in apps to use fonts which have been included
5. need to mount home directory from user writable space
6. "first day" script(?) for things like key generation and baseline configuration

• conformance issues

1. rotate works, but not gracefully
2. need full unicode font set to be fully internationalizable (talk to forsyth about licensing issues)

• emulation issues

1. qemu doesn't seem to use the same screen size so menu bar is cut off under qemu

Notes on conforming to the Low-level Activity API

The big barriers seem to be:

a) dbus - ugh, necessary to interact with core services (resource (camera/audio) control, sharing (not sure how this will fit in with Inferno yet), and most likely job control/monitoring features. Either need to handle this via an external proxy (maybe some kind of dbusfs) or link emu against the necessary bits. Actually, maybe the right approach would be to use py9p to write a 9p gateway to the relevant dbus services. Not sure if there are restrictions against local socket connections, but if necessary I could always do it via stdin/stdout. On the other hand, that could turn out to be prohibative performance wise if I was using that path to do "tubes" or video. Perhaps the right thing is an olpc device driver which does the dbus stuff under the cover in a similar manner to GCompris.

b) Datastore - while unlocked currently, the eventual model for the OLPC is to be locked down in such a way that any state gets stored in their temporal journal. I believe it is a file system, but the apps aren't meant to use it that way. This probably means we'll need to have our own "image" for the user's home directory which we can then mount and bind into place. We'll also have to support consistent snapshots of this sucker. If you do the "full-implementation" of journal, session state (windows which are open, etc.) needs to be stored as well. But it seems to heavy weight to do with all of Inferno. This might be gotten around with the data directory, but right now it won't survive upgrades.

c) user/group - the user name the activity is run as depends on the instance that is run (groan), but the group should be the same for all instances of the activity. Might have to get creative with devfs here.

d) network access - you should be able to set bits to allow open network access, but it might also be nice to support their stream tubes so we link in with the sharing methodology.

So there is a bunch of things that have to be adapted. The only really onerous thing is Dbus interfacing. I've never dealt with DBUS, so I'm not sure how I'd want to interact with it from emu. I suppose we could link against dbus libraries, but maybe it would be better to use devcmd to start some sort of dbus proxy which we can then expose in the file system. Quickly looking at my options I'm leaning towards relying on an external proxy -- there doesn't seem to be a simple C library to link against to provide Dbus hooks.