On Thu, 2002-11-07 at 12:52, Ville Syrj�l� wrote:
> On Thu, Nov 07, 2002 at 11:05:28AM +0800, Antonino Daplas wrote:
> > On Thu, 2002-11-07 at 06:56, Ville Syrj�l� wrote:
> > > The matroxfb patch that is included in DirectFB is broken. Here's a new
> > > patch. get_user() usage was apparently wrong. So I threw it out and things
> > > work a lot better.
> > >
> >
> > Is there anything wrong with the following?
> >
> > int c
> >
> > if (get_user(c, (u32 *) arg)
> > return -EFAULT;
>
> That's exactly what the patch had. But it needs a pointer as argument
> which means an additional variable for simply passing a single number.
> The DirectFB code simply calls ioctl(fd, FBIO_WAITFORVSYNC, 1) and since
> the ioctl handler doesn't dereference the argument things shouldn't
> explode right? If no argument is passed it will simply be some random
If you pass a parameter via ioctl, it's always a pointer, even if it's
something the compiler created. However, you need to be unambiguous on
how you define the ioctl. Unfortunately, the ioctls in fb.h are old
style. You need to use the ioctl macros to specifically define how the
ioctl should behave.
_IO - no parameters (original matrox-vsync )
_IOW - parameter passed from user space
_IOR - parameter passed to user space
_IORW - parameter passed from and returned to user space
With your new patch, redefine the ioctl from:
#define FBIO_WAITFORVSYNC 0x4620
to
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, int)
'F' is always assigned to framebuffer devices.
Now, your ioctl will be unambigous.
> number which can of course lead to waiting for the wrong interrupt but
> still things should not oops. I've tried to look at some other drivers for
> guidance but it seems that some use get_user() and some don't. Also
> ioctl_list(2) list many ioctls using using just (int) and others using
> (int *). If anyone knows which is the right way I'd like to know.
>
(int *) is correct.
Tony
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
