From: Eric Whitney <enwlinux@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, darrick.wong@oracle.com
Subject: current e2fsprogs maint branch test results
Date: Tue, 17 Dec 2013 18:43:13 -0500 [thread overview]
Message-ID: <20131217234313.GA2183@wallace> (raw)
I've built the contents of the current e2fsprogs maint branch (4727c67dc2)
and run make check on both a Pandaboard (ARM) and an x86-64 VM. In each
case I used the following arguments to configure: --disable-uuidd
--disable-libuuid --disable-libblkid.
Both the ARM and x86-64 runs produced warnings when compiling ea_refcount.c
during make check. I posted a patch yesterday (e2fsck: fix printf
conversion specs in ea_refcount.c) that clears those up for me on both
platforms.
The ARM build and make check were otherwise clean.
The x86-64 build and make check contained one more problem - a warning while
compiling debugfs.c:
../../debugfs/debugfs.c:2462:5: warning: too many arguments for format
[-Wformat-extra-args]
This code (commit fe56188b07) is part of that used to check superblock block
numbers specified on the command line, and the error reporting has become
a little fuzzy relative to what we had previously.
Before:
root@debug1:~# debugfs -s 327b /dev/vdc
debugfs 1.42.8 (20-Jun-2013)
debugfs: Bad superblock number - 327b
After:
root@debug1:~# debugfs -s 327b /dev/vdc
debugfs 1.42.8 (20-Jun-2013)
debugfs: Bad block number - 327b
debugfs: Invalid block number: 327b
debugfs: Operation not permitted
Both strtoblk() and parseulonglong() (which it calls) output error messages
for bad/invalid block numbers, which is redundant in this case. The last
(erroneous) error message is output by the call to com_err() which also
causes the warning noted above.
It seems to me that the call to com_err() ought to be deleted, and maybe
the immediately preceding call to strtoblk() ought to be converted to a call
to parseulonglong() to restore the original messaging. I'd like to post a
patch, but there are a number of other calls to strtoblk() in debugfs now
that will produce two messages on errors, and the intent isn't clear to me.
Is this just an area that needed a little more polish?
Thanks,
Eric
next reply other threads:[~2013-12-17 23:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 23:43 Eric Whitney [this message]
2013-12-18 21:36 ` current e2fsprogs maint branch test results Darrick J. Wong
2013-12-23 2:50 ` Eric Whitney
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=20131217234313.GA2183@wallace \
--to=enwlinux@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.