")', 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. Really appreciate hints you provided and I will send the v2 patch soon. Best Regards.

Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbdGKEAO (ORCPT ); Tue, 11 Jul 2017 00:00:14 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:35688 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750795AbdGKEAM (ORCPT ); Tue, 11 Jul 2017 00:00:12 -0400 MIME-Version: 1.0 In-Reply-To: <20170710135144.GN23069@pathway.suse.cz> References: <1499482273-10638-1-git-send-email-vichy.kuo@gmail.com> <20170710135144.GN23069@pathway.suse.cz> From: pierre kuo Date: Tue, 11 Jul 2017 12:00:11 +0800 Message-ID: Subject: Re: [PATCH] printk: Modify operators of printed_len To: Petr Mladek Cc: Sergey Senozhatsky , rostedt@goodmis.org, linux-kernel@vger.kernel.org, Joe Perches Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1133 Lines: 28 hi Petr > 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? sure and it is my pleasure. > > This seems to be your first patch sent to the kernel mailing list. Yes :-) > There is a standard format how to reference older commits. It is > 'commit <12+ chars of sha1> ("")', 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. Really appreciate hints you provided and I will send the v2 patch soon. Best Regards.