cpufreq and 2.4.
(Again) some talk about the chances of cpufreq getting merged into 2.4. As previous cpufreq maintainer, and creator of several 2.4.-backports of cpufreq, here's some input on this matter, especially the problematic aspects:
A) Previous 2.4. cpufreq included in parts of kernel
There _is_ already some cpufreq code in the 2.4. kernel. In arch/arm there are ARM-cpufreq drivers which use the previous 2.4. stable series of cpufreq which nobody uses on x86 any more [I guess]. In 2.6., the ARM cpufreq drivers are updated. However, this isn't included in the current 2.4. backports.
B) Difficult-to-understand cpufreq user interfaces
The /proc/cpufreq and /proc/sys/cpu interfaces are difficult to understand and already deprecated in 2.6. Do we really want them to be added to a stable kernel release?
C) No documentation for 2.4. cpufreq user interfaces
As they're deprecated, I didn't explain them in the 2.6. kernel Documentation (Documentation/cpu-freq/user.txt). However, if it really should be documented well if it gets into the 2.4. stable series.
D) Who?
Who is going to do C), and who will keep track of cpufreq-2.4.?
Just my ¤0.02
Dominik
Quoted 17 lines · Dominik Brodowski
(Again) some talk about the chances of cpufreq getting merged into 2.4. As previous cpufreq maintainer, and creator of several 2.4.-backports of cpufreq, here's some input on this matter, especially the problematic aspects:
A) Previous 2.4. cpufreq included in parts of kernel
There _is_ already some cpufreq code in the 2.4. kernel. Inarch/armthere are ARM-cpufreq drivers which use the previous 2.4. stable series of cpufreq which nobody uses on x86 any more [I guess]. In 2.6., the ARM cpufreq drivers are updated. However, this isn't included in the current 2.4. backports.B) Difficult-to-understand cpufreq user interfaces
The/proc/cpufreqand/proc/sys/cpuinterfaces are difficult to understand and already deprecated in 2.6. Do we really want them to be added to a stable kernel release?
Quoted 8 lines
C) No documentation for 2.4. cpufreq user interfaces
As they're deprecated, I didn't explain them in the 2.6. kernel Documentation (Documentation/cpu-freq/user.txt). However, if it really should be documented well if it gets into the 2.4. stable series.D) Who?
Who is going to do C), and who will keep track of cpufreq-2.4.?
My poor english prevent me to do C) (but perhaps a kind soul with good french knowledge and good english may assist me ?)
I can track cpufreq-2.4 if really needed.
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 6 lines · Ducrot Bruno
Quoted 6 lines
C) No documentation for 2.4. cpufreq user interfaces
As they're deprecated, I didn't explain them in the 2.6. kernel Documentation (Documentation/cpu-freq/user.txt). However, if it really should be documented well if it gets into the 2.4. stable series.
Quoted 7 lines
Quoted 2 lines
D) Who?
Who is going to do C), and who will keep track of cpufreq-2.4.?My poor english prevent me to do C) (but perhaps a kind soul with good french knowledge and good english may assist me ?)
I can track cpufreq-2.4 if really needed.
I guess my English is better than my French, so I'm happy to assist you with C) :-))
I think it to be a good way to learn about cpufreq internals by writing documentation for it.
Regards,
Bas.
Quoted 11 lines · Bas Mevissen
Quoted 9 lines · Ducrot Bruno
Quoted 8 lines
C) No documentation for 2.4. cpufreq user interfaces
As they're deprecated, I didn't explain them in the 2.6. kernel Documentation (Documentation/cpu-freq/user.txt). However, if it really should be documented well if it gets into the 2.4. stable series.D) Who?
Who is going to do C), and who will keep track of cpufreq-2.4.?
Quoted 7 lines
Quoted 4 lines
My poor english prevent me to do C) (but perhaps a kind soul with good french knowledge and good english may assist me ?)
I can track cpufreq-2.4 if really needed.I guess my English is better than my French, so I'm happy to assist you with C) :-))
You mean you can translate french documentations to english, correct? Anyway, I would probably have something at my site but only in French scheduled for the next week in order to get C) (can not be more fast at that time, sorry), and start an English version if nobody can not help me to translate.
Quoted 2 lines
I think it to be a good way to learn about cpufreq internals by writing documentation for it.
Unfortunately, I will do only C) which is the _user_ point-of-view of cpufreq.
(but perhaps I will start a RFC in order to get something similar to 2.6?)
Thanks,
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 7 lines · Ducrot Bruno
You mean you can translate french documentations to english, correct? Anyway, I would probably have something at my site but only in French scheduled for the next week in order to get C) (can not be more fast at that time, sorry), and start an English version if nobody can not help me to translate.
Well, I think your English is good enough to translate what you have from French to English.
My idea is to define what we want to have documented and then see what is there and what needs to be written and split that up somehow.
Quoted 5 lines
Quoted 1 line
I think it to be a good way to learn about cpufreq internals by writing documentation for it.
Unfortunately, I will do only C) which is the _user_ point-of-view of cpufreq.
Yes, but even from a user point of view you want to know what happens. I have no intention to write full documentation. But just a good description of what happens and how to let it happen.
Regards,
Bas.
Quoted 6 lines · Dominik Brodowski
A) Previous 2.4. cpufreq included in parts of kernel
There _is_ already some cpufreq code in the 2.4. kernel. Inarch/armthere are ARM-cpufreq drivers which use the previous 2.4. stable series of cpufreq which nobody uses on x86 any more [I guess]. In 2.6., the ARM cpufreq drivers are updated. However, this isn't included in the current 2.4. backports.
I think that the 2.4 backports should be as complete as possible. Currently, ARM-linux is on 2.4. But when 2.6 is out, they are very likely to go for 2.6 ASAP as power management is a lot better integrated in 2.6.
Quoted 5 lines
B) Difficult-to-understand cpufreq user interfaces
The/proc/cpufreqand/proc/sys/cpuinterfaces are difficult to understand and already deprecated in 2.6. Do we really want them to be added to a stable kernel release?
Well, what then? There is no sysfs in 2.4, so we need something else to control the beast :-)
How feasable is it to "port" the sysfs _interface_ to /proc? It would simplicate matters for users, cpufreqd and documentation as they only needs to change the "working directory" for 2.4.
(Because sysfs is something completely different than /proc, it would mean writing new code. But as 2.4 will be in use for a couple of years, I think it is worth the trouble.)
Regards,
Bas.
Quoted 8 lines · Bas Mevissen
Quoted 6 lines · Dominik Brodowski
A) Previous 2.4. cpufreq included in parts of kernel
There _is_ already some cpufreq code in the 2.4. kernel. Inarch/armthere are ARM-cpufreq drivers which use the previous 2.4. stable series of cpufreq which nobody uses on x86 any more [I guess]. In 2.6., the ARM cpufreq drivers are updated. However, this isn't included in the current 2.4. backports.
Quoted 4 lines
I think that the 2.4 backports should be as complete as possible. Currently, ARM-linux is on 2.4. But when 2.6 is out, they are very likely to go for 2.6 ASAP as power management is a lot better integrated in 2.6.
I don't think so. PM is still developing in 2.6, and there's a fair amount of work that needs to be done in that area. I'm not aware of anyone looking into this topic on "interesting ARM platforms" at present - the main focus today continues to be 2.4-based kernels.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 7 lines · Russell King
On Mon, Aug 18, 2003 at 12:47:36PM +0200, Bas Mevissen wrote:
I don't think so. PM is still developing in 2.6, and there's a fair amount of work that needs to be done in that area. I'm not aware of anyone looking into this topic on "interesting ARM platforms" at present - the main focus today continues to be 2.4-based kernels.
OK. What is better for ARM: what is in 2.4 now or a backport of what is in 2.6 now? The answer to that question helps Dominik in finding out what to do with the ARM stuff when backporting cpufreq from 2.6.
Regards,
Bas.
Quoted 9 lines · Bas Mevissen
Quoted 4 lines · Russell King
I don't think so. PM is still developing in 2.6, and there's a fair amount of work that needs to be done in that area. I'm not aware of anyone looking into this topic on "interesting ARM platforms" at present - the main focus today continues to be 2.4-based kernels.
OK. What is better for ARM: what is in 2.4 now or a backport of what is in 2.6 now? The answer to that question helps Dominik in finding out what to do with the ARM stuff when backporting cpufreq from 2.6.
I've mentioned that people need to speak up about their usage of the 2.4 cpufreq API on the ARM kernel list, and pointed them to this thread.
If no one responds in a few days, feel free to update 2.4 to the 2.6 API.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 9 lines · Bas Mevissen
Quoted 5 lines
B) Difficult-to-understand cpufreq user interfaces
The/proc/cpufreqand/proc/sys/cpuinterfaces are difficult to understand and already deprecated in 2.6. Do we really want them to be added to a stable kernel release?Well, what then? There is no sysfs in 2.4, so we need something else to control the beast :-)
Quoted 7 lines
How feasable is it to "port" the sysfs _interface_ to /proc? It would simplicate matters for users, cpufreqd and documentation as they only needs to change the "working directory" for 2.4.
(Because sysfs is something completely different than /proc, it would mean writing new code. But as 2.4 will be in use for a couple of years, I think it is worth the trouble.)
This seems to be a somewhat reasonable approach. However, it needs to be made clear that this interface will only be available on 2.4. kernels. /proc is bloated in 2.4., and so I don't mind, but for 2.6++ it should be aimed at removing unneccessary stuff from /proc, so I'd strongly oppose forward-porting this interface to 2.6.
Anyways, anyone willing to write the "cpufreq 2.4. sysfs-emulation /proc interface"?
Dominik
Quoted 18 lines · Dominik Brodowski
Quoted 9 lines · Bas Mevissen
Quoted 5 lines
B) Difficult-to-understand cpufreq user interfaces
The/proc/cpufreqand/proc/sys/cpuinterfaces are difficult to understand and already deprecated in 2.6. Do we really want them to be added to a stable kernel release?Well, what then? There is no sysfs in 2.4, so we need something else to control the beast :-)
Quoted 7 lines
How feasable is it to "port" the sysfs _interface_ to /proc? It would simplicate matters for users, cpufreqd and documentation as they only needs to change the "working directory" for 2.4.
(Because sysfs is something completely different than /proc, it would mean writing new code. But as 2.4 will be in use for a couple of years, I think it is worth the trouble.)
Quoted 9 lines
This seems to be a somewhat reasonable approach. However, it needs to be made clear that this interface will only be available on 2.4. kernels. /proc is bloated in 2.4., and so I don't mind, but for 2.6++ it should be aimed at removing unneccessary stuff from /proc, so I'd strongly oppose forward-porting this interface to 2.6.
Anyways, anyone willing to write the "cpufreq 2.4. sysfs-emulation /proc interface"?
Sorry if I wasn't clear. I think I may have something that week, or the next.
Cheers,
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 8 lines · Ducrot Bruno
Quoted 4 lines
Anyways, anyone willing to write the "cpufreq 2.4. sysfs-emulation /proc interface"?
Sorry if I wasn't clear. I think I may have something that week, or the next.
OK. Then I'll do testing and documentation. Can you send me what you have (on regular base) by mail? Please use sgm@... for that.
Regards,
Bas.
Quoted 10 lines · Dominik Brodowski
Quoted 3 lines
(make a cpufreq /proc interface for 2.4 that looks like sysfs interface in 2.6)
This seems to be a somewhat reasonable approach. However, it needs to be made clear that this interface will only be available on 2.4. kernels. /proc is bloated in 2.4., and so I don't mind, but for 2.6++ it should be aimed at removing unneccessary stuff from /proc, so I'd strongly oppose forward-porting this interface to 2.6.
OK. I second that we should not introduce a new /proc interface in 2.6. But then the question is what to do with the /proc interface in 2.6?
I would say, remove /proc in 2.6 ASAP. We need to align this with the update of the userspace governors (if they don't support sysfs already).
Regards,
Bas.
Quoted 14 lines · Bas Mevissen
Quoted 4 lines · Dominik Brodowski
Quoted 3 lines
(make a cpufreq /proc interface for 2.4 that looks like sysfs interface in 2.6)
Quoted 8 lines
This seems to be a somewhat reasonable approach. However, it needs to be made clear that this interface will only be available on 2.4. kernels. /proc
is bloated in 2.4., and so I don't mind, but for 2.6++ it should be aimed at
removing unneccessary stuff from /proc, so I'd strongly oppose forward-porting this interface to 2.6.
Quoted 6 lines
OK. I second that we should not introduce a new /proc interface in 2.6. But then the question is what to do with the /proc interface in 2.6?
I would say, remove /proc in 2.6 ASAP. We need to align this with the update of the userspace governors (if they don't support sysfs already).
I can't be sure at 100%, and rmk will know more than me, but I guess you will be blamed by ARM people if you remove /proc/sys/cpu/... stuff.
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.