lkml.org 
[lkml]   [2004]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: unregister_ioctl32_conversion and modules. ioctl32 revisited.
Hello!
Quoting r. Andi Kleen (ak@suse.de) "Re: unregister_ioctl32_conversion and modules. ioctl32 revisited.":
> > 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.
>
> Good point. It is the first step towards BKL less native ioctls. So it's
> certainly a good idea even for the non compat case.
>
> > 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 post the patch (updated for 2.6.10-rc2, boots) that I built for
> > Juergen, below. If there's interest, let me know.
>
> Patch looks good to me, except for some messed up white space
> that is probably easily fixed.

I did try so .. Where? :)

> > I'd like to add that my patch does not touch any in-kernel users,
> > that would have to be done separately, probably as a first step
> > simply taking the BKL inside ioctl_compat.
>
> I doubt any of the compat wrappers need BKL, they never touch
> any global state and then just call sys_ioctl which takes the BKL
> only when needed.
>
> Ok there is a slight possibility that out of tree code wrote
> compat wrappers that need BKL, but in that case they will just
> have to deal with the bugs. Removing register_ioctl32_conversion
> and some comments would take care of them anyways.

I mean out of tree code can just implement ioctl_compat by taking the BKL
if it needs it.

MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [from the cache]
©2003-2011 Jasper Spaans