Create Docker configuration with BarrlefishOS and Sys161

[alexpatel]

Child of #99

• Clone https://github.com/Harvard-PRINCESS/sys161-princess so we can change the source if need be

[alexpatel]

https://github.com/Harvard-PRINCESS/Guppy/tree/ahp-sys161-docker

[ghost]

Don't use sys161-princess, it's been hacked for the phase 1 evaluation. Upstream is at http://os161.eecs.harvard.edu/download/. I don't have a repository posted in public, but I can do that if anyone wants it. (I can also mirror that on github if anyone wants that badly enough to warrant the time it takes to set it up. It doesn't seem worthwhile to me, but YMMV.)

(You can assume that you can use the version from upstream and won't need custom changes. If this project turns out to require custom changes, they reflect bugs that should be fixed upstream.)

[alexpatel]

Don't use sys161-princess, it's been hacked for the phase 1 evaluation. Upstream is at http://os161.eecs.harvard.edu/download/.

Okay, I will switch sources - @penlu said they only added codes outside of sys161 and so the non-perturbed MIPS implementation was unchanged.

I don't have a repository posted in public, but I can do that if anyone wants it. (I can also mirror that on github if anyone wants that badly enough to warrant the time it takes to set it up. It doesn't seem worthwhile to me, but YMMV.)

I think it's useful to have a public Github repository with these tools, as it seems to me the barrier for contributing is not as low as it could be. Github has an importer for mercurial repositories; have you tried it? I can also give it a shot, but if we want them on the PRINCESS organization I don't have create perms.

[ghost]

There was some set of additional arbitrary hacks done to at least some of the trees, which did things like hardcoding paths for the test VM. Anyway, there's a whole bunch of commits that aren't in upstream. (Plus it's also behind current upstream.)

Anyhow, any copy on github would need to be a mirror, not just an import, so it's not that simple. If you want it, i'll do it sometime. If you want it to be a priority, bring it up in the group meeting and convince Margo it should be...

(I've never been clear on why github is supposed to make contributing so much easier; filing a pull request takes a lot more steps than emailing diffs. But I can't deny that nowadays there are lots of people who refuse to even look at anything they can't get from github.)

[alexpatel]

Okay, cool, not important enough for group meeting, I know you've got a lot on your plate and the tarballs and sys161-princess (if it is backwards-compatible) appears fine for the port.

re: github - makes sense, I think part of it is that e-mail list dev can make things feel less active and welcoming to newcomers, e.g. to contribute to OS/161 I have to download the source tarball and know to just e-mail you my patch (non-obvious to many in my gen). Although the world would probably be a tidier place if everyone just e-mailed diffs :/

[ghost]

There's now a sys161 tree here you can use; it's the release, not a mirror of upstream, but upstream changes slowly, so the only drawback is that it doesn't have the history, and that isn't likely to do anyone but me much good anyhow.

One of the things about emailing diffs is that in a past era you just did cvs diff | mail -s "fixes for foo-1.2" upstream@somewhere.edu; but that doesn't in general work any more. The intermediate steps required now are rote to me (having accumulated slowly over time) but probably not to younger folks. Also, the other problem is that nowadays having and publishing an address to send patches to is an invitation to be flooded with spam, so it's increasingly hard to figure out where to send things. And filing patches in e.g. bugzilla instead is a gigantic pain. Github does sort of solve these problems; it's just that it seems like it introduces an awful lot of unnecessary overhead.

[penlu]

(pull req #108 )

thanks!