From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 17:53:29 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D568016A468; Wed, 11 Jul 2007 17:53:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id A50ED13C459; Wed, 11 Jul 2007 17:53:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I8gBC-0009s4-3u; Wed, 11 Jul 2007 13:40:46 -0400 Date: Wed, 11 Jul 2007 13:40:46 -0400 From: Gary Palmer To: Poul-Henning Kamp Message-ID: <20070711174046.GB91325@in-addr.com> Mail-Followup-To: Poul-Henning Kamp , Robert Watson , Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" References: <20070711115332.I67691@fledge.watson.org> <56223.1184152780@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56223.1184152780@critter.freebsd.dk> Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 17:53:29 -0000 On Wed, Jul 11, 2007 at 11:19:40AM +0000, Poul-Henning Kamp wrote: > In message <20070711115332.I67691@fledge.watson.org>, Robert Watson writes: > >On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > > > >So it sounds like it would be useful for Constantine to help flesh out a few > >pieces of understanding: > > Add to this: > > - Is it possible to correctly identify the hardware platform, so that we know > where to find the sensors and know what they measure, without bloating the > kernel with a lot of tables. Why would the tables have to be in the kernel? Even if they are in the kernel, what is stopping something loading the correct table on boot based on some userland tool run out of /etc/rc.d? I'm also not sure what the benefit to having the tables in the kernel would be. A userland tool which watches the data from the sensors (however they are presented, whether it is a sysctl MIB or data passed via RFC 1149) and acts appropriately would appear to be a more flexible solution (ala devd)