Ok, so it sounds like a "console" is basically the Hurd replacement for what is called the "console" in Linux: that is, its job is to emulate vdt behavior on a PC display, and do the other sorts of things people expect from the Linux "console". This is good because it takes that functionality out of Mach, where it never belonged in the first place. (This was an action item for a long time, and I'm delighted to see it going.)
That is, a console is a mapping between the Hurd term protocol and actual hardware. There's another beastie I'm thinking about, and I wonder if abstracting it might not also be a good idea. That beastie is a "vdt/keyboard/mouse", and you would run X on it, and to run the above mentioned "console" on it too. Call this thing a "human interface link" (a term I have stolen from HP), or "hil" for short. An hil would map between something-we-don't-have-now and actual hardware. We could then run the normal console on top of an hil instead of on top of the raw hardware. That would be fine performance-wise. X would also sort-of run on top of the hil: but only by using hil features to find out what kind of video card you have and such, and then using some hil call to get at the raw hardware. I think the patches to the X server would be fairly minimal here. We could make X configuration a lot easier it seems to me. Now the normal hil would run on raw hardware. But we could also make a java program that implemented the hil inside a remote web browser. Or inside an X window. The possibilities are endless. The console would then no longer have to do the job it does now: understanding the details of hardware; it could instead just map term to hil and let the hil understand the details of hardware. (Or, alternatively, the functions I've described as "console" and "hil" could be combined into one. But I think that's probably the wrong approach.) Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
