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?
Keeping the user interface small is often good. Needing only one
sub-flag rather than two to see all system calls doesn't seem that
bad, either.
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)."
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 ?
Yours,
Ingo
