Adds additional CPU details fields.

Martin S. compiz at sukimashita.com
Mon Oct 6 15:09:17 PDT 2008


On Mon, 2008-10-06 at 15:59 +0200, Danny Kukawka wrote:
> On Donnerstag, 4. September 2008, Martin S. wrote:
> > See http://lists.freedesktop.org/archives/hal/2007-April/007978.html
> > and http://media.sukimashita.com/temp/00-hal-processor-cpuinfo-1.png
> 
> If I have to choose between these two patches I would (if it make sense to add 
> massive cpuinfo parsing to HAL at all) prefer this older patch (with the 
> changes I proposed in my answer to your mail) because it tries to take care 
> about non ix86 archs. But I guess this one would need some changes to fit in.

I can update the patch to match latest git and remaining requirements if
it has a chance to get accepted.

> > Also, did you think about:
> > - FreeBSD? Solaris?
> > - That different CPUs expose different cpuinfo labels?
> > - PPC? ARM? IA64? Sparc? ...
> 
> That's the problem with this patch. It will only work on ix86 archs. For all 
> other archs it wouldn't work because every arch (ppc/ppc64, Cell, s390/s390x 
> ia64) provides a different format for cpu information in proc.
> 
> The most information you try to abstract with your patch are not available for 
> non ix86 archs. I have some doubt that it make sense to introduce an 
> abstraction only for one arch.

Any thoughts on if my patch deals with this?
I think most of the stuff is constified and we already parse cpuinfo
thus this does not add much overhead anyways.

> Personally I would prefer to force the kernel guys to provide a usable for all 
> arch common sysfs interface instead of this mess in /proc/cpuinfo.

As noted, there are (old) kernel cpuinfo->sysfs patches floating around
and it takes quite some effort to introduce such a change among ALL
archs in a consistent way (every arch takes a different approach
providing the cpuinfo and it's not trivial).

But as I noted in the last discussion about it:
I think that we can actually do both, provide cpuinfo parsing on
supported archs AND later on adjust the same code to deal with a new
sysfs type of cpu information without loosing the higher level defined
HAL processor abstraction defined in the specs once sysfs support has
landed (at some distant point in the future).

Until then some essential but required information will be available in
HAL and tools using HAL won't have to be updated once the sysfs support
is in.

--- Martin S.

> Danny 
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal
> 



More information about the hal mailing list