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

quoted text
> > 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.

quoted text
> 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
--
unsubscribe notice
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/