bevans at cray.com
Wed Jun 10 07:01:06 PDT 2015
That much I assumed from context, it just strikes me as a strange way of going about it, since it just adds a second step to change a constant. I figured code reviews would pick that stuff up pretty quickly.
Does using it as a method of identifying unused constants make sense to you?
From: Dilger, Andreas [mailto:andreas.dilger at intel.com]
Sent: Tuesday, June 09, 2015 9:42 PM
To: Ben Evans
Cc: Drokin, Oleg; lustre-devel at lists.lustre.org
Subject: Re: wiretest.c
The point of wiretest.c is that these values should basically never be changed. At compile time these checks should become no-ops unless they have changed, which would be a bug.
On Jun 9, 2015, at 13:49, Ben Evans <bevans at cray.com<mailto:bevans at cray.com>> wrote:
I'm trying to help out with the client code merging into the kernel project. The first thing I dove into was ptlrpc, as it's a space that's been singled out as needing help.
In order to get my head around it, I'm just going through the code, and one of the first things that pops up is wiretest.c, which looks to be checking that things that have been #defined have the values that they are #defined to have, that structures are offset correctly (for a given value of 'correctly') etc.
So, I've started going through wiretest and seeing how much of the things that are defined are actually used in the code, and I find that some just aren't used at all, or at least not in other places than where they're defined, and wiretest. HSM_GHOST_COPY is a good example of it. I can't find any usage in the mainline lustre-release code, or in the drivers/staging/lustre code. Is this the sort of thing that should be flagged for deletion?
Secondly, if the code boils down to:
#define SOME_VAR 10
LASSERT(SOME_VAR == 10);
What's the point from a design perspective other than making it mildly more difficult to change?
Thanks for any help, or insight you can give
More information about the lustre-devel