Re: [discuss] f_ops flag to speed up compatible ioctls in linux kernel

[Herbert Poetzl <herbert@13thfloor.at>]

On Tue, Sep 07, 2004 at 09:07:19PM +0300, Michael S. Tsirkin wrote:
> Hello!
> Quoting r. Herbert Poetzl (herbert@13thfloor.at) "Re: [discuss] f_ops flag to speed up compatible ioctls in linux kernel":
> > On Tue, Sep 07, 2004 at 04:29:46PM +0200, Andi Kleen wrote:
> > > On Tue, Sep 07, 2004 at 05:25:30PM +0300, Michael S. Tsirkin wrote:
> > > > > It may help your module, but won't solve the general problem shorter
> > > > > term.
> > > > But longer term it will be better, so why not go there?
> > > > Once the infrastructure is there, drivers will be able to be
> > > > migrated as required.
> > > 
> > > I have no problems with that. You would need two new entry points:
> > > one 64bit one without BKL and a 32bit one also without BKL. 
> > > 
> > > I think there were some objections to this scheme in the past,
> > > but I cannot think of a good alternative. 
> > 
> > uhm, apologies for dropping in, for what exactly
> > are two (new) separate entry points needed?
> > 
> > somehow lost context here ...
> > 
> > TIA,
> > Herbert
> 
> There are two uses BKL in the ioctl call path:
> 1. BKL is kept across the whole ioctl call
> 2. BKL is used to protect the compat hash lookup
> 
> So ioctl_native is to let drivers declare they dont need the BKL
> in they ioctl.
> 
> ioctl_compat is to let drivers declare 
> they dont need the hash lookup so it can be replaced by direct call by pointer.

okay, thanks, I guess I got it now, just wondered why
there should be different implementations for 32 and
64 bit, but a different semantic explains it ...

thanks,
Herbert

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