ftrace events: parameter tracing

[valdis.kletnieks at vt.edu]

On Wed, 14 Feb 2018 20:26:01 +0100, Christof Warlich said:

> record the build's dependencies. On subsequent runs of the build, these
> depencencies could then be used to decide which compoments must be
> rebuilt due to changed dependencies.

Doesn't "make" already do what you want?

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.

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.

To quote the movie Animal House: "My advice to you is to start drinking heavily....."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180214/1f7deb5d/attachment-0001.sig>