andreas.dilger at intel.com
Tue Jun 9 18:41:35 PDT 2015
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