linux-kernel - Re: [PATCH 0/1] RFC: new kqueue API

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]

Date:	Sun, 13 Dec 2009 22:11:56 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	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>,
	Roger Quadros <quadros.roger@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Shargorodsky Atal <ext-atal.shargorodsky@...ia.com>
Subject: Re: [PATCH 0/1] RFC: new kqueue API

Am Sonntag, den 13.12.2009, 19:37 +0100 schrieb Andi Kleen:
> On Sun, Dec 13, 2009 at 11:37:13AM +0100, Stefani Seibold wrote:
> > As i figured out during the port the old kfifo API users, most of them
> > did not need a streamed fifo, because there work only with fixed size
> > entries. The kfifo is oversized for this kind of users, so i decided to
> > write a new kqueue API which is optimized for fixed size entries. 
> > 
> > There are a some benefits:
> > 
> > - Performance (a put or get of an integer does only generate 4 assembly
> > instructions on a x86) 
> > - Type save
> > - Cleaner interface
> > - Easier to use
> > - Less error prone
> > - Smaller footprint
> > 
> > The API is similar to the new kfifo API, but there is no need for a
> > length paramter, because the size of the entry is know by the queue
> > structure.
> 
> I must say I'm a bit sceptical if the advantages are really worth
> the additional code. That code would be always compiled in in addition
> to kfifo, so at least the code footprint would be always larger.
> 

The additional code is very tiny... less than 1 kb ;-) Changing the
fixed size user to the new kqueue API would result on the other side in
less footprint and a much better performance.

> Perhaps you could get the advantages for type-safety using
> inline wrappers to kfifo?
> 

No, i have no idea how to do this. If you give me the okay to use C++ it
could be easy done with templates (just kidding...)

The next step after merging of the new kfifo API would be the
deinlineing of the code... This will also reduce the footprint of the
kfifo API users, but not as much as with the kqueue API.

But have a look to the new interfaces. It is quite simple and natural to
use and faster than light ;-)

Stefani


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