cpufreq and 2.4.

cpufreq and 2.4.

[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. 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

Re: cpufreq and 2.4.

[Ducrot Bruno]

On Sun, Aug 17, 2003 at 05:35:10PM +0200, Dominik Brodowski wrote:
> (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.? 
> 

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.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: cpufreq and 2.4.

[Bas Mevissen]

Ducrot Bruno wrote:

> 
>>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.
> 

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.

Re: cpufreq and 2.4.

[Ducrot Bruno]

On Mon, Aug 18, 2003 at 12:14:26PM +0200, Bas Mevissen wrote:
> Ducrot Bruno wrote:
> 
> >
> >>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.
> >
> 
> 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.

> 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,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: cpufreq and 2.4.

[Bas Mevissen]

Ducrot Bruno wrote:

> 
> 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.

>>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.

Re: cpufreq and 2.4.

[Bas Mevissen]

Dominik Brodowski wrote:

> 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.
> 

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.

> 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?
> 

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.

Re: cpufreq and 2.4.

[Russell King]

On Mon, Aug 18, 2003 at 12:47:36PM +0200, Bas Mevissen wrote:
> Dominik Brodowski wrote:
> > 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.
> 
> 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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: cpufreq and 2.4.

[Bas Mevissen]

Russell King wrote:

> 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.

Re: cpufreq and 2.4.

[Russell King]

On Mon, Aug 18, 2003 at 02:13:53PM +0200, Bas Mevissen wrote:
> Russell King 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.

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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: cpufreq and 2.4.

[Dominik Brodowski]

On Mon, Aug 18, 2003 at 12:47:36PM +0200, Bas Mevissen wrote:
> >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?
> >
> 
> 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.)

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

Re: cpufreq and 2.4.

[Ducrot Bruno]

On Mon, Aug 18, 2003 at 08:00:12PM +0200, Dominik Brodowski wrote:
> On Mon, Aug 18, 2003 at 12:47:36PM +0200, Bas Mevissen wrote:
> > >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?
> > >
> > 
> > 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.)
> 
> 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,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: cpufreq and 2.4.

[Bas Mevissen]

Ducrot Bruno wrote:
> 
>>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.

Re: cpufreq and 2.4.

[Bas Mevissen]

Dominik Brodowski wrote:
> 
 >> (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.

Re: cpufreq and 2.4.

[Ducrot Bruno]

On Tue, Aug 19, 2003 at 10:45:33AM +0200, Bas Mevissen wrote:
> Dominik Brodowski wrote:
> >
> >> (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).
> 

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.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.