[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What would it take....
Re: What would it take....
Tue, 22 Dec 2009 15:19:26 +0100
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
> > 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
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
Thanks for answering my questions.