From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 13:54:43 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 E7E6D16A421; Wed, 11 Jul 2007 13:54:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A159913C44C; Wed, 11 Jul 2007 13:54:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C9D3A17380; Wed, 11 Jul 2007 13:54:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l6BDsexK056737; Wed, 11 Jul 2007 13:54:40 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 14:42:40 +0200." <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net> Date: Wed, 11 Jul 2007 13:54:40 +0000 Message-ID: <56736.1184162080@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" 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 13:54:44 -0000 In message <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net>, Alexander Leidinger writes: >I was not thinking about 7-layer-OSI, I was thinking about 3 layers: >presentation, infrastructure and "low-level" data acquiring stuff (I >prefer the pragmatic way of looking at things). This again misses the point, because you assume a simple bottom-up architecture will work like it does for PCI devices. In this case however, the majority of systems need some piece of code to identify them, look up in a table (which we get from where ?) and configure the sensors. Sensor hardware is not context-free and selfidentifying like PCI and USB devices, in fact, it is about as far from PnP as you can get. Finding an LM75 and reading the temperature is worth next to nothing if you don't know where the LM75 is mounted. Reading an ADC is worth absolutely nothing, if you don't know what it measures and what voltage dividers are in front of it. Finding an I2C sensor and trying to read it is a catastrophe when it turns out not to be a sensor but the motherboard clock generator or voltage regulater. IFF we want to do something more comprehensive than the gaggle of ports, then we want to do it properly so that it doesn't weigh down the kernel with tons of, on average unused, junk, doesn't imperil hardware and delivers sensor readings which come with the necessary context to have a real physical meaning. Access to I2C busses and I/O registers should happen in the kernel, but maintaining a database of all sorts of weird systems should not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.