| Message ID | 20230105003813.1770367-7-paulmck@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b2b50d572135c5c6e10c2ff79cd828d5a8141ef6 |
| Headers | show |
| Series | Unconditionally enable SRCU | expand |
On 1/4/23 5:37 PM, Paul E. McKenney wrote: > Now that the SRCU Kconfig option is unconditionally selected, there is > no longer any point in selecting it. Therefore, remove the "select SRCU" > Kconfig statements. I'm assuming something earlier made this true (only CC'ed on this patch, not the cover letter or interesting btis...), then: Reviewed-by: Jens Axboe <axboe@kernel.dk>
On Wed, Jan 04, 2023 at 05:43:07PM -0700, Jens Axboe wrote: > On 1/4/23 5:37 PM, Paul E. McKenney wrote: > > Now that the SRCU Kconfig option is unconditionally selected, there is > > no longer any point in selecting it. Therefore, remove the "select SRCU" > > Kconfig statements. > > I'm assuming something earlier made this true (only CC'ed on this patch, > not the cover letter or interesting btis...), then: I was wondering the same. But it is already unconditionally enabled since commit 0cd7e350abc4 ("rcu: Make SRCU mandatory").
On Thu, Jan 05, 2023 at 09:05:47AM +0100, Heiko Carstens wrote: > On Wed, Jan 04, 2023 at 05:43:07PM -0700, Jens Axboe wrote: > > On 1/4/23 5:37 PM, Paul E. McKenney wrote: > > > Now that the SRCU Kconfig option is unconditionally selected, there is > > > no longer any point in selecting it. Therefore, remove the "select SRCU" > > > Kconfig statements. > > > > I'm assuming something earlier made this true (only CC'ed on this patch, > > not the cover letter or interesting btis...), then: > > I was wondering the same. But it is already unconditionally enabled > since commit 0cd7e350abc4 ("rcu: Make SRCU mandatory"). Ah, apologies for the terseness! I took the coward's way out by making CONFIG_SRCU unconditional during the last merge window and removing all references during this merge window. ;-) Thanx, Paul
On 1/5/23 8:33 AM, Paul E. McKenney wrote: > On Thu, Jan 05, 2023 at 09:05:47AM +0100, Heiko Carstens wrote: >> On Wed, Jan 04, 2023 at 05:43:07PM -0700, Jens Axboe wrote: >>> On 1/4/23 5:37 PM, Paul E. McKenney wrote: >>>> Now that the SRCU Kconfig option is unconditionally selected, there is >>>> no longer any point in selecting it. Therefore, remove the "select SRCU" >>>> Kconfig statements. >>> >>> I'm assuming something earlier made this true (only CC'ed on this patch, >>> not the cover letter or interesting btis...), then: >> >> I was wondering the same. But it is already unconditionally enabled >> since commit 0cd7e350abc4 ("rcu: Make SRCU mandatory"). > > Ah, apologies for the terseness! > > I took the coward's way out by making CONFIG_SRCU unconditional during > the last merge window and removing all references during this merge > window. ;-) Are you intending for maintainers to pick up these patches, or are you collecting acks for sending the series separately? That part is also not clear :-)
On Thu, Jan 05, 2023 at 08:36:43AM -0700, Jens Axboe wrote: > On 1/5/23 8:33 AM, Paul E. McKenney wrote: > > On Thu, Jan 05, 2023 at 09:05:47AM +0100, Heiko Carstens wrote: > >> On Wed, Jan 04, 2023 at 05:43:07PM -0700, Jens Axboe wrote: > >>> On 1/4/23 5:37 PM, Paul E. McKenney wrote: > >>>> Now that the SRCU Kconfig option is unconditionally selected, there is > >>>> no longer any point in selecting it. Therefore, remove the "select SRCU" > >>>> Kconfig statements. > >>> > >>> I'm assuming something earlier made this true (only CC'ed on this patch, > >>> not the cover letter or interesting btis...), then: > >> > >> I was wondering the same. But it is already unconditionally enabled > >> since commit 0cd7e350abc4 ("rcu: Make SRCU mandatory"). > > > > Ah, apologies for the terseness! > > > > I took the coward's way out by making CONFIG_SRCU unconditional during > > the last merge window and removing all references during this merge > > window. ;-) > > Are you intending for maintainers to pick up these patches, or are you > collecting acks for sending the series separately? That part is also > not clear :-) Fair point! Maintainer's choice. By default, I collect acks and send it. But if (for example) this change is in a high-traffic area, the maintainer might want to take it, in which case I drop it from my tree. Either way works for me, as long as you let me know. ;-) Thanx, Paul
diff --git a/block/Kconfig b/block/Kconfig index 444c5ab3b67e2..5d9d9c84d5165 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -6,7 +6,6 @@ menuconfig BLOCK bool "Enable the block layer" if EXPERT default y select SBITMAP - select SRCU help Provide block layer support for the kernel.
Now that the SRCU Kconfig option is unconditionally selected, there is no longer any point in selecting it. Therefore, remove the "select SRCU" Kconfig statements. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org --- block/Kconfig | 1 - 1 file changed, 1 deletion(-)