[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4985C1B0.8060905@sandeen.net>
Date: Sun, 01 Feb 2009 09:37:20 -0600
From: Eric Sandeen <sandeen@...deen.net>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>, mfasheh@...e.com,
joel.becker@...cle.com, linux-kernel@...r.kernel.org,
hch@...radead.org, xfs-masters@....sgi.com,
viro@...iv.linux.org.uk, Ankit Jain <me@...itjain.org>,
linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, xfs@....sgi.com,
ocfs2-devel@....oracle.com
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
for compatibility with legacy xfs ioctls
Boaz Harrosh wrote:
...
> I don't understand
>
> if you have a structure like
> struct foo {
> u32 one;
> u32 two;
> };
> vs
> struct foo_packed {
> u32 one;
> u32 two;
> } __packed;
>
> Just adding an __attribute__((packed)) to it clearly does not change
> the layout of the structure. Are you saying the __attribute__((packed))
> is an hint to the compiler that foo_packed might be used unaligned. This
> is just brain-dead, because I can use an unaligned pointer to foo just as
> I can to foo_packed. Otherwise there is no difference what-so-ever between
> the two. I have to see it to believe. It is totally the wrong hint in the
> wrong place taking away valuable meaning of saying "please don't use padding
> holes in this structure"
>
> Sorry for been so slow, I just don't get it.
> Boaz
While I'm no gcc guru, I can confirm that gratuitous use of the packed
attribute is suboptimal; adding "packed" to every ondisk structure made
obdump -d xfs.ko | wc -l explode by about 15,000 lines on ia64.
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists