Re: What would it take....

[Tim Kack]

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