linux-kernel - Re: [PATCH 1/4] input: Introduce buflock, a one-to-many circular buffer mechanism

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Jun 2010 18:08:39 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Henrik Rydberg <rydberg@...math.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Rafi Rubin <rafi@...s.upenn.edu>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH 1/4] input: Introduce buflock, a one-to-many circular
 buffer mechanism

On 06/04/10 09:43, Henrik Rydberg wrote:
> Hi Dmitry,
>>> +struct buflock_writer {
>>> +	unsigned int head;
>>> +	unsigned int next_head;
>>> +};
>>
>> Since there can be only one writer thread should we just create "struct
>> buflock" and pull head and next head into it along with the buffer
>> itself and element size?
> 
> It is possible, but there are some arguments against it:
> 
> 1. What type to give the buffer?
> 2. Static or dynamic buffering?
> 3. Can size be both a compile-time constant and a variable?
> 
> In short, I think that by _not_ including the actual buffer, the method
> ultimately becomes more useful.
> 
>> Also, maybe we could extend kfifo with the notion of multiple readers?
> 
> If merging the data and algorithm as you suggest, that would be a logical step,
> yes. To me, the most ideal would be to modify split the kfifo into data, writers
> and readers. But that would require api changes.
> 
>>
>> In any case, it shoudl not live in include/linux/input/ as it may be
>> useful ouside of input subsystem.
> 
> Agreed.
I've just opened a debate on linux-iio about whether we want our event infrastructure to
support multiple readers. If enough people care, then this looks like some infrastructure
we will be wanting to use as well so I would definitely support putting this outside 
of input.

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