At 21 Apr 2004 22:36:57 -0700, thomas wrote: > Ok, this is the right thing to do. It comes in two flavors, with a > magical component. > > The ideal flavor is this: > > * The bootstrap filesystem initially writes on the console through > magic. Perhaps it passes the magic to init and exec.
I still have no clear picture of what the system console is in your opinion. In your first mail, you say that init must start the console, because it may be "fancy" and require proc and auth. But in my opinion, it is a fundamental flaw to rely on a fancy console as the system console. The system console in my eyes is for example a dedicated serial line, or a dumb terminal a la Mach's console, with the one improvement that it doesn't interfere with other video card using programs later on. So, I think that the right thing is to use a dumb console as a system console, which is magic in the way that it can change its behaviour (ie, stop using the video card at some point, etc). I realize that this picture is slightly different from what you have in mind. But keeping the system console separate from the user's fancy consoles (which may very well be just XFree86, ie not a text console at all), seems to make sense to me. Now, this brings into question what this magic console should be and how it should behave. If it is a serial dedicated line, it will not interfere with video card users, and this setup is indeed an easy one. It gets harder if you want to share the system console resources with other users, and this is currently on of the reason why you can not use my console program on GNU Mach CVS Head (oskit-based). However, as you deliberately excluded this question (how the magic console should behave) from discussion, I don't need to answer it here :) In fact, I am still not yet done with my doubts about what the system console really should be. If it is shared by init etc and the root filesystem for diagnostic output, then it is a mixed logging and login console. This is desired because you want to see the error messages of course, while still being able to log into single user mode and so on. It causes a problem however if the filesystem goes mad and goes into an endless loop printing error messages. This actually happened to me several time (usually when it gets pager faults or runs out of disk space). In any case, how should the bootstrap look like? What I don't understand is why the root filesystem etc need a port to the term server rather than the underlying device used by term. You can argue both ways, that the diagnostic messages should follow the system consoles term session if it is redirected to another output device, or that they should stay where they are (or being redirected in a lower level at the device manager). In other words, I am not sure if the current way of doing it is really actually wrong. I can see reasons for and against it. Of course, I already make the assumption that we never want to use a fancy console as system console, so maybe it is easier for me to go further like this. In more sophisticated setups, the system console will usually go to a manager OS session, or to a serial line. I think that these are the types of setups we should keep in mind as the ideal model. Using the PC hardware kbd+video card as system console will be by far the most often used setup, so it must work. But I don't think it should guide the design, as it is fundamentally flawed. Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
