Re: Looking for a project
Ali,
> > Do you guys have any suggestions? anything that would be really useful
> > that you don't have yet? (apart from ppp ;-). pthreads?
> The most useful contribution is the one that is really done. In other words,
> don't bite off more than you can chew ;) and we don't know where your
> strengths are so making a recommendation is hard.
I completely agree on this! It's all a matter of personal interests, choices
and abilities. You'll certainly want to grab a project that is managable
in a relatively short time. Suggestions such as a port to L4 would mostly
require a lot of time (not so much of coding, but of understanding the
involved issues) and this is not for the faint of heart. OTOH, adding some
binary compat. mode may be managable by one person in a relatively short
period of time, without being trivial.
> This said, I think Mark is currently not continuing his pthread work, and
> pthreads would be very useful. I don't know if he made his latest snapshot
> available, something is at alpha.gnu.org/gnu/hurd/contrib/kettenis/pthreads.
Concerning pthreads and a (currently hypothetic) port of the Hurd to other
ukernels like L4, it is necessary to cleanly isolate the user-level (a.k.a.
library generated) threads from the ukernel-level (mach, l4, whatever...)
threads in the pthreads package. Programming Pthreads and threads in general
is relatively hard to debug and can be really hairy under special conditions.
You'll most certainly need previous exposure to threads programming from a user
of the threads library perspective before thinking of hacking up a [p]threads
library.
> However, there are other projects. So many in fact, I can't count them here.
> I don't even know which one would fit for a Honours project.
> Some nifty translator, SMP support, features needed for distributed systems,
> I don't know. Maybe those are a bit too hard. You tell us ;)
Awwww Marcus, SMP support as a Honours project? I'm not sure. It can be too
easy if you rely on Mach doing all that SMP nasty business (scheduling threads
to processor sets was already in CMU Mach for a _long_ time), so that the
Hurd won't see anything of what's going on behind the scenes. OTOH, it may
be hard to realize, if you plan to extend the Hurd's interfaces (exporting
the SMP abstraction outside of the ukernel) accordingly.
Translators are always welcome and we should all submit some suggestions
on this list, right?
Features for distributed systems will certainly require some kind of
reimplementation of the NORMA/XMM features of Mach so that distributed
shared memory and distributed IPC between nodes becomes possible. The
problem here is Mach again, which is not efficient enough for this (I tried
this myself and was really disappointed by the benchmarks). L4 seems again
to be better alternative for distributed systems, but here again, we need
a port of the Hurd to L4 and we need people to think about it and work on it.
> Also, improving oskit is worth a lot (I say character devices). Or ...
OSKit is great! A good idea may be to use library code of OSKit to hack up
a pfinet-like server which includes the *BSD TCP/IP networking code instead
of Linux's TCP/IP stack (for efficiency reasons and because *BSD supports
ATM NICs etc... whose device drivers can be added to the OSKit). A useful
application may also be a router server (borrow from gated), that can
handle multiple interfaces. Add Cisco-like IOS command syntax and you'll
have a cheap router replacement on a Hurd box ;-)
Moving most of the (Linux- and other) device drivers to user-space would
be very Hurd-like. Using a ukernel and bloating it up with tons of foreign
driver code is paradox and not a good idea. Moving the device drivers into
user-level means writing servers that handle interrupts and (memory-mapped)
IO from/to drivers, using the generic interface of the used ukernel (Mach
now, L4 later). Those servers could include the OSKit libraries for actual
(Flux' maintained) driver code. Efficiency issues _will_ arise here, but
this is a Mach (not L4) problem in general.
Adding some kind of jail(8) syscall may also be a good idea.
Thanks,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
Reply to: