lkml.org 
[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL v2] Preparation for BKL'ed ioctl removal

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> > And don't try to conflate the issue of ioctl and BKL. There are still
> > code-paths that do lock_kernel() without the ioctl's, so the whole ioctl
> > renaming has _zero_ to do with CONFIG_BKL.
>
> It's true, but once it gets pushed down/dropped from every core parts (which
> is what we are working on currently in parallel), lock_kernel() and
> .bkl_ioctl is only going to be used by unmaintained drivers. This is the
> time where having a CONFIG_BKL is going to make sense. And it won't be a
> question of saving some bytes but improve efficiency of schedule() for those
> who don't need such old or unmaintained drivers.

The scheduler will be helped most by getting rid of the BKL altogether. We are
in reaching distance of that now ...

CONFIG_BKL would really just elongate the migration period, unnecessarily so.

> May be we should only start to focus on this new config once this state is
> reached.

Once that state is achived we can just get rid of the BKL and mass-push
per-driver mutexes into those remaining drivers - in a possibly scripted way.
Something like:

foo-driver.c

DEFINE_MUTEX(foo_mutex);

foo_ioctl()
{
mutex_lock(&foo_mutex);
...
mutex_unlock(&foo_mutex);
}

foo_open()
{
mutex_lock(&foo_mutex);
...
mutex_unlock(&foo_mutex);
}

This could be done all automated for a hundred old drivers if need to be.
There would be no bkl_ioctl's left.

That, even if it looks somewhat coarse is still better than having _yet
another_ 'temporary transition'. The Big Kernel Lock was supposed to be
transitionary to begin with. It's been 10+ years and counting :-)

Ingo


\
 
 \ /
  Last update: 2010-04-26 09:29    [W:0.089 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site