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.
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
