From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Olof Johansson <olof@lixom.net>
Cc: Joel Fernandes <joelaf@google.com>,
Joel Fernandes <joel@joelfernandes.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Qais Yousef <qais.yousef@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Manoj Rao <linux@manojrajarao.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
atish patra <atishp04@gmail.com>,
Daniel Colascione <dancol@google.com>,
Dan Williams <dan.j.williams@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Guenter Roeck <groeck@chromium.org>,
Jonathan Corbet <corbet@lwn.net>,
Karim Yaghmour <karim.yaghmour@opersys.com>,
Kees Cook <keescook@chromium.org>,
Android Kernel Team <kernel-team@android.com>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-trace-devel@vger.kernel.org,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Shuah Khan <shuah@kernel.org>, Yonghong Song <yhs@fb.com>
Subject: Re: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier
Date: Wed, 10 Apr 2019 20:15:42 -0700 [thread overview]
Message-ID: <20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAOesGMiuGK-Sbqo2z=1ab070JONav1LF82MRRLCdX-4+14_XZA@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: alexei.starovoitov at gmail.com (Alexei Starovoitov)
Subject: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier
Date: Wed, 10 Apr 2019 20:15:42 -0700 [thread overview]
Message-ID: <20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAOesGMiuGK-Sbqo2z=1ab070JONav1LF82MRRLCdX-4+14_XZA@mail.gmail.com>
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 at google.com> wrote:
> >
> > On Wed, Apr 10, 2019 at 11:07 AM Olof Johansson <olof at 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
WARNING: multiple messages have this Message-ID (diff)
From: alexei.starovoitov@gmail.com (Alexei Starovoitov)
Subject: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier
Date: Wed, 10 Apr 2019 20:15:42 -0700 [thread overview]
Message-ID: <20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com> (raw)
Message-ID: <20190411031542.DqRdFjqottcM4uppwcZzCWRrkCHdtEf9douDkyqbzvs@z> (raw)
In-Reply-To: <CAOesGMiuGK-Sbqo2z=1ab070JONav1LF82MRRLCdX-4+14_XZA@mail.gmail.com>
On Wed, Apr 10, 2019@09:34:49AM -0700, Olof Johansson wrote:
> On Wed, Apr 10, 2019@8:51 AM Joel Fernandes <joelaf@google.com> wrote:
> >
> > On Wed, Apr 10, 2019@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
next prev parent reply other threads:[~2019-04-11 3:15 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 16:31 [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier Joel Fernandes (Google)
2019-03-20 16:31 ` Joel Fernandes (Google)
2019-03-20 16:31 ` joel
2019-03-20 16:31 ` [PATCH v5 2/3] Add selftests for module build using in-kernel headers Joel Fernandes (Google)
2019-03-20 16:31 ` Joel Fernandes (Google)
2019-03-20 16:31 ` joel
2019-03-20 16:31 ` [PATCH v5 3/3] init/config: Do not select BUILD_BIN2C for IKCONFIG Joel Fernandes (Google)
2019-03-20 16:31 ` Joel Fernandes (Google)
2019-03-20 16:31 ` joel
2019-03-20 18:31 ` [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier Andrew Morton
2019-03-20 18:31 ` Andrew Morton
2019-03-20 18:31 ` akpm
2019-03-20 19:42 ` Joel Fernandes
2019-03-20 19:42 ` Joel Fernandes
2019-03-20 19:42 ` joel
2019-04-08 16:29 ` Olof Johansson
2019-04-08 16:29 ` Olof Johansson
2019-04-08 16:29 ` olof
2019-04-08 16:37 ` Daniel Colascione
2019-04-08 16:37 ` Daniel Colascione
2019-04-08 16:37 ` dancol
2019-04-08 16:53 ` Olof Johansson
2019-04-08 16:53 ` Olof Johansson
2019-04-08 16:53 ` olof
2019-04-08 20:36 ` Joel Fernandes
2019-04-08 20:36 ` Joel Fernandes
2019-04-08 20:36 ` joel
2019-04-10 15:07 ` Olof Johansson
2019-04-10 15:07 ` Olof Johansson
2019-04-10 15:07 ` olof
2019-04-10 15:50 ` Joel Fernandes
2019-04-10 15:50 ` Joel Fernandes
2019-04-10 15:50 ` joelaf
2019-04-10 16:34 ` Olof Johansson
2019-04-10 16:34 ` Olof Johansson
2019-04-10 16:34 ` olof
2019-04-10 17:33 ` Joel Fernandes
2019-04-10 17:33 ` Joel Fernandes
2019-04-10 17:33 ` joelaf
2019-04-10 17:35 ` Daniel Colascione
2019-04-10 17:35 ` Daniel Colascione
2019-04-10 17:35 ` dancol
2019-04-11 3:15 ` Alexei Starovoitov [this message]
2019-04-11 3:15 ` Alexei Starovoitov
2019-04-11 3:15 ` alexei.starovoitov
2019-04-11 16:30 ` Joel Fernandes
2019-04-11 16:30 ` Joel Fernandes
2019-04-11 16:30 ` joel
2019-04-14 19:38 ` Olof Johansson
2019-04-14 19:38 ` Olof Johansson
2019-04-14 19:38 ` olof
2019-04-15 9:41 ` Enrico Weigelt, metux IT consult
2019-04-15 9:41 ` Enrico Weigelt, metux IT consult
2019-04-15 9:41 ` lkml
2019-04-15 13:52 ` Joel Fernandes
2019-04-15 13:52 ` Joel Fernandes
2019-04-15 13:52 ` joel
2019-04-15 14:05 ` Joel Fernandes
2019-04-15 14:05 ` Joel Fernandes
2019-04-15 14:05 ` joel
2019-04-15 14:41 ` Steven Rostedt
2019-04-15 14:41 ` Steven Rostedt
2019-04-15 14:41 ` rostedt
2019-04-16 3:50 ` Kees Cook
2019-04-16 3:50 ` Kees Cook
2019-04-16 3:50 ` keescook
2019-04-16 12:33 ` Steven Rostedt
2019-04-16 12:33 ` Steven Rostedt
2019-04-16 12:33 ` rostedt
2019-04-16 12:49 ` Greg Kroah-Hartman
2019-04-16 12:49 ` Greg Kroah-Hartman
2019-04-16 12:49 ` gregkh
2019-04-16 13:04 ` Joel Fernandes
2019-04-16 13:04 ` Joel Fernandes
2019-04-16 13:04 ` joel
2019-04-16 13:32 ` Karim Yaghmour
2019-04-16 13:32 ` Karim Yaghmour
2019-04-16 13:32 ` karim.yaghmour
2019-04-16 13:45 ` Steven Rostedt
2019-04-16 13:45 ` Steven Rostedt
2019-04-16 13:45 ` rostedt
2019-04-16 14:21 ` Joel Fernandes
2019-04-16 14:21 ` Joel Fernandes
2019-04-16 14:21 ` joel
2019-04-16 14:22 ` Greg Kroah-Hartman
2019-04-16 14:22 ` Greg Kroah-Hartman
2019-04-16 14:22 ` gregkh
2019-04-16 14:43 ` Steven Rostedt
2019-04-16 14:43 ` Steven Rostedt
2019-04-16 14:43 ` rostedt
2019-04-16 16:42 ` Olof Johansson
2019-04-16 16:42 ` Olof Johansson
2019-04-16 16:42 ` olof
2019-04-16 16:46 ` Alexei Starovoitov
2019-04-16 16:46 ` Alexei Starovoitov
2019-04-16 16:46 ` alexei.starovoitov
2019-04-16 16:57 ` Olof Johansson
2019-04-16 16:57 ` Olof Johansson
2019-04-16 16:57 ` olof
2019-04-16 17:22 ` Joel Fernandes
2019-04-16 17:22 ` Joel Fernandes
2019-04-16 17:22 ` joel
2019-04-16 17:30 ` Alexei Starovoitov
2019-04-16 17:30 ` Alexei Starovoitov
2019-04-16 17:30 ` alexei.starovoitov
2019-04-16 16:47 ` Olof Johansson
2019-04-16 16:47 ` Olof Johansson
2019-04-16 16:47 ` olof
2019-04-10 19:19 ` Arnd Bergmann
2019-04-10 19:19 ` Arnd Bergmann
2019-04-10 19:19 ` arnd
2019-04-12 16:16 ` Enrico Weigelt, metux IT consult
2019-04-12 16:16 ` Enrico Weigelt, metux IT consult
2019-04-12 16:16 ` lkml
2019-04-12 17:25 ` Steven Rostedt
2019-04-12 17:25 ` Steven Rostedt
2019-04-12 17:25 ` rostedt
2019-04-08 20:52 ` Karim Yaghmour
2019-04-08 20:52 ` Karim Yaghmour
2019-04-08 20:52 ` karim.yaghmour
2019-04-10 15:15 ` Olof Johansson
2019-04-10 15:15 ` Olof Johansson
2019-04-10 15:15 ` olof
2019-04-10 15:44 ` Daniel Colascione
2019-04-10 15:44 ` Daniel Colascione
2019-04-10 15:44 ` dancol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=atishp04@gmail.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dancol@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=karim.yaghmour@opersys.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=linux@manojrajarao.com \
--cc=mhiramat@kernel.org \
--cc=olof@lixom.net \
--cc=qais.yousef@arm.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.