[XenPPC] Re: [Xen-devel] fix vga.c compilation

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Wed, 2006-08-16 at 16:40 +0100, Keir Fraser wrote:
> 
> On 16/8/06 4:35 pm, "Hollis Blanchard" <hollisb@xxxxxxxxxx> wrote:
> 
> > On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote:
> >> @@ -159,12 +160,8 @@
> >>   * into a single 16-bit quantity */
> >>  #define VGA_OUT16VAL(v, r)       (((v) << 8) | (r))
> >>  
> >> -#if defined(__i386__) || defined(__x86_64__)
> >> -# define vgabase 0
> >> -# define VGA_OUTW_WRITE
> >> -# define vga_readb(x) (*(x))
> >> -# define vga_writeb(x,y) (*(y) = (x))
> >> -#endif
> >> +#define vgabase 0         /* use in/out port-access macros  */
> >> +#define VGA_OUTW_WRITE    /* can use outw instead of 2xoutb */
> > 
> > When would you redefine vgabase?
> 
> Right there, with ifdef's, when an arch comes along that requires it.

(By "when" I meant "under what conditions", not "where in the code".)

OK, I was getting confused between readb/writeb and inb/outb. PowerPC
already applies its own offset to inb/outb accesses, but that doesn't
include memory accesses via readb/writeb. So we will need a 'vgabase'.

However, it will need to be a variable, not a #define, since our
physical memory map depends on northbridge configuration. When we do add
support, wouldn't asm/vga.h be a better place to do that than ifdefs in
vga.c?

> >> +const struct font_desc font_vga_8x8, font_vga_8x14, font_vga_8x16;
> > 
> > I think there could be a cleaner separation between console.c and vga.c,
> > and that would avoid needing to redefine these symbols. For example,
> > right now cls(), init_vga(), and others still live in console.c, most of
> > them manually testing vgacon_enabled.
> > 
> > What would be better is a system where console drivers (i.e. serial and
> > vga) register themselves at boot time, so console.c putchar() becomes:
> 
> Well, that'd be more important if it were likely that the powerpc dummy
> versions were going to stick around. Since they're not, I don't think we
> need to over-engineer a solution looking for a problem.

serial.c is already designed this way, and currently we have exactly one
serial backend driver in the tree. I don't think it's over-engineering;
it's a well-understood model and easy to follow in code, even via
cscope.

Also, I should add that VGA is a very low priority for PowerPC. Only one
of our supported platforms has video in the first place, and since it's
a blade, network-accessible serial console is far more useful than video
anyways. So the dummy versions may live longer than you're thinking...

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel