All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Qais Yousef <qais.yousef@arm.com>,
	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>,
	mhiramat@kernel.org, paulmck@linux.vnet.ibm.com,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	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: Thu, 28 Feb 2019 14:10:36 -0500	[thread overview]
Message-ID: <20190228191036.GA203889@google.com> (raw)
In-Reply-To: <b100f0a2-7966-b6a2-dcd5-ca11abe57ead@arm.com>

On Thu, Feb 28, 2019 at 05:04:59PM +0100, Dietmar Eggemann wrote:
[...]                      ^
> kernel/kheaders_data.h:1:1: note: in expansion of macro ‘KH_MAGIC_END’
>  KH_MAGIC_END;
>  ^~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:38:12: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>             kernel_headers_data + KH_MAGIC_SIZE,
>             ^~~~~~~~~~~~~~~~~~~
>             kernel_headers_data_size
> kernel/kheaders.c:38:12: note: each undeclared identifier is reported only
> once for each function it appears in
> kernel/kheaders.c: In function ‘ikheaders_init’:
> kernel/kheaders.c:31:10: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>   (sizeof(kernel_headers_data) - 1 - KH_MAGIC_SIZE * 2)
>           ^
> kernel/kheaders.c:57:23: note: in expansion of macro
> ‘kernel_headers_data_size’
>   proc_set_size(entry, kernel_headers_data_size);
>                        ^~~~~~~~~~~~~~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:40:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>  }
> 
> 
> The reason for me to stay on v4.20 is that with v5.0-rc8 I don't have ebpf
> 'raw tracepoint' support any more on my arm64 board. But this issue is not
> related to your patch though.

I'm glad mainline fixed your issue though as you said in the other thread ;-)
I will refer to your email here later when doing backports if I hit the issue.

> Another point which supports the functionality your patch provides is the
> fact that maintainers don't want to see new TRACE_EVENTs in their code. So
> here your patch comes handy when using ebpf for tracing in embedded
> environments.

Yes, I agree. One can also use the series to build custom kernel modules
which can also contain tracepoints in their own right. Glad you also find it
useful. I will CC you on it for next spin.

thanks,

 - Joel


WARNING: multiple messages have this Message-ID (diff)
From: joel at joelfernandes.org (Joel Fernandes)
Subject: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Thu, 28 Feb 2019 14:10:36 -0500	[thread overview]
Message-ID: <20190228191036.GA203889@google.com> (raw)
In-Reply-To: <b100f0a2-7966-b6a2-dcd5-ca11abe57ead@arm.com>

On Thu, Feb 28, 2019 at 05:04:59PM +0100, Dietmar Eggemann wrote:
[...]                      ^
> kernel/kheaders_data.h:1:1: note: in expansion of macro ‘KH_MAGIC_END’
>  KH_MAGIC_END;
>  ^~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:38:12: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>             kernel_headers_data + KH_MAGIC_SIZE,
>             ^~~~~~~~~~~~~~~~~~~
>             kernel_headers_data_size
> kernel/kheaders.c:38:12: note: each undeclared identifier is reported only
> once for each function it appears in
> kernel/kheaders.c: In function ‘ikheaders_init’:
> kernel/kheaders.c:31:10: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>   (sizeof(kernel_headers_data) - 1 - KH_MAGIC_SIZE * 2)
>           ^
> kernel/kheaders.c:57:23: note: in expansion of macro
> ‘kernel_headers_data_size’
>   proc_set_size(entry, kernel_headers_data_size);
>                        ^~~~~~~~~~~~~~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:40:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>  }
> 
> 
> The reason for me to stay on v4.20 is that with v5.0-rc8 I don't have ebpf
> 'raw tracepoint' support any more on my arm64 board. But this issue is not
> related to your patch though.

I'm glad mainline fixed your issue though as you said in the other thread ;-)
I will refer to your email here later when doing backports if I hit the issue.

> Another point which supports the functionality your patch provides is the
> fact that maintainers don't want to see new TRACE_EVENTs in their code. So
> here your patch comes handy when using ebpf for tracing in embedded
> environments.

Yes, I agree. One can also use the series to build custom kernel modules
which can also contain tracepoints in their own right. Glad you also find it
useful. I will CC you on it for next spin.

thanks,

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: joel@joelfernandes.org (Joel Fernandes)
Subject: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Thu, 28 Feb 2019 14:10:36 -0500	[thread overview]
Message-ID: <20190228191036.GA203889@google.com> (raw)
Message-ID: <20190228191036.JvPgOo49EwUOM03ly0t2WnS9dvwV-n06iKfsW7TpTko@z> (raw)
In-Reply-To: <b100f0a2-7966-b6a2-dcd5-ca11abe57ead@arm.com>

On Thu, Feb 28, 2019@05:04:59PM +0100, Dietmar Eggemann wrote:
[...]                      ^
> kernel/kheaders_data.h:1:1: note: in expansion of macro ‘KH_MAGIC_END’
>  KH_MAGIC_END;
>  ^~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:38:12: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>             kernel_headers_data + KH_MAGIC_SIZE,
>             ^~~~~~~~~~~~~~~~~~~
>             kernel_headers_data_size
> kernel/kheaders.c:38:12: note: each undeclared identifier is reported only
> once for each function it appears in
> kernel/kheaders.c: In function ‘ikheaders_init’:
> kernel/kheaders.c:31:10: error: ‘kernel_headers_data’ undeclared (first use
> in this function); did you mean ‘kernel_headers_data_size’?
>   (sizeof(kernel_headers_data) - 1 - KH_MAGIC_SIZE * 2)
>           ^
> kernel/kheaders.c:57:23: note: in expansion of macro
> ‘kernel_headers_data_size’
>   proc_set_size(entry, kernel_headers_data_size);
>                        ^~~~~~~~~~~~~~~~~~~~~~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:40:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>  }
> 
> 
> The reason for me to stay on v4.20 is that with v5.0-rc8 I don't have ebpf
> 'raw tracepoint' support any more on my arm64 board. But this issue is not
> related to your patch though.

