From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
Josh Triplett <josh@joshtriplett.org>,
kvm-ppc@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Paul Mackerras <paulus@ozlabs.org>,
rcu@vger.kernel.org
Subject: Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
Date: Sat, 25 May 2019 18:18:18 +0000 [thread overview]
Message-ID: <20190525181818.GA225569@google.com> (raw)
In-Reply-To: <20190525181407.GA220326@google.com>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
[snip]
> > That aside, if we are going to change the name of an API that is
> > used 160 places throughout the tree, we would need to have a pretty
> > good justification. Without such a justification, it will just look
> > like pointless churn to the various developers and maintainers on the
> > receiving end of the patches.
>
> Actually, the API name change is not something I want to do, it is Steven
> suggestion. My suggestion is let us just delete _raw_notrace and just use the
> _raw API for tracing, since _raw doesn't do any tracing anyway. Steve pointed
> that _raw_notrace does sparse checking unlike _raw, but I think that isn't an
> issue since _raw doesn't do such checking at the moment anyway.. (if possible
> check my cover letter again for details/motivation of this series).
Come to think of it, if we/I succeed in adding lockdep checking in _raw, then
we can just keep the current APIs and not delete anything. And we can have
_raw_notrace skip the lockdep checks. The sparse check question would still
be an open one though, since _raw doesn't do sparse checks at the moment
unlike _raw_notrace as Steve pointed.
Thanks,
- Joel
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
Josh Triplett <josh@joshtriplett.org>,
kvm-ppc@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Paul Mackerras <paulus@ozlabs.org>,
rcu@vger.kernel.org
Subject: Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
Date: Sat, 25 May 2019 14:18:18 -0400 [thread overview]
Message-ID: <20190525181818.GA225569@google.com> (raw)
In-Reply-To: <20190525181407.GA220326@google.com>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
[snip]
> > That aside, if we are going to change the name of an API that is
> > used 160 places throughout the tree, we would need to have a pretty
> > good justification. Without such a justification, it will just look
> > like pointless churn to the various developers and maintainers on the
> > receiving end of the patches.
>
> Actually, the API name change is not something I want to do, it is Steven
> suggestion. My suggestion is let us just delete _raw_notrace and just use the
> _raw API for tracing, since _raw doesn't do any tracing anyway. Steve pointed
> that _raw_notrace does sparse checking unlike _raw, but I think that isn't an
> issue since _raw doesn't do such checking at the moment anyway.. (if possible
> check my cover letter again for details/motivation of this series).
Come to think of it, if we/I succeed in adding lockdep checking in _raw, then
we can just keep the current APIs and not delete anything. And we can have
_raw_notrace skip the lockdep checks. The sparse check question would still
be an open one though, since _raw doesn't do sparse checks at the moment
unlike _raw_notrace as Steve pointed.
Thanks,
- Joel
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: rcu@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
Date: Sat, 25 May 2019 14:18:18 -0400 [thread overview]
Message-ID: <20190525181818.GA225569@google.com> (raw)
In-Reply-To: <20190525181407.GA220326@google.com>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
[snip]
> > That aside, if we are going to change the name of an API that is
> > used 160 places throughout the tree, we would need to have a pretty
> > good justification. Without such a justification, it will just look
> > like pointless churn to the various developers and maintainers on the
> > receiving end of the patches.
>
> Actually, the API name change is not something I want to do, it is Steven
> suggestion. My suggestion is let us just delete _raw_notrace and just use the
> _raw API for tracing, since _raw doesn't do any tracing anyway. Steve pointed
> that _raw_notrace does sparse checking unlike _raw, but I think that isn't an
> issue since _raw doesn't do such checking at the moment anyway.. (if possible
> check my cover letter again for details/motivation of this series).
Come to think of it, if we/I succeed in adding lockdep checking in _raw, then
we can just keep the current APIs and not delete anything. And we can have
_raw_notrace skip the lockdep checks. The sparse check question would still
be an open one though, since _raw doesn't do sparse checks at the moment
unlike _raw_notrace as Steve pointed.
Thanks,
- Joel
next prev parent reply other threads:[~2019-05-25 18:18 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-24 23:49 [PATCH RFC 0/5] Remove some notrace RCU APIs Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` [PATCH RFC 1/5] powerpc: Use regular rcu_dereference_raw API Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` [PATCH RFC 2/5] trace: " Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` [PATCH RFC 3/5] hashtable: Use the regular hlist_for_each_entry_rcu API Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` [PATCH RFC 4/5] rculist: Remove hlist_for_each_entry_rcu_notrace since no users Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-26 16:20 ` Miguel Ojeda
2019-05-26 16:20 ` Miguel Ojeda
2019-05-26 16:20 ` Miguel Ojeda
2019-05-24 23:49 ` [PATCH RFC 5/5] rcu: Remove rcu_dereference_raw_notrace " Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-24 23:49 ` Joel Fernandes (Google)
2019-05-25 3:24 ` [PATCH RFC 0/5] Remove some notrace RCU APIs Steven Rostedt
2019-05-25 3:24 ` Steven Rostedt
2019-05-25 3:24 ` Steven Rostedt
2019-05-25 8:14 ` Joel Fernandes
2019-05-25 8:14 ` Joel Fernandes
2019-05-25 8:14 ` Joel Fernandes
2019-05-25 11:08 ` Steven Rostedt
2019-05-25 11:08 ` Steven Rostedt
2019-05-25 11:08 ` Steven Rostedt
2019-05-25 14:19 ` Joel Fernandes
2019-05-25 14:19 ` Joel Fernandes
2019-05-25 14:19 ` Joel Fernandes
2019-05-25 15:50 ` Paul E. McKenney
2019-05-25 15:50 ` Paul E. McKenney
2019-05-25 15:50 ` Paul E. McKenney
2019-05-25 18:14 ` Joel Fernandes
2019-05-25 18:14 ` Joel Fernandes
2019-05-25 18:14 ` Joel Fernandes
2019-05-25 18:18 ` Joel Fernandes [this message]
2019-05-25 18:18 ` Joel Fernandes
2019-05-25 18:18 ` Joel Fernandes
2019-05-28 12:24 ` Paul E. McKenney
2019-05-28 12:24 ` Paul E. McKenney
2019-05-28 12:24 ` Paul E. McKenney
2019-05-28 19:00 ` Joel Fernandes
2019-05-28 19:00 ` Joel Fernandes
2019-05-28 19:00 ` Joel Fernandes
2019-05-28 20:00 ` Paul E. McKenney
2019-05-28 20:00 ` Paul E. McKenney
2019-05-28 20:00 ` Paul E. McKenney
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=20190525181818.GA225569@google.com \
--to=joel@joelfernandes.org \
--cc=benh@kernel.crashing.org \
--cc=corbet@lwn.net \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.ibm.com \
--cc=paulus@ozlabs.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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.