On 06/18/2014 09:47 PM, Jonathan Cameron wrote:
On 07/10/13 15:18, Lars-Peter Clausen wrote:
On 10/06/2013 08:15 PM, Jonathan Cameron wrote:
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...
Unfortunately yes. I never liked its API and I still don't like it and we
have to live with it. But this doesn't mean we have to add more of the same.
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 ;)
I'll do that but that might take a few weeks until I get to it.
Bump. Do we want to still wait for this, or should we just go ahead with the
hrtimer as is. It may not be ideal, but it's useful and lets us kill off
some much worse options..
I'd really prefer to not compromise on user-space ABI. Quick hacks are
sometimes fine for kernel internal things since we can clean them up later.
But for userspace ABI we'll be stuck with it forever.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
