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). Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
