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 | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
