spiralofhope

Programming >

I want to talk about the GNU Hurd project. Instead of being like the Linux kernel which uses one gigantic monolithic kernel which does everything, the Hurd kernel is split into many pieces which pass messages. Sound familiar? It’s just like all of Richard Stallman‘s small utilities which can be made to work together to achieve more complex goals by pipelines.

The Hurd kernel project has taken an outrageous amount of time. This is partly due to the incredible adoption of the Linux kernel, which takes mindshare away from non-Linux-kernels like Hurd. It’s also partly due to the complexity of the Hurd’s microkernel design. Stallman has said that it turns out to be extremely difficult to debug code like this.

I always thought that a good solution would have been to build all of the small components as twins. All proper code should have two sides to it. One side is designed with testing/debugging in mind, and the other side is designed for actual use.

I don’t know enough to explain anything other than using my own programming as an example. In the future I’ll probably find my present programming embarrassing, but it’s done using this “twins” concept.

The whole program is “written about” by being broken down into individual problems. Those individual problems become individual little routines which only know how to do that one thing. Those individuals end up being paired with another piece of code which only knows how to test that one thing. This is the twins concept. There are probably a whole lot of different terms for this concept out there, but I can’t think of any at the moment so this will have to do.

So I always imagined that a solution for the Hurd kernel project would be to make each of their little modules as twins. One side is the actual code and the other is a sort of debugging version of that code.

Messages get passed between modules. When a system issue occurs, it’s difficult to know what went wrong where. By using the twins concept, a message gets passed to the debug twin, processed and reported by it and then transferred to its pair. The message packet is processed “for real” and then it gets sent out to its normal destination, only to be received by the appropriate debugging twin.

So when a problem happens, the exact contents, history and path of a message can be known.

I’m totally bullshitting here, but I just wanted to get this idea off of my chest.