At 03 Apr 2004 16:44:04 -0800, thomas wrote: > 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.)
Oh, yes. It's already working for some time now. What marco is working on is extra-features and integrate it with X (so you can start X from inside the console client etc). > 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. Yes. This is really desirable to sanitize the sharing of hardware properly. Switching between the console and X in Linux (and in our current console client, when it is implemented) is really a bad hack (and not really robust). What you want is a layer below the console and X that abstracts the human interface hardware and allows to manage/share it. > 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. Yes, yes, and yes! > 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. Yes again! > 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. Yes once more! > (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.) You know, this idea of a HLI is so great that other people already had it (dammit!), however, rather than patenting it (*sigh of relieve*) they actually implemented it (cool!). It's called KGI, and you probably have heard of it (Kernel Graphics Interface). Despite the odd name, and the fact that it was used as lower-layer for GGI, it is actually exactly what you describe, plus a set of low-level drivers for Linux. KGI has exactl the abstraction you want. It has low level drivers, which are organized into human interface links in the "KGI manager". In the Hurd, the KGI manager would not be in the kernel, as in Linux, but in a Hurdish server, of course. You can assign (and reassign at runtime) several input and output devices to the various human interface links managed by the manager. These can then be used by GGI, or something else (special X server, or SDK, whatever). The KGI people have already worked out interfaces that also allow accelerated hardware access to some extent, if I understood it correctly. However, despite the fact they give you some raw hardware access for that, it is a sufficient high level abstraction. (Given the fact that acceleration is plenty important these days for multi media applications, you can't avoid it - but you can at least make the rest of the infrastructure clean). Implementing a KGI manager for the Hurd (well, the low level drivers are something that is also needed, but I like to think of that as a minor implementation detail that is not visible from the outside) is something we have thought now and then for some time. It always came up when discussing the future of the console, and we actually had a chat with KGI developers about it. So, your intuition matches exactly what we already considered to be our long-term plan. With KGI, there is already an external project to draw from. So, it's not even that difficult a path to follow. When it happens, GGI can easily be ported (and GGI comes with an X server for GGI). The console should also be easy to port to KGI then. At that point, things would fall together very nicely. Until then, the short term plan (which is ery cost-effective, because it is proven and really simple to do), is to have a console switching interface like Linux/BSD, and simple pass-through repeater devices for kbd and mouse (which X uses to get at the raw or even translated input data). Marco is already almost finished with an implementation of this. This setup has none of the cool flexibility of the HLI idea, but it models exactly what people know from Linux/BSD, and allows to make the new Hurd console the default in Debian GNU/Hurd, which is a big usability boost. PS: The new Hurd console already (without the HLI stuff) allows for many nice features like internationalization comparable to the Linux console (unicode support etc), but also makes it pretty easy to port brltty (braille terminal) to it, and many other usability features. I believe that with just a little more work (which Marco seems to be willing to put into it), it will actually slightly exceed the usability of the Linux console, and thus equalizes the "first impression" that the user gets when starting the system. Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
