Subject: Re: Attaching children to cpu (e.g coretemp* at cpu?) ?
To: None <M.Drochner@fz-juelich.de>
From: Juan RP <firstname.lastname@example.org>
Date: 10/30/2007 00:28:22
On Mon, 29 Oct 2007 23:22:39 +0100
Matthias Drochner <M.Drochner@fz-juelich.de> wrote:
> email@example.com 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.
Juan Romero Pardines - The NetBSD Project
http://plog.xtrarom.org - NetBSD/pkgsrc news in Spanish