[ofw] WDK build environment migration thoughts

Sean Hefty sean.hefty at intel.com
Mon Apr 21 15:33:44 PDT 2008


If we're okay with breaking compiled applications, then we should go for a
simple solution.  Just remove __ptr64 everywhere, and make the IOCTL structures
UINT64.  This is basically what you have now anyway - just delete the FUNC_PTR64
and VOID_PTR64 macros.  I would rather see the IOCTL structures use UINT64,
rather than a union, but if the union minimizes the code changes for now, I'm
fine with it.

 

The real question is whether everyone is in agreement that it's okay to break
existing apps.  If we're not okay with breaking userspace binary compatibility,
then we need another solution.

 

I think we should post a clear message, with an appropriate subject, to ofw
asking if breaking binary compatibility is acceptable to everyone.  (I'm
indifferent myself, but only because I don't believe that there are that many
apps out there that aren't part of the WinOF repository.)

 

- Sean

 

 

FUNC_PTR64 and VOID_PTR64 are defined as nothing. They are only comments that
help us check that Alex did a good job.

One day or the other they should be removed. You can think of them as comments.

 

> What does sizeof(qp) return?

It will return 4 on 32 bits systems and8 on 64 systems.

 

I believe that compatibility is broken in the user-user and kernel-kernel level
on 32 bits systems. This is because at the past functions that have received
pointers received them as __ptr64 which means that the size of the pointer was
64 bits. Today they will be 32 bits only. The portability in the move between
user to kernel still exists as the structs in the ioctls are still 64 bits.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080421/3bdd8688/attachment.html>


More information about the ofw mailing list