From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 08:27:01 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8901016A41B; Sun, 11 Nov 2007 08:27:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3924213C480; Sun, 11 Nov 2007 08:27:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 577D417105; Sun, 11 Nov 2007 08:26:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lAB8QpcR003275; Sun, 11 Nov 2007 08:26:51 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Nov 2007 09:18:01 +0100." <20071111091801.761ba5c5@deskjail> Date: Sun, 11 Nov 2007 08:26:51 +0000 Message-ID: <3274.1194769611@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) 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: Sun, 11 Nov 2007 08:27:01 -0000 In message <20071111091801.761ba5c5@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" (Sat, 10 Nov 2007 22:54:41 +0000): > >> But you forget that sensors may have considerable "conversion" time. >> It is a benefit for us to be able to start the sensor and not block >> on the syscall waiting for it to do its thing. > >How do you know from the approach you propose when to read out the >newly polled data without blocking in some syscall? You use the select(2), poll(2) or kqueue(2) systemcall to wait until one of the several fd's the sensord(8) process will have to service becomes ready. Remember the userland access API ? That will need to be serviced via some kind of interface, most likely a unix domain socket (although a shared memory based interface might also work). >How do you >quantify "a problem"? Can this problem be circumvented by userland code >instead (maybe some tunable amount of threads or some other way)? Anybody who proposed "a tunable amount of threads" a solution where poll(2)/select(2)/kqueue(2) would do just fine, doesn't know what he is talking about. >I don't say your proposal is bad, currently I still think you are in >the premature optimization territory [...] No, this is purely architectural, it has nothing to do with "premature optimization". >> You are reading waaay too much into Roberts email and overlooking >> that a fd based kernel interface can also be MIB based. > >I don't overlook the MIB based part. I see that we get the MIB part via >sysctls for free, and that we have to write a filesystem with all the >bells and whistles VFS needs to work, to get this MIB based part via >the fd approach. Ahh, here we have the misunderstanding! Nobody is proposing writing a filesystem, which would be a terribly stupid way to do it. To see why a filesystem isn't needed, please study devd(8)'s kernel interface. We can continue when you have done so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.