On Mon, 29 Oct 2007 23:22:39 +0100
Matthias Drochner <M.Drochner@fz-juelich.de> wrote:

> 
> juan@xtrarom.org said:
> > a few people prefered to make coretemp(4) a real autoconf(9) driver
> > rather than an option, I've heard complaints about options being
> > unhelpful for LKMs for example. 
> 
> I've been working on cleanups of autoconf structures a lot, but
> this one goes a bit too far imho.
> Realistically, a cpu(4) driver won't be an LKM. And if envsys(9)
> was, there would be easier ways to deal with this: Perhaps make
> sysmon_envsys_register(9) et al. hooks which are noops unless
> envsys is pulled in.
> (I didn't look at details yet, please take this with a grain of salt.)
> 
> > IMHO it's more logical to me to attach coretemp(4) at cpu, because
> > there's a sensor per cpu.
> 
> Most CPUs don't, and there are also cases like Intel HT where CPUs
> are just logical entities.
> I'd say the autoconf goo would be a waste here; the act of registering
> a possibly interesting source of environmental information shuld be
> by the device which provides it -- the CPU temperature being registered
> by the cpu, not cpu->coretemp.

Ok, this is how is done actually. Quentin and you agreed on this,
and I believe the overhead of converting this to a real driver doesn't
provide much gain.

I'll leave the code as is, unless someone provides better arguments for
coretemp to be a real autoconf driver.

Cheers,
-- 
Juan Romero Pardines	- The NetBSD Project
http://plog.xtrarom.org	- NetBSD/pkgsrc news in Spanish