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

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<ref>isn't this a nice idea in general?</ref> 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.

1. 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 file system security model - 14:46, 27 January 2008 (EST)

From what I understand about the OLPC security model, the Inferno activity is going to need to store all mutable data under $SUGAR_ACTIVITY_ROOT Inferno will accomplish this by binding directories under $SUGAR_ACTIVITY_ROOT to the typical writable name space areas in Inferno. There are three subdirs of $SUGAR_ACTIVITY_ROOT:

1. tmp - to store transient data
2. instance - to store per-instance data
3. data - activity r/w data store

As such, most of the Inferno subdirs will go under 'data' and be bound into place. I may go ahead and bind $SUAR_ACTIVITY_ROOT/tmp to /tmp and I'm going to reserve 'instance' for session information if we ever support that.

The important Inferno directories to bind would seem to be:

• /usr - home directories and what not
• /keydb - encryption keys and databases
• /mail - for when we support mail boxes(?)
• /services - for various logs that are stored there
• bind as necessary
  • /locale - for setting locale information this will need to be writable (but this could be bound)
  • /lib - maybe? keyboard & ndb definitely seem like candidates, as do scores, etc. The real problem is this is close to 5MB. I think I'm gonna hold off on this for now and maybe