Eduardo Horvath <eeh@turbolinux.com> writes:
> In the kernel alone there's:
> 
> 	isp_tpublic.h

I'm not sure what the deal is with this.  i can't find any actual uses
of 'tmd_cmd' in the code, other than to define the struct an in some
comments.

A noble goal.  However, this isn't the way to accomplish it.  The
right way is to make sure the relevant structure members are padded
'immediately nearby', if at all possible.

For instance, there's the issue:

typedef struct tmd_cmd {
        void *                  cd_private;     /* layer private data */
        void *                  cd_hba;         /* HBA tag */
        void *                  cd_data;        /* 'pointer' to data */
        u_int64_t               cd_iid;         /* initiator ID */

Who's to say that the compiler's not going to put padding between the
third void * and the uint64_t?

"Oh, wait," in fact, _it already does_, in particular on sparc.
(Thanks to mrg for initially confirming my suspicion, but i
reconfirmed it myself on sparc solaris with gcc as well.  8-) (It
would on mips as well, if we used -mips3 -mlong32 for compilation.)

Handling structure padding issues fundamentally has to be done on an
architecture-dependent basis, unless you make the macros to do it
_really_ generic.

(In other words, this particular bit of code seems to be _already
broken_ w.r.t. its expectations about structure padding, and, in
general, adding an lp64 define is neither necessary nor sufficient to
solve those problems.)

Another interesting thing with this one is that the alleged purpose of
an lp64 define here could as easily be solved with simple sizeof math,
like MAXCSBUFS is in ufs/ffs/fs.h (though obviously slightly more
complex)


> 	ip_compat.h

This use of __alpha__ is not even used for NetBSD, if my reading is
correct.


> 	stat.h
> 
> that use __alpha__ as a check for 64-bitness.

Here again is a structure padding issue.  This one particular place
may have its structure padding issues satsifiable by an lp64 check,
but as noted above, such a check is neither necessary nor sufficient
for solving structure padding problems in general.  I'd go so far as
to argue that, because of that, it shouldn't be used.

it's also worth noting that the existing uses of __STATPAD here are a
bit misleading; they'd make you think that the first chunk of padding
is necessarily the same as the last 3.  That's really a
machine-dependent issue.

So, in fact, you could probably get away with an lp64 check here,
assuming you were willing to contrain your notion of "lp64" machines
to be "sparc64 and alpha" to those which we currently know follow
those particularly structure padding rules.  But again, it's not a
good idea.

(It's worth noting that if there were an lp32 system with structure
alignment requirements that mandated 8 byte alignment, this particular
case would break as well.  That's not as far-fetched as it might seem.
For instance, arm26 and arm32 with the normal ABIs -- not arm32's
screwy netbsd ABI -- demand structure padding of 4 bytes, regardless
of the stuff in the structures.  yes, that screws up a _lot_ of
assumptions.  Looking at GCC's md bits, I don't see any cases where
that's actually required, but, really, this is all MD ground and
misapplying an lp64 macro (were one to exist) to this situation would
be the wrong thing.)


This one is actually harder to solve without MD #ifdefs unless you're
willing to resort to GCC-isms, since the very nature of the problem is
such that the members in question can't be wrapped inside structures.
(GCC hackery could work though, specifically potentially-zero-length
arrays could DTRT.)

... On the other hand...  My understanding is that sparc64 uses 64-bit
time_t at this point (thanks again matt 8-), and that fact blows the
ability to use a simple lp64 check out of the water here, too.


> Can't say it's necessarily a good thing.  Although at times it may be a
> necessary thing.

"keep trying!"  8-)



chris