zram: include linux/err.h
Subsystems (2)
PATCH 1/1 zram: include linux/err.h
The zram driver uses the ERR_PTR macro defined in <linux/err.h> and relies on this header to be included implicitly through other headers, which is not (always) the case on the ARM architecture.
Adding an explicit #include allows us to build the driver in all configurations.
drivers/block/zram/zcomp.c +1 -0
@@ -7,6 +7,7 @@* 2 of the License, or (at your option) any later version. */ +#include <linux/err.h> #include <linux/kernel.h> #include <linux/string.h> #include <linux/slab.h>
Hello Arnd,
Quoted 4 lines · Arnd Bergmann
The zram driver uses the
ERR_PTRmacro defined in <linux/err.h> and relies on this header to be included implicitly through other headers, which is not (always) the case on the ARM architecture.
returned from zcomp ERR_PTR is checked and used in zram_drv.c, should in this case there also be inclusion of err.h in zram_drv.h? if so, it probably makes sense to move inclusion of err.h to zcomp.h, which is included both in zcomp.c and zram_drv.c
Quoted 18 lines
Adding an explicit #include allows us to build the driver in all configurations.
Signed-off-by Arnd Bergmann <[email protected]>drivers/block/zram/zcomp.c +1
-0@@ -7,6 +7,7 @@* 2 of the License, or (at your option) any later version. */ +#include <linux/err.h> #include <linux/kernel.h> #include <linux/string.h> #include <linux/slab.h>
Quoted 11 lines · Sergey Senozhatsky
Quoted 4 lines · Arnd Bergmann
The zram driver uses the
ERR_PTRmacro defined in <linux/err.h> and relies on this header to be included implicitly through other headers, which is not (always) the case on the ARM architecture.returned from zcomp
ERR_PTRis checked and used inzram_drv.c, should in this case there also be inclusion oferr.hinzram_drv.h? if so, it probably makes sense to move inclusion oferr.htozcomp.h, which is included both inzcomp.candzram_drv.c
The normal convention is to only include headers from other headers if that is required by the contents of the header itself.
Following the common conventions, it's better to include linux/err.h in both zram_drv.c and zcomp.c, but not in zram_drv.h.
I didn't do that in my patch, because I only got a build error in one of the two files.
Arnd
Hello Arnd,
Quoted 13 lines · Arnd Bergmann
Quoted 11 lines · Sergey Senozhatsky
Quoted 4 lines · Arnd Bergmann
The zram driver uses the
ERR_PTRmacro defined in <linux/err.h> and relies on this header to be included implicitly through other headers, which is not (always) the case on the ARM architecture.returned from zcomp
ERR_PTRis checked and used inzram_drv.c, should in this case there also be inclusion oferr.hinzram_drv.h? if so, it probably makes sense to move inclusion oferr.htozcomp.h, which is included both inzcomp.candzram_drv.c
Quoted 5 lines
The normal convention is to only include headers from other headers if that is required by the contents of the header itself.
Following the common conventions, it's better to include
linux/err.hin bothzram_drv.candzcomp.c, but not inzram_drv.h.
thanks.
may I ask you to resend the patch with linux/err.h included in both zram_drv.c and zcomp.c?
-ss
Quoted 5 lines
I didn't do that in my patch, because I only got a build error in one of the two files.
Arnd
A message that is not in the archive (sent off-list or not yet received): 20140319013946.GF13475@bbox
Quoted 5 lines · Minchan Kim
Quoted 4 lines · Arnd Bergmann
The zram driver uses the
ERR_PTRmacro defined in <linux/err.h> and relies on this header to be included implicitly through other headers, which is not (always) the case on the ARM architecture.
Quoted 9 lines
Quoted 4 lines
Adding an explicit #include allows us to build the driver in all configurations.
Signed-off-by Arnd Bergmann <[email protected]>Regardless of resend fixing another part Sergey asked,
Acked-by Minchan Kim <[email protected]>
Andrew, could you please apply this one? I'll send a patch to also include err.h in zram_drv shortly.
-ss
Quoted 7 lines
Thanks!
Signature · 2 lines
Kind regards, Minchan Kim