On Tue, Sep 12, 2006 at 01:05:29AM +0200, Pavel Machek wrote: > 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. > I disagree. > > >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.> The PowerOP patch has nothing to do with the removal of cpufreq. You may be confusing this work with the david signleton patch. --mgross
