All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Karim Yaghmour <karim.yaghmour@opersys.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Kees Cook <keescook@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Joel Fernandes <joelaf@google.com>,
	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>,
	Guenter Roeck <groeck@chromium.org>,
	Jonathan Corbet <corbet@lwn.net>,
	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>,
	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: Tue, 16 Apr 2019 16:22:40 +0200	[thread overview]
Message-ID: <20190416142240.GA31920@kroah.com> (raw)
In-Reply-To: <20190416094509.1af6326b@gandalf.local.home>

On Tue, Apr 16, 2019 at 09:45:09AM -0400, Steven Rostedt wrote:
> On Tue, 16 Apr 2019 09:32:37 -0400
> Karim Yaghmour <karim.yaghmour@opersys.com> wrote:
> 
> > >>> Then we should perhaps make a new file system call tarballs ;-)
> > >>>
> > >>>   /sys/kernel/tarballs/
> > >>>
> > >>> and place everything there. That way it removes it from /proc (which is
> > >>> the worse place for that) and also makes it something other than debug.
> > >>> That's what I did for tracefs.  
> > >>
> > >> As horrible as that suggestion is, it does kind of make sense :)
> > >>
> > >> We can't put this in debugfs as that's only for debugging and systems
> > >> should never have that mounted for normal operations (users want to
> > >> build ebpf programs), and /proc really should be for processes but that
> > >> horse is long left the barn.
> > >>
> > >> But, I'm willing to consider putting this either in a system-fs-like
> > >> filesystem, or just in sysfs itself, we do have /sys/kernel/ to play
> > >> around in if the main objection is that we should not be cluttering up
> > >> /proc with stuff like this.
> > >>  
> > > 
> > > I am ok with the suggestion of /sys/kernel for the archive. That also seems
> > > to fit well with the idea that the headers are kernel related and probably
> > > belong here more strictly speaking, than /proc.  
> > 
> > This makes sense. And if it alleviates concerns regarding extending 
> > /proc ABIs then might as well switch to this.
> > 
> > Olof, what do you think of this?
> 
> BTW, the name "tarballs" was kind of a joke. Probably should come up
> with a better name. Although, I'm fine with tarballsfs ;-)

No need to have this be a separate filesystem, we can use a binary sysfs
file in /sys/kernel/ for this as the kernel is not doing any "parsing"
of the data, it is just dumping it out to userspace.

If I make /sys/kernel/config.gz be the same thing as /proc/config.gz
will you fix up 'make localmodconfig' to use it?  :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Subject: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier
Date: Tue, 16 Apr 2019 16:22:40 +0200	[thread overview]
Message-ID: <20190416142240.GA31920@kroah.com> (raw)
In-Reply-To: <20190416094509.1af6326b@gandalf.local.home>

On Tue, Apr 16, 2019 at 09:45:09AM -0400, Steven Rostedt wrote:
> On Tue, 16 Apr 2019 09:32:37 -0400
> Karim Yaghmour <karim.yaghmour at opersys.com> wrote:
> 
> > >>> Then we should perhaps make a new file system call tarballs ;-)
> > >>>
> > >>>   /sys/kernel/tarballs/
> > >>>
> > >>> and place everything there. That way it removes it from /proc (which is
> > >>> the worse place for that) and also makes it something other than debug.
> > >>> That's what I did for tracefs.  
> > >>
> > >> As horrible as that suggestion is, it does kind of make sense :)
> > >>
> > >> We can't put this in debugfs as that's only for debugging and systems
> > >> should never have that mounted for normal operations (users want to
> > >> build ebpf programs), and /proc really should be for processes but that
> > >> horse is long left the barn.
> > >>
> > >> But, I'm willing to consider putting this either in a system-fs-like
> > >> filesystem, or just in sysfs itself, we do have /sys/kernel/ to play
> > >> around in if the main objection is that we should not be cluttering up
> > >> /proc with stuff like this.
> > >>  
> > > 
> > > I am ok with the suggestion of /sys/kernel for the archive. That also seems
> > > to fit well with the idea that the headers are kernel related and probably
> > > belong here more strictly speaking, than /proc.  
> > 
> > This makes sense. And if it alleviates concerns regarding extending 
> > /proc ABIs then might as well switch to this.
> > 
> > Olof, what do you think of this?
> 
> BTW, the name "tarballs" was kind of a joke. Probably should come up
> with a better name. Although, I'm fine with tarballsfs ;-)

No need to have this be a separate filesystem, we can use a binary sysfs
file in /sys/kernel/ for this as the kernel is not doing any "parsing"
of the data, it is just dumping it out to userspace.

If I make /sys/kernel/config.gz be the same thing as /proc/config.gz
will you fix up 'make localmodconfig' to use it?  :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
Subject: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier
Date: Tue, 16 Apr 2019 16:22:40 +0200	[thread overview]
Message-ID: <20190416142240.GA31920@kroah.com> (raw)
Message-ID: <20190416142240.ew1toJITcz4-_wLNE163wBPmLLDulcC729Qy7WqhRcQ@z> (raw)
In-Reply-To: <20190416094509.1af6326b@gandalf.local.home>

On Tue, Apr 16, 2019@09:45:09AM -0400, Steven Rostedt wrote:
> On Tue, 16 Apr 2019 09:32:37 -0400
> Karim Yaghmour <karim.yaghmour@opersys.com> wrote:
> 
> > >>> Then we should perhaps make a new file system call tarballs ;-)
> > >>>
> > >>>   /sys/kernel/tarballs/
> > >>>
> > >>> and place everything there. That way it removes it from /proc (which is
> > >>> the worse place for that) and also makes it something other than debug.
> > >>> That's what I did for tracefs.  
> > >>
> > >> As horrible as that suggestion is, it does kind of make sense :)
> > >>
> > >> We can't put this in debugfs as that's only for debugging and systems
> > >> should never have that mounted for normal operations (users want to
> > >> build ebpf programs), and /proc really should be for processes but that
> > >> horse is long left the barn.
> > >>
> > >> But, I'm willing to consider putting this either in a system-fs-like
> > >> filesystem, or just in sysfs itself, we do have /sys/kernel/ to play
> > >> around in if the main objection is that we should not be cluttering up
> > >> /proc with stuff like this.
> > >>  
> > > 
> > > I am ok with the suggestion of /sys/kernel for the archive. That also seems
> > > to fit well with the idea that the headers are kernel related and probably
> > > belong here more strictly speaking, than /proc.  
> > 
> > This makes sense. And if it alleviates concerns regarding extending 
> > /proc ABIs then might as well switch to this.
> > 
> > Olof, what do you think of this?
> 
> BTW, the name "tarballs" was kind of a joke. Probably should come up
> with a better name. Although, I'm fine with tarballsfs ;-)

No need to have this be a separate filesystem, we can use a binary sysfs
file in /sys/kernel/ for this as the kernel is not doing any "parsing"
of the data, it is just dumping it out to userspace.

If I make /sys/kernel/config.gz be the same thing as /proc/config.gz
will you fix up 'make localmodconfig' to use it?  :)

thanks,

greg k-h

  parent reply	other threads:[~2019-04-16 14:22 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
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 [this message]
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=20190416142240.GA31920@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --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=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.