Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, 2003-03-04 at 08:22, Philip Brown wrote: unsigned long is semi-unspecified, but is reasonably assumed to be a 32-bit quantity. On all 64bit bit platforms I have met unsigned long is a 64bit quantity. In fact I can't think of a single exception mmap() takes an arg of type off_t. off_t or loff_t ? off_t tends to be 32bit on a 64bit platform So, if you're going to call something offset, in a struct that is targetted for memory map tracking... it should really be an explicit 64bit length value. That hurts normal computers. Maybe it should be a typedef but thats another question. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
On Tue, 2003-03-04 at 08:22, Philip Brown wrote:
unsigned long is semi-unspecified, but is reasonably assumed to be
a 32-bit quantity.
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single exception
Well then, obviously, you dont use solaris :-)
He uses Solaris and compiles for 64-bit mode, rather than the 32-bit
mode you're compiling for.
sparc$ ./t [compiled with gcc 2.95.2]
Size of unsigned long is 4
Size of long long is 8
sparc$ isalist
sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc
[that confirms the sparc is running with a 64bit kernel]
The 64-bit kernel is perfectly capable of running 32-bit binaries, and
that's precisely what you're doing. Solaris in 64-bit mode is just like
every other 64-bit UNIX.
Every useful 32-bit UNIX is ILP32. Every mainstream 64-bit UNIX is
I32LP64. (Ignoring oddities like UNICOS.) If sizeof(long)==4, you're
on a 32-bit platform. If sizeof(long)==8, you're on a 64-bit platform.
$ uname -a
SunOS exa 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-5_10
$ cat foo.c
#include stdio.h
int main(void)
{
printf(void*=%d\nlong=%d\nint=%d\n,
sizeof(void*), sizeof(long), sizeof(int));
return 0;
}
$ cc foo.c
$ ./a.out
void*=4
long=4
int=4
$ cc -xarch=v9 foo.c
$ ./a.out
void*=8
long=8
int=4
$ cc -V
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
usage: cc [ options] files. Use 'cc -flags' for details
-andy
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote:
On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single exception
Well then, obviously, you dont use solaris :-)
He uses Solaris and compiles for 64-bit mode, rather than the 32-bit
mode you're compiling for.
...
The 64-bit kernel is perfectly capable of running 32-bit binaries, and
that's precisely what you're doing.
Yes. And that's exactly what DRI users will do. So right there is a
64/32 bit problem.
In drm.h, to take just one example.
typedef struct drm_map {
unsigned long offset; /* Requested physical address (0 for SAREA)*/
unsigned long size; /* Requested physical size (bytes) */
drm_map_type_t type; /* Type of memory to map */
drm_map_flags_t flags; /* Flags */
void *handle; /* User-space: Handle to pass to mmap */
/* Kernel-space: kernel-virtual address */
int mtrr; /* MTRR slot used */
/* Private data */
} drm_map_t;
So kernel will be compiled with offset=64bits, user mode will be compiled
with offset=32bits... boom.
All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
Philip Brown wrote: On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote: The 64-bit kernel is perfectly capable of running 32-bit binaries, and that's precisely what you're doing. Yes. And that's exactly what DRI users will do. So right there is a 64/32 bit problem. [snip] So kernel will be compiled with offset=64bits, user mode will be compiled with offset=32bits... boom. All numeric fields passed through the ioctls, should have fixed, identifiable sizes. Ah. So this isn't just a 64-bit arch problem. It's a mixed 32/64 problem. That's different. What happens on Linux is the 32-bit apps go through some sort of ioctl thunking layer to convert the 32-bit ioctls to the native 64-bit ioctls. I know that this is done for IA-64 and PPC64. It will also have to be done for x86-64. Can somebody explain exactly how this works on Linux? I'm still a little fuzzy on it. Is there some way that DRI could handle this genericly for supporting other operating systems? I'm sure that Solaris and *BSD don't handle it quite the same way that Linux does. For Philip, I would suggest getting 64-bit apps to work with a 64-bit kernel before trying to tackle mixed-mode. You've got enough work to port DRI to SPARC Solaris as it is! :) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, 4 Mar 2003, Philip Brown wrote: Does this thunking happen at the native OS level, or in the linux drm code itself? Each user has to thunk on its own, since nobody else even knows what the ioctl stuctures are. Moral of the story: avoid ioctl's. _Especially_ avoid ioctl's with questionable binary structure formats. Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, 2003-03-04 at 18:12, Philip Brown wrote: All numeric fields passed through the ioctls, should have fixed, identifiable sizes. I guess you do need a typedef then so you can support solaris without trashing the other 99.999% of the userbase. In the Linux world the ioctl32 handlers munge the structures. Different philosophy to handling the problem space. I believe DaveM's DRM for the sparc64 linux is quite happy with mixed 32/64 user space. Alan --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, Mar 04, 2003 at 11:02:10PM +, Alan Cox wrote: On Tue, 2003-03-04 at 18:12, Philip Brown wrote: All numeric fields passed through the ioctls, should have fixed, identifiable sizes. I guess you do need a typedef then so you can support solaris without trashing the other 99.999% of the userbase. Well, technically, 99.9% of the userbase will be (linux|*BSD)/x86, so it would only trash a potential 0.099% ;-) In the Linux world the ioctl32 handlers munge the structures. Different philosophy to handling the problem space. Dont think of it as trashing, think of it as an opportunity to get rid of 'munging' :-) I believe DaveM's DRM for the sparc64 linux is quite happy with mixed 32/64 user space. Probably it has the same size for unsigned long in both 32 and 64 bit modes. It works is not the same as it works cleanly. APIs should be fixed, concrete definitions. The struct definitions in drm.h are essentially part of the API (or ABI, whatever), and they are not fixed. They should be cleaned up. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 32/64bit issues in ioctl struct passing
On Tue, 2003-03-04 at 22:15, Philip Brown wrote: I believe DaveM's DRM for the sparc64 linux is quite happy with mixed 32/64 user space. Probably it has the same size for unsigned long in both 32 and 64 bit modes. I don't think so. I think the DRM ioctls get munged properly It works is not the same as it works cleanly. APIs should be fixed, concrete definitions. The struct definitions in drm.h are essentially part of the API (or ABI, whatever), and they are not fixed. They should be cleaned up. You can never achieve that on a wide cross platform OS. Little things like struct padding, alignment rules and so on get in the way now and then. There is an additional consideration because x86 is -horrible- at 64bit ops, gcc manages to do it quite badly at times too making it even uglier. Either way having typedefs for these so they can stay unsigned long and munged on x86 versus enforced 64bit on solaris doesn't seem to cause any problems. For some of the DRM API's I'd agree with you - they don't hit the performance considerations. However we already have an API and most XFree86 4.1/4.2/4.3 drivers [1] all run with the 4.3 DRM. You'd break that by changing the types. Alan [1] i810 breaks 44.1 to 4.2 and 4.2 to 4.3 8( --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
