Date: Fri, 13 Jul 2007 07:40:15 -0400 From: John Baldwin <jhb@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: Rui Paulo <rpaulo@fnop.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "Constantine A. Murenin" <cnst@freebsd.org>, Shteryana Shopova <syrinx@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <200707130740.17680.jhb@freebsd.org> In-Reply-To: <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> References: <55754.1184143579@critter.freebsd.dk> <200707121404.34168.jhb@freebsd.org> <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 13 July 2007 01:37:33 am Alexander Leidinger wrote: > Quoting John Baldwin <jhb@freebsd.org> (from Thu, 12 Jul 2007 14:04:33 -0400): > > > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > >> Quoting John Baldwin <jhb@freebsd.org> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707130740.17680.jhb>