Hi! (cc-ed to lkml). > >>Just as a data point, "keeping the cpufreq interface" is > >>irrelevant to a number of us, because we configure it out > >>of the system. I'm not really arguing that we should get > >>rid of an existing kernel interface, but I don't see any > >>reason why we shouldn't be able to have a separately > >>configurable interface if cpufreq doesn't meet our needs. > > > >Configurable interfaces are evil, > Are you saying that not having sysfs attribute nodes for entities which > don't exist in a certain configuration is evil? I'm saying that #ifdef CONFIG_FOO provide user<->kernel interface #endif is evil. > >patch. You have developed your own little interface that suits your > >needs -- and that's fine -- but now you are trying to push it into > >mainline... and that is not, because those interfaces were not really > >designed to work together. > once cpufreq userland interface functionality which does not belong to the > kernel is moved out of the kernel cpufreq interface becomes a subset of > PowerOP sysfs interface. In other words this means that improvements of PM > stack layers/interfaces design will allow to design/develop an universal > userspace interface. We'd prefer to move gracefully in this direction > though. <tongue-in-cheek warning> Yes, once cpufreq userland interface is removed from kernel, merging powerop is reasonable thing to do. But please get at least Documentation/feature-removal-schedule.txt patch merged to mainline before attempting next powerop submission :-P. <I'm trying to explain that removing cpufreq userland interface is about as probable as MS Linux, and only a bit less likely than hell freezing over.> Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
