On Fri, Jul 29, 2011 at 11:46:21PM +0200, Rafael J. Wysocki wrote: > On Friday, July 29, 2011, mark gross wrote: > > On Fri, Jul 29, 2011 at 10:37:52AM +0200, Jean Pihet wrote: > > > Mark, > > > > > > On Thu, Jul 28, 2011 at 3:14 PM, mark gross <markgross@xxxxxxxxxxx> wrote: > > > > On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pihet@xxxxxxxxxxxxxx wrote: > > > >> From: Jean Pihet <j-pihet@xxxxxx> > > > >> > > > >> This patch set is in an RFC state, for review and comments. > > > >> > > > >> High level implementation: > > > >> > > > ... > > > > > > >> 7. Misc fixes to improve code readability: > > > >> . rename of the PM QoS implementation file from pm_qos_params.[ch] to pm_qos.[ch] > > > > I picked the name for the file as pm_qos_params over pm_qos because I > > > > wanted to make it implicitly clear that this was not an full QOS > > > > implementation. True QOS carries expectations similar to real time and > > > > as the infrastructure is closer to "good intentioned" than even "best > > > > effort" and offers no notification when the QOS request is not able to > > > > be met and really doesn't implement a true QOS at all, (it just provides > > > > the parameter interface for part of one its missing the notification > > > > interface when the service level is not met and I think a few other > > > > things.) So I wanted to have it named a bit different from just pm_qos. > > > > > > > > This said I'm not supper attached to the naming of the modules. If > > > > folks want to change it I wouldn't complain (too much anyway;). > > > Ok got the idea. I do not know what name to chose though. As suggested > > > previously the name pm_qos_params does not reflect the implementation, > > > that is why I renamed it. > > > > I must have missed the part where the name doesn't reflect the > > implementation was talked about. I look at the interface and I see > > parameters all over the place and a small bit of notification. > > The interface is for specifying PM QoS requirements or constraints that > may or may not be regarded as "parameters", depending on ones definition > of the last term. Moreover, the code not only implements the interface, > but also defines data structures and API to be used throughout the kernel > which is quite a bit more than just "parameters". > > In my not so humble opinion the name isn't good and the .c file should be > in kernel/power in the first place. I would call it simply qos.c (the fact > that _right_ _now_ it's not a full QoS implementation doesn't matter, because > it may become one in the future). Sounds ok to me. --mark _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
