Tim Kack, le Tue 22 Dec 2009 15:19:26 +0100, a écrit : > 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 : > > > 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.
I forgot: you'll need to tweak VM_MAX_ADDRESS down to e.g. 0x80000000 to get 2GB support in i386/include/mach/i386/vm_param.h and recompile. You also need a fixed libc (at least Debian's 2.10.1-2) > > > 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. Yes, that's why I suggest starting with a Xen implementation first :) > > > 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, Yes. > but needed for any database I believe. Yes, that's a postgresql blocker. Also a lam-mpi blocker. Record file locking is about the same too. > > > 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 > > Oh, yes - I continuously build all the frameworks from GNUstep and run > the testsuites. So, anything found will be both worked on and reported. Good :) Samuel