WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] [Patch] Detect non hypervisor hardware

On Sat, 2006-04-15 at 08:30 -0400, Jimi Xenidis wrote:
> On Apr 14, 2006, at 11:12 AM, Maria Butrico wrote:
> 
> > Hollis Blanchard wrote:
> >> On Tue, 2006-04-11 at 16:53 -0400, Maria Butrico wrote:
> >>
> >> Hi Maria, I don't think it makes sense to add these flags before  
> >> there is code that uses them.
> >>
> > I disagree.  We are trying to stage this code in easy-to-understand  
> > and isolated pieces, this being the first one, that is a way to  
> > detect hardware where hyper/supervisor are not distinguished.

[snip]
> In fact, after we find out it is a pmac we should probably:
> ifdef CONFIG_PMAC
>       of_panic("Sorry, %s is not supported\n", pmac);
> #else
>       of_write("WARNING, %s is experimental\n", pmac);
> #endif
> 
> I'm happy to allow this code to trickle in.

This code is fine with me. The "WARNING" case could also (later) contain
the call to zilog_init() (analogous to ns16550_init()).

> hmm I guess here is where I'd like to see, vars and macros defined as  
> needed:
>       m = boot_machine_type();
>       switch (m) {
>       BOOT_MAPLE:
>               uart_type = UART_NS16550
>               uart_base = UART_NS16550_BASE;
>               HV_supported = 1;
>               break;
> #ifdef CONFIG_PMAC
>       BOOT_PMAC:
>               uart_type = UART_ZILOG;
>               uart_base = UART_ZILOG_BASE;
>               HV_supported = 0;
>               of_printf("WARNING: PMAC platform is Experimental");
>               break;
> #endif
>       default:
>               of_panic("unsupported platform");
>               break;
>       }

Yup, this looks good; it's also totally separate from the question of a
per-domain "user mode" flag. I would be happy to see the above code go
in now, but I still want to see users before adding any flags.

> >> "Problem state" is a term that nobody outside PowerPC will  
> >> understand, so I would prefer a different name.
> >>
> > I leave this one for Mark to argue one way or another.
> 
> hmm, I like the idea of the arch specific code using arch specific  
> terminology.

*I* have to stop and think about it when I see "problem state."

Besides that, the easier it is for x86 (and ia64) people to grok our
code, the more help we will get and the better it will be for us
long-term. Consider how we go looking at foreign architecture code as a
reference: if it's written IA64-style it's incomprehensible and we give
up and go away.

-- 
Hollis Blanchard
IBM Linux Technology Center


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