linux-kernel - Re: IIO comments

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:	Thu, 17 Mar 2011 14:42:42 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Kay Sievers <kay.sievers@...y.org>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Guenter Roeck <guenter.roeck@...csson.com>
Subject: Re: IIO comments

On 03/17/11 13:47, Arnd Bergmann wrote:
> I just went back to the older email and noticed that I missed some of your
> important replies.
> 
> On Wednesday 16 March 2011, Jonathan Cameron wrote:
>>> I'm slightly confused, mainly because I have no idea how the
>>> buffer and event interfaces are actually being used. I would
>>> have expected an interface as simple as:
>>>
>>> * One iio device per sensor that can provide data, possibly
>>>   many per hardware device
>>
>> One per device.
> 
> I'm not sure what that means. One iio device per hardware device?
Oops. That was particularly unclear!
> 
> What about hardware devices that have multiple unrelated streams
> of buffered input data?
Certainly plausible, but so far the only ones I've seen that actually
do this are really just two bits of silicon in the same plastic
package.  They tend to use different i2c addresses or spi chip
selects anyway so as far as the kernel is concerned are completely
separate.  You are correct that any device which truly has different
streams of data would indeed need more than one device.
> 
>>> * One chardev for each iio device
>>
>> currently 1-3. (event line, buffer access, buffer event)
> 
> It would be really nice to unify this, as I said. What
> are the reasons why you think it cannot or should not be
> done?
Simplicity perhaps, but I'll definitely give your suggestions
a go and see where we end up. 
> 
>>> * Use epoll to wait for data and/or out-of-band messages
>>> * Use chrdev read to get events from the buffer
>>
>> and data?
> 
> I mean get the data associated with the event. The event
> itself as you said does not have any data, so we would not
> need to read it, just to use poll()/epoll() in order to
> wait for it.
Sure. But devices can do a heck of a lot of different events.
(certainly 10's or maybe more).  I'm not immediately clear
on how to handle this via poll etc.  This is probably just
because I've never tried though!
> 
>>> * Use sysfs to read from sensors that are not event based
>>>
>>> What you have is obviously more complex than this, and you
>>> probably have good reasons that I still need to understand.
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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