On Thu, May 30, 2013 at 01:28:26PM +0930, Rusty Russell wrote: > Anthony Liguori <aliguori@xxxxxxxxxx> writes: > > Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: > > > >> Anthony Liguori <aliguori@xxxxxxxxxx> writes: > >>> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > >>>> + case offsetof(struct virtio_pci_common_cfg, device_feature_select): > >>>> + return proxy->device_feature_select; > >>> > >>> Oh dear no... Please use defines like the rest of QEMU. > >> > >> It is pretty ugly. > > > > I think beauty is in the eye of the beholder here... > > > > Pretty much every device we have has a switch statement like this. > > Consistency wins when it comes to qualitative arguments like this. > > I was agreeing with you here, actually. > > >> Yet the structure definitions are descriptive, capturing layout, size > >> and endianness in natural a format readable by any C programmer. > > > >>From an API design point of view, here are the problems I see: > > > > 1) C makes no guarantees about structure layout beyond the first > > member. Yes, if it's naturally aligned or has a packed attribute, > > GCC does the right thing. But this isn't kernel land anymore, > > portability matters and there are more compilers than GCC. > > [ I argued in detail here, then deleted. Damn bikeshedding... ] > > I think the best thing is to add the decoded integer versions as macros, > and have a heap of BUILD_BUG_ON() in the kernel source to make sure they > match. On the qemu side, fine with me, all I want is ability to stay close to kernel headers. Let's have XXX_SIZE macros as well, so access size can be easily validated? On the kernel side, for 'struct virtio_pci_cap', since we only ever do offsetof on this struct, it might be easier to just use the numeric constants directly. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
