lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BD84A56.6060806@infradead.org>
Date:	Wed, 28 Apr 2010 11:46:46 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC:	Hans Verkuil <hverkuil@...all.nl>, Arnd Bergmann <arnd@...db.de>,
	John Kacur <jkacur@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jan Blunck <jblunck@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: [PATCH 10/10] bkl: Fix-up compile problems as a result of the
 bkl-pushdown.

Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wednesday 28 April 2010 14:37:10 Hans Verkuil wrote:
>>> Arnd Bergmann wrote:
> 
> [snip]
> 
>>>> Mauro, does this patch make sense to you? It would be good to have your
>>>> Ack so we can queue this in the series leading to the removal of the
>>>> ->ioctl file operation. We can also do the minimal change and let you
>>>> take care of fixing this up in a different way in your own tree.
>>> We had a similar discussion a while ago at linux-media. The idea is to do
>>> it on a deeper level, changing the drivers to not need to use KBL.
>>> Hans is working on those patches. Not sure about the current status.
>> I'm waiting for the event patch series from Sakari to go in before I can
>> continue working on this.
>>
>>> Anyway, I think that the better is to apply first your patch, to avoid
>>> breaking your patch series, and then ours, as we may otherwise have some
>>> conflicts between your tree and drivers/media git tree.
>> I have no real problem with this patch, as long as people realize that
>> this only moves the BKL from one place to another and does not really fix
>> any drivers.
> 
> Seems that Arnd was more convincing than me. I've submitted the exact same 
> patch a while ago :-)

Same patch, different situation ;)

> Of course this doesn't solve the BKL issue, but it pushes it one level down, 
> closer to the drivers. Higher levels can then stop caring about it. Of course 
> lower levels will still need to remove the BKL.

Yes. This patch doesn't change anything in practice, but it allows RT people
to keep working on their series of changes, giving us a little more time to 
work on a definitive solution. If nacked, we would need to send an alternative
patch for them, and, as this is not ready (and such patch applied via RT tree would
likely cause merge conflicts with our patches), the better is to just ack and keep 
writing the patch that will solve the issue.

Your patch were very useful, as it started the discussions for the BKL removal
on drivers/media drivers.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