Cosmoe Status - Mar/Apr 2004
Mar 31, 2004 07:45 PST
On Mar 31, 2004, at 9:17 AM, Pahtz wrote:
| ||The current CVS version is in limbo as OBOS compatibility and graphics |
driver architecture changes
aren't finished. So the functionality may be less than the earlier
Yes, all that is true. I apologize that I haven't kept everyone more
up to date on the progress of Cosmoe. Quite a lot of work has gone
into it in the past months. I've almost finished the rewrite
(basically turning Cosmoe into a OBOS port to Linux). It has been
incrementally headed in this direction for quite some time, so this is
not a sudden change of direction or anything. Ironically, once the
small problems listed below get fixed, we'll have more up-and-running
functionality than OBOS itself.
Since so many have asked me about the progress, here's the URL where
you can see the code:
You may wish to use curl or wget since the afn.org site doesn't have
the mime set correctly for bz2 archives and may spew it out raw into a
MANY MANY things have changed since 0.7, including fundamental stuff
that older Cosmoe hackers may have taken for granted. I urge you to
read the README very carefully. Sometimes, the *opposite* course of
action is required. For example, in 0.7, only the framebuffer driver
worked reliably. In 0.8, everything but the framebuffer driver works.
The default driver is XWindows, and Cosmoe should be started from an X
session when using this driver.
Some other notable differences:
Cosmoe gets installed in the standard places now, i.e. /usr/local/bin
Cosmoe can now be compiled with distcc (run distconfigure.sh to set it
Cosmoe sources now much more closely match the OBOS directory structure
You can now do a "make uninstall"
All this is getting the horse before the cart so some degree, since
problems with the kernel kit prevent this version of Cosmoe from doing,
well, much of anything at all. The kernel kit, like almost everything
else, is adapted from OBOS, except that it's been modified for userland
operation. There appears to be a problem in either the port or
semaphore classes that causes a deadlock pretty early on when launching
the appserver. On top of that, the current kernel kit uses shared
memory segments to emulate kernel-like global references to objects.
These are not destroyed properly when an app is terminated unexpectedly
(like killing the deadlocked appserver with ctrl-c). Until this is
rectified, testing is a massive pain in the butt since you get one shot
at running the appserver before you need to restart to clear the now
bogus shared memory areas. This will be fixed easily once I get some
signal handlers in there do it, but they are not there yet.
If you're willing to put up with this state of affairs, I'd love some
help. You can test the kernel kit with the
src/apps/testharness/testoskit application. You just run this directly
with no appserver. If you want to put the signal handlers in to make
things easier, go ahead. My wife and I just had a baby so I'm a bit
busy this week and won't be working on it in the next few days.
I've been eagerly awaiting the release of B.E.OS code under the LGPL,
so I can compare my implementation of the kernel kit to theirs, but
they've been having some serious problems getting the hosting worked
out. I offered to help with the distribution, but I received no
response. I even wrote to him in French, but he probably couldn't make
heads nor tails out of my out-of-practice French grammar and spelling.
:-) Il est rare que j'ai l'occasion de parler ou d'ecrire en francais,
donc ma grammaire devient de plus en plus mauvaise.
Lastly, if you decide to hack on this version, you'll probably also
want to get rid of any traces of 0.7 to avoid conflicts, especially old
libcosmoe.so and appserver binaries.