> Date: Thu, 9 Jul 2020 19:43:52 +0200 > From: Ingo Schwarze <schwa...@usta.de> > > Hi Theo, > > Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600: > > Ingo Schwarze <schwa...@usta.de> wrote: > > >> So, what about > >> LD_KTRACE_GETTIME > >> or a similar environment variable name? > > > That naming seems logical. > > > > If it is mostly hidden behind a ktrace flag (-T ?) then I think > > we're in good shape. > > Technically, the implementation of the new ktrace(1) flag will be > totally different from the implementation of the existing ktrace -t > flags. But from the user perspective, the purpose of the new flag > is just to "put some more information into the dump file", so > shouldn't it be just another -t letter? Like, > > c trace system calls > T trace clock_gettime(2) and gettimeofday(2) > > or similar? > > Now that i look at that, and at what you said previously, is it even > plausible that some user ever wants "-t c" ktracing but does > specifically *not* want to see clock_gettime(2) and friends? > > If "i want system call ktracing" logically more or less implies "i > also want to see clock_gettime and friends", then maybe we do not > need a new command line flag at all, not even a sub-flag, and can > instead just let "-t c" enable that, too?
Yes. If I ktrace something like chromium I really don't want to see the thousands of pointless clock_gettime(2) calls. > > Regarding the LD_ prefix, clock_gettime(2) and gettimeofday(2) > are in <time.h> and <sys/time.h>, respectively, but maybe a TIME_ > prefix would be too specific. Sure, it is the "time" sublibrary > of libc, but "TIME_" wouldn't really make it apparent that it > is related to libc at all. > > So, should it instead be something like: > > LIBC_KTRACE_GETTIME ? I wonder if it should start with an underscore instead to indicate that the variable is not for public consumption. _KTRACE_TIME would do the job for me. We can always rename it if we discover another use case apart from ktrace.
