All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dan Raymond <draymond@foxvalley.net>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com
Subject: Re: [PATCH v1] arch/x86: port I/O tracing on x86
Date: Tue, 19 Sep 2023 23:12:14 +0200	[thread overview]
Message-ID: <20230919211214.GE424@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <a5c505d1-730c-912c-3c83-1df83d8e264b@foxvalley.net>

On Tue, Sep 19, 2023 at 01:56:15PM -0600, Dan Raymond wrote:
> > No, very much no.
> > 
> > This sticks tracing in the very rawest of raw output paths.
> 
> That's the point.  Tracing is a low level debug tool that can be
> used to debug the kernel itself.  If you don't trace all port I/O
> then you are bound to miss something important while debugging.
> 
> > This means I can no longer use early_console->write() to print to my
> > early_serial_console.
> 
> Why not?  Did you try it?

I have tried debugging the kernel for the last 15+ years. The only
reliable way to get something out of the machine is outb on the serial
port. Anything else is a waste of time..

Adding tracing to it (which relies on RCU, which might not be alive at
this point) which might itself be the problem, is a total no-go.

You do not wreck early_serial_console.

> > That is the one and only fully reliably output path we have. You're not
> > sticking tracing in it.
> 
> Keep in mind that tracing is optional.  It can be turned off using
> CONFIG_TRACEPOINTS.

Nobody ever does that. Also, tracepoints in general are useful.

  reply	other threads:[~2023-09-19 21:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 17:55 [PATCH v1] arch/x86: port I/O tracing on x86 Dan Raymond
2023-09-19 17:26 ` kernel test robot
2023-09-19 19:30   ` Dan Raymond
2023-09-20  0:31     ` Dan Raymond
2023-09-19 17:26 ` kernel test robot
2023-09-19 19:43 ` Peter Zijlstra
2023-09-19 19:56   ` Dan Raymond
2023-09-19 21:12     ` Peter Zijlstra [this message]
2023-09-19 21:31       ` Dan Raymond
2023-09-19 22:43         ` Dan Raymond
2023-09-21 17:07           ` Dan Raymond
2023-09-25 21:10 ` Dan Raymond

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=20230919211214.GE424@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=draymond@foxvalley.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --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 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.