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.
>> +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.
-- Keir
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home