![]() | |||||||||||||
Messages in this thread |
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 13:08 [from the cache] ©2003-2008 | |||||||||||||