I'm glad mainline fixed your issue though as you said in the other thread ;-)
I will refer to your email here later when doing backports if I hit the issue.

> Another point which supports the functionality your patch provides is the
> fact that maintainers don't want to see new TRACE_EVENTs in their code. So
> here your patch comes handy when using ebpf for tracing in embedded
> environments.

Yes, I agree. One can also use the series to build custom kernel modules
which can also contain tracepoints in their own right. Glad you also find it
useful. I will CC you on it for next spin.

thanks,

 - Joel

  parent reply	other threads:[~2019-02-28 19:10 UTC|newest]

Thread overview: 87+ 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 ` Joel Fernandes (Google)
2019-02-27 19:37 ` joel
2019-02-27 19:37 ` [PATCH v3 2/2] Add selftests for module build using in-kernel headers Joel Fernandes (Google)
2019-02-27 19:37   ` Joel Fernandes (Google)
2019-02-27 19:37   ` joel
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  2:17   ` Masahiro Yamada
2019-02-28  2:17   ` yamada.masahiro
2019-02-28 14:43   ` Joel Fernandes
2019-02-28 14:43     ` Joel Fernandes
2019-02-28 14:43     ` joel
2019-02-28 23:27     ` Joel Fernandes
2019-02-28 23:27       ` Joel Fernandes
2019-02-28 23:27       ` joel
2019-03-01  6:25     ` Masahiro Yamada
2019-03-01  6:25       ` Masahiro Yamada
2019-03-01  6:25       ` yamada.masahiro
2019-03-01 17:19       ` Joel Fernandes
2019-03-01 17:19         ` Joel Fernandes
2019-03-01 17:19         ` joel
2019-03-02  2:13         ` Masahiro Yamada
2019-03-02  2:13           ` Masahiro Yamada
2019-03-02  2:13           ` yamada.masahiro
2019-03-02  2:39           ` Joel Fernandes
2019-03-02  2:39             ` Joel Fernandes
2019-03-02  2:39             ` joel
2019-03-04  5:40             ` Masahiro Yamada
2019-03-04  5:40               ` Masahiro Yamada
2019-03-04  5:40               ` yamada.masahiro
2019-02-28  8:34 ` Masami Hiramatsu
2019-02-28  8:34   ` Masami Hiramatsu
2019-02-28  8:34   ` mhiramat
2019-02-28 15:00   ` Joel Fernandes
2019-02-28 15:00     ` Joel Fernandes
2019-02-28 15:00     ` joel
2019-02-28 15:30     ` Greg KH
2019-02-28 15:30       ` Greg KH
2019-02-28 15:30       ` gregkh
2019-02-28 15:37       ` Joel Fernandes
2019-02-28 15:37         ` Joel Fernandes
2019-02-28 15:37         ` joel
2019-02-28 15:45         ` Greg KH
2019-02-28 15:45           ` Greg KH
2019-02-28 15:45           ` gregkh
2019-02-28 15:59           ` Joel Fernandes
2019-02-28 15:59             ` Joel Fernandes
2019-02-28 15:59             ` joel
2019-02-28 16:09           ` Steven Rostedt
2019-02-28 16:09             ` Steven Rostedt
2019-02-28 16:09             ` rostedt
2019-03-01  2:28     ` Masami Hiramatsu
2019-03-01  2:28       ` Masami Hiramatsu
2019-03-01  2:28       ` mhiramat
2019-03-01  3:26       ` Joel Fernandes
2019-03-01  3:26         ` Joel Fernandes
2019-03-01  3:26         ` joel
2019-03-01  7:03         ` Masami Hiramatsu
2019-03-01  7:03           ` Masami Hiramatsu
2019-03-01  7:03           ` mhiramat
2019-03-01 17:21           ` Joel Fernandes
2019-03-01 17:21             ` Joel Fernandes
2019-03-01 17:21             ` joel
2019-03-01 11:05         ` Qais Yousef
2019-03-01 11:05           ` Qais Yousef
2019-03-01 11:05           ` qais.yousef
2019-02-28 13:53 ` Qais Yousef
2019-02-28 13:53   ` Qais Yousef
2019-02-28 13:53   ` qais.yousef
2019-02-28 14:47   ` Joel Fernandes
2019-02-28 14:47     ` Joel Fernandes
2019-02-28 14:47     ` joel
2019-02-28 16:04     ` Dietmar Eggemann
2019-02-28 16:04       ` Dietmar Eggemann
2019-02-28 16:04       ` dietmar.eggemann
2019-02-28 16:22       ` Qais Yousef
2019-02-28 16:22         ` Qais Yousef
2019-02-28 16:22         ` qais.yousef
2019-02-28 16:48       ` Qais Yousef
2019-02-28 16:48         ` Qais Yousef
2019-02-28 16:48         ` qais.yousef
2019-02-28 18:36         ` Dietmar Eggemann
2019-02-28 18:36           ` Dietmar Eggemann
2019-02-28 18:36           ` dietmar.eggemann
2019-02-28 19:10       ` Joel Fernandes [this message]
2019-02-28 19:10         ` Joel Fernandes
2019-02-28 19:10         ` joel

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=20190228191036.GA203889@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=dietmar.eggemann@arm.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 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.