Re: ioctl definition - has it changed recently?

From: Piotr Hosowicz
Date: Tue Aug 17 2010 - 10:33:41 EST


On 17.08.2010 15:59, Piotr Hosowicz wrote:
On 17.08.2010 15:51, Piotr Hosowicz wrote:
On 17.08.2010 15:18, Arnd Bergmann wrote:
On Tuesday 17 August 2010, Piotr Hosowicz wrote:
Just take a look at all the other patches that went into the
kernel to do this for other drivers.

I do not know how to find them. :-(

git log -p -S"unlocked_ioctl"

Thanks a lot.

It seems different. How to change it? Now it works, I built it without
your remarks, exactly how I described on my blog:

http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/


Ok, as I wrote the prototypes differ. What should I do with the inode
parameter?

It's normally not needed.

It seems so because the implementation nowwhere refers to the inode
parameter. But I guess it won't be OK to just remove this parameter from
the declaraion and the implemetation because some other NVidia code may
refer to this parameter, pass it and so on. Potentially scrambling
(spoiling) the parameter stack.

This is as I said, I just commented inode parameter and it wont build:

I appeared when I examined the code that they prepared for this and :

#define HAVE_UNLOCKED_IOCTL 1

... in nv.c almost suffices. ;-) They defined this like that:

static struct file_operations nv_fops = {
.owner = THIS_MODULE,
.poll = nv_kern_poll,
// .ioctl = nv_kern_ioctl,
#if defined(HAVE_UNLOCKED_IOCTL)
.unlocked_ioctl = nv_kern_unlocked_ioctl,
#endif
#if defined(NVCPU_X86_64) && defined(HAVE_COMPAT_IOCTL)
.compat_ioctl = nv_kern_compat_ioctl,
#endif
#ifndef NV_USER_MAP
.mmap = nv_kern_mmap,
#endif /* NV_USER_MAP */
.open = nv_kern_open,
.release = nv_kern_close,
};

Regards and thanks,

Piotr Hosowicz


--
- Jaka jest największa anomalia fizjologiczno-polityczna?
- Członek wysunięty z ramienia na czoło.
NP: Dream Theater - Pull Me Under
NB: 2.6.36-rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/