processor namespace

[Holger Macht]

On Wed 23. Aug - 22:05:14, Holger Macht wrote:
> On Wed 23. Aug - 21:32:15, Kay Sievers wrote:
> > On Wed, 2006-08-23 at 21:11 +0200, Holger Macht wrote:
> > > On Wed 23. Aug - 21:51:21, S.Çağlar Onur wrote:
> > > > Çarşamba 23 Ağustos 2006 20:44 tarihinde, Holger Macht şunları yazmıştı: 
> > > > > The processor namespace is currently only valid for ACPI. And basically
> > > > > CPU frequency scaling has nothing to do with ACPI.
> > > > 
> > > > I see, but maybe we can add current_frequency and into processor namespace as 
> > > > it is provided by /proc/cpuinfo [with making 
> > > > hald/linux/acpi.d:get_processor_model_name more generic and moving into 
> > > > hald/linux/util.c?]
> > > > 
> > > > > Hm, I think simple shell scripts can parse /sys/.../scaling_cur_freq
> > > > > manually?
> > > > 
> > > > Ok, here is what i want to do. Sorry for previous cryptic mails.
> > > > 
> > > > I'm trying to write a notification system [1] using libnotify, and for example 
> > > > inform the user when frequency changed. So what i want to just connect to it 
> > > > on bus and wait for a signal instead of polling. Or getting free size from 
> > > > volumes, libhal provides volume.size, volume.block_size but not 
> > > > volume.free_size. 
> > > 
> > > But HAL would have to poll too.
> > > 
> > > > 
> > > > So i just want to know is there any way to get these informations with hal 
> > > > that currently i dont know, or will be included next releases or i have to 
> > > > handle these :)
> > > 
> > > Currently there is no way to get this information via HAL. And I also
> > > don't think it makes sence to add it. As long as the kernel is responsible
> > > to change frequencies, which is the majority of the time, and he doesn't
> > > export these changes to userspace, there's no possibility other than
> > > polling.
> > 
> > The kernel can wake up a process sleeping in poll() of a sysfs file. If
> > there is a kernel frequency transition, it would just need to send an
> > fsnotify() for the file, so processes can wait for a change without
> > periodically polling.
> > 
> > We already do the same for /proc/mounts with HAL, where poll() trows an
> > error to let the application waiting in poll() to reread the whole file.
> > 
> > Sounds like this could also work for the cpufreq representation in
> > sysfs?
> 
> Yes, this should be possible. But frequency transitions are very frequent,
> so I don't know how relevant performance issues would be...

And I don't know if it makes sence to add this to the kernel just for the
sake of the user getting realtime CPU frequency information. In my opinion
it is enough that the user gets the current frequency as soon as he
requests it. That should be enough IMO. I can't image any other real use
case at the moment.

Regards,
 	Holger