From owner-freebsd-arch@FreeBSD.ORG Thu Oct 18 11:04:30 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A662816A417 for ; Thu, 18 Oct 2007 11:04:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8164413C45D for ; Thu, 18 Oct 2007 11:04:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5AD5A46DA7; Thu, 18 Oct 2007 06:48:58 -0400 (EDT) Date: Thu, 18 Oct 2007 11:48:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200710172243.51958.max@love2party.net> Message-ID: <20071018113431.K60783@fledge.watson.org> References: <52116.1192652445@critter.freebsd.dk> <200710172243.51958.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , "Constantine A. Murenin" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: sensors fun.. 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: Thu, 18 Oct 2007 11:04:30 -0000 On Wed, 17 Oct 2007, Max Laier wrote: > On Wednesday 17 October 2007, Poul-Henning Kamp wrote: >> In message <47166BA5.1000100@elischer.org>, Julian Elischer writes: >>>> Having a userland interface also makes it easier to have backends that >>>> are entirely in userland. >>> >>> maybe a loopback filesystem >> >> Just what is it that is so enticing about the kernel ? Why not simply pass >> it to a daemon ? > > What I like about the OpenBSD framework is, that you can get the sensor data > with basic tools. What's wrong with "everything is a file"? With a file > system you don't have to jump through any hoops to provide concurrent access > to more than one reader. You could easily create symlinks to map sensors to > location. You have means to restrict access to certain sensors. etc. ... Actually, experience with procfs suggests that you do have to deal with these problems and more. For example, cat offers quite a small read buffer on a file, so what should the kernel do if the read buffer is too small to hold all the data from a procfs file? I.e., with /proc/pid/map? Should it snapshot the state so that iterative reads work to pull out a complete snapshot, requiring handling of concurrency between simultaneous openers -- perhaps multiple snapshots at once or limiting to one reader at a time. Alternatively, it could truncate the read and not report an error, or fail? In procfs, we fail, returning an I/O error if the buffer passed by the user app is too small, resulting in user confusion when a process's memory mappings exceed default buffer sizes for common command line tools. Instead you have to run 'dd if=/proc/pid/map of=/dev/stdout bs=64k" or the like. Sysctl offers a typed data semantic and defined atomicity model, as well as a decent way to query how much space is needed and handle cases where not enough space is available. You won't find me arguing sysctl is perfect, but it has a number aspects of great value. There was a suggestion a few years ago on linux-kernel that procfs should be changed to export all data in XML -- on face value, that might be read as a rather mean joke, but really, it's quite a sensible suggestion. You only have to look at the historic linprocfs/linux procfs parts to see what can go wrong with free-form data representation :-). Robert N M Watson Computer Laboratory University of Cambridge