From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 12:22:25 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 D344316A400; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3FD13C48D; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6DCMJHL003289; Fri, 13 Jul 2007 08:22:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alexander Leidinger Date: Fri, 13 Jul 2007 07:40:15 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <200707121404.34168.jhb@freebsd.org> <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> In-Reply-To: <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130740.17680.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Jul 2007 08:22:23 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , 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: Fri, 13 Jul 2007 12:22:26 -0000 On Friday 13 July 2007 01:37:33 am Alexander Leidinger wrote: > Quoting John Baldwin (from Thu, 12 Jul 2007 14:04:33 -0400): > > > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > >> Quoting John Baldwin (from Wed, 11 Jul 2007 > > 11:45:26 -0400): > >> > >> > On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > >> > >> >> On the other hand you don't want to allow an userland tool to directly > >> >> mess around with the registers on your RAID or NIC to get some status... > >> > > >> > Err, that's how all the RAID utilities I've used work. They send firmware > >> > commands from userland and parse the replies in userland. One exception > > I've > >> > >> That's sad... they should provide this functionality in the driver > >> instead, it would allow to use access restrictions for some parts. > > > > Not really, it avoids having to duplicate a lot of work in drivers > > that can be > > written once in a cross-platform userland utility. Drivers aren't really the > > If the sensor querying is already cross-platform, it can also be used > in the kernel. You have the driver just call the cross-platform > function to get back a firmware command it then can send to the > hardware. Not if the cross-platform code is in userland (think vendor-supplied binaries). > > place to be monitoring raid status sending pages, e-mails, etc. It's best to > > let userland invoke sendmail, not the kernel. :) > > I fully agree, but nobody wants to send mails from the kernel. We just > want to get the sensor data out of the kernel without the possibility > to fuck up the device from userland. You don't have a userland tool > for each NIC (which you need if you go the cross-platform-tool way), > we have a well defined interface there which allows to get back some > sensor data (wire speed, MAC address, IP address(es), ...) already and > we display it in ifconfig. There's one tool to query it (ifconfig), > and nobody complains about it being hard to do it in the driver > instead of in a cross-platform userland tool (and Sam enhanced > ifconfig to be able to get rid of the special tools for each WLAN NIC, > and everybody was happy about this). The sensors framework tries to > accomplish the same for sensor data. A driver (or something else in > the kernel) registers himself with the sensor framework, and then you > can use a generic tool to query all sensor data. No need to reinvent > the wheel (how to export, how to name, what unit to use), and a good > consistency (e.g. units used). ifconfig doesn't use strings from sysctl. It uses a more sophisticated interface with data structures, etc. If you wanted to add a standard RAID monitoring interface, then I would add ioctl's for different RAID operations along with a set of generic RAID structures (probably based at least conceptually on DDF) so that there's an ioctl to return the current RAID config that gives you a list of virtual disks, basic virtual disks, etc. You need to be able to enumerate volumes, enumerate disks, have generic state enums for volumes and disks, etc. > > Whatever talks directly to the driver needs to run as root, yes, but > > you could > > always write a proxy app that receives requests from utilities running as > > non-root and does its own access restrictions. > > That's a lot of infrastructure you want to create for such a simple > task as displaying "resyncing 50% done" or "0 hotspares" or similar... Strings are a horrible data interface. The stuff I work on needs to send e-mails that are more like: volume X on controller Y is degraded the following disks(s) need to be replaced: drive 5 (enclosure 1, slot 2), drive 7 (enclosure 1, slot 4) To do that sanely, I need to have access to data structures, not just arbitrary strings from a sysctl. -- John Baldwin