This is a lot more appropriate than PI_LIST, which in the kernel one would assume that it has to do with priority-inheritance; which is not -- furthermore futexes make use of plists so this can be even more confusing, albeit the debug nature of the config option.
Showing the changes to include/linux (1 of 3 files). Show all
Unified · Split
| @@ -231,7 +231,7 @@ static inline int plist_node_empty(const struct plist_node *node) · 230 unmodified lines | ||
| 231 | 231 | * @type: the type of the struct this is embedded in |
| 232 | 232 | * @member: the name of the list_head within the struct |
| 233 | 233 | */ |
| 234 | −#ifdef CONFIG_DEBUG_PI_LIST | |
| 234 | +#ifdef CONFIG_DEBUG_PLIST | |
| 235 | 235 | # define plist_first_entry(head, type, member) \ |
| 236 | 236 | ({ \ |
| 237 | 237 | WARN_ON(plist_head_empty(head)); \ |
| @@ -248,7 +248,7 @@ static inline int plist_node_empty(const struct plist_node *node) · 10 unmodified lines | ||
| 248 | 248 | * @type: the type of the struct this is embedded in |
| 249 | 249 | * @member: the name of the list_head within the struct |
| 250 | 250 | */ |
| 251 | −#ifdef CONFIG_DEBUG_PI_LIST | |
| 251 | +#ifdef CONFIG_DEBUG_PLIST | |
| 252 | 252 | # define plist_last_entry(head, type, member) \ |
| 253 | 253 | ({ \ |
| 254 | 254 | WARN_ON(plist_head_empty(head)); \ |