<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Am 14.02.2018 um 20:43 schrieb <a
        class="moz-txt-link-abbreviated"
        href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>:<br>
    </p>
    <blockquote type="cite"
      cite="mid:48396.1518637408@turing-police.cc.vt.edu">
      <pre wrap="">Doesn't "make" already do what you want?</pre>
    </blockquote>
    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.<br>
    <blockquote type="cite"
      cite="mid:48396.1518637408@turing-police.cc.vt.edu">
      <pre wrap="">
Oh, wait...

</pre>
      <blockquote type="cite">
        <pre wrap="">dependency recording, because the "results" of running "ls -l" do depend
on its shared libraries!
</pre>
      </blockquote>
      <pre wrap="">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.</pre>
    </blockquote>
    Well, unwanted dependencies could be excluded by a blacklist,
    although I still believe that at least <i><u>most</u></i> 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.<br>
    <blockquote type="cite"
      cite="mid:48396.1518637408@turing-police.cc.vt.edu">
      <pre wrap="">
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.</pre>
    </blockquote>
    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.<br>
    <blockquote type="cite"
      cite="mid:48396.1518637408@turing-police.cc.vt.edu">
      <pre wrap="">
To quote the movie Animal House: "My advice to you is to start drinking heavily....."</pre>
    </blockquote>
    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?<br>
    <br>
    Thus, I'd still be interested in a solution or hint to my initial
    question.<br>
    <blockquote type="cite"
      cite="mid:48396.1518637408@turing-police.cc.vt.edu">
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kernelnewbies mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>