All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Joe Perches <joe@perches.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] printk: Move printk_delay to separate file
Date: Fri, 14 Jul 2017 17:57:44 +0200	[thread overview]
Message-ID: <20170714155744.GD32632@pathway.suse.cz> (raw)
In-Reply-To: <df7851a1308425cfa6c09510a1a97dcbce5de981.1499450194.git.joe@perches.com>

On Fri 2017-07-07 11:08:59, Joe Perches wrote:
> printk.c is a huge file with too many local functions for a
> human to read and easily parse.
> 
> Start to separate out bits into smaller files.
> 
> Miscellanea:
> 
> o Rename suppress_message_printing to printk_suppress_message

Some renaming might make sense. But please, do it in a separate patch.
It will make the changes much easier to review.

Some existing names are ugly. But there should be a good reason
to rename them, for example, that the existing one causes confusion.
We should be careful here. Otherwise, it will be a nightmare to
search the history or backport important fixes.

Also note that some variables are exported a strange way for
external utilities line crash, makedumpfile, see
log_buf_vmcoreinfo_setup(). Renaming such variables would
require fixing all the external applications.


> o Add function definitions to printk.h

We should not declare functions in a global header without a reason.
It would allow to use them anywhere and it is not always intended
or even safe.

If we want to make some function available in global, we should
do so in a separate patch with a reasonable explanation.

If we want to share them between kernel/printk/*.c sources,
we should declare them in a local header, e.g.
kernel/printk/internal.h


> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index fc47863f629c..b8e63a5f1558 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1709,8 +1640,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>  		in_sched = true;
>  	}
>  
> -	boot_delay_msec(level);
> -	printk_delay();
> +	printk_delay(level);

This makes me nervous. It is not even documented. Please, do not do
any hidden changes in general! The patch that splits the sources
should only shuffle the code. It might do only some minimal
necessary changes like removing "static" for functions that
newly need to be accessed from other source file.

Best Regards,
Petr

PS: Please, split only the console stuff as a start. It will be
the most helpful thing. Also we are still maintainers beginners.
I would like to start slowly, preferably get some feedback from
more experienced developers, and get one such change into the
mainline before we do many more changes.

  parent reply	other threads:[~2017-07-14 15:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-07 18:08 [PATCH] printk: Move printk_delay to separate file Joe Perches
2017-07-08  5:24 ` Sergey Senozhatsky
2017-07-08  5:44   ` Joe Perches
2017-07-14 15:17     ` Petr Mladek
2017-07-14 15:45       ` Joe Perches
2017-07-14 15:57 ` Petr Mladek [this message]
2017-07-14 16:14   ` Joe Perches

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=20170714155744.GD32632@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.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.