sorted by: recent | see : popular

Content Tagged with v9fs + inferno

This week's update to inferno-olpc includes OLPC-optimized fonts and a customized logon with two extensions:

• it binds the Inferno activity "writable" area to important areas of the Inferno name space which the user may want to write to (/usr, /services, /keydb, /tmp). This will be necessary for the next OLPC update which will start enforcing security (including only allowing writing to the activity writable area of the file system. Also bundled is a day-one scenario which will setup template directories to bind from and copying relevant files.
• when logon can't find a user it will now prompt to create the user by copying the template /usr/inferno directory to /usr/username. This can probably be generalized back into the standard Inferno base.

I also have a "customized" toolbar which just limits the size of labels to 15 characters so you don't get the awful line wrap. This is a stopgap, a better toolbar metaphor needs to be developed for the OLPC version of Inferno. I also augmented wmsetup with a larger set of applications.

I had a larger agenda that included social-network style "profiles" and integrated security/password setup. But there were too many corner cases to test and "bullet-proof" so I decided to hold that off for later and maybe just incorporate those functions into separate applications.

I'm still a little uncertain of how I want to handle authentication and security. On one side, there could be a central "schoolserver" to setup authentication against. However, as most of the current users don't have such a server, having a pure peer-to-peer mode is probably preferable. Given that every laptop will be an auth-server then, do we setup a laptop wide authentication setup, or do we do a per user authentication setup. The later would seem to make more sense to me as the user-provided password wouldn't have to be stored anywhere and could be use to setup keyfs and the user's own authentication secrets. Other users "registering" with that user for the purpose of collaboration could then provide their own secrets in his keydb, etc. I'm not sure if that makes sense or if there is a better model I should be considering.

The file system security is another pain. Inferno users won't necessarily equal underlying system users (a common problem). This will be made worse with the new OLPC security enforcement which may have different uid's for each "instance" of Inferno (but the same "gid"). I think the right thing to do is a new version of devfs which always keeps group permissions open in the underlying fs and uses extended attributes or some other mechanism to maintain Inferno uid's and gid's for the files.

Since I wrote about it in my other post, I might as well explain metafs. Basically in order to accommodate the OLPC file system security model I need to maintain uid, gid, and mode bits for Inferno's view of the underlying file system separately. This is actually a common need within hosted Inferno when you don't necessarily want to keep Inferno user's sync'd with system users. In any case, this amounts to an overlay file system, which stores away the additional metadata.

While I am tempted to keep a central database of the metadata, the most pragmatic solution would seem to either use extended attributes or a hidden file in each directory. Since extended attributes are somewhat distasteful and not available anywhere, I'm going to start with the per-directory hidden file.

In the future this same mechanism might be extendable to implement semantic file system extensions (or extended attributes for that matter) -- allowing for tagged organization and searching of the file system as well as alternative views such as a "journal" style temporal view (which might also be useful for backup purposes). However, these extended metadata scenarios may beg a re-evaluation of the distributed versus centralized storage model.

In any case, the basic plan is squirel away the extra meta data, indexed by the string filename/directory-name in a hidden file. If the directory isn't writable by eve then no extended metadata will be written and the directory will default to the underlying uname/gname/mode -- however, if eve isn't able to access the files, the overlay won't be able to access the data -- so it's likely a moot point.

I've reset up my Inferno git repository on http://git.9grid.us/git based on a mirror of Forsyth's SVN repository. Included now is my working OLPC modifications repository which contains both my core-Inferno patches as well as new mk rules for packaging. I'm going to move on to better OLPC applications support now, but there probably won't be an update on that until after next weekend.

Got my daughter an OLPC for Christmas, but have spent a lot of time playing with it myself. First order of biz was to load Inferno on it ;) I can run it from the shell quite happily, but am now trying to come up with a Sugar launcher and package for wider deployment. I may start with a simple sugar app that toggles between loading Inferno versus loading sugar. This should be much easier as it'll avoid interacting with the Python gorp. Another alternative would be to just hack the terminal application (which would then act as emu's console), but I'd like to try to find a way to tie it in better.

(UPDATE: launcher is working, now working on packaging)

I've added the Xen shared memory channel bits to devshm and pushed the code to the inferno-power repository (although hypothetically this is a more generic feature). I really need to separate the devshm code from the power code, it just seemed more convenient to work on them in the same branch.

The Xen shared memory code only functions as a server right now. I just tested it with a slightly modified Libra client and everything seems cool. I need to revisit performance results to make sure I didn't screw anything up and work out the right way to modify the Libra launch scripts.

Nearly complete with a second take on my Linux-Power Inferno port. I've corrected (with Forsyth's help) many of the hacks I had rushed through the first time. I'm still a bit concerned with floating point and math libraries, but on the whole it seems functional and no longer uses pthreads so hopefully the SMP problems we were seeing will go away.

I'm trying for a clean merge against the Google Code inferno-os tip now, which should leave me plenty of time tomorrow to do a clean integration of the shared memory transport with shm, mmap, and xen back-ends.

I've been playing with the idea of some simple shell scripts that would provide git-like-service on-top of venti for use as wide-area source control. Essentially, to access a repository, you'd need access to the venti hosting the repository and the current score of the repo which could be published in a 9p partition or web page or whatever. Alternatively you could have the branches of the repo published (or pull the branches from the single score).

The scm-part of the repo would contain the branches, tags, and log messages. Branches and tags are just files with the particular score in them (not sure that there really is a difference between the two) -- might also squirell a description or something in the file.

Log messages would be in files named after the score of the tree that their commit represents. The log message would contain a parsable pointer to the parent score of the commit. Probably reasonable to organize the log messages in directories by date or something to keep things efficient. The logs themselves are probably best stored in venti, referenced by a "special" branch named log.

Then it's just a matter of writing some scripts to handle initializing a scm database, adding and removing files, commiting changes, and helper routines for doing diffs, merges, branching, etc. Also could have git-pull/git-push equivilent commands for syncing remote and local venti stores (if you wanted to have a local venti).