On 8 May 2014 17:09, Paolo Bonzini <pbonz...@redhat.com> wrote: > The ld_raw and st_raw definitions are only needed in code that > must compile for both user-mode and softmmu emulation. Device > models can use the equivalent ld_p/st_p which are simple > pointer accessors. > > The checkpatch situation of nseries.c and mips_malta.c is > messy. I'm only doing a textual substitution in this RFC, > maintainers should let me know what they prefer.
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > hw/9pfs/virtio-9p-device.c | 2 +- > hw/arm/nseries.c | 236 > ++++++++++++++++++++--------------------- > hw/block/virtio-blk.c | 12 +-- > hw/display/omap_lcd_template.h | 10 +- > hw/display/sm501_template.h | 6 +- > hw/display/vga_template.h | 4 +- > hw/mips/mips_fulong2e.c | 28 ++--- > hw/mips/mips_malta.c | 176 +++++++++++++++--------------- > hw/scsi/vhost-scsi.c | 4 +- > hw/scsi/virtio-scsi.c | 28 ++--- The virtio parts of this look dubious. What actual endianness does the virtio spec say that things like the block device geometry should have in memory? I suspect we should be using the use-the-virtio-endianness accessors Greg's on-list patches implement, which renders the raw-vs-p question moot. In any case you'll probably have patch conflicts there. For nseries.c I think I'd prefer we do the checkpatch fixups. There's no reason we can't do this now (ie we don't wait on the fixes which make the rest of this series an RFC), so if you want to make this patch smaller you could submit a patch for the ARM bits of this and I'll take it in target-arm.next. (Or I can do it, if you'd rather.) I suspect the OMAP display device at least should technically be doing lduw_le_p(), since this isn't the CPU doing the access, but an independent peripheral doing DMA reads from memory. It's kind of an academic question for the moment since you'll only see an OMAP device in an LE-target QEMU binary, though, so straight substitution is reasonable. thanks -- PMM
