On Fri, 17 Aug 2018 12:34:27 +0300 "Yordan Karadzhov (VMware)" <y.karadz@xxxxxxxxx> wrote: > Hi Steven, > > On 16.08.2018 21:52, Steven Rostedt wrote: > >> +/** > >> + * @brief Check the type of a Configuration document and compare with an > >> + * expected value. > >> + * > >> + * @param conf: Input location for the kshark_config_doc instance. > >> + * @param type: Input location for the expected value of the Configuration > >> + * document type, e.g. "kshark.record.config" or > >> + * "kshark.filter.config". > > Oh, I forgot to ask... > > > > Do you expect to have different "kshark.record" and kshark.filter" > > options other than ".config"? If not, shouldn't it be: > > > > "kshark.config.record" and "kshark.config.filter" ? > > > > That way we can do searches for all the configs in a json file by > > searching for "kshark.config". > > > > > > My logic was that in the future we may have KernelShark doing some > automated analyses over the trace data. In this case the result can be > outputted to a Json file and have a type "kshark.*.output". So I > intuitively added the ".config" at the end, like a file extension. > > However your logic makes sense and I am OK with switching the order. Yes please. Naming like this is usually done in "reverse" language. Similar to DNS names. Although we may type "www.vmware.com", it is really processed in the order of "com:vmware:www". And with config names, the more detailed the data, the farther out it goes: <domain>.<subdomain>.<topic>.<detailed_topic> Thanks! -- Steve
|