Date: Tue, 10 Jul 2007 20:13:45 -0400 From: "Constantine A. Murenin" <cnst@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@FreeBSD.org>, "Constantine A. Murenin" <cnst@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <469420B9.20401@FreeBSD.org> In-Reply-To: <53705.1184107078@critter.freebsd.dk> References: <53705.1184107078@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/07/2007 18:37, Poul-Henning Kamp wrote: > In message <469406E0.3090206@FreeBSD.org>, "Constantine A. Murenin" writes: > >>There is no lack in namespace, specifically after the recent redesign of >>the framework. >> >>When you do sysctl(3) calls in OpenBSD 4.1 [...] > > >>How do you see this as a lack of a namespace? > > > What OpenBSD has is an enumeration, and that is not the same as a > name-space. > > If you live in the USA, chances are that you have a social security > number. That is an example of an enumeration: "We have all these > FOOs and we need to tell them apart". I don't see how this comparison applies to the framework. SSN is a magic number, and there are no magic numbers to be remembered to access temperature sensors from sysctl. You ask for temperature, you are given temperature. You ask for fan speed, you are given fan speed. > However, you parents gave you a name, because what that is the key > to the human name-space, which is so called for the obvious reason. And sensors are given unique, consistent and predictable names by the framework, which are easy to remember and manipulate. > Physical measurements are only relevant in the context of their > physical location and the OpenBSD enumeration doesn't even encode > this, it is only interested in the logical location of the sensor, > what kind of bus it is on, what kind of address it has. There is no distinction in sensors at i2c bus from sensors at isa bus, or any other real or imaginary bus. > For any hw-sensor namespace to make sense, it must, as a minimum, > identify the sensors in terms of the device(-drivers) associated > with the hardware where the sensor senses, not the device-driver > of the sensor itself. Some ethernet adapters have sensors, and they are exported under the name of the adapter (e.g. hw.sensors.nxb0.temp0 for some 10Gb Ethernet NetXen cards). Intel Core on-die temperature sensors are exported under the name of the cpu (e.g. hw.sensors.cpu0.temp0). With Super I/O and i2c sensor chips, it's a bit different. With i2c sensors there is usually no way to know sensor's physical location no matter what kind of a namespace you propose to come up with. > The OpenBSD stuff is a 1980 style hack, and should not be propagated. The more complex the system, the higher the chance that it will contain multiple mistakes. This framework is simple enough to be elegant. The result -- there are 51 (fifty-one) drivers that use this framework and several userland and port utilities. Every machine that runs OpenBSD, from Apple and ThinkPad laptops to home PCs to high-end servers, has many sensors that work out of the box (tm), with zero configuration and with a unified interface by which they can be accessed, locally or remotely. If you want to have no such framework that could potentially diagnose or predict system failure, it's your choice, and I'm not going to argue against it. However, there are many people who desire to have this feature in an operating system, and these people include FreeBSD users and developers. Cheers, Constantine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469420B9.20401>