Re: [Qemu-devel] [RFC PATCH 1/2] serial console, output

[Kevin O'Connor]

On Mon, Jul 04, 2016 at 02:46:24PM +0200, Gerd Hoffmann wrote:
> On Mo, 2016-07-04 at 11:11 +0200, Paolo Bonzini wrote:
> > On 04/07/2016 10:16, Gerd Hoffmann wrote:
> > > +static void sercon_set_color(u8 fg, u8 bg, u8 bold)
> > > +{
> > > +    sercon_putchar('\x1b');
> > > +    sercon_putchar('[');
> > > +    sercon_putchar('0');
> > Add a sercon_putstr perhaps?
> 
> We run in real mode, so passing around pointers isn't that easy.
> Given this would make sense for constant strings only (like the 4-byte
> clear-screen sequence) and not so much for variable stuff we might put
> all strings in the global segment.
> 
> Would this ...
> 
> void sercon_putchar(char *ptr)
> {
>     char c = GET_GLOBAL(ptr[0]);
>     [ ... ]
> 
> ... work?

Yes.  See output.c:puts_cs() as an example.  It only works if it's a
constant string (as opposed to a string built on the stack).

> > > Maybe we can reuse the output buffer which we have anyway.  Logic needs
> > > reworked a bit.  We can't just clear characters after printing them out
> > > if we want be able to read them later, so we need a separate
> > > pending-updates bit.  Also should be bigger I guess, maybe 80 chars so
> > > it can cover a complete line.
> > 
> > 80x25 is just 2K...  Perhaps it's simpler to just allocate the whole
> > video buffer from the UMB or EBDA when serial console is in use?
> 
> 4k, we need both character and attribute.  But, yes, if we can allocate
> that somewhere in real mode address space without running into memory
> pressure this might be the best option.

Unfortunately, the screen can be larger than 80x25.

If a large buffer is desired, it's also possible to malloc_high() it
and then use either: call32() to access it, or int1587 to read/write
it (see ramdisk.c:ramdisk_copy() as an example).  Either way it seems
ugly.

At one point I looked through the sgabios code and was able to
understand how it did caching.  I'll take another look and see if I
can describe it.

-Kevin