On Wed, Apr 10, 2019 at 08:15:42PM -0700, Alexei Starovoitov wrote:
On Wed, Apr 10, 2019 at 09:34:49AM -0700, Olof Johansson wrote:
On Wed, Apr 10, 2019 at 8:51 AM Joel Fernandes joelaf@google.com wrote:
On Wed, Apr 10, 2019 at 11:07 AM Olof Johansson olof@lixom.net wrote: [snip]
Wouldn't it be more convenient to provide it in a standardized format such that you won't have to take an additional step, and always have This is that form IMO.
...
Compared to:
- Extract tarball
- Build and load
- Remove file tree from filesystem
I think there are too many assumptions in this thread in regard to what is more convenient for user space. I think bcc should try to avoid extracting tarball into file system. For example libbcc can uncompress kheader.tar.xz into virtual file system of clang front-end. It's more or less std::map<string, string> with key=path, value=content of the file. Access to such in-memory 'files' is obviously faster than doing open/read syscalls. bcc already uses this approach for some bcc internal 'files' that it passes to clang during compilation. All of /proc/kheaders.tar.xz files can be passed the same way without extracting them into real file system.
Joel, would be great if you can share corresponding bcc patch that takes advantage of /proc/kheaders
That sounds good to me. Others have tested this with BCC with a manual extraction and setting environment variable to point BCC to the extracted location, but I can work BCC patch that makes this automatic and share it (I was planning to do the "automatically make BCC do it" patch for the BCC project, but first wanted this in. But I agree with Alexei, its a good idea to do it now and share it). Masahiro had some nits in v6 that I need to address anyway ;-) And Olof grumbled a bit about the commit message which could be polished a bit more :-)
thanks!
- Joel