Re: [PATCH -next] drivers/base/inode.c: let vmstat_text be optional

[Andrew Morton]

> Subject: [PATCH -next] drivers/base/inode.c: let vmstat_text be optional

The patch-against-next thing always disturbs me.  It implies that the
patch is only needed in linux-next, but often that's wrong.  So I have
to go off and work out what kernel it really is applicable to.

And that's OK, it keeps me healthy.  But two minds are better than one,
and if the originator has already worked this out, they should state it
explicitly, please.

On Thu, 4 Aug 2011 15:22:11 -0700
Randy Dunlap <rdunlap@xxxxxxxxxxxx> wrote:

> From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
> 
> vmstat_text is only available when PROC_FS or SYSFS is enabled.
> This causes build errors in drivers/base/node.c when they are
> both disabled:
> 
> drivers/built-in.o: In function `node_read_vmstat':
> node.c:(.text+0x10e28f): undefined reference to `vmstat_text'
> 
> Rather than litter drivers/base/node.c with #ifdef/#endif around
> the affected lines of code, add macros for optional sysdev
> attributes so that those lines of code will be ignored, without
> using #ifdef/#endif in the .c file(s).  I.e., the ifdeffery
> is done only in a header file with sysdev_create_file_optional()
> and sysdev_remove_file_optional().
> 
> --- linux-next-20110804.orig/include/linux/vmstat.h
> +++ linux-next-20110804/include/linux/vmstat.h
> @@ -258,6 +258,8 @@ static inline void refresh_zone_stat_thr
>  
>  #endif		/* CONFIG_SMP */
>  
> +#if defined(CONFIG_PROC_FS) || defined(CONFIG_SYSFS)
>  extern const char * const vmstat_text[];
> +#endif
>

The ifdef around the declaration isn't needed, really.  If we remove
it then a build-time error becomes a link-time (or even moddep-time) error,
which is a bit of a pain.  But it's less painful than having ifdefs
around squillions of declarations.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/