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

Herbert Poetzl
2004-09-09T13:58:56Z

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/