On Wed, Nov 15, 2017 at 7:14 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > On 15/11/17 15:33, Timur Tabi wrote: >> On Wed, Nov 8, 2017 at 8:18 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >>> I still prefer this as debugfs and not as sysfs ABI. We already have >>> issues with multiple interfaces for the same thing. E.g. cpufreq on x86. >>> I don't want this to end up in the same way after few years. CPUIdle >>> sysfs should be only sysfs ABI for these, adding an alternative is >>> inviting troubles for future especially if some user-space starts using >>> it and we will be stuck with that. Moreover with more h/w controlled >>> idle we may not provide accurate data sooner. >>> >>> Sorry for the noise, I will shup up now ;). Since this may be last >>> chance to make some noise, I am trying it. I completely understand that >>> this is just my opinion and am fine if others thinks it's good to make >>> this sysfs ABI. >> >> Unfortunately, I think Prashanth really needs a specific requirement >> rather than opinions. > > I completely understand that. So for I haven't got a solid reason as > why debugfs is not sufficient? If it becomes so popular in future, we > can discuss and then make it sysfs ABI with more thoughts/discussions. Well, the recent discussions regarding tracepoints indicate that the ABI rule is not really about where the stuff is located in the directory structure. :-) The main question to me is whether or not the information exposed is more suitable for debugfs or for sysfs, considering all of the limitations (like one value per file rule in sysfs etc). Of course, debugfs means that the users of, say, Android will not be able to access this information, but should that really influence decisions at the technical level? >> This patch has been languishing for over a month, and we still have >> no idea whether it will make 4.15 or if Prashanth is *required* to >> make any more changes. >> > > It's sysfs ABI which we need to support for very long time(not in months > but in years), so waiting/discussing for couple of months is much safer > than spending more time to keep it the sysfs ABI unbroken. In either case we need to be sure that the information is exposed the way everybody (who cares) likes and there won't be future attempts to tweak it to some needs that were not expressed at the outset. IOW, I'd like more people to look at this and let me know what they think. > Also I assume(was explicitly mentioned IIRC) that it's purely used > for debug and tuning purposes and hence I see *no need* to be part of > *sysfs ABI*. Let me know if the circumstances have changed. And that is a good argument for putting it into debugs. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
