From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 08:18:28 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 7443616A419; Sun, 11 Nov 2007 08:18:28 +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 D808E13C4A7; Sun, 11 Nov 2007 08:18:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5694F.dip.t-dialin.net [84.165.105.79]) by redbull.bpaserver.net (Postfix) with ESMTP id 406CB2E098; Sun, 11 Nov 2007 09:18:05 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id B7DC7616D3; Sun, 11 Nov 2007 09:18:01 +0100 (CET) Date: Sun, 11 Nov 2007 09:18:01 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071111091801.761ba5c5@deskjail> In-Reply-To: <1402.1194735281@critter.freebsd.dk> References: <20071110203229.64021d85@deskjail> <1402.1194735281@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, 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: Sun, 11 Nov 2007 08:18:28 -0000 Quoting "Poul-Henning Kamp" (Sat, 10 Nov 2007 22:54:41 +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. How do you know from the approach you propose when to read out the newly polled data without blocking in some syscall? How many such sensors per system does it require to make this a problem? 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)? I don't say your proposal is bad, currently I still think you are in the premature optimization territory with this part of your proposals (moving this part of the polling responsibility into the kernel), and we haven't seen hard data or good arguments against the premature optimization argument yet. > >> >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. 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. > >> 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. For events it doesn't matter, it's the current state. If you haven't got the initial state transition, you didn't start the monitoring early enough. For smart sensors the max time offset is known from the configuration and it also represents the "current" value. If you want the "real" current value, you need to tell the smart sensor to forget his hardware timed polling and do the poll "now". In typical monitoring software (be it open source or commercial) you don't give a acquired data value a different date stamp than "now". If you have the requirement for this, you are not in a generic monitoring environment anymore, but in a specialized application specific situation, which deserves its own special monitoring program, which should acquire the sensor data specific to the service delivery requirements on its own. We don't try to solve a specific application/serve problem here (and get rid of all specialized 3rd party software which is specific to a special service delivery problem like, e.g., monitoring a nuclear power plant), we try to make it more easy to monitor your every day computing environment. I see benefits for your proposals for special environments (if this is your main target for the kernel sensors framework), but it complicates the system in 99% of the real world application use of this framework. I don't think it is a good idea to put that much code into the kernel for just 1% (estimated, probably it's much less) of the use cases, when you can write specialized software in userland for this 1% (remember, the single-system sensors framework is supposed to handle userland stuff, and this estimated 1% of smart sensors fits nicely into this part instead of into the kernel sensors framework). > 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. You need locking for the filesystem approach too. For the access time part I proposed another way of handling it in userland instead of the kernel (which also works for a fd based approach). For the overhead part the simple sysctl approach looks more lightweight than the writting a filesystem approach, feel free to show it isn't. What are the other issues? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 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. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 10:37:47 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 B589316A418; Sun, 11 Nov 2007 10:37:47 +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 2C2D713C4B6; Sun, 11 Nov 2007 10:37:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5694F.dip.t-dialin.net [84.165.105.79]) by redbull.bpaserver.net (Postfix) with ESMTP id 76A512E2F5; Sun, 11 Nov 2007 11:37:20 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id DE31D62A37; Sun, 11 Nov 2007 11:37:17 +0100 (CET) Date: Sun, 11 Nov 2007 11:37:17 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071111113717.4803b3ab@deskjail> In-Reply-To: <3274.1194769611@critter.freebsd.dk> References: <20071111091801.761ba5c5@deskjail> <3274.1194769611@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=-0.085, required 8, BAYES_40 -0.18, RDNS_DYNAMIC 0.10) 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: Sun, 11 Nov 2007 10:37:47 -0000 Quoting "Poul-Henning Kamp" (Sun, 11 Nov 2007 08:26:51 +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. 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? What about the hierarchic aspect (/dev/sensors/hierlev1/.../hierlevX/senY, ... this is where I came up with my filesystem comment in the previous mail)? And then you open all those fd's the sensord process wants to service and issue a select. And to get the sensor data you issue either one ioctl for each sensor in the beginning to let the kernel return the data of each sensor periodically (polling code in the kernel for most sensors (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). In both cases you need to read the data with another syscall. And you repeat this until all sensors of one poll run delivered the data (this is true even for one fd instead of multiple ones). 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), 1-N syscalls for waiting, and 1 syscall to read for each sensor (for only one fd for all sensors, this reduces to 1 call in the best case and N calls in the worst case). So we have between N+2 and 3N calls. The simple sysctl approach has N calls. Done in a naive way, this takes longer than the fd approach (fast sensors can not overtake slow ones). 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, and in the multiple fd case you need to write some kind of filesystem logic to get the hierarchical benefit. Both fd approaches (which have to be written, additionally to the kernel API for hooking up sensors) are more complex than using the existing sysctl logic (which can just be used in the kernel API for hooking up sensors). And all this to have maybe 1% of sensors which are smart handled in the kernel. This assumes that those sensors need to be handled in the kernel. That they are some kind of device in the PC which needs a kernel driver, and not an external device which can be accessed over a serial line or some other userland driven code and should therefore be handled by the userland part of the single-system sensors framework and not the kernel sensors framework. > 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 (for the fd based approach this means congruent access needs to work, for the sysctl based approach with caching it works already). The admin is supposed to make sure not too (this is a number which is different from system to system, and typically you only have 1-3 tools running) much utilities are run at the same time. > >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. Threads are an userland hammer. It's less complex to get right than a hierarchic fd approach in the kernel. And as already asked (that's the important thing of the paragraph, which you haven't replied to): when does the time to get the sensor data a problem that we would have to look at problem mitigation solutions. You need to add _a lot_ of _slow_ sensors to the _kernel_ in a _single_ system that this becomes a problem. > >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 propose to write more code with more complex logic to get faster to the sensor data. This is contrary to KISS and looks very much as premature optimization. It doesn't matter if it is micro-optimization in an implementation or macro-optimization on the architecture level. Fact is that you propose a more complex handling in the kernel of what can be done simpler in userland. Feel free to come up with hard facts of the contrary. > >> 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. See above. > To see why a filesystem isn't needed, please study devd(8)'s > kernel interface. > > We can continue when you have done so. 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. See the dispatching in the kernel comment for the one fd based approach above, using the existing sysctl API is less complex and less work. Also see the comment above which talks about those 1% if smart sensors which IMO most of the time should be handled by the userland part of the single-system sensors framework and not by the kernel. Bye, Alexander. -- I'm in direct contact with many advanced fun CONCEPTS. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 11:26:24 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA8316A417 for ; Sun, 11 Nov 2007 11:26:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 53C7713C4A3 for ; Sun, 11 Nov 2007 11:26:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 44422167 for freebsd-arch@freebsd.org; Sun, 11 Nov 2007 12:26:00 +0200 Message-ID: <4736D8AF.7010209@FreeBSD.org> Date: Sun, 11 Nov 2007 12:25:51 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: freebsd-arch@freebsd.org References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> In-Reply-To: <1191189248.00807488.1191177603@10.7.7.3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Kernel thread stack usage 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:26:24 -0000 > As known in netgraph susbystem information passing from one node to > another by direct function calls without queueing. It gives performance > bonuses, but it also gives permanent stack overflow risk on complicated > graphs. Netgraph is still have a queues and able to use them when asked, > but now queueing is a flag which should be controlled by sending node. I > think it would be good to implement some algorithm which could monitor > stack usage on each call and enforce queueing when stack usage become > critical. > > The question is: is there correct way to somehow get current kernel > thread stack usage or just a stack base address? Digging kernel with a dirty hands I have found the way which looks like working. I have briefly tested it on i386. printf("%p, %p. Used %d of %d.\n", &var, (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE, (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE - (char *)&var, td->td_kstack_pages * PAGE_SIZE); 'var' here is a name of some local variable. Can anybody comment correctness of this way or propose another one? -- Alexander Motin 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. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 16:38:32 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB02116A46D for ; Sun, 11 Nov 2007 16:38:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2C15913C4B7 for ; Sun, 11 Nov 2007 16:38:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IrFp9-0008l4-PR; Sun, 11 Nov 2007 18:38:16 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lABGcFLA049206; Sun, 11 Nov 2007 18:38:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id lABGcFBA049205; Sun, 11 Nov 2007 18:38:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Nov 2007 18:38:15 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8O4mmsqCUhOCyWJp" Content-Disposition: inline In-Reply-To: <4736D8AF.7010209@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1761 [Nov 09 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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 16:38:32 -0000 --8O4mmsqCUhOCyWJp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 11, 2007 at 12:25:51PM +0200, Alexander Motin wrote: > >As known in netgraph susbystem information passing from one node to > >another by direct function calls without queueing. It gives performance > >bonuses, but it also gives permanent stack overflow risk on complicated > >graphs. Netgraph is still have a queues and able to use them when asked, > >but now queueing is a flag which should be controlled by sending node. I > >think it would be good to implement some algorithm which could monitor > >stack usage on each call and enforce queueing when stack usage become > >critical. > > > >The question is: is there correct way to somehow get current kernel > >thread stack usage or just a stack base address? >=20 > Digging kernel with a dirty hands I have found the way which looks like= =20 > working. I have briefly tested it on i386. >=20 > printf("%p, %p. Used %d of %d.\n", &var, > (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE, > (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE - > (char *)&var, > td->td_kstack_pages * PAGE_SIZE); >=20 > 'var' here is a name of some local variable. >=20 > Can anybody comment correctness of this way or propose another one? Most of the time, you will get the correct value. But, see the vm_thread_new_altstack() in vm/vm_glue.c. --8O4mmsqCUhOCyWJp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHNy/2C3+MBN1Mb4gRAuh/AJ9MS/VAWnbhZ9Ne63x4ZNe++AWeUgCfcVM+ WYGlKQXjxdPUfRhLxADZqN0= =I7+7 -----END PGP SIGNATURE----- --8O4mmsqCUhOCyWJp-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 17:31:21 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25EA716A475 for ; Sun, 11 Nov 2007 17:31:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 0AAB113C4B5 for ; Sun, 11 Nov 2007 17:31:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 11 Nov 2007 09:31:09 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E7FBA1269B4; Sun, 11 Nov 2007 09:31:08 -0800 (PST) Message-ID: <47373C5E.2080800@elischer.org> Date: Sun, 11 Nov 2007 09:31:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kostik Belousov References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> In-Reply-To: <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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 17:31:21 -0000 Kostik Belousov wrote: > On Sun, Nov 11, 2007 at 12:25:51PM +0200, Alexander Motin wrote: >>> As known in netgraph susbystem information passing from one node to >>> another by direct function calls without queueing. It gives performance >>> bonuses, but it also gives permanent stack overflow risk on complicated >>> graphs. Netgraph is still have a queues and able to use them when asked, >>> but now queueing is a flag which should be controlled by sending node. I >>> think it would be good to implement some algorithm which could monitor >>> stack usage on each call and enforce queueing when stack usage become >>> critical. >>> >>> The question is: is there correct way to somehow get current kernel >>> thread stack usage or just a stack base address? >> Digging kernel with a dirty hands I have found the way which looks like >> working. I have briefly tested it on i386. >> >> printf("%p, %p. Used %d of %d.\n", &var, >> (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE, >> (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE - >> (char *)&var, >> td->td_kstack_pages * PAGE_SIZE); >> >> 'var' here is a name of some local variable. >> >> Can anybody comment correctness of this way or propose another one? > > Most of the time, you will get the correct value. But, see the > vm_thread_new_altstack() in vm/vm_glue.c. Also, and others may want to pipe in on this, it might go in machine dependent code because it is *theoretically* we could port one day to a machine with an upward growing stack. It has happened in the distant past but it has been growing less likely in the recent past. With the advent of truely HUGE address spaces, it becomes feasible again. (which of course doesn't mean someone will do it). I guess that if someone ports to such a machine, this would be the least of his problems, so I guess it's not a factor. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 17:41:38 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC5016A420 for ; Sun, 11 Nov 2007 17:41:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE6E13C4B5 for ; Sun, 11 Nov 2007 17:41:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 44529236; Sun, 11 Nov 2007 19:41:30 +0200 Message-ID: <47373EC0.2040804@FreeBSD.org> Date: Sun, 11 Nov 2007 19:41:20 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> In-Reply-To: <47373C5E.2080800@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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 17:41:39 -0000 > Kostik Belousov wrote: >>>> The question is: is there correct way to somehow get current kernel >>>> thread stack usage or just a stack base address? >>> Digging kernel with a dirty hands I have found the way which looks >>> like working. I have briefly tested it on i386. >>> >>> printf("%p, %p. Used %d of %d.\n", &var, >>> (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE, >>> (char *)td->td_kstack + td->td_kstack_pages * PAGE_SIZE - >>> (char *)&var, >>> td->td_kstack_pages * PAGE_SIZE); >>> >>> 'var' here is a name of some local variable. >>> >>> Can anybody comment correctness of this way or propose another one? >> >> Most of the time, you will get the correct value. But, see the >> vm_thread_new_altstack() in vm/vm_glue.c. I have seen that. But as I have understood td_altkstack is just a temporal storage for original td_kstack value. I don't see how it interfere my question. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 19:49:33 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE23C16A419 for ; Sun, 11 Nov 2007 19:49:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6BAAB13C480 for ; Sun, 11 Nov 2007 19:49:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp008-s [10.150.69.71]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id lABJnAAf015910; Sun, 11 Nov 2007 11:49:11 -0800 (PST) Received: from [192.168.1.101] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp008/MantshX 4.0) with ESMTP id lABJn8ri006148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Nov 2007 11:49:09 -0800 (PST) Message-Id: <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> From: Marcel Moolenaar To: Julian Elischer In-Reply-To: <47373C5E.2080800@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Sun, 11 Nov 2007 11:49:08 -0800 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> X-Mailer: Apple Mail (2.912) Cc: Kostik Belousov , Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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 19:49:33 -0000 On Nov 11, 2007, at 9:31 AM, Julian Elischer wrote: > Also, and others may want to pipe in on this, it might go in > machine dependent code because it is *theoretically* we could port > one day to a machine with an upward growing stack. This is not theoretical at all: On ia64 there are 2 stacks. One growing down and one growing up. The downward stack is used for stack-based variables and the pward growing stack is used by the processor for stacked registers. The code suggested will not be meaningful on ia64. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sun Nov 11 20:43:52 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8588D16A418 for ; Sun, 11 Nov 2007 20:43:52 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0D713C4AA for ; Sun, 11 Nov 2007 20:43:51 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 44547795; Sun, 11 Nov 2007 22:43:33 +0200 Message-ID: <4737696A.7050605@FreeBSD.org> Date: Sun, 11 Nov 2007 22:43:22 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marcel Moolenaar References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> In-Reply-To: <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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 20:43:52 -0000 Marcel Moolenaar wrote: > This is not theoretical at all: On ia64 there are 2 stacks. One > growing down and one growing up. The downward stack is used for > stack-based variables and the pward growing stack is used by > the processor for stacked registers. Hmm, interesting. And which one is pointed by td_kstack there? Or they are using same segment but from opposite sides? > The code suggested will not be meaningful on ia64. Why? If variable stack growing down and it's segment is pointed by td_kstack then where is the problem? Or you mean that system will die earlier when those two stacks in same segment will reach each other? -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 00:14:55 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897F916A417 for ; Mon, 12 Nov 2007 00:14:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 62D8A13C4A8 for ; Mon, 12 Nov 2007 00:14:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 11 Nov 2007 16:14:23 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 83F0E1269B6; Sun, 11 Nov 2007 16:14:22 -0800 (PST) Message-ID: <47379AE0.2070808@elischer.org> Date: Sun, 11 Nov 2007 16:14:24 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marcel Moolenaar References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> In-Reply-To: <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 00:14:55 -0000 Marcel Moolenaar wrote: > On Nov 11, 2007, at 9:31 AM, Julian Elischer wrote: > >> Also, and others may want to pipe in on this, it might go in >> machine dependent code because it is *theoretically* we could port one >> day to a machine with an upward growing stack. > > This is not theoretical at all: On ia64 there are 2 stacks. One > growing down and one growing up. The downward stack is used for > stack-based variables and the pward growing stack is used by > the processor for stacked registers. > > The code suggested will not be meaningful on ia64. > I KNEW I'd heard something about an upward growing stack recently... From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 01:10:58 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FB6016A419; Mon, 12 Nov 2007 01:10:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.71]) by mx1.freebsd.org (Postfix) with ESMTP id 4F47C13C494; Mon, 12 Nov 2007 01:10:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id lAC1Am8M018054; Sun, 11 Nov 2007 17:10:48 -0800 (PST) Received: from [192.168.1.101] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id lAC1AhK5006734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Nov 2007 17:10:44 -0800 (PST) Message-Id: <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> From: Marcel Moolenaar To: Alexander Motin In-Reply-To: <4737696A.7050605@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Sun, 11 Nov 2007 17:10:43 -0800 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> X-Mailer: Apple Mail (2.912) Cc: Kostik Belousov , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 01:10:58 -0000 On Nov 11, 2007, at 12:43 PM, Alexander Motin wrote: > Marcel Moolenaar wrote: >> This is not theoretical at all: On ia64 there are 2 stacks. One >> growing down and one growing up. The downward stack is used for >> stack-based variables and the pward growing stack is used by >> the processor for stacked registers. > > Hmm, interesting. And which one is pointed by td_kstack there? Or > they are using same segment but from opposite sides? The latter. The td_kstack variable points to the bottom, which is where the register stack starts. The memory stack start from td_kstack + td_kstack_size. >> The code suggested will not be meaningful on ia64. > > Why? If variable stack growing down and it's segment is pointed by > td_kstack then where is the problem? Or you mean that system will > die earlier when those two stacks in same segment will reach each > other? It's the register stack that grows faster in general and yes, they grow towards each other so they can eventually run into each other. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 04:49:59 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4EF16A468 for ; Mon, 12 Nov 2007 04:49:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7D413C494 for ; Mon, 12 Nov 2007 04:49:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 11 Nov 2007 20:34:42 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 6078512697A; Sun, 11 Nov 2007 20:34:42 -0800 (PST) Message-ID: <4737D7E3.3090500@elischer.org> Date: Sun, 11 Nov 2007 20:34:43 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marcel Moolenaar References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> In-Reply-To: <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Motin , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 04:49:59 -0000 Marcel Moolenaar wrote: > > On Nov 11, 2007, at 12:43 PM, Alexander Motin wrote: > >> Marcel Moolenaar wrote: >>> This is not theoretical at all: On ia64 there are 2 stacks. One >>> growing down and one growing up. The downward stack is used for >>> stack-based variables and the pward growing stack is used by >>> the processor for stacked registers. >> >> Hmm, interesting. And which one is pointed by td_kstack there? Or they >> are using same segment but from opposite sides? > > The latter. The td_kstack variable points to the bottom, > which is where the register stack starts. The memory stack > start from td_kstack + td_kstack_size. > >>> The code suggested will not be meaningful on ia64. >> >> Why? If variable stack growing down and it's segment is pointed by >> td_kstack then where is the problem? Or you mean that system will die >> earlier when those two stacks in same segment will reach each other? > > It's the register stack that grows faster in general and > yes, they grow towards each other so they can eventually > run into each other. > so one could write something that detects tha tyou are getting close, but it would have to be machine dependent.. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 09:35:22 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 9F25816A41B for ; Mon, 12 Nov 2007 09:35:22 +0000 (UTC) (envelope-from d.penkov@ipaei.government.bg) Received: from ipaei.government.bg (mail.ipaei.government.bg [212.122.188.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2A34413C4BA for ; Mon, 12 Nov 2007 09:35:21 +0000 (UTC) (envelope-from d.penkov@ipaei.government.bg) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8250D.8FCF56DB" Date: Mon, 12 Nov 2007 11:22:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <938FD3AC052326459B65E5C4432DE95047C45C@server1.ipaei.bg> X-MS-Has-Attach: X-MS-TNEF-Correlator: <938FD3AC052326459B65E5C4432DE95047C45C@server1.ipaei.bg> Thread-Topic: Virus Found in message "hi" Thread-Index: AcglDY/PyfrkkgQVRV6gNByzgjrptA== From: "Dimitar Penkov" To: X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Virus Found in message "hi" 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: Mon, 12 Nov 2007 09:35:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8250D.8FCF56DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Symantec AntiVirus found a virus in an attachment you (arch@freebsd.org = ) sent to Dimitar Penkov. To ensure the recipient(s) are able to use the files you sent, perform a = virus scan on your computer, clean any infected files, then resend this = attachment. Attachment: letter.zip Virus name: W32.Mydoom.M@mm Action taken: Quarantine succeeded :=20 File status: Infected ------_=_NextPart_001_01C8250D.8FCF56DB-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 18:28:20 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 589E416A420; Mon, 12 Nov 2007 18:28:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 364B313C4BC; Mon, 12 Nov 2007 18:28:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp008-s [10.150.69.71]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id lACIQXYw015325; Mon, 12 Nov 2007 10:26:33 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp008/MantshX 4.0) with ESMTP id lACIQVp1026867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2007 10:26:31 -0800 (PST) Message-Id: <2FA48BC6-BCF3-4C16-B914-30A13C15B8AA@mac.com> From: Marcel Moolenaar To: Julian Elischer In-Reply-To: <4737D7E3.3090500@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 12 Nov 2007 10:26:28 -0800 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> <4737D7E3.3090500@elischer.org> X-Mailer: Apple Mail (2.912) Cc: Kostik Belousov , Alexander Motin , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 18:28:20 -0000 On Nov 11, 2007, at 8:34 PM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> It's the register stack that grows faster in general and >> yes, they grow towards each other so they can eventually >> run into each other. > > so one could write something that detects tha tyou are getting close, > but it would have to be machine dependent.. Yes. A good place would be cpu_switch in this case, because the processor flushes the dirty stacked registers onto the register stack only when it "feels" like it or when instructed to do so. In practice this means that while the stacks may have run into each other based on the pointers, the memory corruption (sec) often happens in cpu_switch where we force the processor to flush the dirty stacked registers. In other words: a thread is expected in the common case to encounter the corruption until the next switch-in, but could in case of excessive use of either or both stacks encounter it on function boundaries (function calls and/or returns). As a side-note: The implementation of kernel stack guard pages is just as meaningless for ia64. As a first improvement, you want guard pages both at the top and at the bottom and not just at the bottom. Secondly, you want to be able to protect each stack running into each other. However, putting a guard page somewhere in the middle may not be the right thing, because different threads may require different ratios... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 19:07:07 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214F616A421 for ; Mon, 12 Nov 2007 19:07:07 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 95EA013C4BF for ; Mon, 12 Nov 2007 19:07:06 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 44825990; Mon, 12 Nov 2007 21:06:54 +0200 Message-ID: <4738A444.8040708@FreeBSD.org> Date: Mon, 12 Nov 2007 21:06:44 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marcel Moolenaar References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> <4737D7E3.3090500@elischer.org> <2FA48BC6-BCF3-4C16-B914-30A13C15B8AA@mac.com> In-Reply-To: <2FA48BC6-BCF3-4C16-B914-30A13C15B8AA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 19:07:07 -0000 Marcel Moolenaar wrote: > Yes. A good place would be cpu_switch in this case, because > the processor flushes the dirty stacked registers onto the > register stack only when it "feels" like it or when instructed > to do so. In practice this means that while the stacks may > have run into each other based on the pointers, the memory > corruption (sec) often happens in cpu_switch where we force > the processor to flush the dirty stacked registers. > > In other words: a thread is expected in the common case to > encounter the corruption until the next switch-in, but could > in case of excessive use of either or both stacks encounter > it on function boundaries (function calls and/or returns). > > As a side-note: The implementation of kernel stack guard pages > is just as meaningless for ia64. As a first improvement, you > want guard pages both at the top and at the bottom and not just > at the bottom. Secondly, you want to be able to protect each > stack running into each other. However, putting a guard page > somewhere in the middle may not be the right thing, because > different threads may require different ratios... If I understand you right you are talking about stack overflow/memory corruption detection mechanism. But I am speaking just about getting stack usage statistics. When Netgraph subsystem passes packet from one node to another it can or make direct function call or use queues. Direct call is preferred for the performance reasons, but numerous subsequent calls may cause stack overflow. To optimize behaviour I need some platform independent mechanism to get current stack usage to check is it reached some defined level, for example 50%, or not. Definitely such method still keeps overflow possible, but it will reduce it's probability as much as possible. For i386 platform we have registers pointing current stack head. To simplify my example I have used address of local variable for that. Probably for ia64 we should just use one more register or algorithm to take into account second stack growing upward. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 19:16:10 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F7E16A418; Mon, 12 Nov 2007 19:16:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.83]) by mx1.freebsd.org (Postfix) with ESMTP id 773BE13C4A7; Mon, 12 Nov 2007 19:16:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp003-s [10.150.69.66]) by smtpoutm.mac.com (Xserve/smtpout020/MantshX 4.0) with ESMTP id lACJG23s015319; Mon, 12 Nov 2007 11:16:02 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp003/MantshX 4.0) with ESMTP id lACJG0Ca022811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2007 11:16:00 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Alexander Motin In-Reply-To: <4738A444.8040708@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 12 Nov 2007 11:15:57 -0800 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> <4737D7E3.3090500@elischer.org> <2FA48BC6-BCF3-4C16-B914-30A13C15B8AA@mac.com> <4738A444.8040708@FreeBSD.org> X-Mailer: Apple Mail (2.912) Cc: Kostik Belousov , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage 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: Mon, 12 Nov 2007 19:16:10 -0000 On Nov 12, 2007, at 11:06 AM, Alexander Motin wrote: > For i386 platform we have registers pointing current stack head. To > simplify my example I have used address of local variable for that. > Probably for ia64 we should just use one more register or algorithm > to take into account second stack growing upward. Remember that taking the address of a local variable automatically prevents that variable from being register-promoted. As such, it increases stack pressure :-) I think GCC has an intrinsic to get the current frame pointer. You may want to use that instead. Granted, this would not help ia64, but it's better than taking the address of a local variable. For ia64 you can do as you suggest and add a second "algorithm". This means you probably want to make it machine specific in the first place (i.e. add a MD function that returns an approximation of the number of bytes of stack space in use). -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 07:02:00 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB0FC16A41A for ; Tue, 13 Nov 2007 07:02:00 +0000 (UTC) (envelope-from ameyburgh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id 6520313C4AA for ; Tue, 13 Nov 2007 07:02:00 +0000 (UTC) (envelope-from ameyburgh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1013730nzf for ; Mon, 12 Nov 2007 23:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=YgPSbYSiYA6WDlFbPLCDcZwZPBsPBkEFslHbbLdmBbs=; b=lsC6SCKfYt74jeMU33sm3Wt6lZlNZw4OUoe00dOeZvm6GFdqIipsdN1zVsmC7FzL6U/O+cW8VHJHN2C3+EIDmcifaHh9hDY5jnByKNFJ+LFS25Gp1ERRa/jJPVt7ja9nS8ZcIzO2QCZF4+J0hTnsiVZPwm5ufgDQQwhadolA5w0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Q9OmD013oku4l8N1sT9E8dJPAEetKBIErYwsQB1RTlt11bmGz8yTpx4CTGCFvmXQ3oPEYsIaTKmt8wI/51nC1nwjGhHa6BmQTtpIwhmmgbs9AT28Pis8KDj9qTRA6PnkfOJJpE8bCTaw+Q73FjRh0SvRVq6skPQIpa9iZSb30cA= Received: by 10.142.222.21 with SMTP id u21mr1081669wfg.1194935796367; Mon, 12 Nov 2007 22:36:36 -0800 (PST) Received: by 10.142.217.19 with HTTP; Mon, 12 Nov 2007 22:36:36 -0800 (PST) Message-ID: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> Date: Mon, 12 Nov 2007 22:36:36 -0800 From: "Albert Meyburgh" To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: monolithic 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: Tue, 13 Nov 2007 07:02:00 -0000 Hi, I read that freebsd is monolithic. Is that still true? If I wanted to add functionality like device drivers, or maybe my own tcp/ip stack, (or maybe add the facility to allow modules) do I have to download the entire source and add it in there? nothing available like a kernel module in linux? (which afaik you can attach at runtime) also when I add packages using the ports system, then remove them, are they completely gone or are there still random conf files / misc.. laying around slowly bloating the hdd also is there a way to scan for unused packages somehow and list them thanks a lot From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 08:18:35 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 784B816A417 for ; Tue, 13 Nov 2007 08:18:35 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id 327FC13C4B6 for ; Tue, 13 Nov 2007 08:18:35 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so861067wra for ; Tue, 13 Nov 2007 00:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RC3fOAWVYs3G+fv1YUuTia9TWiPDZixsMqK6WW5Qkxk=; b=MQJp0Dtb1Z4gSPz4ZiNHjexVSv2y0NZ5rEdRaMgjAml0LpnqZ7W+7isM8RNv4C5dOe9V69ukTDb+OhUwGTKfTjew9e/le9AMbXRnprd88ZPOeUMpiHZLC8m76F7hOsDw9NLo1fZ3zoE3TOM8OV9Vj3kR6r61nXLbtlBUzt/XbhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZNRR3jChj83iUiVVGdjN5IVfXNXC41sjDZOz/08o4yR14dkPFwKky/bmVYHZ9hc5595Ujy6fXPKwQSn8liZq81+X+jA8/Budo4qQlHxEALzggSLyjzz89w2zm0WPDb9VBJNBKgdGm223YXFPiAp+tPS9c3/pAYqTeJGkWKI53CY= Received: by 10.90.25.3 with SMTP id 3mr704633agy.1194940372402; Mon, 12 Nov 2007 23:52:52 -0800 (PST) Received: by 10.90.113.20 with HTTP; Mon, 12 Nov 2007 23:52:52 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 09:52:52 +0200 From: "Ivo Vachkov" To: "Albert Meyburgh" In-Reply-To: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: monolithic 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: Tue, 13 Nov 2007 08:18:35 -0000 On Nov 13, 2007 8:36 AM, Albert Meyburgh wrote: > Hi, > > I read that freebsd is monolithic. Is that still true? Yes. > If I wanted to add functionality like device drivers, or maybe my own > tcp/ip stack, (or maybe add the facility to allow modules) do I have > to download the entire source and add it in there? > > nothing available like a kernel module in linux? (which afaik you can > attach at runtime) > You can write kernel modules. However this does not make the kernel non-monolithic (microkernel, exokernel, etc). > > also when I add packages using the ports system, then remove them, are > they completely gone or are there still random conf files / misc.. > laying around slowly bloating the hdd > > also is there a way to scan for unused packages somehow and list them > > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 10:11:34 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5382316A418 for ; Tue, 13 Nov 2007 10:11:34 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id CBD3E13C4A5 for ; Tue, 13 Nov 2007 10:11:33 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so2007038mue for ; Tue, 13 Nov 2007 02:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=1DO7/qP6SlW2PAZL2FioJF636Y6CsAzlarL2PYr6yTY=; b=AUKqPJ7qDy29CMx0DqBd4mzHT4tUIVLW0TWs92GfPEfc/oC7hjTFl2HYImEw0nS2zjUwTgNf5QkGS3xTmiYaw0K+Fc5gKZcyhaDdAX9eiGj3bdI8nZxml92EwQL4FtECewxmo/hn37wfc01qiQAjXefAdyBuNZjBbMFyALwAaxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=FsBFDvvG/aY+X0yo1B4QyJIccv23EaYirWZWyYbtHy7TodqNoubs/L4PdLVKgr5mfgP8tjuCichvfjpR9YSF8muBEuXc8cuq8WpHlZAe3Te79fPjl7O85qhLUj670PB37z9j+bbqCDGzrlMP3zdfPgNr2zO2t9YaEpB9acyDAgg= Received: by 10.82.119.17 with SMTP id r17mr1102556buc.1194948683307; Tue, 13 Nov 2007 02:11:23 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id g8sm12641470muf.2007.11.13.02.11.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2007 02:11:22 -0800 (PST) From: Nikolay Pavlov To: freebsd-arch@freebsd.org Date: Tue, 13 Nov 2007 12:11:12 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> In-Reply-To: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1262937.Iz7DqJhs9d"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711131211.17170.qpadla@gmail.com> Cc: Albert Meyburgh Subject: Re: monolithic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2007 10:11:34 -0000 --nextPart1262937.Iz7DqJhs9d Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 13 November 2007 08:36:36 Albert Meyburgh wrote: > Hi, > > I read that freebsd is monolithic. Is that still true? > > If I wanted to add functionality like device drivers, or maybe my own > tcp/ip stack, (or maybe add the facility to allow modules) do I have > to download the entire source and add it in there? > > nothing available like a kernel module in linux? (which afaik you can > attach at runtime) > > > > also when I add packages using the ports system, then remove them, are > they completely gone or are there still random conf files / misc.. > laying around slowly bloating the hdd > > also is there a way to scan for unused packages somehow and list them > Hi Albert. Probably you should read this FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html And visit a documentation page: http://www.freebsd.org/docs.html. In any=20 case freebsd-questions is much better place to find an answer for such=20 questions. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1262937.Iz7DqJhs9d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHOXhF/2R6KvEYGaIRAtbVAKDd1xWqyArt1/n5b/nUJa8R9Gmz7QCeNIri KLoKlcZRFqVlGLXjNfevkl0= =nKUu -----END PGP SIGNATURE----- --nextPart1262937.Iz7DqJhs9d-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 07:19:23 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFDC416A420 for ; Tue, 13 Nov 2007 07:19:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE4113C4A6 for ; Tue, 13 Nov 2007 07:19:22 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-021-137.pools.arcor-ip.net [88.66.21.137]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1Irq3H0Zhs-0003Se; Tue, 13 Nov 2007 08:19:15 +0100 From: Max Laier Organization: FreeBSD To: freebsd-questions@freebsd.org Date: Tue, 13 Nov 2007 08:18:58 +0100 User-Agent: KMail/1.9.7 References: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> In-Reply-To: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3916165.6uFiMNN0AU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711130819.09271.max@love2party.net> X-Provags-ID: V01U2FsdGVkX193TY6SyJb39DhfrFBD+dcUAeEQoDpiswWMbl2 gghwFN+eQIqYAKTjZyDjiwx4BvF6zMovg+AiqnWkTy9Gubvaqv D2TcdIcoj74u4nDEtHa68S53jCvPaS/F+4mYcavhzM= X-Mailman-Approved-At: Tue, 13 Nov 2007 12:22:51 +0000 Cc: Albert Meyburgh Subject: Re: monolithic 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: Tue, 13 Nov 2007 07:19:24 -0000 --nextPart3916165.6uFiMNN0AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46irst off - freebsd-arch@ is not the right mailing list to ask these kind= =20 of basic questions. Plus, I'm hoping this is not a course work for you=20 CS class! On Tuesday 13 November 2007, Albert Meyburgh wrote: > I read that freebsd is monolithic. Is that still true? Yes in that it is not based on a "micro kernel" and that the kernel and=20 all it's services and drivers are running in one address space. > If I wanted to add functionality like device drivers, or maybe my own > tcp/ip stack, (or maybe add the facility to allow modules) do I have > to download the entire source and add it in there? That depends on the type of thing you want to do. FreeBSD offers a lot of= =20 entry points to hook in your code as needed. Device drivers can=20 absolutely be standalone modules (there are a few in the ports tree (e.g.=20 the nvidia one)). Your own TCP/IP stack is more tricky, but you could=20 use the netgraph(3) framework to hook that at runtime, too. > nothing available like a kernel module in linux? (which afaik you can > attach at runtime) Yes, kernel modules are available and can be attached at runtime=20 (depending on what they are doing). This doesn't make the kernel=20 non-monolithic, though. > also when I add packages using the ports system, then remove them, are > they completely gone or are there still random conf files / misc.. > laying around slowly bloating the hdd We try to make sure this does not happen. During the package build the=20 buildcluster checks for files that are not accounted for and issues a=20 warning to the maintainer. The strict rule of putting all 3rd party=20 programs under either /usr/local or /compat also helps to keep the mess=20 to a minimum. > also is there a way to scan for unused packages somehow and list them There is a tool called pkg_cutleaves in the ports tree that will show you=20 all ports that are not used by any other ports and lets you decide if you=20 want to keep them or not. There might be other solutions, too. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3916165.6uFiMNN0AU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHOU/tXyyEoT62BG0RAlHBAJwMjP9g/53+nV0w+srFTWd4zAqOygCfUiC6 SQwgGDcqVOlI6WMaT+gkJng= =qpLX -----END PGP SIGNATURE----- --nextPart3916165.6uFiMNN0AU-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 17:44:34 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC99F16A417 for ; Tue, 13 Nov 2007 17:44:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id A4D3913C481 for ; Tue, 13 Nov 2007 17:44:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 13 Nov 2007 09:44:22 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 0EE0C1269E0; Tue, 13 Nov 2007 09:44:22 -0800 (PST) Message-ID: <4739E277.3000102@elischer.org> Date: Tue, 13 Nov 2007 09:44:23 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Albert Meyburgh References: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> In-Reply-To: <35f053b10711122236t7ce754eew69dd55144d5a144f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: monolithic 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: Tue, 13 Nov 2007 17:44:35 -0000 Albert Meyburgh wrote: > Hi, > > I read that freebsd is monolithic. Is that still true? > > If I wanted to add functionality like device drivers, or maybe my own > tcp/ip stack, (or maybe add the facility to allow modules) do I have > to download the entire source and add it in there? > > nothing available like a kernel module in linux? (which afaik you can > attach at runtime) > Linux and BSD are both Monolithic. That means that all the system services run in a single address space under a single protection domain. On Both Linux and BSD you can add modules which are dynamically linked in as you need them. In both cases you will need at leas the kernel include files (and sometimes more) to compile and link against. > > > also when I add packages using the ports system, then remove them, are > they completely gone or are there still random conf files / misc.. > laying around slowly bloating the hdd If the config files are unchenged they will be removed but if you have edited them, they will remain so as to not lose your information. People usually remove a port/package so they can reinstall a newer version. They'd usually get pissed off of their hard work got blown away. pkg_delete will tell you what files it is leaving behind. > > also is there a way to scan for unused packages somehow and list them define unused? > > > thanks a lot > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 19:18:05 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7197716A476 for ; Tue, 13 Nov 2007 19:18:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id E1F1C13C465 for ; Tue, 13 Nov 2007 19:18:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so2208769fka for ; Tue, 13 Nov 2007 11:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=VdLWf/FStFmuU54hVmwCVnINGNgbTLsnVa2ygpD/4x8=; b=MrekccjccZ5OpASjQBThn81FwXtjOZVBgh/DzZ5D47rVon/TpBFrAbH/bF8bipjktmbkgyRDkv0ax/DmzhzELcX/qOrSkb3gZfdXa7MJe60bNhq4+CnTjF5ewNjuLnrGhBBy53p6tFhb8OhtnNI2N3YwJwsGrP/tfWbI5mNc83U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Bfk2EzkrqTZ3JVy5gZix4zXXrjmbR9bmN2S/3mxHRxnNEpQxXOEmn6GWFKuQsRkYdBugMn70eso9iXj6zsccMm/TVVTXYcRW4xGdOSr6yNdht0a7bEVv/j4ZUU4hMiDZsKc/WcGWJDkjg3YI3tiLxDP7HHeQHVbQrfn1tGZ/nS8= Received: by 10.86.81.8 with SMTP id e8mr6071041fgb.1194981477460; Tue, 13 Nov 2007 11:17:57 -0800 (PST) Received: by 10.86.25.3 with HTTP; Tue, 13 Nov 2007 11:17:57 -0800 (PST) Message-ID: <3bbf2fe10711131117i1465b186u1662587b8ea680a0@mail.gmail.com> Date: Tue, 13 Nov 2007 20:17:57 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-arch@freebsd.org In-Reply-To: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> X-Google-Sender-Auth: a79ed00b1ab78cda Cc: Subject: Re: [RFC] callout overhaul: part I 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: Tue, 13 Nov 2007 19:18:05 -0000 2007/11/8, Attilio Rao : > Hello, > Some benchmarks posted by rwatson some time ago ( > http://lists.freebsd.org/pipermail/freebsd-arch/2007-October/006945.html > ) evicted callout_lock spinlock as an highly contented lock, in > particular for network paths. Honestly, this is not a surprise at all > :). This moved me in the direction of working on callouts, mainly for > improving the scalability respect a large number of CPUs but, since > callout are rather sensitive for the whole system, a general overhaul > to the whole mecanism would be a good idea. > In particular, I found phk's ideas about it ( > http://lists.freebsd.org/pipermail/freebsd-arch/2006-November/005730.html > ) very valuable and I have on-going discussions with him and rwatson > about these. > > phk's proposal is however not complete at 100% and I'm trying to > integrate with other missing supports. > This patch, for example: > http://people.freebsd.org/~attilio/callout_rwlock.diff I modified a little bit this patch in order to make stuff saner. In particular, I introduced lock assertions in callout_stop(). So now, when necessary, callout_stop() will panic if the lock is not held while running over it. The only one thing I really don't like is that I had to use the "bogus" cast lock_object -> lock primitive (really, alredy used in debugging functions). We should find a better solution about it as it gets as constraints to have lock_object field as the first member of any locking primitive. New patch: http://people.freebsd.org/~attilio/callout_rwlock2.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Nov 13 20:51:40 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 A045E16A419; Tue, 13 Nov 2007 20:51:40 +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 20CAC13C4C6; Tue, 13 Nov 2007 20:51:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5744B.dip.t-dialin.net [84.165.116.75]) by redbull.bpaserver.net (Postfix) with ESMTP id C5BDB2E2FC; Tue, 13 Nov 2007 21:51:20 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id B6042639BF; Mon, 13 Nov 2000 21:51:15 +0100 (CET) Date: Tue, 13 Nov 2007 21:51:17 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071113215117.3b9bab8c@deskjail> In-Reply-To: <3720.1194780644@critter.freebsd.dk> References: <20071111113717.4803b3ab@deskjail> <3720.1194780644@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.1, required 8, BAYES_50 2.50, RDNS_DYNAMIC 0.10, SMILEY -0.50) 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: Tue, 13 Nov 2007 20:51:40 -0000 Quoting "Poul-Henning Kamp" (Sun, 11 Nov 2007 11:30:44 +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. For an active monitoring program (doing probes on it's own, instead of waiting that probes connected to the monitoring program and deliver data), it starts a probe and and polls for data. If it starts probes in parallel, the returned data has about the same timestamp. If it doesn't probes in parallel, there will be some seconds or even minutes in difference, but all of those probes have a timestamp within the current round of probing, which can be describes as one current timestamp (the polling round). For a time-guy like you, this description is very inaccurate, for a normal operator which has to monitor the monitoring program (or a manger of the boss of the just mentioned operator), this description fits. The scenario I was talking about (99% of the use cases) doesn't require a precision to the second. For the remaining 1% you should use a special software and don't complicate the normal case for the other 99%. > >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 ? You can do that for the one fd for all sensors case. I forgot to write about this case at this place, sorry. > >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 ? This is what you can do if all data is ready at the same time. But what's the point of doing a select/poll/kevent, if you wait in the kernel until all data is ready before returning something? You can do a blocking read for this. See also my next sentence below. > You sound like an IBM mainframe-guy: "There shall be one record per > syscall only!" :-) I was talking about the one fd per sensor part here, and you snipped the part where I've read about the one fd for all sensors part. > You could, best case, poll _all_ the sensors in two syscalls. Great... in the best case I can poll all the sensors in one syscall with the sysctl apporach (nothing prevents me from writting a sysctl_xxx which returns the data from a subtree). It's just that the best case will not happen often for sensors when you want to measure some latency of a probe, in such cases you don't probe all at once and wait that all data returns at the same time. And please, don't tell me to do the latency measurement in the kernel, it would contradict your requirement to do as less work as possible in the kernel (it's already stretched too much by your suggestion to let the kernel poll the simple sensors in a configurable time interval). If you get this info back from a smart sensor, fine, you can have (MIB notation) x.y.smart.data.value and x.y.smart.data.latency as separate sensors which you can correlate. But I still think a smart sensor is better attached to the userland sensor part, than to the kernel sensor part (where to draw the line between having it in the kernel or not, is up to the person writting the access code). BTW: you still haven't answered my question about examples of real work sensors which are smart. > >The simple sysctl approach has N calls. > > Which is a terrible waste of syscalls in my mind. With just one syscall (see above for the sysctl approach) you can not do latency measurement in userland. And latency measurement of simple sensors doesn't belong into the kernel. > >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. I'm sill waiting for hard data where you show that sysctl semantics hurt, and that it is not efficient enough, and that the more complex development for the fd approach is necessary. You are good in skipping the questions you don't want/can't answer. I think a lot of the questions you skipped would show that a sysctl approach instead of writting fd handling code is sufficient to cover 99% of cases. > >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. I wrote about both cases, a single fd and multiple fd's. Now that you clarified that you talk about one fd, see my comment regarding additional code for the single fd case in my last mail. > >> 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 This is what you understood (feel free to explain why you need N sensor libraries, one is enough). The description allows another interpretation: N * userland applications (a sensorsd, systat, ..) | 1 * sensors library | | N * kernel sensors N * userland sensors It also allows this interpretation: single-system sensors framework (see note 1) | | 1 * kernel sensors library 1 * userland sensors library | | N * kernel sensors N * userland sensors Note 1: this can be another lib, it can be one daemon, it can be N applications (if it makes sense or not). We didn't talk about this part in enough detail to say "the diagram looks like this". What we agree upon is, that we want a userland lib to abstract the kernel interface away from an application programmer. This means that programs which want to show data from kernel sensors need to use this lib. You can not depend upon the fact, that there's always a sensor daemon running. If you are in single user mode and need the data of a sensor, you should be able to get it even without a sensor daemon running. If we extend the kernel sensor lib with stuff so that it also understands userland sensors or not was not discussed at all. Having no lib between sensord and the kernel in your drawing let's me thing you haven't understood what the people where talking about. > >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 asked multiple times that you provide technical facts for the "bad interface" part. So far you only provided suggestions for changes which are beneficial for an insignificant amount of cases. Those changes unnecessary complicate the code for 99% of cases. > >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 ? We have this already. It's called sysctl. Ok, the syntax is a little bit different, but the syntax you provided is just an example, and not a final decision. > 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. How does a sensor know about their placement in the hierarchy if this data is not in the kernel? It has to be in the kernel. And either the sensor needs to know it's parent if you want that it returns its placement in the hierarchy, or the parent needs to tell that the child belongs to him. And it sounds like you want to write some additional code to do this. By using sysctl to access the sensor, you get this for free. > 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. How much is this tremendous overhead of sysctl, and when does it start to be a bottleneck. As I asked those questions already without getting an answer from you, I don't expect to get an answer now. As long as we don't get answers, you talk about premature optimization (yes, you told me already that you don't think that you talk about premature optimization). Warner, John, Robert, others: either I don't understand Poul's arguments why the fd approach is better / all this things which can be done in userland need to be done in the kernel / ..., or he doesn't understand my arguments why the fd approach is not better / why those things he proposes to be done in the kernel can be done in userland. Could someone please help out and explain either him or me the parts we fail to understand? That would be very nice, as it looks like we're running around in a circle ATM. Bye, Alexander. -- Only a mediocre person is always at their best. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 20:12:22 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB3316A419 for ; Wed, 14 Nov 2007 20:12:22 +0000 (UTC) (envelope-from billy@nlcc.us) Received: from mail1.wildblue.net (mail1.wildblue.net [216.126.204.45]) by mx1.freebsd.org (Postfix) with ESMTP id 06EAF13C46B for ; Wed, 14 Nov 2007 20:12:21 +0000 (UTC) (envelope-from billy@nlcc.us) Received: from ibm.nlcc.us (67-54-202-48.cust.wildblue.net [67.54.202.48]) by mail1.wildblue.net (Postfix) with ESMTP id C198A36CDC6 for ; Wed, 14 Nov 2007 12:53:16 -0700 (MST) Received: (qmail 81068 invoked by uid 89); 14 Nov 2007 19:53:05 -0000 Received: from unknown (HELO ?192.168.0.33?) (billy@192.168.0.33) by ibm.nlcc.us with ESMTPA; 14 Nov 2007 19:53:05 -0000 Message-ID: <473B521D.7050202@nlcc.us> Date: Wed, 14 Nov 2007 13:53:01 -0600 From: Billy Newsom User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: reBoot code: can we detect if there is an AT keyboard controller? 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, 14 Nov 2007 20:12:22 -0000 AFAIK, the FreeBSD kernel still relies on a 90s codebase for rebooting... It uses the keyboard controller reset method to do a warm reboot. I have had trouble with this method over the years... a Pentium Pro and more recently a Mac Pro with no keyboard controller. I have speculated that Mac laptops and blade servers would also lack the KBC. If Intel continues their progress of dropping deprecated hardware, the KBC could disappear in the next 3 to 5 years. So could there be some intelligent software code to check the presence of this device, and if not present, use the alternate reboot? The ACPI reboot sequence, for example, works for FreeBSD 6.2 and later, on my Mac Pro quad Xeon, amd64. Unfortunately, although the kernel detects the presence of a KBC during boot, it doesn't seem that this information gets stored as a global variable for later use. (I made this assertion a few times at freebsd-stable.) It seems like the logical course is to only reboot the keyboard controller if such a thing exists!! Looking back at my notes and my previous research, it appears that the code is around where you can find the cpu_reset code near... /* "good night, sweet prince .... " */ Setting hw.acpi.handle_reboot=1 must bypass that. Could we force the use of this tunable when it's obvious that the KBC is missing? Billy From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 20:38:09 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9386916A474 for ; Wed, 14 Nov 2007 20:38:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3E30E13C4C5 for ; Wed, 14 Nov 2007 20:38:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 219323150-1834499 for multiple; Wed, 14 Nov 2007 15:38:55 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lAEKbwow072725; Wed, 14 Nov 2007 15:38:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 14 Nov 2007 15:37:51 -0500 User-Agent: KMail/1.9.6 References: <473B521D.7050202@nlcc.us> In-Reply-To: <473B521D.7050202@nlcc.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711141537.51447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 14 Nov 2007 15:38:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4790/Wed Nov 14 13:13:53 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Billy Newsom Subject: Re: reBoot code: can we detect if there is an AT keyboard controller? 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, 14 Nov 2007 20:38:09 -0000 On Wednesday 14 November 2007 02:53:01 pm Billy Newsom wrote: > AFAIK, the FreeBSD kernel still relies on a 90s codebase for rebooting... It uses the > keyboard controller reset method to do a warm reboot. > > I have had trouble with this method over the years... a Pentium Pro and more recently > a Mac Pro with no keyboard controller. I have speculated that Mac laptops and blade > servers would also lack the KBC. If Intel continues their progress of dropping > deprecated hardware, the KBC could disappear in the next 3 to 5 years. > > So could there be some intelligent software code to check the presence of this > device, and if not present, use the alternate reboot? The ACPI reboot sequence, for > example, works for FreeBSD 6.2 and later, on my Mac Pro quad Xeon, amd64. > > Unfortunately, although the kernel detects the presence of a KBC during boot, it > doesn't seem that this information gets stored as a global variable for later use. (I > made this assertion a few times at freebsd-stable.) It seems like the logical course > is to only reboot the keyboard controller if such a thing exists!! > > Looking back at my notes and my previous research, it appears that the code is around > where you can find the cpu_reset code near... > > /* "good night, sweet prince .... " */ > > Setting hw.acpi.handle_reboot=1 must bypass that. Could we force the use of this > tunable when it's obvious that the KBC is missing? Actually, I recently updated the reboot code to try several other sequences besides just the keyboard controller such as flipping reset bits in I/O ports 0xcf9 and 0x92. Also, when I did the update I also fixed a bug in the triple-fault last-effort that had caused it to not actually cause a triple-fault. As a result, you might be able to reboot just fine now on newer stable w/o the tunable if you have this commit: revision 1.259.2.6 date: 2007/04/30 17:45:44; author: jhb; state: Exp; lines: +40 -6 MFC: Various fixes to cpu_reset_real() - Try to use the reset control register (I/O port 0xcf9) and the fast a20 and init register (I/O port 0x92) if the keyboard reset fails. - Fix the triple fault to actually work when PGE is enabled. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 14 20:51:04 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2148E16A421 for ; Wed, 14 Nov 2007 20:51:04 +0000 (UTC) (envelope-from billy@nlcc.us) Received: from mail1.wildblue.net (mail1.wildblue.net [216.126.204.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0353C13C467 for ; Wed, 14 Nov 2007 20:51:03 +0000 (UTC) (envelope-from billy@nlcc.us) Received: from ibm.nlcc.us (67-54-202-48.cust.wildblue.net [67.54.202.48]) by mail1.wildblue.net (Postfix) with ESMTP id 6B07736D025 for ; Wed, 14 Nov 2007 13:50:59 -0700 (MST) Received: (qmail 82521 invoked by uid 89); 14 Nov 2007 20:50:49 -0000 Received: from unknown (HELO ?192.168.0.33?) (billy@192.168.0.33) by ibm.nlcc.us with ESMTPA; 14 Nov 2007 20:50:49 -0000 Message-ID: <473B5FA4.1060704@nlcc.us> Date: Wed, 14 Nov 2007 14:50:44 -0600 From: Billy Newsom User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <473B521D.7050202@nlcc.us> <200711141537.51447.jhb@freebsd.org> In-Reply-To: <200711141537.51447.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: reBoot code: can we detect if there is an AT keyboard controller? 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, 14 Nov 2007 20:51:04 -0000 John Baldwin wrote: > On Wednesday 14 November 2007 02:53:01 pm Billy Newsom wrote: >> AFAIK, the FreeBSD kernel still relies on a 90s codebase for rebooting... It uses the >> keyboard controller reset method to do a warm reboot. >> >> I have had trouble with this method over the years... a Pentium Pro and more recently >> a Mac Pro with no keyboard controller. I have speculated that Mac laptops and blade >> servers would also lack the KBC. If Intel continues their progress of dropping >> deprecated hardware, the KBC could disappear in the next 3 to 5 years. >> >> So could there be some intelligent software code to check the presence of this >> device, and if not present, use the alternate reboot? The ACPI reboot sequence, for >> example, works for FreeBSD 6.2 and later, on my Mac Pro quad Xeon, amd64. >> >> Unfortunately, although the kernel detects the presence of a KBC during boot, it >> doesn't seem that this information gets stored as a global variable for later use. (I >> made this assertion a few times at freebsd-stable.) It seems like the logical course >> is to only reboot the keyboard controller if such a thing exists!! >> >> Looking back at my notes and my previous research, it appears that the code is around >> where you can find the cpu_reset code near... >> >> /* "good night, sweet prince .... " */ >> >> Setting hw.acpi.handle_reboot=1 must bypass that. Could we force the use of this >> tunable when it's obvious that the KBC is missing? > > Actually, I recently updated the reboot code to try several other sequences > besides just the keyboard controller such as flipping reset bits in I/O > ports 0xcf9 and 0x92. Also, when I did the update I also fixed a bug in > the triple-fault last-effort that had caused it to not actually cause a > triple-fault. As a result, you might be able to reboot just fine now on > newer stable w/o the tunable if you have this commit: > > revision 1.259.2.6 > date: 2007/04/30 17:45:44; author: jhb; state: Exp; lines: +40 -6 > MFC: Various fixes to cpu_reset_real() > - Try to use the reset control register (I/O port 0xcf9) and the fast a20 > and init register (I/O port 0x92) if the keyboard reset fails. > - Fix the triple fault to actually work when PGE is enabled. > Great. Thanks John for working on this code... It was looking pretty grungy after about 10 years! Wouldn't William Shakespeare be proud. I will do an update to 6.2-stable and put that drive back into my Mac Pro and see what happens without the kernel tunable. My Mac Pro, is, um, well, running another operating system or two right now. One comment is that my Mac system wasn't FAILING to reboot, it was panicking with a Trap 12, I believe. My last attempt on that system was around 2/20/2007 perhaps, so my memory lapses. Billy From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 14:26:29 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D52116A417 for ; Thu, 15 Nov 2007 14:26:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6CF13C478 for ; Thu, 15 Nov 2007 14:26:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1E0D948912; Thu, 15 Nov 2007 09:26:26 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 15 Nov 2007 09:26:26 -0500 X-Sasl-enc: VjAIC+nC0gQNQZdEGhVLs3m911+EYUZMlm47ch0xQryl 1195136785 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 782FBE20F; Thu, 15 Nov 2007 09:26:25 -0500 (EST) Message-ID: <473C5710.7040909@incunabulum.net> Date: Thu, 15 Nov 2007 14:26:24 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andrew Reilly References: <4722BDBE.5030408@incunabulum.net> <20071028.000300.-861062412.imp@bsdimp.com> <20071115130058.GA71758@duncan.reilly.home> In-Reply-To: <20071115130058.GA71758@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel 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: Thu, 15 Nov 2007 14:26:29 -0000 Andrew Reilly wrote: > Could that be done with cfront (C++ to C translation)? From > memory, cfront didn't do exceptions or rtti either, as they had > not been invented yet. > The thing is Stroustrup has come out and said that eC++ is pretty much not worth bothering with. Based on my experience in working with C++ on project XORP, I am inclined to agree with him -- the usefulness of C++ is degraded without these features. The point which invoked the original discussion, keeping this compiler/toolchain agnostic for the moment: the fact the Netlab team has shown it is possible to implement C++ exceptions for a kernel target, in a manner which has acceptable performance characteristics for that kind of target. RTTI is a separate issue from exceptions. Usually it just amounts to an additional slot in the vtbl to allow the type of the object to be determined; and the depth of the inheritance graph. Beyond this, any additional cost is due to how the compiler implements RTTI -- naming conventions and linkage conventions are the real issue here. I don't doubt that how RTTI is implemented in GNU C++, for example, is likely to lead to bloat, so I am inclined to agree with you that RTTI is best avoided, for the time being, in kernel context -- although the benefits of dynamic_cast in capturing shared semantics speak for themselves. Based on my experience with C++, I would be more concerned about the potential misuse of templates for introducing bloat. One has to be very, very careful about how meta-classes are implemented. It is possible to capture a lot of common semantics in a large software project using templates, and obtain the benefits of code reuse without sacrificing performance, but, as I have said earlier in this thread, the tool has to be wielded carefully to get these benefits. regards, BMS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 18:15:08 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49E6F16A579 for ; Thu, 15 Nov 2007 18:15:08 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from qsrv01sl.mx.bigpond.com (qsrv01sl.mx.bigpond.com [144.140.92.181]) by mx1.freebsd.org (Postfix) with ESMTP id 66CFE13C46A for ; Thu, 15 Nov 2007 18:15:06 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta04sl.mx.bigpond.com ([124.188.162.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071115130340.UFWU22254.omta02sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Thu, 15 Nov 2007 13:03:40 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by oaamta04sl.mx.bigpond.com with ESMTP id <20071115130340.UGHH11084.oaamta04sl.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 15 Nov 2007 13:03:40 +0000 Received: (qmail 71884 invoked by uid 501); 15 Nov 2007 13:00:58 -0000 Date: Fri, 16 Nov 2007 00:00:58 +1100 From: Andrew Reilly To: "M. Warner Losh" Message-ID: <20071115130058.GA71758@duncan.reilly.home> References: <4722BDBE.5030408@incunabulum.net> <20071028.000300.-861062412.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071028.000300.-861062412.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: bms@incunabulum.net, freebsd-arch@freebsd.org Subject: Re: C++ in the kernel 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: Thu, 15 Nov 2007 18:15:08 -0000 On Sun, Oct 28, 2007 at 12:03:00AM -0600, M. Warner Losh wrote: > In message: <4722BDBE.5030408@incunabulum.net> > Bruce M Simpson writes: > : It seems a team in Iceland succeeded in making Linux C++ enabled: > > Most people on this list haven't had experience with eC++. In this > environment, a number of the features of the language are omitted to > be better suited to the embedded environment. > > If it were up to me, I wouldn't bother with supporting exception. > They are one of the areas that are abused that have dire consequences > when abused (uncaught exceptions are evil, for example). Rtti was > also omitted from eC++ as well. These things help debloat the > language and can be used to good effect. Could that be done with cfront (C++ to C translation)? From memory, cfront didn't do exceptions or rtti either, as they had not been invented yet. -- Andrew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 10:29:29 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 85FE616A41A; Fri, 16 Nov 2007 10:29:29 +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 D99AB13C447; Fri, 16 Nov 2007 10:29:28 +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 9E95F17105; Fri, 16 Nov 2007 10:29:26 +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 lAGATPDE027727; Fri, 16 Nov 2007 10:29:26 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 13 Nov 2007 21:51:17 +0100." <20071113215117.3b9bab8c@deskjail> Date: Fri, 16 Nov 2007 10:29:25 +0000 Message-ID: <27726.1195208965@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: Fri, 16 Nov 2007 10:29:29 -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". 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. 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. So let me make my position 100% clear: 1. I would LOVE to see FreeBSD grow competent support for managing sensors, (and possibly actuators). 2. I have many years of experience and a fair bit of code I can and will contribute to such a project. 3. I don't want some half-assed, badly thought out "it works for me" crap, because I have spent most of my FreeBSD years cleaning that sort of stuff up, and I'm trying to break the habbit. 4. Therefore, any attempt to get sensorcode into FreeBSD that does not comply with the architectural model set out below will be met with my full effort of resistance. 5. The ball is now in your court. Sincerely, Poul-Henning 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.) 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. 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. -- 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. 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 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 20:17:14 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 3E1EA16A417; Fri, 16 Nov 2007 20:17:14 +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 E88DF13C448; Fri, 16 Nov 2007 20:17:13 +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 7C2AA17105; Fri, 16 Nov 2007 20:17:12 +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 lAGKHBtf030394; Fri, 16 Nov 2007 20:17:11 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 16 Nov 2007 20:59:18 +0100." <20071116205918.0e9d5819@deskjail> Date: Fri, 16 Nov 2007 20:17:11 +0000 Message-ID: <30393.1195244231@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: Fri, 16 Nov 2007 20:17:14 -0000 In message <20071116205918.0e9d5819@deskjail>, Alexander Leidinger writes: >> 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)? I'm not forcing any architecture, FreeBSD is no single mans project and neither I, nor anybody else has veto power over our architecture or direction. Neither am I denying anybody any voice or chance to argue, but after a certain amount of, IMO pretty pointless, argument, I may tire of them. Instead of wasting more time on these endless emails, which in my opinion has not moved anywhere since they began, I have simply boiled my requirements down to the core in the above diagram. You're free to try to sell any different architecture to me and the rest of the project. If you come up with something better, I will support it, if you come up with something worse, I'll put a every hole in its archtecture that my cross-hairs can be fixed on. If you go with the above architecture, you will have answered most, if not all critism that has been leveraged against the half-baked code imported from OpenBSD, and we can move right ahead to start to get things done. It's your choice how you want to spend your time... -- 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. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 17 11:59:31 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 0FE8C16A419; Sat, 17 Nov 2007 11:59:31 +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 52F9A13C4D9; Sat, 17 Nov 2007 11:59:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A543FB.dip.t-dialin.net [84.165.67.251]) by redbull.bpaserver.net (Postfix) with ESMTP id 23BC72E09D; Sat, 17 Nov 2007 12:59:16 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id DFB6C676D8; Sat, 17 Nov 2007 12:59:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1195300753; bh=nn1tEpXfwW/ZHGdWWZu4L6tqIgmX++yfz KuEgxEcGNU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:X-Mailer:Mime-Version:Content-Type: Content-Transfer-Encoding; b=JKbnEVMDYcec/O0najFmsb0He/HTrDYqOJ9MC VZsMiCAf28m/8/PYQjXiSeENwdYSmDXpvALOjkVi05E36THZ9IR4WAH26TAKgQvQtC8 AZyCX7OD/VJ6553se/H2C1fWJlmBautgp0bDeWmSvgCcmTuCYcb+HRGsMMgxqoYmhif tdixgzlX3ACwYhrgFb9tELWtR32T3Ov2mjA0ARgm5REKNnR5shkSt59dj+wtSEH+jDE +INLQrB9i18R6188/ZNOI3UaXvNb4MJwHtFms/r/Q4JOJHra+bP474YUcbEJV8uF8CF 14yJS6UForY29If2y6Nnoxd9cPDF/kz7em7jQ== Date: Sat, 17 Nov 2007 12:59:11 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071117125911.472e9390@deskjail> In-Reply-To: <30393.1195244231@critter.freebsd.dk> References: <20071116205918.0e9d5819@deskjail> <30393.1195244231@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=-14.9, required 8, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) 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: Sat, 17 Nov 2007 11:59:31 -0000 Quoting "Poul-Henning Kamp" (Fri, 16 Nov 2007 20:17:11 +0000): > In message <20071116205918.0e9d5819@deskjail>, Alexander Leidinger writes: > Neither am I denying anybody any voice or chance to argue, but after > a certain amount of, IMO pretty pointless, argument, I may tire of > them. You proposed something in the kernel, I pointed out how it can be done in the userland (which fits to your requirement of doing as much as possible in the userland instead of the kernel), and you haven't pointed out where my arguments are wrong. And I asked you to prove them wrong. Several times. But you just cut those parts out on your replies without answering any related questions I wrote. I agree that the discussion _between both of us_ is pretty pointless and that we have to find other discussion participants which interact better regarding this. Again: I try to find people which are either able to explain to me what you refuse to tell me (and then I'm quiet and you can proceed with your architectural proposal), or which agree that your proposal is more complex in the kernel without a significant benefit. > If you go with the above architecture, you will have answered most, > if not all critism that has been leveraged against the half-baked > code imported from OpenBSD, and we can move right ahead to start > to get things done. Your comments reads as you have looked at the architecture of the OpenBSD code. Is this the case, or do you still refuse to look at the OpenBSD code like you told us several times before? And in the architecture thread I don't talk about the OpenBSD code. I talk about using sysctl's to get the sensors data out of the kernel, and for example Robert Watson also likes the sysctl approach better than a fd based approach (Robert, if you changed your mind, it would be nice if you could explain me what changed your mind, as I haven't seen an argument from Poul which made it obvious for me that his more complex approach is better than the less complex sysctl approach). Jhb didn't see anything obviously wrong with the sysctl approach to export the data to the userland in his initial mail here on arch@ and he didn't participated in the discussion to explain me where I'm wrong. This means either he has no time to explain me in other words why your approach is better, doesn't care how the data is exported, or doesn't want to get into the line of fire. Those which proposed a fd approach in the beginning also didn't participated in our ping-pong mails to provide answers to the questions I asked. So _nobody_ explains what is wrong with my arguments against the fd approach, even when I ask to point out things I may have overlooked or get wrong. Yes, the OpenBSD code is an implementation which complies with the architectural proposal I talk about here, and if enough people are more interested in the sysctl approach than the fd approach, it would be logical to review the implementation and to decide if we adopt it (which would make our approach compatible with the one of other BSDs), or if we want to do a different implementation of such an architecture. Bye, Alexander. -- Somewhere in Tenafly, New Jersey, a chiropractor is viewing "Leave it to Beaver"! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137