[LU-1298] lustre needs to be built with #undef LIBCFS_DEBUG occasionally

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.0.0
• Type: Bug
• Priority: Minor
• Reporter: Bruce Korb (Inactive)
• Assignee: WC Triage
• Resolution: Incomplete

Environment

Build.

• Severity: 3

Description

When LIBCFS_DEBUG is not defined, neither will be ldlm_lock_debug.
Unclear when this was introduced. 2008 seems like long ago.

#ifdef LIBCFS_DEBUG
#define ldlm_lock_debug(msgdata, mask, cdls, lock, fmt, a...) do {[...]
#else /* !LIBCFS_DEBUG */

1. define LDLM_DEBUG(lock, fmt, a...) ((void)0)
2. define LDLM_ERROR(lock, fmt, a...) ((void)0)
3. define ldlm_lock_debuf(cdls, level, lock, file, func, line, fmt, a...) \
   ((void)0)
   #endif

10beeaac (nikita 2008-10-18 15:13:21 +0000 927) # define ldlm_lock_debuf(cdls, level, lock, file, func, line, fmt, a...) \
10beeaac (nikita 2008-10-18 15:13:21 +0000 928) ((void)0)

Comments

[Bruce Korb (Inactive)]

Hmmm. That's a very clever program, that Jira. That enumeration in the description is actually a quote of a series of "#define" statements, not an enumeration.

[Oleg Drokin]

Please submit a patch.

Also there are more problems with not having LIBCFS_DEBUG not defined that that. There are still some lasserts that execute important code I think. So i nshort running with debug compiled out is not supported ATM and not something we would recommend

[Bruce Korb (Inactive)]

I had guessed that there might be more issues than that. I'm buried in trying to understand ldlm locking on the 1.8 tree so I can cut down lr_lock hold times. (Heart beats are going missing....) So this is a heads up, patch will/may come when I have the right round tuit.

So, clearly building with LIBCFS_DEBUG not defined cannot be supported at the moment, but getting it to compile ought not be a particularly difficult thing to accomplish. Worry over side effects within asserts later.

[Bruce Korb (Inactive)]

Oh, one other detail: unless there is a program put in place to compile the thing once in a while, it'd be a waste of time to fix it. It would just atrophy.

[Andreas Dilger]

I don't think this is a priority. Can be reopened if someone wants to work on this.