linux-kernel - Re: [RFC] Staging: IIO: New ABI V2

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]

Message-ID: <20100216024924.GA29008@suse.de>
Date:	Mon, 15 Feb 2010 18:49:24 -0800
From:	Greg KH <gregkh@...e.de>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dtor@...l.ru>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	Robin Getz <rgetz@...ckfin.uclinux.org>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	Ira Snyder <iws@...o.caltech.edu>,
	Jean Delvare <khali@...ux-fr.org>,
	Samu Onkalo <samu.p.onkalo@...ia.com>,
	Stefani Seibold <stefani@...bold.net>
Subject: Re: [RFC] Staging: IIO: New ABI V2

On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> > On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
> >> Here is another iteration of the ABI spec for IIO with changes made
> >> in response to http://lkml.org/lkml/2010/1/20/195 and
> >> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
> >> other general tidy ups.
> >>
> >> If there are no major issues raised, we may begin working on the move
> >> to this ABI shortly on the basis any minor changes can always get
> >> cleaned up before those patches merge. ??I'll also be doing a formal
> >> version of this file for in kernel documentation once things are
> >> fairly stable with all of the information not relevant to this
> >> discussion.
> >>
> >> Changes since v1:
> >>
> >> * iio is now a bus with directory changes resulting in this document.
> >> * moved to in0_raw etc for voltage sensors to avoid confusion with
> >> ?? a completely different ABI from hwmon. ??Jean made the point that
> >> ?? we shouldn't take this to far, but as things currently stand there
> >> ?? is no disadvantage in this name change.
> >> * dropped freefall event for now. More discussions need to be had on this
> >> ?? and in a straight IIO world we normally won't care about this one anyway.
> >> * 'device' naming changed for the various subsidiary devices so as make
> >> ?? the interconnections more obvious. ??I haven't tried implementing this
> >> ?? yet, but I think the small amount of pain involved is worth it for
> >> ?? increased clarity. The only exception is triggers where the connections
> >> ?? are not specified as a given trigger may not have and IIO device
> >> ?? associated with it. ??Anyone suggest a scheme for this? (see about 10
> >> ?? lines below to clarify what I mean here!)
> >> * As conversion of the max1363 driver over to a consistent scan_element
> >> ?? interface will mean that these will only apply to the ring buffer
> >> ?? (rather than direct capture), scan_elements is moved into the ring
> >> ?? buffer device directory.
> >> * Switch ring for simply buffer as it might be a fifo or other buffer
> >> ?? form instead.
> >>
> >> At times I may have suppressed links that would be created by the tree of
> >> devices. In the flat base directory a given driver can now create the
> >> following:
> >>
> >> device[n]
> >> device[n]:ring
> >> device[n]:ring:access
> >> device[n]:ring:event
> >> device[n]:event[m]
> >> trigger[o]
> >>
> >
> > What exists today still requires a copy_[to|from]_user when using the ring
> > buffer (and then another cache_flush if you are dma'ing things). These seems
> > pretty expensive and will consume extra cycles that will limit throughput.
> >
> > Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
> > system could avoid some of the above overhead? (This is what we had to do for
> > some other drivers - which were able to handle a 40 MSample/second data
> > processed by userspace for a soft radio).
> 
> does sysfs currently support mmap-ing of files in there ?

For binary files, yes.  If you are going to use mmap, use a character
device node instead please, that's not what sysfs is for.

thanks,

greg k-h
--
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/