From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 13 Jul 2004 20:47:11 -0600 From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] port/devcons.c is not port-able In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Topicbox-Message-UUID: bfec9a74-eacd-11e9-9e20-41e7f4b1d025 On Tue, 13 Jul 2004, Geoff Collyer wrote: > It's just not the amount of mechanism at issue, but the odds of a > panic message or other serious complaint being seen, for instance. If > you've got console prints going only to a pipe, and the process > reading the pipe blocks, for a while prints will go into pipe > buffering (and not be seen) and then finally kernel processes doing > prints will start to block when the pipe buffering fills. yes but ... it was not just a pipe. The thing I was proposing was to allow multiple console devices while - removing the hardcode junk that is in there now (What happens when you have a machine with NO uart and NO display -- I have some now -- simple -- no console output). port/devcons.c is no longer portable. - avoiding the hellish Linux 'structs with lots of initialized pointers' since in Plan 9 you can just do a namec() and get to the device that way. So using a pipe did not at all rule out using a serial port, AND a window, AND a tcp connection, AND vga if you were that crazy. Anyway, I'll stop talking and at some point try to implement it. > The current devcons is messy but pragmatic. Plugging your serial > consoles into a console server gives you remote access to the consoles > and logging. asuming you have a serial console. I have an HP K8 node with no serial console at all. This is going to be the common case soon -- those serial connectors are huge, require odd voltages, and vendors want them to go away. ron