Re: What would it take....

[Samuel Thibault]

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