From: Petr Mladek <pmladek@suse.com>
To: Pierre Kuo <vichy.kuo@gmail.com>
Cc: sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
linux-kernel@vger.kernel.org, joe@perches.com
Subject: Re: [PATCH] printk: Modify operators of printed_len
Date: Mon, 10 Jul 2017 15:51:44 +0200 [thread overview]
Message-ID: <20170710135144.GN23069@pathway.suse.cz> (raw)
In-Reply-To: <1499482273-10638-1-git-send-email-vichy.kuo@gmail.com>
On Sat 2017-07-08 10:51:13, Pierre Kuo wrote:
> In 8b1742c9c207, we remove printk-recursion detection code in
> vprintk_emit(), where it is the first place that printed_len calculated.
> After removing above detection, it seems we can directly assign the
> result of log_output to printed_len.
>
> Signed-off-by: Pierre Kuo <vichy.kuo@gmail.com>
Great catch!
I just noticed that the same applies also to text_len
variable. Well, it was caused by another commit ddb9baa822265b55
("printk: report lost messages in printk safe/nmi contexts").
Could you please send a patch for this as well?
I would personally fix both variables in a single patch. But
I do not have a strong opinion about it.
This seems to be your first patch sent to the kernel mailing list.
Let me share some hints that might help you to handle more complex
patchsets ;-)
There is a standard format how to reference older commits. It is
'commit <12+ chars of sha1> ("<title line>")', see my comment above
for an example.
A good practice is to run ./scripts/checkpatch.pl <patch> before
you send the patch. Well, you need to use a common sense and ignore
false positives or hints that make a particular patch less readable
in the end.
Also it is handy to bump the version of the patch when it is
updated, e.g. use [PATCH v2] in the subject. People also
summarize changes against the previous version(s) below
the --- line. Well, this is more useful when there is a longer
delay between the versions and the changes are more complicated.
Best Regards,
Petr
next prev parent reply other threads:[~2017-07-10 13:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-08 2:51 Pierre Kuo
2017-07-08 5:12 ` Sergey Senozhatsky
2017-07-10 13:51 ` Petr Mladek [this message]
2017-07-11 4:00 ` pierre kuo
-- strict thread matches above, loose matches on Subject: below --
2017-07-07 16:30 Pierre Kuo
2017-07-07 17:12 ` Joe Perches
2017-07-07 20:32 ` pierre kuo
2017-07-07 23:03 ` Joe Perches
2017-07-08 2:49 ` pierre kuo
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=20170710135144.GN23069@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=vichy.kuo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®