linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Ezequiel Garcia <ezequiel@collabora.com>, Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org, kernel@collabora.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu: Lower severity of add/remove device messages
Date: Fri, 27 Mar 2020 18:04:22 +0000	[thread overview]
Message-ID: <6db3bcfb-c778-7190-a936-836eaba4bb73@arm.com> (raw)
In-Reply-To: <9e863f96cd9a188db84ae8bc5a0d49287b4b4922.camel@collabora.com>

On 2020-03-27 1:02 pm, Ezequiel Garcia wrote:
> Hello Joerg,
> 
> Thanks for reviewing.
> 
> I understand this change bears some controversy
> for IOMMU, as developers are probably used to see these
> messages.
> 
> On Fri, 2020-03-27 at 10:50 +0100, Joerg Roedel wrote:
>> On Mon, Mar 23, 2020 at 06:49:56PM -0300, Ezequiel Garcia wrote:
>>> These user messages are not really informational,
>>> but mostly of debug nature. Lower their severity.
>>
>> Like most other messages in the kernel log, that is not a reason to
>> lower the severity.
>>
>> These messages are the first thing to look at when
>> looking into IOMMU related issues.
>>
> 
> Sure, but the messages are still here, you can
> always enable them when you are looking at IOMMU issues :-)

That still begs the question of who "you" is and how they know they're 
debugging an IOMMU issue in the first place. When all the developer has 
to go on is a third-hand bugzilla attachment from a distro user's vague 
report of graphics corruption/poor I/O performance/boot 
failure/whatever, being able to tell straight away from a standard dmesg 
dump whether an IOMMU is even in the picture or not saves a lot of 
protracted back-and-forth for everyone involved.
> The idea is to reduce the amount of verbosity in the kernel.

Under what justification? Users with slow consoles or who just want a 
quiet boot are already free to turn down the loglevel; a handful of 
messages at boot-time and device hotplug seem hardly at risk of drowning 
out all the systemd audit spam anyway. Note that the IOMMU subsystem is 
by nature a little atypical as a lot of what it does is only visible as 
secondary effects on other drivers and subsystems, without their 
explicit involvement or knowledge. In that respect, hiding its activity 
can arguably lead to more non-obvious situations than many other subsystems.

> If all subsystems would print messages that are useful
> when looking at issues, things would be quite nasty verbose.

 From a personal standpoint, can we at least eradicate all the "Hi! I'm 
a driver/subsystem you don't even have the hardware for!" messages 
first, then maybe come back and reconsider the ones that convey actual 
information later?

Robin.

  reply	other threads:[~2020-03-27 18:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 21:49 [PATCH] iommu: Lower severity of add/remove device messages Ezequiel Garcia
2020-03-27  9:50 ` Joerg Roedel
2020-03-27 13:02   ` Ezequiel Garcia
2020-03-27 18:04     ` Robin Murphy [this message]
2020-03-27 22:25       ` Ezequiel Garcia

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=6db3bcfb-c778-7190-a936-836eaba4bb73@arm.com \
    --to=robin.murphy@arm.com \
    --cc=ezequiel@collabora.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.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).