Date: Thu, 22 Nov 2001 20:01:44 -0600 From: Mike Meyer <mwm@mired.org> To: Harti Brandt <brandt@fokus.gmd.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: sysctls for hardware monitoring? Message-ID: <15357.44552.847847.568773@guru.mired.org> In-Reply-To: <20011122120233.B2946-100000@beagle.fokus.gmd.de> References: <15356.54999.36663.125374@guru.mired.org> <20011122120233.B2946-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Harti Brandt <brandt@fokus.gmd.de> types: > MM>Harti Brandt <brandt@fokus.gmd.de> types: > MM>> On Thu, 22 Nov 2001, Mike Meyer wrote: > MM>> MM>Linux uses a device driver that's a directory full of files holding > MM>> MM>sensor information. That doesn't seem to be the right direction for > MM>> MM>FBSD, though. An option that enabled a set of sysctls to collect the > MM>> MM>information seemed to be more approrpiate. > MM>> MM>Comments? Suggestions? Brickbats? > MM>> > MM>> What's bad about using files? Just to be different? > MM> > MM>Other than having to deal with devfs in -current vs. -stable, nothing > MM>in particular. I'm just looking at the trend for doing things in > MM>-stable, which is to make read-only data from in the kernel available > MM>via sysctls. For example, where Linux has /proc/net/dev and > MM>/proc/net/route, FreeBSD uses a sysctl to get the data. > > It's just annoying to need a special program to get at the values. For > some parts of the MIB, like the interface MIB, even sysctl doesn't help - > you need to write a program to look at these. I still think, its easier to > read the fan speed by cat(1)-ing a file, than to fire up a special > program for this. Is there really that much difference between "cat /dev/hwmon/fan0" and "sysctl hw.mon.fan.0"? You have to fire up a program in the base system to read the value either way. > MM>>Isn't it easier to select, poll, kqueue, what ever on files than on sysctls? > MM> > MM>True, but none of the things you've named are useful for these > MM>hardware monitors. The only useful thing you can do is read the > MM>current value. > Not sure. You could have a file, that gives you events, like 'CPU to > hot' or so. The the user space program wouldn't need to poll the values. I don't think that's a good design. Extracting temperatures, voltages and so on from the chipset depends only on the chipset. Deciding that some component is out of spec depends on the component, which the driver may not know. So doing this means you need *another* interface to communicate the out of bounds values for the signal, and probably a special program for reading those values from a config file and passing them to the interface. In return, you get a kernel thread polling the hardware instead of a user thread polling hardware. I'd rather keep the kernel part simple, and leave dealing with the values in user space. After all, we already have a nice collection of tools to do that. <miken -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15357.44552.847847.568773>