All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	John Kacur <jkacur@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Ingo Molnar <mingo@elte.hu>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 6/6] procfs: Kill the bkl in ioctl
Date: Sat, 10 Apr 2010 18:24:42 +0200	[thread overview]
Message-ID: <20100410162439.GH5204@nowhere> (raw)
In-Reply-To: <201004011442.38536.arnd@arndb.de>

On Thu, Apr 01, 2010 at 02:42:38PM +0200, Arnd Bergmann wrote:
> On Wednesday 31 March 2010, Frederic Weisbecker wrote:
> > On Wed, Mar 31, 2010 at 10:21:23PM +0200, Arnd Bergmann wrote:
> > 
> > > In the meantime, we can move the declaration of the .locked_ioctl callback
> > > into an #ifdef CONFIG_BKL, to make sure nobody builds a driver with an
> > > ioctl function that does not get called.
> > 
> > 
> > Ok, now how to get this all merged? A single monolithic patch is probably
> > not appropriate.
> > 
> > The simplest is to have a single branch with the default_ioctl implemented,
> > and then attributed to drivers in a set cut by subsystems/drivers. And
> > push the whole for the next -rc1.
> > 
> > The other solution is to push default_ioctl for this release and get
> > the driver changes to each concerned tree. That said, I suspect a good
> > part of them are unmaintained, hence the other solution looks better
> > to me.
> 
> I don't care much about the unmaintained parts, we can always have a
> tree collecting all the patches for those drivers and merge it in -rc1.
> 
> I'd say the nicest way would be to get Linus to merge the patch
> below now, so we can start queuing stuff in maintainer trees on top
> of it, and check against linux-next what is still missing and push
> all of them from our branch.
> 
> 	Arnd
> 
> ---
> Subject: [PATCH] introduce CONFIG_BKL and default_ioctl
> 
> This is a preparation for the removal of the big kernel lock that
> introduces new interfaces for device drivers still using it.
> 
> We can start marking those device drivers as 'depends on CONFIG_BKL'
> now, and make that symbol optional later, when the point has come
> at which we are able to build a kernel without the BKL.
> 
> Similarly, device drivers that currently make use of the implicit
> BKL locking around the ioctl function can now get annotated by
> changing
> 
> 	.ioctl = foo_ioctl,
> 
> to
> 
> 	.locked_ioctl = foo_ioctl,
> 	.unlocked_ioctl = default_ioctl,
> 
> As soon as no driver remains using the old ioctl callback, it can
> get removed.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>


Al, we would like to make this for 2.6.34, so that we can start
converting the drivers that use bkl'ed ioctl to this new scheme
in the relevant maintainers trees.

Can we get your ack?

Thanks.


  parent reply	other threads:[~2010-04-10 16:24 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30  6:20 [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 1/6] procfs: Kill BKL in llseek on proc base Frederic Weisbecker
2010-03-30  6:40   ` Alexey Dobriyan
2010-03-30  6:50     ` Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 2/6] procfs: Use generic_file_llseek in /proc/kcore Frederic Weisbecker
2010-03-30 10:28   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 3/6] procfs: Use generic_file_llseek in /proc/kmsg Frederic Weisbecker
2010-03-30 10:38   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 4/6] procfs: Use generic_file_llseek in /proc/vmcore Frederic Weisbecker
2010-03-30 10:38   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 5/6] procfs: Push down the bkl from ioctl Frederic Weisbecker
2010-03-30  6:31   ` Alexey Dobriyan
2010-03-30  7:02     ` Frederic Weisbecker
2010-04-09 14:45     ` [PATCH v2] " Frederic Weisbecker
2010-04-10 13:25       ` [PATCH v3] " Frederic Weisbecker
2010-05-17  1:23         ` [PATCH v4] " Frederic Weisbecker
2010-03-30 10:37   ` [PATCH 5/6] " Arnd Bergmann
2010-03-30 18:27     ` Frederic Weisbecker
2010-03-30 18:54       ` Arnd Bergmann
2010-03-30 19:21         ` Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 6/6] procfs: Kill the bkl in ioctl Frederic Weisbecker
2010-03-30  6:38   ` Alexey Dobriyan
2010-03-30  7:07     ` Frederic Weisbecker
2010-03-30 10:33       ` Arnd Bergmann
2010-03-31 17:22         ` Frederic Weisbecker
2010-03-31 20:21           ` Arnd Bergmann
2010-03-31 21:04             ` Arnd Bergmann
2010-03-31 21:55               ` Alan Cox
2010-04-01  9:07                 ` Arnd Bergmann
2010-03-31 21:56               ` Frederic Weisbecker
2010-04-01 11:37                 ` Arnd Bergmann
2010-04-01 10:22               ` John Kacur
2010-03-31 21:41             ` Frederic Weisbecker
2010-04-01 12:42               ` Arnd Bergmann
2010-04-03 17:53                 ` Stefan Richter
2010-04-10 16:09                 ` Frederic Weisbecker
2010-04-12 15:05                   ` Arnd Bergmann
2010-04-10 16:14                 ` Frederic Weisbecker
2010-04-10 16:24                 ` Frederic Weisbecker [this message]
2010-04-01 11:39           ` Stefan Richter
2010-04-01 12:45             ` Arnd Bergmann
2010-04-10 15:28               ` Frederic Weisbecker
2010-04-11 13:03                 ` Christoph Hellwig
2010-04-12 17:34                   ` Arnd Bergmann
2010-04-12 21:53                     ` Frederic Weisbecker
2010-04-13  9:26                       ` Arnd Bergmann
2010-04-13 20:10                         ` Frederic Weisbecker
2010-04-13 18:03                     ` Christoph Hellwig
2010-04-10 13:27 ` [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100410162439.GH5204@nowhere \
    --to=fweisbec@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=jkacur@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.