From: Joe Perches <joe@perches.com>
To: Tomasz Figa <tfiga@google.com>,
Hirokazu Honda <hiroh@chromium.org>,
Hans Verkuil <hverkuil@xs4all.nl>
Cc: Pawel Osciak <pawel@osciak.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
Date: Wed, 07 Jun 2017 22:16:22 -0700 [thread overview]
Message-ID: <1496898982.1929.7.camel@perches.com> (raw)
In-Reply-To: <CAAFQd5AnpjwgWkNL1RvOY1C2WR8gqVuCrPQmaRVCwjSvAM2u8Q@mail.gmail.com>
On Thu, 2017-06-08 at 13:39 +0900, Tomasz Figa wrote:
> On Thu, Jun 8, 2017 at 12:24 PM, Hirokazu Honda <hiroh@chromium.org> wrote:
> > Hi,
> >
> > I completely understand bitmask method now.
> > I agree to the idea, but it is necessary to change the specification of
> > a debug parameter.
> > (We probably need to change a document about that?)
> > For example, there is maybe a user who set a debug parameter 3.
> > The user assume that logs whose levels are less than 4 are shown.
> > However, after the bitmask method is adopted, someday the logs whose
> > level is 1 or 2 are only shown, not 3 level logs are not shown.
> > This will be confusing to users.
>
> I think I have to agree with Hirokazu here. Even though it's only
> about debugging, there might be some automatic testing systems that
> actually rely on certain values here.
I think it's a non-argument.
If there automated systems that rely on specific levels, then
changing the levels of individual messages could also cause
those automated systems to fail.
next prev parent reply other threads:[~2017-06-08 5:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 9:49 [PATCH v2] [media] vb2: core: Lower the log level of debug outputs Hirokazu Honda
2017-05-30 10:19 ` Joe Perches
[not found] ` <CAO5uPHO7GwxCTk2OqQA5NfrL0-Jyt5SB-jVpeUA_eCrqR7u5xA@mail.gmail.com>
2017-05-31 2:16 ` Joe Perches
[not found] ` <CAO5uPHPWGABuKf3FuAky2BRx+9E=n-QhZ94RPQ7wEuHAwC1qGg@mail.gmail.com>
2017-05-31 4:06 ` Joe Perches
2017-06-07 9:01 ` Hans Verkuil
2017-06-08 3:24 ` Hirokazu Honda
2017-06-08 4:39 ` Tomasz Figa
2017-06-08 5:16 ` Joe Perches [this message]
2017-06-08 5:24 ` Tomasz Figa
2017-06-08 5:33 ` Joe Perches
2017-06-27 22:57 ` Hirokazu Honda
2017-07-28 13:13 ` Hans Verkuil
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=1496898982.1929.7.camel@perches.com \
--to=joe@perches.com \
--cc=hiroh@chromium.org \
--cc=hverkuil@xs4all.nl \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=pawel@osciak.com \
--cc=tfiga@google.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