linux-kernel - Re: [lm-sensors] Accelerometer etc subsystem (Update on progress)

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]

Message-ID: <48665A09.9090705@cam.ac.uk>
Date:	Sat, 28 Jun 2008 16:34:33 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Ben Nizette <bn@...sdigital.com>
CC:	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	mgross@...ux.intel.com, Dmitry Torokhov <dtor@...l.ru>,
	linux-kernel@...r.kernel.org,
	LM Sensors <lm-sensors@...sensors.org>, hmh@....eng.br,
	spi-devel-general@...ts.sourceforge.net,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: Re: [lm-sensors] Accelerometer etc subsystem (Update on progress)

Hi Ben,
>>> union channel {
>>> 	char data[2];
>>> 	int16_t val;
>>> }
>> Good point, I'd forgotten you could do that with unions.
> 
> Cool, just watch endianness of course :-)
> 
That and the annoyance of alignment issues making that approach taking way more
space that you'd think.
>>> Incidentally, is there much that your ringbuffer can do which kfifo
>>> can't?  Apart from having a bunch of extra nice accessor-helpers sitting
>>> on the top.
>> Not sure, I'll look into it.
> 
> kfifo won't be a drop in replacement, it's just a very simple ring fifo.
> I suspect your higher level ring buffer accessors and allocators could
> live on top of it though.
Sure, but from my understanding of kfifo it takes a much more symmetric
approach to reading and writing with locking used to prevent them occuring
concurrently.  You obviously can use it without locking but I don't believe
that it provide any facility for coping with the nasty case, (buffer full
and hence during read attempts a certain amount of what is copied out may
have become invalid).  It maybe the case that, as you say suitable high level
functions on top of a kfifo would be a good way to proceed (afterall,  kfifo
is well tested etc), but I fear, given how little of kfifo's code would actually
be used it would be more likely to cause problems than not. 

It might be best to leave this decision until the exact requirements of the ring
buffer are actually known.

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/