From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>, Denis CIOCCA <denis.ciocca@st.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: IIO hrtimer trigger
Date: Sun, 06 Oct 2013 19:15:26 +0100 [thread overview]
Message-ID: <5251A8BE.9000309@kernel.org> (raw)
In-Reply-To: <524DA508.2030606@metafoo.de>
On 10/03/13 18:10, Lars-Peter Clausen wrote:
> On 09/29/2013 09:36 PM, Denis CIOCCA wrote:
>> Hi Lars,
>>
>> Thanks for your review.
>> I reviewed the code in accordance with your comments, for the other point
>> can you explain me better please?
>> You intend to use one driver to manage all triggers added by sysfs?
>
> Not necessarily, but I think we should have some common code that manages
> the software triggers.
That is fair enough.
> But what I'm most concerned about is the userspace
> ABI, since once we have added it, we have to maintain it forever. So the big
> question do we think that the current ABI implemented by that patch is good
> enough.
We are pretty much stuck with that for the sysfs trigger already...
> Some thoughts:
>
> * Should it maybe be called timer instead of hrtimer.
Agreed.
> * Do we only want to allow names which follow "hrtimer-%d" or do we want to
> allow arbitrary names.
Arbitary would be fine.
> * Do we want to have a top-level folder for each sw trigger type
I'm not that bothered about this we are hardly talking a huge number of such
folders.
> * Is sysfs actually the right place for this, or should it go into configfs?
> Quote from Documentation/filesystems/configs:
> "configfs is a ram-based filesystem that provides the converse of
> sysfs's functionality. Where sysfs is a filesystem-based view of
> kernel objects, configfs is a filesystem-based manager of kernel
> objects, or config_items. [...] Unlike sysfs, the
> lifetime of the representation is completely driven by userspace. The
> kernel modules backing the items must respond to this."
Hmm. maybe, I'm not sure how cleanly this would work and it adds an additional
dependency for all these types of drivers. I'll take the lazy option:
Go on Lars, put together a full proposal on the actual interface ;)
Another vague thought was the on demand creation of timer based triggers
that I think zio provides. Basically if a non existent trigger is requested
the subsystem figures out what is requested and creates it. Not terribly
nice to implement, and to my mind unnecessary and possibly confusing...
Jonathan
>
> I think especially the last one deserves some though.
>
> - Lars
>
>
>
next prev parent reply other threads:[~2013-10-06 17:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 19:36 IIO hrtimer trigger Denis CIOCCA
2013-09-29 19:36 ` [PATCH] iio:trigger: Added iio-hrtimer-trigger Denis CIOCCA
2013-10-03 17:10 ` IIO hrtimer trigger Lars-Peter Clausen
2013-10-06 18:15 ` Jonathan Cameron [this message]
2013-10-07 14:18 ` Lars-Peter Clausen
2014-06-18 19:47 ` Jonathan Cameron
2014-06-19 10:57 ` Lars-Peter Clausen
2014-06-19 14:42 ` Jonathan Cameron
-- strict thread matches above, loose matches on Subject: below --
2014-09-05 18:22 Ezequiel Garcia
2014-09-05 19:06 ` Lars-Peter Clausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5251A8BE.9000309@kernel.org \
--to=jic23@kernel.org \
--cc=denis.ciocca@st.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).