RE: Unserializing ioctl() system calls

[Spinka, Kristofer]

It doesn't necessarily have to be a flag on a driver, just an example.

I was more interested in a transitional interface to wean current
modules/code off of any BKL expectations during an ioctl.

Why should the kernel take out the BKL for the module during an ioctl?  Does
the kernel know how long this request might take?

  /kristofer

-----Original Message-----
From: viro@xxxxxxxxxxxxxxxx [mailto:viro@xxxxxxxxxxxxxxxx] On Behalf Of
viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sent: Friday, May 21, 2004 7:54 PM
To: Spinka, Kristofer
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: Unserializing ioctl() system calls

On Fri, May 21, 2004 at 10:46:45PM -0400, Spinka, Kristofer wrote:
> I noticed that even in the 2.6.6 code, callers to ioctl 
> system call (sys_ioctl in fs/ioctl.c) are serialized with 
> {lock,unlock}_kernel().
> 
> I realize that many kernel modules, and POSIX for that 
> matter, may not be ready to make this more concurrent.
> 
> I propose adding a flag to indicate that the underlying 
> module would like to support its own concurrency 
> management, and thus we avoid grabbing the BKL around the 
> f_op->ioctl call.
> 
> The default behavior would adhere to existing standards, 
> and if the flag is present (in the underlying module), we 
> let the module (or modules) handle it.
> 
> Reasonable?

No.  Flags on drivers are never a good idea.  What's more, if somebody
wants that shit parallelized they can always drop BKL upon entry and
reacquire on exit from their ->ioctl().

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