From: Boaz Harrosh <bharrosh@panasas.com>
To: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Chris Leech <christopher.leech@intel.com>,
jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
devel@open-fcoe.org
Subject: Re: [PATCH 1/3] 24-bit types: typedef and macros for accessing 3-byte arrays as integers
Date: Thu, 11 Sep 2008 11:30:04 +0300 [thread overview]
Message-ID: <48C8D70C.7090908@panasas.com> (raw)
In-Reply-To: <1221074409.27385.39.camel@norville.austin.ibm.com>
Dave Kleikamp wrote:
> On Wed, 2008-09-10 at 19:11 +0300, Boaz Harrosh wrote:
>> Dave Kleikamp wrote:
>
>>> @@ -62,7 +60,7 @@ struct timestruc_t {
>>> */
>>> typedef struct {
>>> unsigned len:24;
>>> - unsigned off1:8;
>>> + u8 off1;
>>> u32 off2;
>>> } lxd_t;
>>>
>> Why is the difference from below definition. That is the
>> use/not of __le24?
>
> Answered elsewhere, but this is host-endian. I plan to kill this
> structure soon.
>
>>> @@ -90,8 +88,8 @@ struct lxdlist {
>>> * physical xd (pxd)
>>> */
>>> typedef struct {
>>> - unsigned len:24;
>>> - unsigned addr1:8;
>>> + __le24 len;
>> Is this stuff on-the-wire?
>
> Written to disk, so basically, yeah.
>
>> Do you need a:
>> + __le24 len __packed;
>>
>>> + u8 addr1;
>>> __le32 addr2;
>>> } pxd_t;
>> and:
>> } pxd_t __packed ;
>
> I'm not convinced that this is needed. Does the compiler do any padding
> for alignment when it only contains char types (or structs of chars)?
>
>> Note that before the :24 bit-field was kept packed but now
>> with the use of struct at the __le24 definition it might
>> choose to pad them.
>
> Maybe, but I can't get the compiler to add any padding playing around
> with variants of these structures. I've tested a simple program on both
> x86 and ppc64, but I'm not sure what would happen on, say, arm.
>
You have an "__le32 addr2" followed, it might want too in rare cases.
But for me this is also a a declaration issue and a readability issue.
I'm telling the compiler, don't mess with my structure, this needs
to be constant whatever the compiler is. In C the compiler is even
allowed to change fields order if it wants to. Why the guess work,
__packed and be done with it.
And it's also a readability issue. Look above lxd_t vs pxd_t. I can't
know that one is in memory and one is on disk. I have to ask questions
and make wrong remarks. But if the later had a __packed on it, then
there are no more questions.
__packed for me is a statement for both the programmer and compiler
that says: "This stuff will be seen externally of the machine. It must
be universally constant"
>> Chris you might want to change the definitions at linux/types.h
>> to:
>>
>> typedef struct { __u8 b[3]; } __be24, __le24 __packed;
>>
>> With gcc it will not help with the proceeding fields, and the
>> containing struct will need it's own "__packed" declaration
>> but it will keep it packed with previous fields.
>>
>> Just my $0.017
>> Boaz
>
> Shaggy
Boaz
next prev parent reply other threads:[~2008-09-11 8:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-05 16:57 [PATCH 1/3] 24-bit types: typedef and macros for accessing 3-byte arrays as integers Chris Leech
2008-09-05 16:57 ` Chris Leech
[not found] ` <20080905165732.16689.50256.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-09-05 16:57 ` [PATCH 2/3] 24-bit types: convert iSCSI to use the __be24 type and macros Chris Leech
2008-09-05 16:57 ` Chris Leech
[not found] ` <20080905165738.16689.31487.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-09-05 17:03 ` Mike Christie
2008-09-05 17:03 ` [Open-FCoE] " Mike Christie
2008-09-05 16:57 ` [PATCH 3/3] 24-bit types: Convert Open-FCoE to use " Chris Leech
2008-09-05 16:57 ` Chris Leech
2008-09-07 9:36 ` [PATCH 1/3] 24-bit types: typedef and macros for accessing 3-byte arrays as integers Boaz Harrosh
2008-09-07 15:56 ` Chris Leech
2008-09-07 17:21 ` Boaz Harrosh
2008-09-07 17:52 ` Chris Leech
2008-09-09 22:59 ` [PATCH] 24-bit types: typedef and functions " Chris Leech
2008-09-10 12:57 ` Boaz Harrosh
2008-09-07 9:57 ` [PATCH 1/3] 24-bit types: typedef and macros " Boaz Harrosh
2008-09-10 14:07 ` Christoph Hellwig
2008-09-10 15:40 ` Dave Kleikamp
2008-09-10 16:11 ` [PATCH " Boaz Harrosh
2008-09-10 16:25 ` Boaz Harrosh
[not found] ` <48C7F19D.3080507-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
2008-09-10 19:20 ` Dave Kleikamp
2008-09-10 19:20 ` Dave Kleikamp
2008-09-11 8:30 ` Boaz Harrosh [this message]
2008-09-11 1:51 ` Chris Leech
2008-09-10 16:25 ` Chris Leech
2008-09-10 17:45 ` [Open-FCoE] " Chris Leech
2008-09-10 18:04 ` Boaz Harrosh
2008-09-10 18:04 ` Boaz Harrosh
2008-09-10 18:23 ` Dave Kleikamp
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=48C8D70C.7090908@panasas.com \
--to=bharrosh@panasas.com \
--cc=christopher.leech@intel.com \
--cc=devel@open-fcoe.org \
--cc=hch@infradead.org \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=shaggy@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.