On 2021/9/19 13:38, John Hubbard wrote: > On 9/18/21 00:03, Weizhao Ouyang wrote: > ... >> Anyway, I didn't find a simply way the build the "everywhere" relationship behind >> the packaged TRACE_DEFINE_ENUM , what do you think. >> > It's actually pretty easy, unless I'm unknowingly violating some rule > here. But I did review tracing a bit before diving in, and I think this > is reasonable. > > The trace macros EM(), EMe(), and MIGRATE_REASON are flexible enough to > get whatever you want, out of them. So, the trace header can be the one > location for the definition of the enum-to-string mapping. > > The key is to move the enum to a common header file that both the trace > system (trace/events/migrate.h) and the migrate header > (include/linux/migrate.h) can include. Fortunately, that's already been > started for enum migrate_mode: there is migrate_mode.h. > > So it all works approximately like this, below. (I'll attach a > white-space-correct diff that you can apply directly, too). I've > compiled tested and rebooted with it, but haven't checked much more > than that yet. Thanks for your detailed patch! Yeah, if we move the enum migrate_reason to another header file it will attach it easily. The previous mail I said the tricky point is that we build the "everywhere relationship" on the basis of maintaining the original file structure, sorry for the confusing misleading. I think we should not change a lot for a slight synchronization. For now we can just apply the update in migrate_reason_name(maybe leave a comment to notify) on this patch, I will send v2 patch soon include the "cma" update. As for the trace_event synchronization, we can figure out a more generic implementation in the future, so that other subsystem can use it to catch a string info from its trace event header. Thanks, Weizhao
