From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 22:54:56 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 75FD516A421; Sat, 10 Nov 2007 22:54:56 +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 E462F13C4B5; Sat, 10 Nov 2007 22:54:55 +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 B788F17105; Sat, 10 Nov 2007 22:54:42 +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 lAAMsf0u001403; Sat, 10 Nov 2007 22:54:42 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Nov 2007 20:32:29 +0100." <20071110203229.64021d85@deskjail> Date: Sat, 10 Nov 2007 22:54:41 +0000 Message-ID: <1402.1194735281@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: Sat, 10 Nov 2007 22:54:56 -0000 In message <20071110203229.64021d85@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" (Sat, 10 Nov 2007 10:04:22 +0000): > >> >This >> > implies that we have to move the polling intervall code for non-event driv >> >en sensors from the userland to the kernel. >> >> No it does not. >> >> It would be prefectly sensible to have an ioctl(2) (or write(2)!) >> that says "poll this sensor now" to keep control in userland if >> that is desired. >> >> Some sensors however, are hardware timed, and for those it makes >> more sense to be able to tell them "we want one report every second" >> and not worry more about it. > >Two kinds of behavior come into my mind when I read this. > >First behavior ("poll this sensor now"): If the userland application >wants to poll the non-event driven sensors (or sensors which are not >hardware timed), it has to issue 2 syscalls for each sensor, one to let >it poll (ioctl), and one to read the data. The polling interval is >handled by the userland. > >What I like here is, that the polling interval handling is in the >userland for non-event driven and non-hardware-timed sensors (let's >call those "simple" sensors). What I don't like is that we have to issue >more than one syscall. 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. >> >So to sum it up it looks like the architecture looks as follows: >> > - using sysctls for centralized exporting of sensor data from kernel >> > to userland (polling interface for userland polling code) >> >> I think you are jumping to conclusions here. > >As written, nobody came up with strong arguments (actually there where >no replies at all) to Roberts mail. You are reading waaay too much into Roberts email and overlooking that a fd based kernel interface can also be MIB based. >> sysctl is by definition limited to polling, which, for any significant >> number of sensors, becomes very expensive compared the ability of >> an fd-based approach to queue and batch data. > >See my caching argument above. Which just adds to the mess, because then you have to also pass along a timestamp to tell how old the returned value is. There are a lot of downsides to sysctls which you do not seem to be aware of, locking, access time, overhead and several other issues makes sysctl very undesirable for anything which isn't "ad-hoc" or really seldomly used. Poul-Henning -- 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.