From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 11:31:04 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 775C916A419; Sun, 11 Nov 2007 11:31:04 +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 EC1DC13C49D; Sun, 11 Nov 2007 11:31:03 +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 BC85017105; Sun, 11 Nov 2007 11:30:45 +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 lABBUio7003721; Sun, 11 Nov 2007 11:30:45 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Nov 2007 11:37:17 +0100." <20071111113717.4803b3ab@deskjail> Date: Sun, 11 Nov 2007 11:30:44 +0000 Message-ID: <3720.1194780644@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 11:31:04 -0000 In message <20071111113717.4803b3ab@deskjail>, Alexander Leidinger writes: >> 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. > >This sounds like you propose more than one kernel access point for all >sensors. Maybe something like /dev/sensors/senX instead of >the /dev/sensor_interface I thought initially? One device node is plenty: /dev/sensors >the /dev/sensor_interface I thought initially? What about the >hierarchic aspect (/dev/sensors/hierlev1/.../hierlevX/senY, ... this is >where I came up with my filesystem comment in the previous mail)? There is no need to waste device nodes and vnodes on that, it can be more efficiently encoded inband, just like devd does. >(the simple sensors)), or you issue an "poll now" ioctl each time you >want the data and wait for the return of the select/poll/kqueue. So in >the end you do a blocking wait, with slow sensors comming back later >than faster ones, and in the monitoring software those get attributed >to about the same time slot (if they are all polled at the same time). That would only happen if you implement things in a truly pointless way. >As I don't like the generic poll logic for simple sensors (used in the >majority of use cases) in the kernel, let's look at the "poll >now"-case: 1 syscall for the "poll now" for each sensor (N calls), Why couldn't you tell multiple sensors to poll in one syscall ? >1-N >syscalls for waiting, and 1 syscall to read for each sensor (for only >one fd for all sensors, And read all the results in one read(2) operation, if they are ready ? You sound like an IBM mainframe-guy: "There shall be one record per syscall only!" :-) You could, best case, poll _all_ the sensors in two syscalls. >The simple sysctl approach has N calls. Which is a terrible waste of syscalls in my mind. >Again: when does it hurt that it takes longer? > >For sysctls you go directly to a sensor (benefit of the hierarchic >property), for the single fd approach you need additional code in the >kernel to go dispatch to the sensor, You mean, code that isn't hampered by the sysctl semantics and which can do so in a very efficient way ? Yes, that would be a great thing indeed. >and in the multiple fd case you >need to write some kind of filesystem logic to get the hierarchical >benefit. Only you talk about one devicenode per sensor, please forget that red herring. >> 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). > >Why? We want a userland library to access it, so all tools which query >a sensor need to use this. This library can access the interface >directly [...] No, then you clearly have not understood what people told you, the diagram looks like this: N * accessing application | | N * sensor-library | | 1 * sensor daemon ---- N * sensor-library - N * userland sensors | | N * kernel sensors >You propose to write more code with more complex logic to get faster >to the sensor data. No, I propose to solve the problem, rather than hack up bad code using bad interfaces for 20% of the problem. >I've done this. Passing strings down a fd from the kernel is no magic. >It's good for the kernel->userland part, but not for the >userland->kernel querying of only a subset of the sensors. Here is a straw-man API for the kernel<->userland device: Kernel sends "S 32 acpi.cpu.0.temperature bla bla bla\n" This means: I have a sensor which I know as number 32, and it tells me it has these properties. Userland does an ioctl: SENSOR_POLL(32) Kernel sends, when the data is ready, "D 32 34.45\n" There you are, can it be any simpler ? Amongst the points you totally overlook, is the fact that the sensors don't need to be a hierarchy in the kernel, as long as they tell sensord about their placement in the hierarchy. In fact, if for no other reason, the tremendous overhead for the hierarchy in sysctl is reason not to use it. to sysctl for this. -- 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.