linux-kernel - Re: [PATCH 0/7] kfifo: new API v0.6

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] [day] [month] [year] [list]

Date:	Wed, 28 Oct 2009 03:36:36 -0200
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andy Walls <awalls@...ix.net>,
	Stefani Seibold <stefani@...bold.net>,
	Andi Kleen <andi@...stfloor.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Amerigo Wang <xiyou.wangcong@...il.com>,
	Joe Perches <joe@...ches.com>, linux-media@...r.kernel.org
Subject: Re: [PATCH 0/7] kfifo: new API v0.6

Em Wed, 28 Oct 2009 04:20:49 +0100
Andi Kleen <andi@...stfloor.org> escreveu:

With respect to the kfifo series of patches:

Acked-by: Mauro Carvalho Chehab <mchehab@...hat.com>

> > Here's a V4L-DVB cx23885 module change, that is on its way upstream,
> > that uses kfifo as is:
> > 
> > http://linuxtv.org/hg/v4l-dvb/rev/a2d8d3d88c6d
> > 
> > Do you really have to break the old API?
> 
> That was extensively discussed in the original patch kit submission,
> and yes there are good reasons. You will just have to adapt
> the driver if it gets in after the new kfifo patches; if kfifo
> gets in later it'll have to adapt it.

I agree. The current kfifo implementation is very limited that can't be
used on several places. Changing its implementation to be generic enough
requires changing the API, since, on several places, we don't want to have
a spinlock. So, as we'll need to change the API anyway, better to do it at the
right way.

That's said, i7core_edac will also need the new kfifo API for 2.6.33, so I'll
have to handle this upstream change anyway. So, the faster this change went into
upstream, the better, since I'll hold my pull requests to happen after it.

Since I'll have 2 -git trees depending on this change (i7core_edac and v4l-dvb),
the better is if you could put the kfifo code on a git tree that won't be
rebased. This way, we can make our trees based on kfifo -git tree, having
everything rebased there to avoid any merge or bisect conflict (in my case,
cx23885 will need to be rebased, and i7core_edac will need kfifo -git objects
for a new NMI-aware fifo implementation using kfifo)

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/