Re: [9fans] port/devcons.c is not port-able

[ron minnich <rminnich@lanl.gov>]

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