All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: paulmck@kernel.org, Naresh Kamboju <naresh.kamboju@linaro.org>,
	open list <linux-kernel@vger.kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>
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]
Date: Tue, 22 Nov 2022 16:55:26 +0100	[thread overview]
Message-ID: <Y3zw7nv5KJ32P4FG@alley> (raw)
In-Reply-To: <87leo3ovpw.fsf@jogness.linutronix.de>

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.

Best Regards,
Petr

  reply	other threads:[~2022-11-22 15:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22  9:08 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] Naresh Kamboju
2022-11-22 14:27 ` John Ogness
2022-11-22 14:48   ` Paul E. McKenney
2022-11-22 15:27     ` John Ogness
2022-11-22 15:55       ` Petr Mladek [this message]
2022-11-22 18:20         ` Paul E. McKenney
2022-11-22 22:00         ` Paul E. McKenney
2022-11-22 22:11           ` Randy Dunlap
2022-11-22 23:14           ` John Ogness
2022-11-22 23:42             ` Paul E. McKenney
2022-11-30  0:18               ` Paul E. McKenney
2022-11-30  8:53                 ` John Ogness
2022-11-30 10:37                   ` Petr Mladek
2022-11-30 21:59                     ` Paul E. McKenney
2022-11-22 16:35       ` 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=Y3zw7nv5KJ32P4FG@alley \
    --to=pmladek@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=nathan@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=senozhatsky@chromium.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.