Re: [Qemu-devel] [PULL V4 00/31] Net patches

[Dmitry Fleytman]

Hi,

After deeper investigation:

From lttng/tracepoint.h:

…

/*
 * TP_ARGS takes tuples of type, argument separated by a comma.
 * It can take up to 10 tuples (which means that less than 10 tuples is
 * fine too).
 * Each tuple is also separated by a comma.
 */

…

So this is a ust backend limitation.

Since build is failing, I’m sending a patch that splits this tracepoint into 2 
events.

~Dmitry


> On 2 Jun 2016, at 21:09 PM, Dmitry Fleytman <address@hidden> wrote:
> 
>> 
>> On 2 Jun 2016, at 19:29 PM, Peter Maydell <address@hidden> wrote:
>> 
>> On 2 June 2016 at 15:15, Peter Maydell <address@hidden> wrote:
>>> On 2 June 2016 at 07:47, Jason Wang <address@hidden> wrote:
>>>> The following changes since commit 
>>>> 287db79df8af8e31f18e262feb5e05103a09e4d4:
>>>> 
>>>> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into 
>>>> staging (2016-05-24 13:06:33 +0100)
>>>> 
>>>> are available in the git repository at:
>>>> 
>>>> https://github.com/jasowang/qemu.git tags/net-pull-request
>>>> 
>>>> for you to fetch changes up to 517b5e9a175fe7d47cc0fab6c2310241fd33c115:
>>>> 
>>>> Add ENET device to i.MX6 SOC. (2016-06-02 10:42:46 +0800)
>>>> 
>>>> ----------------------------------------------------------------
>>>> Main changes:
>>>> - e1000e emulation
>>>> - convet vmxnet3 to use DMA api
>>>> - ENET support for FEC device
>>>> Changes from V3:
>>>> - add ENET series
>>>> - fix clang sanitizer about misaligned access
>>>> Changes from V2:
>>>> - fix clang build
>>>> Changes from V1:
>>>> - fix 32bit build
>>>> 
>>> 
>>> Applied, thanks.
>> 
>> Looks like this caused a travis build failure for the config which
>> uses --enable-trace-backends=ust:
>> https://travis-ci.org/qemu/qemu/jobs/134759359
>> 
>> Could you or Dmitry have a look, please?
> 
> Hi Peter,
> 
> The build did not pass because of tracepoint e1000e_rx_rss_ip6 which failed 
> to compile.
> 
> This tracepoint has 11 parameters, when 1 parameter is removed build succeeds.
> Could it be that ust backend has a limitation of 10 parameters per event?
> Should I split this trace into 2 events?
> 
> In general, I would like to check compilability of my patches better next 
> time,
> is there a way to figure out a full list of configurations to be tested? Is 
> there a tool for that maybe?
> 
> Thanks,
> Dmitry
> 
>> 
>> thanks
>> -- PMM