> Wed, Mar 05, 2003 at 12:23:50AM +, Alan Cox wrote:
> > "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 u
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
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 9
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
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
q
On Tue, Mar 04, 2003 at 10:56:25AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > 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
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 wi
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
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 bi
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'
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".
11 matches
Mail list logo
