bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What would it take....


From: Samuel Thibault
Subject: Re: What would it take....
Date: Tue, 22 Dec 2009 14:51:22 +0100
User-agent: Mutt/1.5.12-2006-07-14

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.

> 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).

> 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.

> 4. What would it take to integrate a sound subsystem architecture on top
> of Mach? (Say OSS

See DDE.

> 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.

> What I am looking for is a) how complex these topics are,

They're all quite complex.

> 2) Blockers (cannot be implemented without new kernel design)

A priori no real blocker.

> 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.

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.

Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]