Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/5] target-ppc: Extend rtas-blob

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On Fri, Aug 29, 2014 at 03:33:59AM +0200, Alexander Graf wrote:
> 
> 
> > Am 29.08.2014 um 03:06 schrieb Benjamin Herrenschmidt <benh@au1.ibm.com>:
> > 
> >> On Fri, 2014-08-29 at 02:40 +0200, Alexander Graf wrote:
> >> 
> >>> On 29.08.14 00:25, Benjamin Herrenschmidt wrote:
> >>>> On Fri, 2014-08-29 at 00:18 +0200, Alexander Graf wrote:
> >>>> I strongly disagree with David. Legally there is no difference between a
> >>>> .bin file that contains code and an array made of instructions. And the
> >>>> more target code we can keep outside of QEMU the better.
> >>> 
> >>> Ugh ... having a separate file with it's own build system etc... for 5
> >>> instructions is borderline ridiculous too :-)
> >> 
> >> Then don't use it - nobody's forcing you to do so :). Just use the
> >> provided binary. I fail to see the difference between
> >> 
> >>  uint32_t rtas_blob[] = { INST_SC1, INST_BLR };
> >> 
> >> and
> >> 
> >>  uint32_t *rtas_blob;
> >>  load_file_from_disk(rtas_blob);
> >> 
> >> except that we're using an actual assembler ;).
> > 
> > So you fail to see the difference with an array of 5 words vs. running
> > through thousands of instructions & syscall to read those same 5 words
> > from disk ? :-)
> 
> I fail to see a problem, yeah :). Imagine the same thing on x86 with
> its completely messed up instruction set. Would you still advocate
> for in-qemu code or would you prefer to have a compiler between you
> and the ugly opcodes?

If it was only 20 bytes worth, and by it's nature unlikely to need
changing, then, yes, I would, even with the extra x86 ugliness.
Assuming it was well commented, obviously.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]