[oi-dev] Broadcom wireless drivers for OpenIndiana

Jim Klimov jimklimov at cos.ru
Fri Apr 26 15:01:44 UTC 2013


Sorry, there's a "stream of thought" here... I guess the real post worth 
of attention starts at the "OR..." below, and the rest is
just context ;)

On 2013-04-26 16:27, Jean-Pierre wrote:
> Jim Klimov wrote:
>> On 2013-04-26 09:30, Jean-Pierre wrote:
>>>> struct io_stack_location {
>>>> uint8_t isl_major;
>>>> uint8_t isl_minor;
>>>> uint8_t isl_flags;
>>>> uint8_t isl_ctl;
>>>> ...
>>>>
>>>> union {
>>>> struct {
>>>> uint32_t isl_len;
>>>> /* "POINTER_ALIGNMENT" according to msdn */
>>>> uint32_t *isl_key;
>>>> uint64_t isl_byteoff;
>>>> } isl_read;
>>>> ...

>> But in this case you have 4 1-byte values an 1 4-byte value
>> and then the pointer, doesn't this make the pointer 8-byte
>> aligned without fillers? (And the isl_len thus starts at
>> the offset of 4?)
>
> No, because the inner structs have to stand by themselves.
> For instance you must be able to define a pointer to the
> inner struct "isl_read", and the fields must be aligned
> from the pointer.


Hm... that is weird. I wonder if it is at all possible to define
the structure in such a manner that both the offset to the pointer
from start of the "mother" structure and from start of isl_read
structure would both be divisible by 8?

Should the start of the inner structure also be 8-aligned from the
start of its parent structure, or there is no such requirement?

For example, this test (based on your experience):
   || (offsetof(struct io_stack_location,
     isl_parameters.isl_read.isl_len) != 8)
   || (offsetof(struct io_stack_location,
     isl_parameters.isl_read.isl_byteoff) != 24)
implies that there is a 4-byte padding after the four single-bytes
before the unions (or, perhaps, should that be in the start of the
sub-structure itself?) Then there is a 4-byte isl_len which should
be at offset 8 from start of mother-structure, and the pointer
(8-bytes long?) isl_key...

The latter would be starting at either offset 8 or 4 from child
struct (depending on where we put the padding between isl_ctl and
isl_len, and at offset 12 from parent structure.

OR...

+ parent struct:
* 4 single-bytes (they do remain single, right?..)
* 4-byte padding (...or the single-bytes should be 4*2-byte words)
++ Sub-structure in the union (8-aligned itself):
** 4-byte isl_len (starts at offset 8 from parent struct)
** 4-byte padding
** 8-byte pointer (8-aligned in both structures)
** 8-byte offset (starts at offset 24 from parent struct)

Does this layout fit the actual drivers? :)
If so, some more #ifdef padding fields are needed, but I guess I can
craft them based on your offset numbers...

Does the first 4-byte padding belong in the child struct or in the
parent, prefixing all variations of the union sub-structures?





More information about the oi-dev mailing list