On 15/11/17 18:37, Rafael J. Wysocki wrote: > 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. :-) > Agreed. > 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). > I was thinking of keeping it simple and just one file for all the stats like we have /sys/kernel/debug/clk/clk_summary It looks somethings like below: clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------- juno:uartclk 1 2 7273800 0 0 ... > 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? > That's the idea. IIUC, this is basically useful in the initial days of development to tune your idle parameters and for idle characterization. I am not sure(and hope) that this will be consumed by some application and acted upon dynamically. It's more like collect data, analyze, tune, repeat and rinse until happy with the tuning. Prashanth/Timur, please correct me if that's not the case. Understanding how the data is used is essential here. -- Regards, Sudeep -- 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
