On Tue, 2009-12-22 at 14:51 +0100, Samuel Thibault wrote: > Tim Kack, le Tue 22 Dec 2009 14:31:46 +0100, a écrit : > > 1. What would it take to bring the device driver layer (which is from > > Linux 2.0 via glue code?) up to either a modern BSD or Linux 2.6 level? > > A lot. See the discussion about the DDE work of Zheng Da for a way to > deport the work to the DDE community.
Thanks for this - I have not looked closely what Zheng Da has done in this area. This is exactly what I was looking for. > > 2. What would it take to enable Hurd to use >1 Gb of memory > > It already does since a recent commit. We're still bound by the 4GiB > limit of 32bit address space (and I just don't want to implement > something like Linux' kmap, going to 64bit would probably reveal to be > just easier to achieve). I will rebuild gnumach from git to test and work with this. 4GiB is of course a limitation - but full 64 bit can a "future" goal. Depending on when nextgen kernel will be alpha/beta etc. > > 3. What would it take to enable SMP and/or NORMA-RPC? > > No real development as GNU Mach is already supposed to be SMP-safe. > Problem is that the drivers are old and don't work with ACPI, and the > SMP-safety hasn't been checked for a while. Thanks also for this - definitely something to look at. Though from following Haiku dev I noticed that ACPI implementations are quite problematic. > > 5. What would it take to implement task #7050? (process-shared > > semaphores and mutexes) > > Good understanding of both the Posix norm and Hurd's RPCs, and careful > implementation. > Not a beginners task this, but needed for any database I believe. Hopefully something I one day can look at. > > My motivation is very simple - I am trying to keep GNUstep compiling on > > GNU/Hurd. I am also interested in one day compile Etoile (GNUstep based > > desktop env) for Hurd. > > Then I'd say start with that, I guess it's probably code that you > already know so it's easier to start from that. Then see if you notice > bugs that don't come from your code (e.g. libc errors) and try to debug > them. It's always easier to start digging into a system from something > that you already know. Oh, yes - I continuously build all the frameworks from GNUstep and run the testsuites. So, anything found will be both worked on and reported. > Another approach would be to debug testsuite failures (like glibc's, > glib's, perl's). Yes, debugging is difficult, but it requires much less > knowledge than implementing/designing things, and on the contrary, gives > a path to discover things. That's how I proceeded: I still don't know > all the details of RPCs and would probably be unable to correctly design > shared semaphore RPCs, but to fix a couple of bugs I was seeing with > sudo, I digged a bit and understood more about RPCs. I guess that is the key - take something small (manageable) and work through it. Thanks for answering my questions. Best regards, Tim
