[PATCH RESEND] migrate: Wrap CONFIG_DEVICE_PRIVATE dependent function declarations with ifdef

[PATCH RESEND] migrate: Wrap CONFIG_DEVICE_PRIVATE dependent function declarations with ifdef

[SeongJae Park]

'migrate_vma_{setup,pages,finalize}()' functions are defined under
CONFIG_DEVICE_PRIVATE, but their declarations are not.  This commit
wraps the declaration under the config to minimize confusion.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 include/linux/migrate.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 66a34eae8cb6..f8fa7db83e23 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -162,9 +162,14 @@ struct migrate_vma {
 	unsigned long		flags;
 };
 
+#ifdef CONFIG_DEVICE_PRIVATE
+
 int migrate_vma_setup(struct migrate_vma *args);
 void migrate_vma_pages(struct migrate_vma *migrate);
 void migrate_vma_finalize(struct migrate_vma *migrate);
+
+#endif /* CONFIG_DEVICE_PRIVATE */
+
 int next_demotion_node(int node);
 
 #else /* CONFIG_MIGRATION disabled: */
-- 
2.17.1

Re: [PATCH RESEND] migrate: Wrap CONFIG_DEVICE_PRIVATE dependent function declarations with ifdef

[Andrew Morton]

On Wed,  9 Feb 2022 09:47:53 +0000 SeongJae Park <sj@kernel.org> wrote:

> 'migrate_vma_{setup,pages,finalize}()' functions are defined under
> CONFIG_DEVICE_PRIVATE, but their declarations are not.  This commit
> wraps the declaration under the config to minimize confusion.
> 
> ...
>
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -162,9 +162,14 @@ struct migrate_vma {
>  	unsigned long		flags;
>  };
>  
> +#ifdef CONFIG_DEVICE_PRIVATE
> +
>  int migrate_vma_setup(struct migrate_vma *args);
>  void migrate_vma_pages(struct migrate_vma *migrate);
>  void migrate_vma_finalize(struct migrate_vma *migrate);
> +
> +#endif /* CONFIG_DEVICE_PRIVATE */
> +

We often don't do this.  The advantage is that errors are revealed at
compile time rather than at link time.  But the downside is quite a lot
of maintenance overhead and messier-looking header files.

And that maintenance overhead is significant, partly because we can get
this wrong but the kernel will still happily compile and boot!  So the
only way to maintain these things is by inspection.