From: Matthew Wilcox <matthew@wil.cx>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Mariusz Kozlowski <m.kozlowski@tuxland.pl>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: some numbers on macros
Date: Sat, 24 May 2008 12:52:01 -0600 [thread overview]
Message-ID: <20080524185201.GZ2638@parisc-linux.org> (raw)
In-Reply-To: <20080524093350.60e6dc8d@infradead.org>
On Sat, May 24, 2008 at 09:33:50AM -0700, Arjan van de Ven wrote:
> unused macros in common header files are an indication of stale APIs
> otoh.. and might be of some interest. (Same for static inline in
> headers)
Possibly. There's likely to be a lot of macros unused like these ones:
#define PCI_X_CMD_MAX_READ 0x000c /* Max Memory Read Byte Count */
/* Max # of outstanding split transactions */
#define PCI_X_CMD_SPLIT_1 0x0000 /* Max 1 */
#define PCI_X_CMD_SPLIT_2 0x0010 /* Max 2 */
#define PCI_X_CMD_SPLIT_3 0x0020 /* Max 3 */
...
where the macros embody the PCI specification in code -- possibly we
don't use them yet, but if we ever did, we'd have the macros to use.
Another category of false positive is macros that ought to be used,
but the code that ought to be using them has decided to go its own way.
That still indicates a bug, but not the one you might initially think.
In summary, this is probably an interesting exercise, but the results
would need to be interpreted with care.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-05-24 18:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-24 15:48 some numbers on macros Mariusz Kozlowski
2008-05-24 16:33 ` Arjan van de Ven
2008-05-24 18:52 ` Matthew Wilcox [this message]
2008-05-24 23:41 ` Mariusz Kozlowski
2008-05-24 23:46 ` Arjan van de Ven
2008-05-25 9:11 ` Mariusz Kozlowski
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=20080524185201.GZ2638@parisc-linux.org \
--to=matthew@wil.cx \
--cc=arjan@infradead.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.kozlowski@tuxland.pl \
/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