Hi, i wonder whether there is a layering violation going on here.
>From the user perspective, whether an API call is a syscall or a mere library function doesn't make any difference, it's an implementation detail. API calls have often moved from being library functions to syscall and vice versa, witnessed by the blurry line between sections 2 and 3 in the manual (which is not a problem at all). So you say the user wants to see whether their program calls some time-related API functions, and in the past, ktrace was useful for that. On a machine where syscalls for the purpose are no longer needed due to pirofti@'s optimization, does it really make sense to force useless syscalls just to be able to see the API calls in ktrace? Wouldn't it make more sense to instead simply use ltrace(1), which IIUC is intended for just that purpose, tracing API calls? Someone said setting up ltrace(1) is kind of harder, while ktrace(1) is very easy to use (i can confirm the latter, i use ktrace regularly). So maybe the real problem is to make sure ltrace(1) is about as easy to use as ktrace(1)? (Not sure what exactly the problem(s) with ltrace usability are, if any, i didn't use it much so far.) It feels odd that a user would fiddle with the internal way how API calls are implemented, in particular using something as scary as environment variables, just to *inspect* what their program is doing... And that they would actually change what their program is doing just for the purpose of that inspection... Obviously, i don't object to any of this, and i may be totally wrong trying to think about something so deep down in the system. I'm just wondering... Yours, Ingo
