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 > > > -- 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
