Date: Wed, 11 Jul 2007 19:04:30 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@FreeBSD.org>, "Constantine A. Murenin" <cnst@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@FreeBSD.org, Alexander Leidinger <Alexander@Leidinger.net> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <20070711185530.R68820@fledge.watson.org> In-Reply-To: <20070711175325.GQ45894@elvis.mu.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711175325.GQ45894@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2007, Alfred Perlstein wrote: >>> I'm trying to point out that your kernel framework belongs in userland. >> >> It's not my framework. >> >>> There is no benefit from having it in the kernel. >> >> You need to get some information out of the kernel somehow (you cut this >> part of my mail). And as far as I understand the high level description >> (presentation in the net) of this framework, this does this in an unified >> way. Do you propose to get the information out of the kernel in a >> non-uniform way? > > Possibly, one way to do that is to provide a well thought out userland > library that can make for a nice interface. If by doing it userland the > kernel implementation can be kept smaller and more simple it might be a win. > > That said, it may be a loss if you wind up having to duplicate work over and > over for different devices it may be a loss. > > Remember, once the kernel interface is exposed it has to be there almost > forever, while a userland interface and much more easily be adapted. The flip side of the user/kernel, of course, is that userland implementations may require more privilege to invoke than kernel implementations, since they may need to frob with /dev/pci, /dev/mem, etc, rather than accessing a very narrow sysctl interface using essentially unprivileged access. Compare, for example, the old ps(1) which required root or kmem privilege in order to be able to grope through kernel memory, and the new ps(1) that uses a set of controlled APIs that not only let it run as any user, but also scope the process information exposed by requesting process. However, the point I think that you specifically are making is that if we define a user API to access the information, then the implementation can be flexible, and what we really want to know is how applications will interact with the data. I think this is precisely the right point -- what we should not do is lock ourselves into a particular sysctl representation of the data and approach, which has happened to quite a few of our monitoring interfaces and makes it quite hard to abstract things, change the implementation, etc. Consider directly accessing sysctls (as done in most of netstat) and the slightly more abstract libkvm interfaces, which allow you to access information as data and hide the method (allowing the method to be /dev/kmem, sysctls, coredumps, etc). Since Constantine already has monitoring tools from the OpenBSD side, he can probably say a bit more about what their requirements are. I suspect right now they are pretty thin wrappers since the data processing happens before it goes out the sysctl interface...? Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711185530.R68820>