Ingo Schwarze <schwa...@usta.de> wrote: > 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?
Every single one of the -t sub-optionsd are flags passed to the kernel, and the kernel evaluates what to export. This is completely not like -t. > 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? Sorry, that isn't how this works. > Unless i'm mistaken, we don't provide a way either to say "i want > to see system calls, except that i don't want to see chdir(2), > chmod(2), getuid(2), and mprotect(2)." And.... that is not what is happening here. This is a totally new condition where libc has a way to "skip" doing "calls to system calls" but we need a way to expose them *BECAUSE THE DEVELOPMENT PROCESS NEEDS THE VISIBILITY*.
