Re: [Qemu-devel] [PATCH for-2.1 v2 0/2] Generalise FIFO to more integer types

[Don Slutz <dslutz@verizon.com>]

On 04/08/14 05:10, Markus Armbruster wrote:
> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>
>> On Tue, Apr 8, 2014 at 5:14 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>>>
>>>> There is a utility helper for dealing with 8 bit fifos. This should be
>>>> applicable to other integer widths as well. These two patches
>>>> generalise this FIFO to work for 16, 32 and 64 bit ints.
>>> Can you show us a user for the wider FIFOs?
>>>
>> Hi Markus,
>>
>> I have a couple out of tree that are incomplete and a bit out of scope
>> of this series. Rather not wait and send a complicated series spanning
>> multiple sub-systrems. I guess I could shop around for an easy lead
>> example to fix, but does the series stand in its own right?
> I don't like infrastructure without an in-tree user.  Even if it's
> "only" a sensible, straightforward generalization of existing
> infrastructure.
>
> Infrastructure without a user tends to rot.  Probably not a serious
> issue in this particular case.
>
> The cost of applying a change and maintaining the additional complexity
> needs to be justified by some gain.  Even when the costs are small, like
> they probably are in this particular case.  An in-tree user could
> probably justify easily.

I am not sure that the run time cost is the best.  Looks more like c++ 
templates should be done via macros.  Just like 
include/exec/softmmu_header.h:


void glue(glue(fifo, 8), _create)(Fifo *fifo, uint32_t capacity);
void glue(glue(fifo, 8), _push)(Fifo *fifo, glue(glue(uint, 8), _t) data);
...

Also that would mean not doing the patch #1 at all.

That way all the cost is at compile time, and only the versions 
currently used are generated.

    -Don Slutz