[Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Philip Brown
As promised from the irc session... here's details on the little 32/64-bit issue I ran into. Its not quite a direct 32/64 bit thing in the drm itself exactly, but ambiguity can be a problem... drm_map_t.offset is unsigned long. unsigned long is semi-unspecified, but is reasonably assumed to

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Alan Cox
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Andy Isaacson
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Philip Brown
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Ian Romanick
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Linus Torvalds
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Alan Cox
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

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Philip Brown
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%

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

2003-03-04 Thread Alan Cox
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