Re: unregister_ioctl32_conversion and modules. ioctl32 revisited.

[Michael S. Tsirkin]

Hello!
Quoting r. Lee Revell (rlrevell@xxxxxxxxxxx) "Re: unregister_ioctl32_conversion and modules. ioctl32 revisited.":
> On Wed, 2004-12-15 at 19:20 +0100, Takashi Iwai wrote:
> > At Wed, 15 Dec 2004 09:46:35 +0200,
> > Michael S. Tsirkin wrote:
> > > 
> > > There were two additional motivations for my patch:
> > > 1. Make it possible to avoid the BKL completely by writing
> > >    an ioctl with proper internal locking.
> > > 2. As noted by  Juergen Kreileder, the compat hash does not work
> > >    for ioctls that encode additional information in the command, like this:
> > > 
> > > #define EVIOCGBIT(ev,len)  _IOC(_IOC_READ, 'E', 0x20 + ev, len) > > 
> > I like the idea very well.  Other benifits in addition:
> > 
> 
> How does this all relate to Ingo's ->unlocked_ioctl stuff which is "an
> official way to do BKL-less ioctls"?
> 
> http://lkml.org/lkml/2004/12/14/53
> 
> Lee

It conflicts :) When I wrote the original patch for 2.6.8.1
I didnt see the unlocked_ioctl.patch.

unlocked_ioctl is the same as ioctl_native in my patch, except that

1. I added more documentation in several places :)
   (notably Documentation/filesystems/Locking)

2. I thought it a bit silly to name a function for what
   it does not do (does not take a lock), and we
   still need a call for the compat layer.

My patch adds another call to enable special handling
for 32 bit ioctls on 64 bit systems.

I could look at porting to -rc3-mm1, unless
we dont want to back unlocked_ioctl.patch off.
What do people here think?

MST
-
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/