Messages in this thread | | | From | "Spinka, Kristofer" <> | Subject | RE: Unserializing ioctl() system calls | Date | Fri, 21 May 2004 20:35:55 -0700 |
| |
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@www.linux.org.uk [mailto:viro@www.linux.org.uk] On Behalf Of viro@parcelfarce.linux.theplanet.co.uk Sent: Friday, May 21, 2004 7:54 PM To: Spinka, Kristofer Cc: linux-kernel@vger.kernel.org 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |