From: J William Piggott <elseifthen@gmx.com>
To: kerolasa@gmail.com
Cc: Karel Zak <kzak@redhat.com>, util-linux <util-linux@vger.kernel.org>
Subject: Re: [PATCH 2/2] hwclock: fix debug regression
Date: Sun, 19 Nov 2017 15:09:43 -0500 [thread overview]
Message-ID: <2e56d19b-e8e8-576c-c071-92e181162512@gmx.com> (raw)
In-Reply-To: <CAG27Bk2rXPKTyz=qEzns5zmJVUoWZUOa0KSHSTzD-1JWz9t70A@mail.gmail.com>
On 11/19/2017 04:51 AM, Sami Kerola wrote:
> That is probably fine as intermediate issue fix. It would be nice to
> see in longer term move to use debug.h. Then ctl->debug could
> be made single bit switch that turns on messaging it does, and
> all internal developer debugging stuff would be done with
> HWCLOCK_DEBUG_ bits. Assuming done this way adding more
> debuging levels is appropriate.
>
> FYI login-utils/su-common.c is pretty good DBG example.
>
Hi Sami, I agree and so does Karel. He brought it up when I first
started contributing to ul back in 2014.
https://marc.info/?l=util-linux-ng&m=141415311703313&w=2
Karel Zak wrote:
> Good point, then it would be better to [keep] --debug independent on
> HWCLOCK_DEBUG=.
>
> But I still think that for so complex tool like hwclock we need a
> real debug output for developers / bug reporters. The current --debug
> is more like --verbose we have in another tools.
It's on my radar and TODO list. I just do not know when I will get to
it. I've been trying to reduce the current 'debug' output as I go.
Hopefully that will make splitting verbose/debug and adding debug.h easier.
next prev parent reply other threads:[~2017-11-19 20:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-18 21:19 [PATCH 0/2] Pull Request J William Piggott
2017-11-18 21:20 ` [PATCH 1/2] hwclock: use reentrant time conversion functions J William Piggott
2017-11-18 21:21 ` [PATCH 2/2] hwclock: fix debug regression J William Piggott
2017-11-19 9:51 ` Sami Kerola
2017-11-19 20:09 ` J William Piggott [this message]
2017-11-20 11:05 ` Karel Zak
2017-11-20 11:08 ` [PATCH 0/2] Pull Request Karel Zak
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=2e56d19b-e8e8-576c-c071-92e181162512@gmx.com \
--to=elseifthen@gmx.com \
--cc=kerolasa@gmail.com \
--cc=kzak@redhat.com \
--cc=util-linux@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