On Mon, Jun 15, 2026 at 03:26:25PM +0530, Praveen Talari wrote:
> HI Steven,
> 
> On 29-05-2026 19:44, Steven Rostedt wrote:
> > On Tue, 26 May 2026 23:07:39 +0530
> > Praveen Talari <[email protected]> wrote:
> > 
> > > +DECLARE_EVENT_CLASS(geni_serial_data,
> > > +             TP_PROTO(struct device *dev, const u8 *buf, unsigned int 
> > > len),
> > > +             TP_ARGS(dev, buf, len),
> > > +
> > > +             TP_STRUCT__entry(__string(name, dev_name(dev))
> > > +                              __field(unsigned int, len)
> > > +                              __dynamic_array(u8, data, len)
> > > +             ),
> > > +
> > > +             TP_fast_assign(__assign_str(name);
> > > +                            __entry->len = len;
> > > +                            memcpy(__get_dynamic_array(data), buf, len);
> > > +             ),
> > > +
> > > +             TP_printk("%s: len=%u data=%s",
> > > +                       __get_str(name), __entry->len,
> > > +                       __print_hex(__get_dynamic_array(data), 
> > > __entry->len))
> > > +);
> > No need to save the length of the dynamic array in __entry->len because
> > it's already saved in the metadata of the dynamic array that is stored
> > on the buffer. Instead you can have:
> > 
> > DECLARE_EVENT_CLASS(geni_serial_data,
> >                 TP_PROTO(struct device *dev, const u8 *buf, unsigned int 
> > len),
> >                 TP_ARGS(dev, buf, len),
> > 
> >                 TP_STRUCT__entry(__string(name, dev_name(dev))
> >                                  __dynamic_array(u8, data, len)
> >                 ),
> > 
> >                 TP_fast_assign(__assign_str(name);
> >                                memcpy(__get_dynamic_array(data), buf, len);
> >                 ),
> > 
> >                 TP_printk("%s: len=%u data=%s",
> >                           __get_str(name), __entry->len,
> >                           __print_hex(__get_dynamic_array(data),
> >                                     __get_dynamic_array_len(data)))
> > );
> > 
> > That will save you 4 bytes per event on the ring buffer. And a few
> > cycles not having to store the redundant information.
> 
> This patch has already been accepted and is available in linux-next.

Great, can you send a fixup for it?  Or want me to revert this instead?

thanks,

greg k-h

Reply via email to