Hi, On Thu, Sep 06, 2007 at 09:12:02PM +0200, Alfred M. Szmidt wrote:
> We *know* that there are some fundamental issues with the current > implementation. We *know* for example that performance will never > quite match modern monolithic systems; that there are problems that > can not be fully solved within the current design. > > This depends on what issues you are refering to. The two > (semi-serious) problems that Marcus pointed out wrt to passive > translators and firmlinks can be solved. As was pointed out by > Bushenell, and someone else. I was referring to more general issues. There is no accounting of resources used by applications, and Mach lacks the facilities to implement that. IPC is slow, and can't be fixed without simplifying the semantics. Passive translators are way too limited. (The specific issues pointed out with passive translators can all be solved by specific corrections or workarounds I believe; but in the long run we need a more powerful mechanism IMHO.) Some of the Hurd server interfaces are too complicated, and unnecessarily store per-client state in the server, making interposition very hard. Userspace drivers are not possible for most hardware because of missing kernel facilities. The thread model of Hurd servers (one thread per request) is fundamentally wrong, making for poor performance and resource utilisation. (And making resource accounting much harder...) Some functionality is unnecessarily implemented in complicated and inefficient servers that handle multiple connections, although no coordination is necessary between the individual connections. All of these issues are real, and we will have to address them sooner or later. Only I don't think any of them is very urgent -- none of them prevents the existing Hurd from being a useful system, once the more pressing implementation issues are fixed. -antrik-
