[SLOF] [PATCH v3 19/22] virtio: 1.0 helper to read 16/32/64 bit value

Thomas Huth thuth at redhat.com
Fri Jan 29 01:31:15 AEDT 2016


On 28.01.2016 05:53, Nikunj A Dadhania wrote:
> Thomas Huth <thuth at redhat.com> writes:
> 
>> On 22.01.2016 11:55, Nikunj A Dadhania wrote:
>>> To avoid cluttering the driver code with modern/legacy code introduce
>>> virtio_cpu_to_modern{16,32,64} and virtio_modern{16,32,64}_to_cpu
>>>
>>> Signed-off-by: Nikunj A Dadhania <nikunj at linux.vnet.ibm.com>
>>> Suggested-by: Thomas Huth <thuth at redhat.com>
>>  
>>> +extern uint16_t virtio_cpu_to_modern16(struct virtio_device *dev, uint16_t val);
>>> +extern uint32_t virtio_cpu_to_modern32(struct virtio_device *dev, uint32_t val);
>>> +extern uint64_t virtio_cpu_to_modern64(struct virtio_device *dev, uint64_t val);
>>> +extern uint16_t virtio_modern16_to_cpu(struct virtio_device *dev, uint16_t val);
>>> +extern uint32_t virtio_modern32_to_cpu(struct virtio_device *dev, uint32_t val);
>>> +extern uint64_t virtio_modern64_to_cpu(struct virtio_device *dev, uint64_t val);
>>
>> Patch looks fine ... but I'd maybe move the functions into the virtio.h
>> header file instead and declare them as "static inline",
> 
> I had tried that, there were some related to the virtio.h header getting
> included in virtio.code file. That is the reason I had moved it here.

Ah, right, that's always the issue with headers that get included from
the .code files - you can't define inline functions there since the
board.code file gets included from within a function in paflof.c.

So either put the inline functions into a new, separate header file
(which does not get included from virtio.code), or simply leave it this
way (we still can optimize it later if we feel that there's the need).

 Thomas



More information about the SLOF mailing list