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:	Fri, 10 Apr 2015 16:43:16 +0300
From:	Daniel Baluta <daniel.baluta@...el.com>
To:	Jonathan Cameron <jic23@...nel.org>
Cc:	Daniel Baluta <daniel.baluta@...el.com>,
	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 Thu, Apr 9, 2015 at 8:18 PM, Jonathan Cameron <jic23@...nel.org> wrote:
> On 08/04/15 14:30, Daniel Baluta wrote:
>> 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.
> A reasonable aim perhaps, as opposed to locally implemented polling
> all over the place (which should definitely not happen).

Yes, exactly! :)

>
> An alternative the zio guys used was to create timer
> based triggers on the fly purely based on them being requested
> (with an appropriate name IIRC)...  Doesn't quite solve your
> problem though as still needs userspace changes.
>>
>> 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.
> My initial thought is this really is a job for userspace, as should
> be in most cases connecting up the device specific trigger as well
> (as it's not always the right thing to use).
>
> In the general case it is far from obvious that an hrtimer is the
> right option.  Many usecases would be better off with a sysfs trigger
> or even running off a different interrupt based trigger entirely.
>>
>> Also, handling sampling_frequency/delay would be transparent to
>> applications if we provide this in kernel API.
> Not really as sampling frequency in this case should only be an
> attribute of the trigger, not the device.  We only really allow
> it for the device rather than always the triggers on the basis
> that it has impacts on other device elements (events etc).

Well, if the trigger is directly created from the driver then we will
have a reference to a function that sets its delay.

Each time the user sets the sampling frequency for the device
with hit write_raw and there on IIO_CHAN_INFO_SAMP_FREQ
case we also call set_delay(). Thus we always have have device
sampling frequency in sync with trigger delay.

I know this sounds crazy :) and I don't like it. I am not sure how
to guarantee that device frequency is always in sync with trigger
delay.

>
> Now sensible userspace ought to search for the trigger sysfs
> directory and look there as well.
>
> I suppose if there is an awful lot of demand for this function
> we could add a control knob somewhere that would set a 'default
> trigger type' to be created for buffered devices that haven't
> provided their own...  I'm not overly keen though.
>>

This functionality would be very nice and useful, lets see if we can
find some elegant way to do it.
--
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/