linux-kernel - What is the near term future for kfifo?

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

Date:	Tue, 29 Sep 2009 21:38:09 -0400
From:	Andy Walls <awalls@...ix.net>
To:	linux-kernel@...r.kernel.org
Cc:	linux-media@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...radead.org>
Subject: What is the near term future for kfifo?

LKML,

What's the status of the recently proposed kfifo changes?

This change set of mine, for implementing IR receiver support for the
CX23888 chip:

On Sun, 2009-09-27 at 20:12 -0400, Andy Walls wrote:
> Mauro,
> 
> Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part2
> 
> for the following 5 changesets:
> 
> 01/05: v4l2-subdev: Add v4l2_subdev_ir_ops and IR notify defines for v4l2_device
> http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=8cbb951bbb9f
> 
> 02/05: cx23885: Complete CX23888 IR subdev implementation for Rx & almost for Tx
> http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=a2d8d3d88c6d
> 
> 03/05: cx23885: Add integrated IR subdevice interrupt and notification handling
> http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=1eb199665dbc
> 
> 04/05: ir-functions: Export ir_rc5_decode() for use by the cx23885 module
> http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=55a1e2e8128f
> 
> 05/05: cx23885: Add IR input keypress handling and enable for the HVR-1850
> http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=b05a093688a2


relies on the current implementation

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=include/linux/kfifo.h;h=ad6bdf5a5970c5fdbceb6b5c440a196b7a620b22;hb=HEAD

that still requires a spinlock.  Fortunately, I happen to need a
spinlock.


I'd like this changeset to move forward, and I don't want to have a
problem with unfortuante timing of any kfifo changes.

Should I plan to

1. leave my code alone and use the current kfifo API,
2. update my use of kfifo to the new proposal I saw on the LKML
recently, or
3.  just write my own fifo implementation and port to the new kfifo
later?


Regards,
Andy

--
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/