Date: Wed, 11 Jul 2007 11:14:20 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Robert Watson <rwatson@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: <20070711181420.GS45894@elvis.mu.org> In-Reply-To: <20070711185530.R68820@fledge.watson.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711175325.GQ45894@elvis.mu.org> <20070711185530.R68820@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Watson <rwatson@FreeBSD.org> [070711 11:05] wrote: > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > > >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). Yes, this was the point I was trying to put across, well said. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711181420.GS45894>