"Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> writes: > You seem to be getting confused as to what the *actual* userspace > expectation was, in that mail thread. The expectation was that suspend/ > resume is a kernel operation that brings back the system to the same > state (as much as possible) at the end of resume, as it was before > suspend. And that is a perfectly valid expectation, and it is something > that the kernel has to try its level best to honor. Our understanding of the thread is obviously biased by our respective views of the matter ;-) > And in this particular case, the specific expectation was that the sysfs > file permissions set by the user for cpufreq files will remain as it is > even after a suspend/resume cycle. That's it. There is _absolutely_ _no_ > talk about CPU hotplug here. This is not a cpufreq problem. It is a CPU problem. You are only complicating things by trying to solve it in cpufreq. What about permissions on the other CPU sysfs attributes? > Robert _happened_ to dig this further and observe that suspend/resume > actually does offline/online of CPUs, and thought that he should have > also seen the associated udev events as well. But we have purposefully > not exposed the fact that suspend/resume involves CPU hotplug. Well, that is a bug in my opinion. You are adding lots of kernel code to avoid a very simple userspace configuration. Seems very backwards. This is mostly a documentation problem, if a problem at all. I do note that Robert did try the udev way before concluding that this was a kernel bug. > Today, > suspend/resume uses CPU hotplug internally because we don't have any > other better alternative. The very concept/semantic of suspend/resume > _does_ _not_ imply CPU hotplug - it is just an implementation detail > that userspace should not need to care about or rely on. > > Moreover, cpufreq is not the only subsystem that participates in suspend/ > resume and CPU hotplug. And fundamentally, regular CPU hotplug has _very_ > different semantics and guarantees than the hotplug done in suspend/resume. > For example, if you offline CPUs normally, the cpusets associated with > those CPUs will get destroyed, potentially in ways that _won't_ bring > them back to the same state when you online those exact same CPUs! > And this would have been totally unacceptable to a user innocuously > using suspend/resume. Look at commit d35be8bab9 (CPU hotplug, cpusets, > suspend: Don't modify cpusets during suspend/resume), for more details > on how we fixed that problem. Yes, I do see that point. The special suspend/resume handling is definitely necessary in this case. > So, to summarize, suspend/resume should mean one simple thing to > userspace - "the kernel will transparently (to the extent possible) > perform suspend/resume and bring back the system during resume, to a > state as close as possible compared to how it was before suspend". > Any implementation challenges must be handled in the kernel (as far as > possible), and we should avoid burdening userspace with extraneous > events etc. OK, I think we may have different views on how much kernel implementation details userspace need to know :-) That's fine, and it really was not my intention to question the way cpufreq handled this. It all just seemed so meaningless to me. I now understand that it has a meaning to you, which of course is what matters. I am glad I could help removing the most obvious bugs. Bjørn -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
