Re: [PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE

[Andrew Morton]

On Thu, 31 Aug 2017 10:20:46 -0700 Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote:

> The next_id object-allocation functionality was introduced in
> 03f595668017f (ipc: add sysctl to specify desired next object id).
> Given that these new entries are _only_ exported under the
> CONFIG_CHECKPOINT_RESTORE option, there is no point for the
> common case to even know about ->next_id. As such rewrite
> ipc_buildid() such that it can do away with the field as well as
> unnecessary branches when adding a new identifier. The end result
> also better differentiates both cases, so the code ends up being
> cleaner; albeit the small duplications regarding the default case.
> 
> ...
>
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +/*
> + * Specify desired id for next allocated IPC object.
> + */
> +#define ipc_idr_alloc(ids, new)						\
> +	idr_alloc(&(ids)->ipcs_idr, (new),				\
> +		  (ids)->next_id < 0 ? 0: ipcid_to_idx((ids)->next_id), \
> +		  0, GFP_NOWAIT);
> +
> 
> ...
>
> +#else
> +#define ipc_idr_alloc(ids, new)					\
> +	idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT);
> +
> ...

Not a fan of checkpatch, I see...

--- a/ipc/util.c~sysvipc-unteach-ids-next_id-for-checkpoint_restore-checkpatch-fixes
+++ a/ipc/util.c
@@ -223,8 +223,8 @@ int ipc_get_maxid(struct ipc_ids *ids)
  */
 #define ipc_idr_alloc(ids, new)						\
 	idr_alloc(&(ids)->ipcs_idr, (new),				\
-		  (ids)->next_id < 0 ? 0: ipcid_to_idx((ids)->next_id), \
-		  0, GFP_NOWAIT);
+		  (ids)->next_id < 0 ? 0 : ipcid_to_idx((ids)->next_id),\
+		  0, GFP_NOWAIT)
 
 static inline int ipc_buildid(int id, struct ipc_ids *ids,
 			      struct kern_ipc_perm *new)
@@ -243,7 +243,7 @@ static inline int ipc_buildid(int id, st
 
 #else
 #define ipc_idr_alloc(ids, new)					\
-	idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT);
+	idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT)
 
 static inline int ipc_buildid(int id, struct ipc_ids *ids,
 			      struct kern_ipc_perm *new)

Did these "functions" *have* to be implemented in cpp?  Wouldn't they
be better in C?