From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:14:21 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 2F9D216A400; Wed, 11 Jul 2007 18:14:21 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 176D813C455; Wed, 11 Jul 2007 18:14:21 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id ED5BB1A4DAA; Wed, 11 Jul 2007 11:14:20 -0700 (PDT) Date: Wed, 11 Jul 2007 11:14:20 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070711181420.GS45894@elvis.mu.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711175325.GQ45894@elvis.mu.org> <20070711185530.R68820@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711185530.R68820@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , freebsd-arch@FreeBSD.org, Alexander Leidinger 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: Wed, 11 Jul 2007 18:14:21 -0000 * Robert Watson [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