Re: __packed vs. __attribute__((packed)) in kernel headers

From: richard -rw- weinberger
Date: Thu Jun 23 2011 - 13:04:27 EST


On Wed, Jun 22, 2011 at 8:34 AM, Markus Trippelsdorf
<markus@xxxxxxxxxxxxxxx> wrote:
> A recent commit 3627924acf70a changed __attribute__ ((packed)) to
> __packed in some UBI headers. This breaks the build of busybox:
>
>  CC      miscutils/ubi_attach_detach.o
> In file included from miscutils/ubi_attach_detach.c:27:0:
> /usr/include/mtd/ubi-user.h:330:3: error: conflicting types for ‘__packed’
> /usr/include/mtd/ubi-user.h:314:3: note: previous declaration of ‘__packed’ was here
> /usr/include/mtd/ubi-user.h:372:3: error: conflicting types for ‘__packed’
> /usr/include/mtd/ubi-user.h:314:3: note: previous declaration of ‘__packed’ was here
> ...
>
> But this kind of change is suggested by checkpatch.pl:
>  WARN("__packed is preferred over __attribute__((packed))\n
>
> One possible solution would be to let the "scripts/headers_install.pl"
> script automatically substitute __packed with __attribute__((packed)):
>
> diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
> index efb3be1..e0dc065 100644
> --- a/scripts/headers_install.pl
> +++ b/scripts/headers_install.pl
> @@ -35,6 +35,7 @@ foreach my $file (@files) {
>                $line =~ s/([\s(])__iomem\s/$1/g;
>                $line =~ s/\s__attribute_const__\s/ /g;
>                $line =~ s/\s__attribute_const__$//g;
> +               $line =~ s/\s__packed/__attribute__((packed))/g;
>                $line =~ s/^#include <linux\/compiler.h>//;
>                $line =~ s/(^|\s)(inline)\b/$1__$2__/g;
>                $line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
>
> Any thoughts?
>

Hmm, this introduces a new error source.
Whenever we change the definition of __packed we have to
adjust headers_install.pl too.

--
Thanks,
//richard
--
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/