At 22 Apr 2004 10:06:05 -0700, thomas wrote: > A magic console is a necessary thing to tolerate. It's a way for > programs to write on "the console" when they are the only beast in the > world. Right now they use the Mach "console" device. That's a bug. > That device will vanish like the wind when we strip away the Mach > terminal code once and for all.
It's only a bug if you think of the Mach console as anything else but the magic console itself. In other words, if you remove the Mach console, then you have to put something in there to take its place. You can call it something different, like a "boot logging device", but it needs to be something, and of course it doesn't even need to be in Mach, although whatever it is must be integrated with other device drivers to sort out the problems of concurrent access (directly or indirectly). So, let's try to formulate the questions you want to discuss, rather those you don't want to discuss right now: Let's call the entity that root servers are using for diagnostic output at boot and crash time a "logging port". Then in my understanding this logging port should be created very early and propagated to other initial servers. In my opinion, this can very well be in the form of a file descriptor for "stdout", although I don't really care. We could just as well make it more abstract, forbid such servers from using stdin/stdout/stderr at all and use a more abstract logging interface, something that is on the todo list anyway. printf is just one such logging interface, it's easy enough to replace it with something else. Now, in your second mail you wrote that init opens the "real" console and gives back a port to it to the initial servers. This would mean that those servers replace their logging port with something else, or that they cease to use the logging port and start to use a proper console as stdout. That this is the right thing to do is not at all obvious to me. It raises questions about what this "real" console is, and if it has all the right properties. What I think would be the right thing is to leave the logging port in place, and use it for the whole life time of the servers. Then the logging port, or rather whatever implements its service, can do the right thing from outputting on the screen to forwarding it to syslog if polled for it. init should be concerned about opening a real console, but that console would only be used for console purposes of init and its children. In other words, I'd vote for a dedicated logging service, that is started by or even before the root filesystem and other initial servers. The real work is then in the implementation of this logging service. This would mean however that by default you wouldn't see messages on the screen after init started and took over the hardware (assuming that we use a shared single screen here, rather than a dedicated logging hardware or serial line). This is solvable, but not easily. For example, if the machine then goes into a warmstart after a failure, the log buffer could still be found in memory and read out for diagnostic purposes, or a trace of the log buffer could be kept on disk in a few dedicated blocks. All of these are questions you want to exclude, but which are crucial if you want to ensure that no messages are lost while not having a dedicated logging hardware - which is the only hard part about the whole design. > Right now, we are doing a horrible thing. We open the Mach device > named "console" (a feature we are planning to remove from Mach > anyway); we are casual and careless about where that port is passed > around, including storing it in wildly inappropriate places, like file > descriptor tables; init never bothers to open /dev/console for the > users the way BSD does (and it's a mistake that Linux does not); we > don't capture anything written on it for logging; etc. It's clear that the current situation is not correct in many ways. What is not clear is what should replace it. I don't know what init in BSD does in terms of open /dev/console, can you elaborate on that? Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
