linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	tglx@linutronix.de, peterz@infradead.org,
	linux-usb@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Date: Fri, 17 Mar 2017 10:37:30 +0800	[thread overview]
Message-ID: <58CB4BEA.8020606@linux.intel.com> (raw)
In-Reply-To: <20170316071704.GA4237@gmail.com>

Hi Ingo,

On 03/16/2017 03:17 PM, Ingo Molnar wrote:
> * Lu Baolu <baolu.lu@linux.intel.com> wrote:
>
>> Hi Ingo,
>>
>> On 03/02/2017 02:40 PM, Ingo Molnar wrote:
>>> * Lu Baolu <baolu.lu@linux.intel.com> wrote:
>>>
>>>> Hi Ingo,
>>>>
>>>> How about this version? Any further comments?
>>> So I have re-read the review feedback I gave on Jan 19 and found at least one 
>>> thing I pointed out that you didn't address in the latest patches ...
>> Do you mind telling me which one is not addressed? Is it one of below
>> feedbacks?
> So one piece of feedback I gave was:
>
> | BTW., just a side note, some kernel developers (like PeterZ - and I do it 
> | sometimes too) remap early_printk to printk permanently and use it as their main 
> | printk facility - because printk() reliability has suffered over the last couple 
> | of years.
> |
> | So it's more than just early boot debugging - it's a very simple state-less 
> | logging facility to an external computer.
>
> But the latest Kconfig help text still says this:
>
> +config EARLY_PRINTK_USB_XDBC
> +       bool "Early printk via the xHCI debug port"
> +       depends on EARLY_PRINTK && PCI
> +       select EARLY_PRINTK_USB
> +       ---help---
> +         Write kernel log output directly into the xHCI debug port.
> +
> +         This is useful for kernel debugging when your machine crashes very
> +         early before the console code is initialized. For normal operation
> +         it is not recommended because it looks ugly and doesn't cooperate
> +         with klogd/syslogd or the X server. You should normally N here,
> +         unless you want to debug such a crash.
>
> ... while in reality it's an alternative lockless logging facility that goes way 
> beyond debugging early boot crashes!
>
> Granted, I qualified that with 'just a side note'. I guess something like this 
> would work:
>
> +         One use for this feature is kernel debugging, for example when your 
> +	  machine crashes very early before the regular console code is 
> +	  initialized. Other uses include simpler, lockless logging instead of a 
> +	  full-blown printk console driver + klogd.
> +
> +	  For normal production environments this is normally not recommended,
> +	  because it doesn't feed events into klogd/syslogd and doesn't try to
> +	  print anything on the screen.
> +
> +	  You should normally N here, unless you want to debug early crashes or 
> +	  need a very simple printk logging facility.

Very appreciated for pointing this out. I will replace it.

>
> Another piece of feedback I gave was:
>
>>> +config USB_EARLY_PRINTK
>>> +     bool
>> Also, could we standardize the nomencalture to not be a mixture of prefixes and 
>> postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig 
>> space) and rename this one to EARLY_PRINTK_USB or so?
> yet your latest submission still includes the very same postfixed config switch 
> name that collides with the prefixed names such as EARLY_PRINTK_USB:
>
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO
>  config USB_EHCI_BIG_ENDIAN_DESC
>         bool
>  
> +config USB_EARLY_PRINTK
> +       bool
> +
>  menuconfig USB_SUPPORT
>         bool "USB support"
>         depends on HAS_IOMEM
>
> The problem I tried to point out with my review feedback is that we thus have 
> both:
>
> 	CONFIG_EARLY_PRINTK_USB=y
> 	CONFIG_USB_EARLY_PRINTK=y
>
> ... which is confusing at the very least.
>
> On a second look, this config switch appears to be unused - is it a leftover from 
> earlier patches?

Yes, it is a leftover from the earlier patches. I should remove it.
Sorry about it.

>
> The patches don't look too bad otherwise, so we are not far from having something 
> acceptable, IMHO.
>

Thanks.

For the typo and grammar issues, I will recheck the patches and ask some
English speakers for review.

Best regards,
Lu Baolu

      reply	other threads:[~2017-03-17  2:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14  2:27 [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port Lu Baolu
2017-02-14  2:27 ` [PATCH v7 1/5] x86: add simple udelay calibration Lu Baolu
2017-02-14  9:23   ` Sergei Shtylyov
2017-02-15  2:33     ` Lu Baolu
2017-02-14  2:27 ` [PATCH v7 2/5] usb: dbc: early driver for xhci debug capability Lu Baolu
2017-02-14  2:27 ` [PATCH v7 3/5] x86: add support for earlyprintk via USB3 debug port Lu Baolu
2017-02-14  2:27 ` [PATCH v7 4/5] usb: serial: add dbc debug device support to usb_debug Lu Baolu
2017-02-14  2:27 ` [PATCH v7 5/5] usb: doc: add document for USB3 debug port usage Lu Baolu
     [not found]   ` <CAL411-o5xaA+awYi9zEZog1zCZvMCvNQ0i0R7yh24_zrTuu4gQ@mail.gmail.com>
2017-02-14  4:41     ` Lu Baolu
2017-02-14  6:13       ` Peter Chen
2017-02-14  7:20         ` Lu Baolu
2017-03-02  2:17 ` [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port Lu Baolu
2017-03-02  6:40   ` Ingo Molnar
2017-03-03  8:22     ` Lu Baolu
2017-03-16  7:17       ` Ingo Molnar
2017-03-17  2:37         ` Lu Baolu [this message]

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=58CB4BEA.8020606@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).