Messages in this thread | | | Date | Tue, 22 Nov 2022 10:20:44 -0800 | From | "Paul E. McKenney" <> | Subject | Re: next-20221122: tinyconfig: ppc n s390: kernel/printk/printk.c:95:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Werror,-Wimplicit-int] |
| |
On Tue, Nov 22, 2022 at 04:55:26PM +0100, Petr Mladek wrote: > On Tue 2022-11-22 16:33:39, John Ogness wrote: > > On 2022-11-22, "Paul E. McKenney" <paulmck@kernel.org> wrote: > > >> @paulmck: Do you have a problem with permanently activating CONFIG_SRCU? > > > > > > The people wanting it separate back in the day were those wanting very > > > tiny kernels. I have not heard from them in a long time, so maybe it > > > is now OK to just make SRCU unconditional. > > > > Who decides this? Or maybe I should create a semaphore-based Variant of > > console_srcu_read_lock()/console_srcu_read_unlock() for the > > "!CONFIG_PRINTK && !CONFIG_SRCU" case? > > I would prefer to avoid it. It would require keeping this in mind. > Semaphore behaves very differently than srcu_read_lock (deadlocks, > nesting). > > I am not sure how much the tiny SRCU would increase the size of > the kernel. I doubt that it would be more that what printk() > added by the various per-CPU and per-console buffers. > > Well, another question is why we actually need to register the consoles > at all for !CONFIG_PRINTK. Only reasons come to my mind: > > + /dev/console > + preventing double registration/unregistration (initialization) > > I could imagine to handle these two use-cases a special way > on tiny systems. But I would do it only when anyone complains.
Tiny SRCU is indeed tiny.
And given the large number of "select SRCU" statements out there, I doubt that there are very many Linux kernels running in production without SRCU. Very likely none at all, actually.
I will put together a patch series.
Thanx, Paul
| |