GNU/Hurd

GNU/Hurd

[Torbjörn Gannholm]

Have you ever considered the GNU/Hurd for SGI? It has some good points:
1) It is designed to be 100% reentrant from scratch and is also heavily
multithreaded.
2) Basic kernel is minuscule.
3) Added functionality (files, memory, authorization, scheduling, etc)
comes from "servers" which can be replaced at will or even have
different ones running at the same time. The point is you can easily
have a mix of proprietary/freeware/own-design for different
functionalities. Different tasks with conflicting interests could run
against different servers and, above all, totally ignore unused servers.

4) According to the developers it is extremely stable, errors never
resulting in anything worse than an interruptible hang.

A possible minus is the message-passing between the servers which might
be time-consuming.

Still, my feeling is that this could be a real winner on flexibility and
performance. Any comments?

--
/Torbjörn

This message is a personal message from Torbjörn Gannholm
and does not necessarily represent the opinion of my employer.

Re: GNU/Hurd

[Alan Cox]

> A possible minus is the message-passing between the servers which might
> be time-consuming.

"Yesterdays technology, next week" to quote an OSI saying

> Still, my feeling is that this could be a real winner on flexibility and
> performance. Any comments?

If you want a pre-emptible OS core its not HURD. Being pre-emptible without
deadlocks or other interesting suprises is a very very hard problem. Consider
things like disk sorting algorithms when you have 40 blocks for a low pri
process queued up with 2 for a real time one.

Re: GNU/Hurd

[Ron G. Minnich]

Got some numbers to go with that? 
ron

Ron Minnich                |"Using Windows NT, which is known to have some 
rminnich@sarnoff.com       | failure modes, on a warship is similar to hoping 
(609)-734-3120             | that luck will be in our favor"- A. Digiorgio
ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html 

   

Re: GNU/Hurd

[Torbjörn Gannholm]

Ron G. Minnich wrote:

> Got some numbers to go with that?
> ron
>

 Sorry, no. I've only read about what the design ambition is.


--
/Torbjörn

This message is a personal message from Torbjörn Gannholm
and does not necessarily represent the opinion of my employer.

Re: GNU/Hurd

[Torbjörn Gannholm]

Alan Cox wrote:

> > A possible minus is the message-passing between the servers which might
> > be time-consuming.
>
> "Yesterdays technology, next week" to quote an OSI saying

Possibly, but maybe Unix and Linux also are yesterdays technology in some sense,
but cooperative development is the future (and a small bit of the present) and I
think it's sad that science is held back because of money and prestige
(Although, mind you, I don't mind paying for software and giving credit where
it's due, but I want to know what it does and be able to change it if I think I
can do something better).

>
>
> > Still, my feeling is that this could be a real winner on flexibility and
> > performance. Any comments?
>
> If you want a pre-emptible OS core its not HURD. Being pre-emptible without
> deadlocks or other interesting suprises is a very very hard problem. Consider
> things like disk sorting algorithms when you have 40 blocks for a low pri
> process queued up with 2 for a real time one.

 Actually, for the most part I couldn't care less about preemptible or
real-time. I just want to get maximum cream out of my system (scaled to a
zillion cpus), and I want it to run until I kill it. Maybe I'm being boring, but
to watch video I use a TV, to listen to music I use a HiFi, reality is a lot
more interesting than virtual, and to run a nuclear power station I have
dedicated machines. And if I did want to use my computer for any of this I could
probably load the appropriate mechanisms if they existed and everything else is
nicely designed.

IMHO, maybe preemptibility is a fix rather than a solution and the solution lies
in another dimension.

But still, why wouldn't some implementation of HURD (or mach) be able to be
preemptible?

--
/Torbjörn

This message is a personal message from Torbjörn Gannholm
and does not necessarily represent the opinion of my employer.

Re: GNU/Hurd

[Alan Cox]

> But still, why wouldn't some implementation of HURD (or mach) be able to be
> preemptible?

I believe its been done for MACH so that MACH tasks are hard real time. FOr
hard real time on Linux Rtlinux sits under the kernel and runs as a very
compact realtime microkernel