Re: [Netconsole-devel] Should netcon be a virtual screen-based protocol?

[H. P. A. <hp...@tr...>]

li...@ho... wrote:
> 
> > Originally I said "of course not", but in the car today I started to
> > wonder about it.  A (text) virtual screen would fit nicely in a single
> > UDP datagram, and would make it very easy to map native console
> > operations -- how weird they may be -- onto the virtual screen.  The
> > downside is that it makes server-side logging and scrollback harder.
> 
> Well, 80x25 characters (never mind attributes) is larger than 1500 bytes.
> Do we want to require support for fragmentation?
> 

Fragmentation is trivial.  Reassembly isn't, but that is the server's
job.

> > Thoughts on this subject?
> 
> It also makes defining "catching everything" for logging a bit difficult.
> 
> It would theoretically permit using BIOS setup utilities across the
> protocol, but is the probability of the support being added non-negligible
> enough to worry about it?  What other benefits are there?

For one thing, it makes the issue of retransmissions trivial... there is
only one buffer and it's the current screen buffer.  Similarly, if a
server is rebooted and has to reattach, the screen is still intact as it
will be included in full by the next transmission from the client.  A lot
of the issues of terminal emulation and the potential need for SIGWINCH,
etc, go away.

> It *would* be kind of nice for a Linux boot loader to convert the text-mode
> BIOS screen to console logs for dumping, similar to the way that the
> various stages manage to coordinate the screen cursor and not overwrite
> each other...

Yes, one could do that that way.


-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt