Jonathan Cameron wrote:
> On Wed, 20 Dec 2023 16:17:31 -0800
> Ira Weiny <ira.weiny@xxxxxxxxx> wrote:
>
> > The UUID data is redundant in the known event trace types. The addition
> > of static defines allows the trace macros to create the UUID data inside
> > the trace thus removing unnecessary code.
> >
> > Have well known trace events use static data to set the uuid field based
> > on the event type.
> >
> > Suggested-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > Signed-off-by: Ira Weiny <ira.weiny@xxxxxxxxx>
> >
>
> > TP_STRUCT__entry(
> > CXL_EVT_TP_entry
> > @@ -422,7 +424,8 @@ TRACE_EVENT(cxl_dram,
> > ),
> >
> > TP_fast_assign(
> > - CXL_EVT_TP_fast_assign(cxlmd, log, uuid, rec->hdr);
> > + CXL_EVT_TP_fast_assign(cxlmd, log, rec->hdr);
> > + memcpy(&__entry->hdr_uuid, &CXL_EVENT_DRAM_UUID, sizeof(uuid_t));
>
> Hmm. Why not
>
> __entry->hdr_uuid = CXL_EVENT_DRAM_UUID;
> ?
>
> Compiler should be able to squish the stuff in the define down to data as as the
> UUID generation logic is pretty simple.
>
> I've not emulated the cper records for these yet, so not tested that works beyond
> compiling.
We can follow on with this conversion later as I see other usage of uuid
copying in trace events (bcache for instance). Although I probably would
not replace it with straight assignment and instead use the uuid_copy()
helper. Otherwise, why do {uuid,guid}_copy() helpers exist?
