ftrace events: parameter tracing

[cwarlich@gmx.de (Christof Warlich)]

Am 14.02.2018 um 20:43 schrieb valdis.kletnieks at vt.edu:

> Doesn't "make" already do what you want?
No, make itself cannot generate dependency lists on its own, it needs 
tooling like gcc -MD ... to do that. I'm interested in a generic 
approach. But it my read and thus obey them.
> Oh, wait...
>
>> dependency recording, because the "results" of running "ls -l" do depend
>> on its shared libraries!
> This way lies madness - touch glibc or other package like that, and you just forced
> a rebuild of the entire world.  In fact, I suspect that trying to follow "dependencies"
> to that level will result in build times close to what a 'make world' would do, because
> computing what ends up being the transitive closure of all file references is painful.
>
> Hint:  To really do this correctly, you need to be able to force 100% code path
> coverage - otherwise you won't pick up the fact that /usr/lib64/libsnark.so is only
> actually used in an error path or similar rare-access corner case.
Well, unwanted dependencies could be excluded by a blacklist, although I 
still believe that at least /_most_/ of the required shared libraries 
should rightfully be kept as dependencies, last but not least because 
libraries are changed occasionally only on a build server, making world 
builds rare as well.
> For bonus points:
>
> openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3
>
> Which file(s) count?  How do you test for all values of $LANG and the various LC_*
> environment variables?
>
> There's a reason that most sane software builds and tools like rpm / dpkg and
> so on just check "glibc is still version 2.22" and don't bother going any
> further than that.
>
> And it just gets worse if you include kernel patches - how many modules end up
> involved in an open() call on a USB device?  How do you detect that your code
> "depends" on a given behavior - often kernel patches address error conditions
> that doesn't change the perceived behavior in your userspace program...
>
> ... until a rare error condition arises.  At this point, you need 100% code coverage
> of both the userspace *and* the kernel.
I'm not so sure whether full coverage is really necessary. Instead, the 
depencency record of a full succesful initial build might be sufficient. 
Even considering other influencing things like the environment should be 
possible.
> To quote the movie Animal House: "My advice to you is to start drinking heavily....."
You are most probably right with that, but I'd still like to continue 
pondering ... - as long as there is a way to yield the filename of an 
opened file using (fast) ftrace instead of slow ptrace?

Thus, I'd still be interested in a solution or hint to my initial question.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180214/2999651c/attachment.html>