linux-kernel - Re: [PATCH v3 1/3] iio: configfs: Add configfs support to IIO

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:	Wed, 8 Apr 2015 16:30:27 +0300
From:	Daniel Baluta <daniel.baluta@...el.com>
To:	Daniel Baluta <daniel.baluta@...el.com>
Cc:	Jonathan Cameron <jic23@...nel.org>,
	Joel Becker <jlbec@...lplan.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Hartmut Knaack <knaack.h@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"octavian.purdila@...el.com" <octavian.purdila@...el.com>,
	Paul Bolle <pebolle@...cali.nl>, patrick.porlan@...el.com,
	adriana.reus@...el.com
Subject: Re: [PATCH v3 1/3] iio: configfs: Add configfs support to IIO

On Mon, Apr 6, 2015 at 5:18 PM, Daniel Baluta <daniel.baluta@...el.com> wrote:
> This module is the core of IIO configfs. It creates the "iio" subsystem under
> configfs mount point root, with one default group for "triggers".
>
> It offers basic interface for registering software trigger types. Next patches
> will add "hrtimer" and "sysfs" trigger types. To add a new trigger type we must
> create a new kernel module which implements iio_configfs_trigger.h interface.
>
> See Documentation/iio/iio_configfs.txt for more details on how configfs
> support for IIO works.
>
> Signed-off-by: Daniel Baluta <daniel.baluta@...el.com>

Hi all,

I also need your feedback on the following problem.

We would like to be able to create hrtimer triggers from within
a kernel module. There are cases where we don't have an interrupt
pin or the interrupt pin is not connected, and we would like
that applications to run unmodified with these types of sensors too.

We will split the current design into 3 parts:

(1) IIO trigger handling generic part, which offers an API
     to register/unregister/get a reference to a trigger type

(2) IIO configfs part that gets a reference to a trigger type and
handles user requests to create/destroy a trigger.

(3) IIO hrtimer driver that use the API at (1) for registering
/ deregistering a trigger type.

Then, each driver in the case that it doesn't have a "real" trigger,
will get a reference to a "hrtimer" trigger type and create
a new "hrtimer" trigger.

Does this look good to you? This could be easily done from
userspace, but we will need to modify our userspace applications.

Also, handling sampling_frequency/delay would be transparent to
applications if we provide this in kernel API.

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