From: Boaz Harrosh <bharrosh@panasas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Ankit Jain <me@ankitjain.org>,
viro@zeniv.linux.org.uk, hch@infradead.org,
linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com,
xfs@oss.sgi.com
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Date: Sun, 01 Feb 2009 14:32:45 +0200 [thread overview]
Message-ID: <4985966D.8040402@panasas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0902011151180.20875@anakin>
Geert Uytterhoeven wrote:
> On Sun, 1 Feb 2009, Boaz Harrosh wrote:
>> Geert Uytterhoeven wrote:
>>> On Sun, 1 Feb 2009, Boaz Harrosh wrote:
>>>> Arnd Bergmann wrote:
>>>>> +struct space_resv {
>>>>> + __s16 l_type;
>>>>> + __s16 l_whence;
>>>>> + __s64 l_start;
>>>>> + __s64 l_len; /* len == 0 means until end of file */
>>>>> + __s32 l_sysid;
>>>>> + __u32 l_pid;
>>>>> + __s32 l_pad[4]; /* reserve area */
>>>>> +};
>>>> What about telling the compiler exactly what you said above, just
>>>> to be sure we all mean the same thing. (And as documentation for new
>>>> comers):
>>>>
>>>> +struct space_resv_64 {
>>>> + __s16 l_type;
>>>> + __s16 l_whence;
>>>> + __u32 reserved;
>>>> + __s64 l_start;
>>>> + __s64 l_len; /* len == 0 means until end of file */
>>>> + __s32 l_sysid;
>>>> + __u32 l_pid;
>>>> + __s32 l_pad[4]; /* reserve area */
>>>> +} __packed;
>>> Because the compiler will assume all fields are always unaligned and will use very
>>> suboptimal code to access them?
>> This discussion comes up every once in a while. I'm using an old FC7 compiler
>> (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)) And tests show that when the layout
>> of a structure is exactly the same the "__packed" on structure declarations does
>> nothing. It only starts to affect when there are real differences in alignment.
>> Also tests with gcc 3.4.x showed the same effect.
>>
>> On previous discussions no one could come forward and say what compiler version
>> breaks when __packed is applied on structure definition. I'm afraid your statement
>> above is a myth.
>
> FC7, targeting ia32? Sure, ia32 has no alignment restrictions.
> Try e.g. MIPS.
>
> Gr{oetje,eeting}s,
>
> Geert
>
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
next prev parent reply other threads:[~2009-02-01 12:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 20:59 [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls Ankit Jain
2009-01-31 0:22 ` Andrew Morton
2009-01-31 0:38 ` Arnd Bergmann
2009-01-31 1:14 ` Andrew Morton
2009-01-31 1:48 ` Arnd Bergmann
2009-02-01 9:48 ` Boaz Harrosh
2009-02-01 10:05 ` Geert Uytterhoeven
2009-02-01 10:39 ` Boaz Harrosh
2009-02-01 10:59 ` Geert Uytterhoeven
2009-02-01 12:32 ` Boaz Harrosh [this message]
2009-02-01 15:37 ` [xfs-masters] " Eric Sandeen
2009-02-01 16:25 ` Boaz Harrosh
2009-02-01 16:35 ` Eric Sandeen
2009-02-01 16:41 ` Christoph Hellwig
2009-02-01 16:57 ` Boaz Harrosh
2009-02-02 0:31 ` Arnd Bergmann
2009-02-02 8:29 ` Boaz Harrosh
2009-02-02 8:45 ` Geert Uytterhoeven
2009-02-02 9:33 ` Boaz Harrosh
2009-02-02 20:51 ` Jamie Lokier
2009-02-03 7:31 ` Boaz Harrosh
2009-02-03 11:21 ` Jamie Lokier
2009-06-19 18:28 ` Christoph Hellwig
2009-06-20 8:13 ` Arnd Bergmann
2009-06-21 18:41 ` [xfs-masters] " Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4985966D.8040402@panasas.com \
--to=bharrosh@panasas.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=joel.becker@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@ankitjain.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs-masters@oss.sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).