From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 19:59:59 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 2636716A419; Fri, 16 Nov 2007 19:59:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 533A313C50C; Fri, 16 Nov 2007 19:59:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5759A.dip.t-dialin.net [84.165.117.154]) by redbull.bpaserver.net (Postfix) with ESMTP id 1D7B92E09D; Fri, 16 Nov 2007 20:59:21 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 8D43B6745A; Fri, 16 Nov 2007 20:59:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1195243158; bh=Y5Og3YAum+MGPmN5byNMVRtTXiU/5bJ1Q ojjIpNvTIc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:X-Mailer:Mime-Version:Content-Type: Content-Transfer-Encoding; b=hWME+msnoQ0fCQOR+go9wrYEqlAwGs7TXdnH9 AAbPvqq4N6OXBPqYm4jEsICat9QZhxSWQto2jUJsDd86+UnSa3ry22dSOPkvEhJHP73 D6c5N5tt0+0q5/TAzP1JgKPTqfjRifFhkMZzl6HOMvW79y3CQl4KlrispQU/b1mW52Z DdYEFI5hScdGy5/JKfDhPq6KX9tYrulCs2DK/NHXDLwWzXYwVsLGpqfBZqePDHV95w/ LBDBpnx+SwLYDVrTEOBhp3O3lcgnvfpfm5veeudF4RADdqFr/6wDOso79dgHhF+lMmQ LQPpB/qn8+D2ivHadYyYtKpad7sqevFTYzqiQ== Date: Fri, 16 Nov 2007 20:59:18 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071116205918.0e9d5819@deskjail> In-Reply-To: <27726.1195208965@critter.freebsd.dk> References: <20071113215117.3b9bab8c@deskjail> <27726.1195208965@critter.freebsd.dk> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.6, required 8, BAYES_50 2.50, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No 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: Fri, 16 Nov 2007 19:59:59 -0000 Quoting "Poul-Henning Kamp" (Fri, 16 Nov 2007 10:29:25 +0000): > In message <20071113215117.3b9bab8c@deskjail>, Alexander Leidinger writes: > > Alexander, > > This discussion is leading nowhere, because no matter what we tell > you, your only focus is to prove that "sysctl can do that also". Sorry, you misinterpreted what I say, see below. > There are so many interesting things we could work together on in > this area, and I have quite a bit of interesting code I could > contribute (see http://phk.freebsd.dk/phkrel/Measure.20071017.tgz), > but we never get to that point because of your rather childish > insistence that sysctl is the only and right way to do this. I don't insist that sysctl is the only right way to do this. I think that your proposal is more complex without providing a real benefit for us. Go back and read the mails again. I explain why I think that several pieces of code you propose (for functionality in the kernel) belong into the userland. And I explain how this can be done with less complex code. And I ask questions to give you the possibility to show me that I'm wrong. You didn't answered most of the questions, and the few questions which you answered, where not one of those where you had the change to show that your approach is superior. So far your mails can be interpreted as one of the following possibilities in my eyes: - premature optimization and/or - second system syndrome and/or - resistance about giving an architecture a change which you rejected before without looking what the architecture is you reject (I'm talking about Constantines work in this item) and/or - trying to fit 1% more use-cases into the kernel with a lot more complexity/code into something which can be handled in userland It may also be the case that you are right and I am wrong. Show me the facts I asked you about here on arch@ to show that I overlooked something important which makes your more complex proposal the better one, and I'm quiet. > It also gets more than a bit tedious after a while, and I have > decided that I do not want to continue wasting my time discussing > this, until you are willing to compromise on your sysctl addiction. A compromise is something which, e.g., takes parts of the proposals of 2 opposing parties to get a solution in the middle. What you propose is not a compromise, it's either your solution or nothing. Sorry Poul, it doesn't work like this. Go back, read my questions, and provide hard facts / good arguments I can not disprove to show that your solution is better than the one I propose (and showed it is able to handle the features you want). Do it and you get my support. Don't do it and I ask around for an explanation why your proposal is better. If I don't get such an explanation, I will ask around if the people see a problem with my proposal. If they don't see a problem, your proposal lost, as it is more complex (code in the kernel for things which can be done in userland). Note: I'm talking only about the kernel interface, not about the userland parts. > High-level architectural view of sensor support > ----------------------------------------------- > > N * application (linked -lsensor) > | > | > 1 * sensord ---- N * userland-sensors (linked -lsensor) > | > | > 1 * sensor multiplex device driver > | > | > N * kernel sensors > > (There may also be a connection from the multiplex driver to devd(8) > or it may be from sensord(8) or possibly both, but that could come > later.) So you deny the people which participated in the beginning to voice their opinion about this and want to force this architecture upon them (your mails sounds like this)? While I have no strong opinions about the pure-userland part of the architecture ATM, I think it deserves some more discussion on arch@ instead of forcing this architecture based only upon your opinion / view of the world. A good team is able to deliver a better architecture than one person. > The sensor daemon is there to act as clearing-house and single > configuration point for the sensors, because I really don't want > to have all the sensors polled by all the applications and I don't > want all the applications to have to read the config file and do > calibration/alarm calculations themselves. What about a hybrid approach, using sensord when it is available, and reading the sensor data directly if it is not activated? This way you can even get to the sensor data when you are in single-user mode and don't need a fully functional system. In case you have a problem which only gives you single-user mode with limited resources, but can be solved fast when you have the sensor data, your approach is not really a good solution. Whatever solution is taken for the pure-userland part, I think it needs to work without a daemon running to be useful even in troubling situations. I don't object to have a daemon running and all userland applications connecting to it when the system is ok, I only object if I can not get to the sensors data of the machine if the system is mostly down. Sensor data can be very valuable in such a situation. > In my experience, it makes sense to not restrict the userland side > communication to UNIX sockets, since being able to access another > machines sensors using TCP saves a userland process on that machine. Typically a lot of daemons provide both options. This way you don't have a TCP socket visible to the network if you don't need it (the "bind to localhost" argument only counts when you teach jail to provide a localhost on it's own instead of only one official IP). Do you want that there's only a TCP socket, or is it ok for you to have both kind of sockets? Bye, Alexander. -- A snake lurks in the grass. -- Publius Vergilius Maro (Virgil) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137