From: Joel Fernandes <joel@joelfernandes.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
ast@kernel.org, atishp04@gmail.com, dancol@google.com,
Dan Williams <dan.j.williams@intel.com>,
gregkh@linuxfoundation.org, Guenter Roeck <groeck@chromium.org>,
Jonathan Corbet <corbet@lwn.net>,
karim.yaghmour@opersys.com, Kees Cook <keescook@chromium.org>,
kernel-team@android.com, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org,
linux-trace-devel@vger.kernel.org,
Manoj Rao <linux@manojrajarao.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
paulmck@linux.vnet.ibm.com,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
qais.yousef@arm.com, rdunlap@infradead.org, rostedt@goodmis.org,
Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
yhs@fb.com
Subject: Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Fri, 1 Mar 2019 12:21:58 -0500 [thread overview]
Message-ID: <20190301172158.GB217990@google.com> (raw)
In-Reply-To: <20190301160309.2ddadeeb4aadbab4cdc88171@kernel.org>
On Fri, Mar 01, 2019 at 04:03:09PM +0900, Masami Hiramatsu wrote:
> Hi Joel,
>
> On Thu, 28 Feb 2019 22:26:11 -0500
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
> > On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote:
[..]
> > There are many usecases for this, I have often run into issues with Linux
> > over the years not only with Android, but other distros, where I boot custom
> > kernels with no linux-headers package. This is quite painful. It is
> > convenient to have it as /proc file since the file is dependent on kernel
> > being booted up and this will work across all Linux distros and systems. I
> > feel that if you can keep an open mind about it, you will see that a lot of
> > people will use this feature if it is accepted and there is a lot of positive
> > feedback in earlier posts of this set.
>
> I don't complain about having headers for custom boot kernel. I agree with you
> that having kernel headers for debugging is always good. :)
> So google recommends built-in, it is reasonable.
Ok, thanks :)
> > > > > > The code to read the headers is based on /proc/config.gz code and uses
> > > > > > the same technique to embed the headers.
> > > > > >
> > > > > > To build a module, the below steps have been tested on an x86 machine:
> > > > > > modprobe kheaders
> > > > > > rm -rf $HOME/headers
> > > > > > mkdir -p $HOME/headers
> > > > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null
> > > > > > cd my-kernel-module
> > > > > > make -C $HOME/headers M=$(pwd) modules
> > > > > > rmmod kheaders
> > > > >
> > > > > It seems a bit complex, but no difference from compared with carrying
> > > > > kheaders.tar.gz. I think we would better have a psudo filesystem
> > > > > which can mount this compressed header file directly :) Then it becomes
> > > > > simpler, like
> > > > >
> > > > > modprobe headerfs
> > > > > mkdir $HOME/headers
> > > > > mount -t headerfs $HOME/headers
> > > > >
> > > > > And this doesn't consume any disk-space.
> > > >
> > > > I felt using a compressed tar is really the easiest way because of all the
> > > > tools are already available.
> > >
> > > As I asked above, if the pure tarball is useful, you can simply ask vendors
> > > to put the header tarball on their vendor directory. I feel making it as
> > > a module is not a right way.
> >
> > I don't see what is the drawback of making it a module, it makes it well
> > integrated into kernel build and ecosystem. I also didn't see any
> > justification you're providing about why it cannot be a module. If you go
> > through this and earlier threads, a lot of people are Ok with having a module
> > option. And I asked several top kernel maintainers at LPC and many people
> > suggested having it as a module.
>
> I meant, if we have a tarball, we don't need any operation of loading/unloading
> kmodules. But if we have this as built-in, yes, this would be much easier to
> deploy it to device.
>
> Anyway, having that option (make it as a module) is not bad. IMHO, that may
> be more complicated than just have a tarball file, but it is a user's choice.
>
> OK, now I understand it.
Sounds good. :) Just sent out v4.
thanks,
- Joel
next prev parent reply other threads:[~2019-03-01 17:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 19:37 [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel Joel Fernandes (Google)
2019-02-27 19:37 ` [PATCH v3 2/2] Add selftests for module build using in-kernel headers Joel Fernandes (Google)
2019-02-28 2:17 ` [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel Masahiro Yamada
2019-02-28 14:43 ` Joel Fernandes
2019-02-28 23:27 ` Joel Fernandes
2019-03-01 6:25 ` Masahiro Yamada
2019-03-01 17:19 ` Joel Fernandes
2019-03-02 2:13 ` Masahiro Yamada
2019-03-02 2:39 ` Joel Fernandes
2019-03-04 5:40 ` Masahiro Yamada
2019-02-28 8:34 ` Masami Hiramatsu
2019-02-28 15:00 ` Joel Fernandes
2019-02-28 15:30 ` Greg KH
2019-02-28 15:37 ` Joel Fernandes
2019-02-28 15:45 ` Greg KH
2019-02-28 15:59 ` Joel Fernandes
2019-02-28 16:09 ` Steven Rostedt
2019-03-01 2:28 ` Masami Hiramatsu
2019-03-01 3:26 ` Joel Fernandes
2019-03-01 7:03 ` Masami Hiramatsu
2019-03-01 17:21 ` Joel Fernandes [this message]
2019-03-01 11:05 ` Qais Yousef
2019-02-28 13:53 ` Qais Yousef
2019-02-28 14:47 ` Joel Fernandes
2019-02-28 16:04 ` Dietmar Eggemann
2019-02-28 16:22 ` Qais Yousef
2019-02-28 16:48 ` Qais Yousef
2019-02-28 18:36 ` Dietmar Eggemann
2019-02-28 19:10 ` Joel Fernandes
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=20190301172158.GB217990@google.com \
--to=joel@joelfernandes.org \
--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=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--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=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).