From owner-freebsd-arch@FreeBSD.ORG Sun Jul 8 02:21:59 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 937A216A41F; Sun, 8 Jul 2007 02:21:59 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id F1F9713C4CC; Sun, 8 Jul 2007 02:21:58 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l681hswq026191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 05:43:58 +0400 Message-ID: <46904153.7040909@FreeBSD.org> Date: Sat, 07 Jul 2007 21:43:47 -0400 From: "Constantine A. Murenin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Andre Oppermann , freebsd-arch@FreeBSD.org References: <200707062345.l66Njpx3091970@repoman.freebsd.org> <468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> In-Reply-To: <468F517D.3010709@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , Perforce Change Reviews , "Constantine A. Murenin" Subject: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 08 Jul 2007 02:21:59 -0000 On 07/07/2007 04:40, Andre Oppermann wrote: > Rui Paulo wrote: > >> Constantine A. Murenin wrote: >> >>> http://perforce.freebsd.org/chv.cgi?CH=123040 >>> >>> Change 123040 by cnst@dale on 2007/07/06 23:45:36 >>> >>> add new node to sysctl.h: HW_SENSORS / "hw.sensors" >> >> >> Hmm. I thought new sysctl nodes or leafs were dynamic and you needn't to >> add any entry to sysctl.h. > > > Yes, all new sysctl nodes and leaves should be entirely dynamic. > The (old) static ones should go away with 8.0 or so. IIRC there > hasn't been any new static sysctl node since a loooong time. I don't exactly consider April 2007 being a loooong time ago. ;) So even first- and second-level nodes must be generated dynamically by 8.0? Hardware sensors tree is going to be pretty deep down. Under sysctl(8) the variable names will look like this: hw.sensors.lm0.temp0 whereas in reality, the tree has five levels: hw.sensors.lm0.temp.0 but as an exception to sysctl rule -- specifically for hw.sensors -- in OpenBSD the last dot is ommitted from sysctl(8) presentation to the user, to improve readability and preserve some sanity. :) I want to keep FreeBSD's sysctl hw.sensors tree compatible with the one in OpenBSD, so that both sysctl(8) shell scripts and sysctl(3) C utilities will be portable between the systems. Any suggestions are welcome, and let me know if you have any questions about the framework itself -- I'm the principal author of the current "two-level" revision of the framework on OpenBSD, so I know everything that is immediately relevant on how it works. ;) P.S. Obviously, what I say here about sysctl(8) variable names will equally apply to FreeBSD's sysctlbyname(3). P.P.S. Here is a sample output of a recent sysctl(8) on OpenBSD 4.1-current, on a consumer-grade G965-based Core 2 Duo system, with a pretty standard Winbond W83627DHG Super I/O: dale: {3360} dmesg | fgrep -e "cpu0: Intel" -e lm | tail -n2 cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.81 GHz lm0 at isa0 port 0x290/8: W83627DHG dale: {3361} sysctl hw.sensors.{cpu0,lm0.{temp,fan,volt{0,1,2,7}}} hw.sensors.cpu0.temp0=28.00 degC hw.sensors.lm0.temp0=58.00 degC hw.sensors.lm0.temp1=24.00 degC hw.sensors.lm0.fan1=917 RPM hw.sensors.lm0.volt0=1.15 VDC (VCore) hw.sensors.lm0.volt1=12.30 VDC (+12V) hw.sensors.lm0.volt2=3.33 VDC (+3.3V) hw.sensors.lm0.volt7=3.31 VDC (3.3VSB) dale: {3362} And let me warn you that the framework supports many more things than just temperature sensors -- from raid drive status to NMEA time offsets! :) Cheers, Constantine, Google Summer of Code 2007 Student. From owner-freebsd-arch@FreeBSD.ORG Sun Jul 8 03:02:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F08D16A421; Sun, 8 Jul 2007 03:02:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 15BA713C455; Sun, 8 Jul 2007 03:02:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from sam-lefflers-powerbook-g4-15.local (sam@[10.0.0.178]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l682aCIj093881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 19:36:12 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46904D9B.7030807@errno.com> Date: Sat, 07 Jul 2007 19:36:11 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Constantine A. Murenin" References: <200707062345.l66Njpx3091970@repoman.freebsd.org> <468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> <46904153.7040909@FreeBSD.org> In-Reply-To: <46904153.7040909@FreeBSD.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , Perforce Change Reviews , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 08 Jul 2007 03:02:40 -0000 Constantine A. Murenin wrote: > On 07/07/2007 04:40, Andre Oppermann wrote: > >> Rui Paulo wrote: >> >>> Constantine A. Murenin wrote: >>> >>>> http://perforce.freebsd.org/chv.cgi?CH=123040 >>>> >>>> Change 123040 by cnst@dale on 2007/07/06 23:45:36 >>>> >>>> add new node to sysctl.h: HW_SENSORS / "hw.sensors" >>> >>> >>> Hmm. I thought new sysctl nodes or leafs were dynamic and you needn't to >>> add any entry to sysctl.h. >> >> >> Yes, all new sysctl nodes and leaves should be entirely dynamic. >> The (old) static ones should go away with 8.0 or so. IIRC there >> hasn't been any new static sysctl node since a loooong time. > > I don't exactly consider April 2007 being a loooong time ago. ;) > > So even first- and second-level nodes must be generated dynamically by 8.0? > > Hardware sensors tree is going to be pretty deep down. Under sysctl(8) > the variable names will look like this: > > hw.sensors.lm0.temp0 > > whereas in reality, the tree has five levels: > > hw.sensors.lm0.temp.0 > > but as an exception to sysctl rule -- specifically for hw.sensors -- in > OpenBSD the last dot is ommitted from sysctl(8) presentation to the > user, to improve readability and preserve some sanity. :) I want to keep > FreeBSD's sysctl hw.sensors tree compatible with the one in OpenBSD, so > that both sysctl(8) shell scripts and sysctl(3) C utilities will be > portable between the systems. > > Any suggestions are welcome, and let me know if you have any questions > about the framework itself -- I'm the principal author of the current > "two-level" revision of the framework on OpenBSD, so I know everything > that is immediately relevant on how it works. ;) > > P.S. Obviously, what I say here about sysctl(8) variable names will > equally apply to FreeBSD's sysctlbyname(3). > > P.P.S. Here is a sample output of a recent sysctl(8) on OpenBSD > 4.1-current, on a consumer-grade G965-based Core 2 Duo system, with a > pretty standard Winbond W83627DHG Super I/O: > > dale: {3360} dmesg | fgrep -e "cpu0: Intel" -e lm | tail -n2 > cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) > 1.81 GHz > lm0 at isa0 port 0x290/8: W83627DHG > dale: {3361} sysctl hw.sensors.{cpu0,lm0.{temp,fan,volt{0,1,2,7}}} > hw.sensors.cpu0.temp0=28.00 degC > hw.sensors.lm0.temp0=58.00 degC > hw.sensors.lm0.temp1=24.00 degC > hw.sensors.lm0.fan1=917 RPM > hw.sensors.lm0.volt0=1.15 VDC (VCore) > hw.sensors.lm0.volt1=12.30 VDC (+12V) > hw.sensors.lm0.volt2=3.33 VDC (+3.3V) > hw.sensors.lm0.volt7=3.31 VDC (3.3VSB) > dale: {3362} > > And let me warn you that the framework supports many more things than > just temperature sensors -- from raid drive status to NMEA time offsets! :) Compatibility is a worthy goal and in this case fixing the 2nd level mib may be fine. But please recognize that openbsd != freebsd and some design decisions may turn out differently on freebsd. The p4 depot is provided specifically so you can explore different designs w/o polluting CVS. But before any code like this goes into CVS it will need review and at that point you may find decisions such as this questioned. Sam From owner-freebsd-arch@FreeBSD.ORG Sun Jul 8 08:05:13 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3162816A41F; Sun, 8 Jul 2007 08:05:13 +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 A76FD13C4BF; Sun, 8 Jul 2007 08:05:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A563C0.dip.t-dialin.net [84.165.99.192]) by redbull.bpaserver.net (Postfix) with ESMTP id 677782E178; Sun, 8 Jul 2007 09:36:21 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 46C095B4902; Sun, 8 Jul 2007 09:34:10 +0200 (CEST) Date: Sun, 8 Jul 2007 09:37:34 +0200 From: Alexander Leidinger To: "Constantine A. Murenin" Message-ID: <20070708093734.31df53b3@deskjail> In-Reply-To: <46904153.7040909@FreeBSD.org> References: <200707062345.l66Njpx3091970@repoman.freebsd.org> <468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> <46904153.7040909@FreeBSD.org> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-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.7, required 8, BAYES_50 2.50, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Andre Oppermann , Reviews , Perforce, "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 08 Jul 2007 08:05:13 -0000 Quoting "Constantine A. Murenin" (Sat, 07 Jul 2007 21:43:47 -0400): > On 07/07/2007 04:40, Andre Oppermann wrote: > > > Rui Paulo wrote: > > > >> Constantine A. Murenin wrote: > >> > >>> http://perforce.freebsd.org/chv.cgi?CH=123040 > >>> > >>> Change 123040 by cnst@dale on 2007/07/06 23:45:36 > >>> > >>> add new node to sysctl.h: HW_SENSORS / "hw.sensors" > >> > >> > >> Hmm. I thought new sysctl nodes or leafs were dynamic and you needn't to > >> add any entry to sysctl.h. > > > > > > Yes, all new sysctl nodes and leaves should be entirely dynamic. > > The (old) static ones should go away with 8.0 or so. IIRC there > > hasn't been any new static sysctl node since a loooong time. > > I don't exactly consider April 2007 being a loooong time ago. ;) > > So even first- and second-level nodes must be generated dynamically by 8.0? > > Hardware sensors tree is going to be pretty deep down. Under sysctl(8) > the variable names will look like this: > > hw.sensors.lm0.temp0 > > whereas in reality, the tree has five levels: > > hw.sensors.lm0.temp.0 > > but as an exception to sysctl rule -- specifically for hw.sensors -- in > OpenBSD the last dot is ommitted from sysctl(8) presentation to the > user, to improve readability and preserve some sanity. :) I want to keep Have a look at the dev tree, we don't have this rule in FreeBSD: ---snip--- dev.xl.0.%desc: 3Com 3c905C-TX Fast Etherlink XL dev.xl.0.%driver: xl dev.xl.0.%location: slot=11 function=0 dev.xl.0.%pnpinfo: vendor=0x10b7 device=0x9200 subvendor=0x10b7 subdevice=0x1000 class=0x020000 dev.xl.0.%parent: pci0 dev.xl.1.%desc: 3Com 3c905C-TX Fast Etherlink XL dev.xl.1.%driver: xl dev.xl.1.%location: slot=12 function=0 dev.xl.1.%pnpinfo: vendor=0x10b7 device=0x9200 subvendor=0x10b7 subdevice=0x1000 class=0x020000 dev.xl.1.%parent: pci0 ---snip--- > FreeBSD's sysctl hw.sensors tree compatible with the one in OpenBSD, so > that both sysctl(8) shell scripts and sysctl(3) C utilities will be > portable between the systems. I let other people comment if the hw.sensors tree should be consistent with the rest of the sysctl tree (personally I lean towards this, but I'm not interested in a bikeshed discussion, I just want to point out the current facts in FreeBSD) or compatible with OpenBSD (I don't moan if this is the final result). Bye, Alexander. -- Want to see how much virtual memory you're using? Just type "swapinfo" to be shown information about the usage of your swap partitions. 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 Jul 8 08:52:43 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16A0E16A400; Sun, 8 Jul 2007 08:52:43 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id D65DC13C46A; Sun, 8 Jul 2007 08:52:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (93umwt6hi0l5wxh7@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l688FEwZ054956; Sun, 8 Jul 2007 01:15:14 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l688FCZE054954; Sun, 8 Jul 2007 01:15:12 -0700 (PDT) (envelope-from jmg) Date: Sun, 8 Jul 2007 01:15:11 -0700 From: John-Mark Gurney To: "Constantine A. Murenin" Message-ID: <20070708081511.GX1221@funkthat.com> Mail-Followup-To: "Constantine A. Murenin" , Andre Oppermann , freebsd-arch@FreeBSD.org, Rui Paulo , Shteryana Shopova , Perforce Change Reviews References: <200707062345.l66Njpx3091970@repoman.freebsd.org> <468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> <46904153.7040909@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46904153.7040909@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Rui Paulo , Shteryana Shopova , Perforce Change Reviews , Andre Oppermann , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2007 08:52:43 -0000 Constantine A. Murenin wrote this message on Sat, Jul 07, 2007 at 21:43 -0400: > Hardware sensors tree is going to be pretty deep down. Under sysctl(8) > the variable names will look like this: > > hw.sensors.lm0.temp0 > > whereas in reality, the tree has five levels: > > hw.sensors.lm0.temp.0 I'm curious, why do we want/need these in the kernel as opposed to a userland library/utility to provide this info? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jul 8 11:09:05 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C81616A41F; Sun, 8 Jul 2007 11:09:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B983913C46A; Sun, 8 Jul 2007 11:09:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5A4C4472C1; Sun, 8 Jul 2007 06:44:54 -0400 (EDT) Date: Sun, 8 Jul 2007 11:44:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Constantine A. Murenin" In-Reply-To: <46904153.7040909@FreeBSD.org> Message-ID: <20070708113624.C13758@fledge.watson.org> References: <200707062345.l66Njpx3091970@repoman.freebsd.org> <468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> <46904153.7040909@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Shteryana Shopova , Perforce Change Reviews , Andre Oppermann , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 08 Jul 2007 11:09:05 -0000 On Sat, 7 Jul 2007, Constantine A. Murenin wrote: > On 07/07/2007 04:40, Andre Oppermann wrote: > >> Rui Paulo wrote: >> >>> Constantine A. Murenin wrote: >>> >>>> http://perforce.freebsd.org/chv.cgi?CH=123040 >>>> >>>> Change 123040 by cnst@dale on 2007/07/06 23:45:36 >>>> >>>> add new node to sysctl.h: HW_SENSORS / "hw.sensors" >>> >>> Hmm. I thought new sysctl nodes or leafs were dynamic and you needn't to >>> add any entry to sysctl.h. >> >> Yes, all new sysctl nodes and leaves should be entirely dynamic. The (old) >> static ones should go away with 8.0 or so. IIRC there hasn't been any new >> static sysctl node since a loooong time. > > I don't exactly consider April 2007 being a loooong time ago. ;) > > So even first- and second-level nodes must be generated dynamically by 8.0? While Andre's proposed goal of eliminating static sysctl nodes for 8.0 is laudable, a casual glimpse run found 261 references to top-level CTL_ constants in src outside of the kernel, so there's quite a bit of work to be done, as well as some rather serious ABI issues to address if we want that to happen. As such, while we can fix the consumers, I think simply eliminating support for static OIDs in 8.0 is likely unrealistic. In general, it is desirable, however, for all new nodes to be created using OID_AUTO rather than hand-humbering in order to avoid introducing any further ABI dependencies on static OID allocation. All recent large node hierarchies have used automatic OID numbering, including the top-level compat, sysctl, and security hierarchies. I would like to see the hw.sensor subtree also use automatic OID numbering for the same reason. While the sysctlbyname(3) API has its limitations, it is straight forward to use, and automatic OID numbering has both code cleanliness and compatibility benefits -- for example, when companies or organizations have heavily modified local FreeBSD installs, it prevents otherwise unresolvable collisions that would lead to ABI incompatibility. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Jul 8 12:21:17 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 067E816A46D; Sun, 8 Jul 2007 12:21:17 +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 AB55013C458; Sun, 8 Jul 2007 12:21:16 +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 B1BDE17380; Sun, 8 Jul 2007 12:03:01 +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 l68C30Ep066354; Sun, 8 Jul 2007 12:03:01 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 08 Jul 2007 11:44:54 +0100." <20070708113624.C13758@fledge.watson.org> Date: Sun, 08 Jul 2007 12:03:00 +0000 Message-ID: <66353.1183896180@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Andre Oppermann , Perforce Change Reviews , "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 08 Jul 2007 12:21:17 -0000 In message <20070708113624.C13758@fledge.watson.org>, Robert Watson writes: >While Andre's proposed goal of eliminating static sysctl nodes for 8.0 is >laudable, a casual glimpse run found 261 references to top-level CTL_ >constants in src outside of the kernel, so there's quite a bit of work to be >done, [...] Nothing that couldn't be emulated, either in libraries or a kernel-shim. -- 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 Jul 8 12:26:21 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F34716A400; Sun, 8 Jul 2007 12:26:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCEA13C458; Sun, 8 Jul 2007 12:26:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E98B947271; Sun, 8 Jul 2007 08:26:20 -0400 (EDT) Date: Sun, 8 Jul 2007 13:26:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <66353.1183896180@critter.freebsd.dk> Message-ID: <20070708132500.N9997@fledge.watson.org> References: <66353.1183896180@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Andre Oppermann , Perforce Change Reviews , "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 08 Jul 2007 12:26:21 -0000 On Sun, 8 Jul 2007, Poul-Henning Kamp wrote: > In message <20070708113624.C13758@fledge.watson.org>, Robert Watson writes: > >> While Andre's proposed goal of eliminating static sysctl nodes for 8.0 is >> laudable, a casual glimpse run found 261 references to top-level CTL_ >> constants in src outside of the kernel, so there's quite a bit of work to >> be done, [...] > > Nothing that couldn't be emulated, either in libraries or a kernel-shim. Kris and I have been discussing moving to a model in which the compatXx distributions move to having custom-built libc/libpthread parts, so that if KSE support is removed entirely from the 8.x kernel, it will still be possible to run 5.x/6.x binaries, as we'd provide a 5.x/6.x libpthread that was actually a 7.x libthr. Something similar would be required here. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Jul 9 01:29:12 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC3BC16A469 for ; Mon, 9 Jul 2007 01:29:12 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [204.228.229.66]) by mx1.freebsd.org (Postfix) with ESMTP id C431413C4C1 for ; Mon, 9 Jul 2007 01:29:12 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net ([204.228.229.66] helo=localhost ident=mailnull) by diana.db.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1I7hOj-000LST-3g for freebsd-arch@freebsd.org; Sun, 08 Jul 2007 18:46:41 -0600 Received: from diana.db.net ([127.0.0.1] helo=localhost) (envelope-from ) id 1I7hOi-000G3p-7J for freebsd-arch@FreeBSD.ORG; Sun, 08 Jul 2007 20:46:40 -0400 Date: Sun, 8 Jul 2007 20:46:40 -0400 From: Diane Bruce To: freebsd-arch@FreeBSD.ORG Message-ID: <20070709004640.GA61639@night.db.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: select timings 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, 09 Jul 2007 01:29:12 -0000 Hi, It is a rather naive test program, close all fd's except for 0,1,2 of course, then open /dev/null multiple times, then do a select() on each descriptor. ~db/selt.c Each fd "fires" so select() goes through each bit. First two tests are with STOCK -7 kernel STOCK MAXFD = 1024 ./selt First select 0 4052 Second select 0 4011 dark# ./selt First select 0 4037 Second select 0 3991 dark# ./selt First select 0 4006 Second select 0 4018 dark# ./selt First select 0 4008 Second select 0 4583 dark# ./selt First select 0 4041 Second select 0 4012 MAXFD 8192 dark# ./selt First select 0 28736 Second select 0 28607 dark# ./selt First select 0 28655 Second select 0 28641 dark# ./selt First select 0 28629 Second select 0 28592 dark# ./selt First select 0 28890 Second select 0 29189 dark# ./selt First select 0 28629 Second select 0 28963 dark# ./selt First select 0 28960 Second select 0 28593 dark# ./selt First select 0 28622 Second select 0 28689 With Jeffr select2.diff MAXFD 8192 ./selt First select 30328 Second select 0 30375 dark% ./selt First select 0 30423 Second select 0 30214 dark% ./selt First select 0 30444 Second select 0 30200 dark% ./selt First select 0 30362 Second select 0 30797 dark% ./selt First select 0 30372 Second select 0 30365 Using Jeffr's original select.diff with 8192 fds First select 0 30738 Second select 0 28906 dark% ./selt First select 0 29242 Second select 0 28880 dark% ./selt First select 0 28612 Second select 0 28684 dark% ./selt First select 0 28617 Second select 0 28709 dark% ./selt First select 0 28926 Second select 0 28784 with 1024 fds ./selt First select 0 4056 Second select 0 4063 dark# ./selt First select 0 4297 Second select 0 4163 dark# ./selt First select 0 4101 Second select 0 4728 dark# ./selt First select 0 4137 Second select 0 4218 dark# ./selt First select 0 4034 Second select 0 4036 dark# ./selt First select 0 4075 Second select 0 4062 I will be trying some other select tests. I suspect with a sparse fd_set, jeffr's results will be better than stock. We'll see. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arch@FreeBSD.ORG Mon Jul 9 02:53:31 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1835116A421 for ; Mon, 9 Jul 2007 02:53:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id C38D413C4AD for ; Mon, 9 Jul 2007 02:53:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l692E9jE006401; Mon, 9 Jul 2007 12:14:09 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l692E8JL006400; Mon, 9 Jul 2007 12:14:08 +1000 (EST) (envelope-from peter) Date: Mon, 9 Jul 2007 12:14:08 +1000 From: Peter Jeremy To: Diane Bruce Message-ID: <20070709021408.GK3434@turion.vk2pj.dyndns.org> References: <20070709004640.GA61639@night.db.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline In-Reply-To: <20070709004640.GA61639@night.db.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@freebsd.org Subject: Re: select timings 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, 09 Jul 2007 02:53:31 -0000 --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-08 20:46:40 -0400, Diane Bruce wrote: >It is a rather naive test program, close all fd's except >for 0,1,2 of course, then open /dev/null multiple times, then do >a select() on each descriptor. ~db/selt.c Thanks for the testing. Can you please feed the output through (eg) src/tools/tools/ministat. >I will be trying some other select tests. >I suspect with a sparse fd_set, jeffr's results will be better than stock. >We'll see. Having a very large number of selected FDs return ready is unrealistic - I can't think of any real-world situation where this would occur. A more realistic situation would look like a Poisson distribution with a small lambda (probably 1). Writing a test suite for this is probably significantly more effort than your selt.c --=20 Peter Jeremy --oTHb8nViIGeoXxdp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGkZnw/opHv/APuIcRApcsAKCB9Hlx9M2wYuSqQ/JOZxLJqZp/DQCffSjT QKdqq4F9mvEMFaSBvEHzUKo= =uBnv -----END PGP SIGNATURE----- --oTHb8nViIGeoXxdp-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 9 18:08:46 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75D7E16A41F for ; Mon, 9 Jul 2007 18:08:46 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4180A13C457 for ; Mon, 9 Jul 2007 18:08:46 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l69I8d15089345 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 14:08:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 8 Jul 2007 14:58:51 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Peter Jeremy In-Reply-To: <20070709021408.GK3434@turion.vk2pj.dyndns.org> Message-ID: <20070708145714.B537@10.0.0.1> References: <20070709004640.GA61639@night.db.net> <20070709021408.GK3434@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Diane Bruce , freebsd-arch@freebsd.org Subject: Re: select timings 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, 09 Jul 2007 18:08:46 -0000 On Mon, 9 Jul 2007, Peter Jeremy wrote: > On 2007-Jul-08 20:46:40 -0400, Diane Bruce wrote: >> It is a rather naive test program, close all fd's except >> for 0,1,2 of course, then open /dev/null multiple times, then do >> a select() on each descriptor. ~db/selt.c > > Thanks for the testing. Can you please feed the output through (eg) > src/tools/tools/ministat. > >> I will be trying some other select tests. >> I suspect with a sparse fd_set, jeffr's results will be better than stock. >> We'll see. > > Having a very large number of selected FDs return ready is unrealistic > - I can't think of any real-world situation where this would occur. A > more realistic situation would look like a Poisson distribution with a > small lambda (probably 1). Writing a test suite for this is probably > significantly more effort than your selt.c Well this test is useful because it shows the expected worst case for this patch which is very encouraging since one version of it is not slower than the original select code. That means in the best case we would expect my patch to be much faster. For example, if there were 8k fds and only one triggered my patch only calls fo_poll() on one fd and simply frees the other descriptors. Contrasted with the original code which calls poll all over again on each. Thanks very much for your help Diane. Jeff > > -- > Peter Jeremy > From owner-freebsd-arch@FreeBSD.ORG Mon Jul 9 18:10:21 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F08F616A400 for ; Mon, 9 Jul 2007 18:10:21 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B2C1713C458 for ; Mon, 9 Jul 2007 18:10:21 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l69IAGLD089906 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 14:10:18 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 8 Jul 2007 15:00:28 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Diane Bruce In-Reply-To: <20070709004640.GA61639@night.db.net> Message-ID: <20070708145900.Y537@10.0.0.1> References: <20070709004640.GA61639@night.db.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: select timings 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, 09 Jul 2007 18:10:22 -0000 On Sun, 8 Jul 2007, Diane Bruce wrote: > Hi, > > It is a rather naive test program, close all fd's except > for 0,1,2 of course, then open /dev/null multiple times, then do > a select() on each descriptor. ~db/selt.c I should mention that select2.diff embeds a selfd in each selinfo which means that with no collision we avoid malloc(). selfd is the structure that is allocated for each file descriptor by each thread that is selecting. select.diff allocates them on demand every time. The first select is slower as we have to fill the uma cache but after that it's remarkably faster. Thanks, Jeff > > Each fd "fires" so select() goes through each bit. > > First two tests are with STOCK -7 kernel > > STOCK > MAXFD = 1024 > > ./selt > First select 0 4052 > Second select 0 4011 > dark# ./selt > First select 0 4037 > Second select 0 3991 > dark# ./selt > First select 0 4006 > Second select 0 4018 > dark# ./selt > First select 0 4008 > Second select 0 4583 > dark# ./selt > First select 0 4041 > Second select 0 4012 > > MAXFD 8192 > > dark# ./selt > First select 0 28736 > Second select 0 28607 > dark# ./selt > First select 0 28655 > Second select 0 28641 > dark# ./selt > First select 0 28629 > Second select 0 28592 > dark# ./selt > First select 0 28890 > Second select 0 29189 > dark# ./selt > First select 0 28629 > Second select 0 28963 > dark# ./selt > First select 0 28960 > Second select 0 28593 > dark# ./selt > First select 0 28622 > Second select 0 28689 > > With Jeffr select2.diff > MAXFD 8192 > ./selt > First select 30328 > Second select 0 30375 > dark% ./selt > First select 0 30423 > Second select 0 30214 > dark% ./selt > First select 0 30444 > Second select 0 30200 > dark% ./selt > First select 0 30362 > Second select 0 30797 > dark% ./selt > First select 0 30372 > Second select 0 30365 > > Using Jeffr's original select.diff > > with 8192 fds > First select 0 30738 > Second select 0 28906 > dark% ./selt > First select 0 29242 > Second select 0 28880 > dark% ./selt > First select 0 28612 > Second select 0 28684 > dark% ./selt > First select 0 28617 > Second select 0 28709 > dark% ./selt > First select 0 28926 > Second select 0 28784 > > with 1024 fds > ./selt > First select 0 4056 > Second select 0 4063 > dark# ./selt > First select 0 4297 > Second select 0 4163 > dark# ./selt > First select 0 4101 > Second select 0 4728 > dark# ./selt > First select 0 4137 > Second select 0 4218 > dark# ./selt > First select 0 4034 > Second select 0 4036 > dark# ./selt > First select 0 4075 > Second select 0 4062 > > I will be trying some other select tests. > I suspect with a sparse fd_set, jeffr's results will be better than stock. > We'll see. > > - Diane > -- > - db@FreeBSD.org db@db.net http://www.db.net/~db > _______________________________________________ > 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 Jul 10 19:01:46 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9B3E16A468; Tue, 10 Jul 2007 19:01:46 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 9A98013C4FA; Tue, 10 Jul 2007 19:01:46 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 10 Jul 2007 11:28:13 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l6AIX1Pf049967; Tue, 10 Jul 2007 11:33:01 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l6AIX0xl049962; Tue, 10 Jul 2007 11:33:00 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707101833.l6AIX0xl049962@ambrisko.com> In-Reply-To: <20070708081511.GX1221@funkthat.com> To: John-Mark Gurney Date: Tue, 10 Jul 2007 11:33:00 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Rui Paulo , Andre Oppermann , Perforce Change Reviews , "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 10 Jul 2007 19:01:46 -0000 John-Mark Gurney writes: | Constantine A. Murenin wrote this message on Sat, Jul 07, 2007 at 21:43 -0400: | > Hardware sensors tree is going to be pretty deep down. Under sysctl(8) | > the variable names will look like this: | > | > hw.sensors.lm0.temp0 | > | > whereas in reality, the tree has five levels: | > | > hw.sensors.lm0.temp.0 | | I'm curious, why do we want/need these in the kernel as opposed to a | userland library/utility to provide this info? I agree. There are so many different flavours of HW monitoring chips and several tools that can read them live in ports. Lots of them are slightly different, intefaces can be i2c or direct I/O. We are already somewhat battling with the various ways IPMI controllers can be attached to the system. Now in the case of IPMI there is a good win in providing a device driver interface for the HW and user land tools to get info. out of them. I don't see a win with this in the various HW monitoring chips. Doug A. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 10 20:38:07 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C76716A421; Tue, 10 Jul 2007 20:38:07 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8F513C44C; Tue, 10 Jul 2007 20:38:06 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6AKbWiP024342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 00:37:38 +0400 Message-ID: <4693EDFB.5050401@FreeBSD.org> Date: Tue, 10 Jul 2007 16:37:15 -0400 From: "Constantine A. Murenin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Doug Ambrisko References: <200707101833.l6AIX0xl049962@ambrisko.com> In-Reply-To: <200707101833.l6AIX0xl049962@ambrisko.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 10 Jul 2007 20:38:07 -0000 On 10/07/2007 14:33, Doug Ambrisko wrote: >There are so many different flavours of HW monitoring chips > and several tools that can read them live in ports. Lots of them are > slightly different, intefaces can be i2c or direct I/O. Please, enlighten me which of these several tools were updated in the last few years. Most hardware monitoring tools in the ports tree are outdated and no longer being maintained: xmbmon, healthd, lmmon, consolehm, wmhm etc. Several of these have a last-modified date of 2000, that's 7 years ago! Please note that this framework is not limited to monitoring temperature and fan speed sensors -- it also allows one to monitor raid array status and a few other things. Moreover, in OpenBSD and NetBSD these kinds of in-kernel frameworks are used to display ipmi(4) sensors, too. Monitoring of remote machines with this framework is also possible -- with symon from ports. Querying local machines is as easy as running sysctl or systat, and alerts can be generated through sensorsd. Cheers, Constantine. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 10 21:00:33 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF26E16A421; Tue, 10 Jul 2007 21:00:33 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8A89513C48C; Tue, 10 Jul 2007 21:00:33 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 10 Jul 2007 13:55:44 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l6AL0W8q063339; Tue, 10 Jul 2007 14:00:32 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l6AL0WPA063338; Tue, 10 Jul 2007 14:00:32 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707102100.l6AL0WPA063338@ambrisko.com> In-Reply-To: <4693EDFB.5050401@FreeBSD.org> To: "Constantine A. Murenin" Date: Tue, 10 Jul 2007 14:00:32 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 10 Jul 2007 21:00:33 -0000 Constantine A. Murenin writes: | On 10/07/2007 14:33, Doug Ambrisko wrote: | >There are so many different flavours of HW monitoring chips | > and several tools that can read them live in ports. Lots of them are | > slightly different, intefaces can be i2c or direct I/O. | | Please, enlighten me which of these several tools were updated in the | last few years. Most hardware monitoring tools in the ports tree are | outdated and no longer being maintained: xmbmon, healthd, lmmon, | consolehm, wmhm etc. Several of these have a last-modified date of 2000, | that's 7 years ago! Being in the kernel means they get updated? It's so trivial to write this stuff that I've put it in various embedded appliances. There are so many different chips why bother trying to support them all when there is little bang for effort and it add's kernel bloat. | Please note that this framework is not limited to monitoring temperature | and fan speed sensors -- it also allows one to monitor raid array status | and a few other things. | | Moreover, in OpenBSD and NetBSD these kinds of in-kernel frameworks are | used to display ipmi(4) sensors, too. Which is probably a mistake IMHO but atleast has a common interface. Note that talking to IPMI controllers can be rather expensive. Users have to be careful with things talking to IPMI when updating firmware. There are more firmware upgrade tools that use the OpenIPMI interface so they just work with the driver. | Monitoring of remote machines with this framework is also possible -- | with symon from ports. Querying local machines is as easy as running | sysctl or systat, and alerts can be generated through sensorsd. It's trivial to do in other ways as well. Personally, I don't care if someone does it as a project. Personally, I'd recommend it done as a library that has a kernel front end and user land interface. To clarify it could be built as a kernel module or user land tool. Then you have the best of both worlds. This would be trivial to do. I've done something similar with something else. Doug A. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 10 21:43:46 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD0F16A475; Tue, 10 Jul 2007 21:43:46 +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 9518F13C4AE; Tue, 10 Jul 2007 21:43:46 +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 8311D17380; Tue, 10 Jul 2007 21:43:44 +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 l6ALhhXA053467; Tue, 10 Jul 2007 21:43:43 GMT (envelope-from phk@critter.freebsd.dk) To: Doug Ambrisko From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 10 Jul 2007 14:00:32 MST." <200707102100.l6AL0WPA063338@ambrisko.com> Date: Tue, 10 Jul 2007 21:43:43 +0000 Message-ID: <53466.1184103823@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review) 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, 10 Jul 2007 21:43:47 -0000 A number of observations: The main problem about hardware monitoring is the lack of a name-space. The OpenBSD sysctl doesn't get anywhere close to providing that. Putting stuff in the kernel is not a magic solution to that problem, as we have seen far too many examples of, starting with the socket(2) mistake in early BSD UNIX, and reaching a preliminary pinnacle with the SysV IPC mechanisms. The first task therefore, must be to design a namespace where all the assorted pieces of software can contribute their measurements and registrations. Once that's designed, we can start to argue if the code should live in the kernel, userland or in ports. But please don't import any half-assed "Ohh, I'll just hack this in there" non-solutions. -- 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 Tue Jul 10 22:23:46 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B0E116A421; Tue, 10 Jul 2007 22:23:46 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id EDAC413C43E; Tue, 10 Jul 2007 22:23:45 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6AMNduN012123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 02:23:42 +0400 Message-ID: <469406E0.3090206@FreeBSD.org> Date: Tue, 10 Jul 2007 18:23:28 -0400 From: "Constantine A. Murenin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Poul-Henning Kamp References: <53466.1184103823@critter.freebsd.dk> In-Reply-To: <53466.1184103823@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 10 Jul 2007 22:23:46 -0000 On 10/07/2007 17:43, Poul-Henning Kamp wrote: > A number of observations: > > The main problem about hardware monitoring is the lack of a name-space. > > The OpenBSD sysctl doesn't get anywhere close to providing that. There is no lack in namespace, specifically after the recent redesign of the framework. When you do sysctl(3) calls in OpenBSD 4.1, you specify the type of the sensor that you want to look at in mib[3], and go through a combination of mib[2] (sensor device, i.e. lm0 or ipmi0) and mib[4] (sensor number of above type on above device) to query all devices and all sensors on all of these devices (mib[0] = CTL_HW; mib[1] = HW_SENSORS;). You can be 100% sure that every sensor returned with these calls is a sensor of type specified in mib[3]. Each sensor type has a well-defined unit and other properties. String descriptions are entirely optional, predefined sensor types is all that matters. Range for mib[4] is provided in the sensordev datastructure that can be accessed when mib[3] and mib[4] are omitted. How do you see this as a lack of a namespace? Cheers, Constantine. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 10 22:38:00 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C679B16A46C; Tue, 10 Jul 2007 22:38:00 +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 8040F13C469; Tue, 10 Jul 2007 22:38: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 DA07217380; Tue, 10 Jul 2007 22:37:58 +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 l6AMbwjb053706; Tue, 10 Jul 2007 22:37:58 GMT (envelope-from phk@critter.freebsd.dk) To: "Constantine A. Murenin" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 10 Jul 2007 18:23:28 -0400." <469406E0.3090206@FreeBSD.org> Date: Tue, 10 Jul 2007 22:37:58 +0000 Message-ID: <53705.1184107078@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 10 Jul 2007 22:38:00 -0000 In message <469406E0.3090206@FreeBSD.org>, "Constantine A. Murenin" writes: >On 10/07/2007 17:43, Poul-Henning Kamp wrote: > >> A number of observations: >> >> The main problem about hardware monitoring is the lack of a name-space. >> >> The OpenBSD sysctl doesn't get anywhere close to providing that. > >There is no lack in namespace, specifically after the recent redesign of >the framework. > >When you do sysctl(3) calls in OpenBSD 4.1 [...] >How do you see this as a lack of a namespace? What OpenBSD has is an enumeration, and that is not the same as a name-space. If you live in the USA, chances are that you have a social security number. That is an example of an enumeration: "We have all these FOOs and we need to tell them apart". However, you parents gave you a name, because what that is the key to the human name-space, which is so called for the obvious reason. Physical measurements are only relevant in the context of their physical location and the OpenBSD enumeration doesn't even encode this, it is only interested in the logical location of the sensor, what kind of bus it is on, what kind of address it has. For any hw-sensor namespace to make sense, it must, as a minimum, identify the sensors in terms of the device(-drivers) associated with the hardware where the sensor senses, not the device-driver of the sensor itself. The OpenBSD stuff is a 1980 style hack, and should not be propagated. -- 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 Tue Jul 10 23:41:44 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02BAF16A46B; Tue, 10 Jul 2007 23:41:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD0FA13C448; Tue, 10 Jul 2007 23:41:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 401EE476B3; Tue, 10 Jul 2007 19:41:43 -0400 (EDT) Date: Wed, 11 Jul 2007 00:41:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <53705.1184107078@critter.freebsd.dk> Message-ID: <20070711003958.V8913@fledge.watson.org> References: <53705.1184107078@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 10 Jul 2007 23:41:44 -0000 On Tue, 10 Jul 2007, Poul-Henning Kamp wrote: > Physical measurements are only relevant in the context of their physical > location and the OpenBSD enumeration doesn't even encode this, it is only > interested in the logical location of the sensor, what kind of bus it is on, > what kind of address it has. > > For any hw-sensor namespace to make sense, it must, as a minimum, identify > the sensors in terms of the device(-drivers) associated with the hardware > where the sensor senses, not the device-driver of the sensor itself. > > The OpenBSD stuff is a 1980 style hack, and should not be propagated. This argument would be more convincing if accompanied by a concrete example, fabricated or otherwise. Are you suggesting, for example, adding newbus sensor methods associated with existing driver attachments? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jul 10 23:59:00 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 358F116A41F; Tue, 10 Jul 2007 23:59:00 +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 E5BD213C48A; Tue, 10 Jul 2007 23:58:59 +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 6459317383; Tue, 10 Jul 2007 23:58:58 +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 l6ANwvPF053932; Tue, 10 Jul 2007 23:58:57 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 00:41:43 +0100." <20070711003958.V8913@fledge.watson.org> Date: Tue, 10 Jul 2007 23:58:57 +0000 Message-ID: <53931.1184111937@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 10 Jul 2007 23:59:00 -0000 In message <20070711003958.V8913@fledge.watson.org>, Robert Watson writes: >On Tue, 10 Jul 2007, Poul-Henning Kamp wrote: >> The OpenBSD stuff is a 1980 style hack, and should not be propagated. > >This argument would be more convincing if accompanied by a concrete example, >fabricated or otherwise. Are you suggesting, for example, adding newbus >sensor methods associated with existing driver attachments? I'm not advocating that we actually tro to overengineer a solution for this stuff. As long as the hardware people don't think about where the slam down the sensors, there is little chance of us making any kind of sense of their measurements without the context which we often have to glean from physical inspection. I'm objecting to the OpenBSD code because it gives the impression of order and structure, where none exists. -- 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 Wed Jul 11 00:14:01 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7D9016A41F; Wed, 11 Jul 2007 00:14:01 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 40D0913C458; Wed, 11 Jul 2007 00:14:00 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6B0Duex008273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 04:13:59 +0400 Message-ID: <469420B9.20401@FreeBSD.org> Date: Tue, 10 Jul 2007 20:13:45 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Poul-Henning Kamp References: <53705.1184107078@critter.freebsd.dk> In-Reply-To: <53705.1184107078@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 00:14:01 -0000 On 10/07/2007 18:37, Poul-Henning Kamp wrote: > In message <469406E0.3090206@FreeBSD.org>, "Constantine A. Murenin" writes: > >>There is no lack in namespace, specifically after the recent redesign of >>the framework. >> >>When you do sysctl(3) calls in OpenBSD 4.1 [...] > > >>How do you see this as a lack of a namespace? > > > What OpenBSD has is an enumeration, and that is not the same as a > name-space. > > If you live in the USA, chances are that you have a social security > number. That is an example of an enumeration: "We have all these > FOOs and we need to tell them apart". I don't see how this comparison applies to the framework. SSN is a magic number, and there are no magic numbers to be remembered to access temperature sensors from sysctl. You ask for temperature, you are given temperature. You ask for fan speed, you are given fan speed. > However, you parents gave you a name, because what that is the key > to the human name-space, which is so called for the obvious reason. And sensors are given unique, consistent and predictable names by the framework, which are easy to remember and manipulate. > Physical measurements are only relevant in the context of their > physical location and the OpenBSD enumeration doesn't even encode > this, it is only interested in the logical location of the sensor, > what kind of bus it is on, what kind of address it has. There is no distinction in sensors at i2c bus from sensors at isa bus, or any other real or imaginary bus. > For any hw-sensor namespace to make sense, it must, as a minimum, > identify the sensors in terms of the device(-drivers) associated > with the hardware where the sensor senses, not the device-driver > of the sensor itself. Some ethernet adapters have sensors, and they are exported under the name of the adapter (e.g. hw.sensors.nxb0.temp0 for some 10Gb Ethernet NetXen cards). Intel Core on-die temperature sensors are exported under the name of the cpu (e.g. hw.sensors.cpu0.temp0). With Super I/O and i2c sensor chips, it's a bit different. With i2c sensors there is usually no way to know sensor's physical location no matter what kind of a namespace you propose to come up with. > The OpenBSD stuff is a 1980 style hack, and should not be propagated. The more complex the system, the higher the chance that it will contain multiple mistakes. This framework is simple enough to be elegant. The result -- there are 51 (fifty-one) drivers that use this framework and several userland and port utilities. Every machine that runs OpenBSD, from Apple and ThinkPad laptops to home PCs to high-end servers, has many sensors that work out of the box (tm), with zero configuration and with a unified interface by which they can be accessed, locally or remotely. If you want to have no such framework that could potentially diagnose or predict system failure, it's your choice, and I'm not going to argue against it. However, there are many people who desire to have this feature in an operating system, and these people include FreeBSD users and developers. Cheers, Constantine. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 02:59:44 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB3316A421; Wed, 11 Jul 2007 02:59:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BB9FF13C457; Wed, 11 Jul 2007 02:59:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6B2vpLq021388; Tue, 10 Jul 2007 20:57:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 10 Jul 2007 20:57:51 -0600 (MDT) Message-Id: <20070710.205751.-1962670861.imp@bsdimp.com> To: ambrisko@ambrisko.com From: "M. Warner Losh" In-Reply-To: <200707101833.l6AIX0xl049962@ambrisko.com> References: <20070708081511.GX1221@funkthat.com> <200707101833.l6AIX0xl049962@ambrisko.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 10 Jul 2007 20:57:57 -0600 (MDT) Cc: rpaulo@fnop.net, gurney_j@resnet.uoregon.edu, andre@freebsd.org, perforce@freebsd.org, cnst@freebsd.org, syrinx@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 02:59:44 -0000 In message: <200707101833.l6AIX0xl049962@ambrisko.com> Doug Ambrisko writes: : John-Mark Gurney writes: : | Constantine A. Murenin wrote this message on Sat, Jul 07, 2007 at 21:43 -0400: : | > Hardware sensors tree is going to be pretty deep down. Under sysctl(8) : | > the variable names will look like this: : | > : | > hw.sensors.lm0.temp0 : | > : | > whereas in reality, the tree has five levels: : | > : | > hw.sensors.lm0.temp.0 : | : | I'm curious, why do we want/need these in the kernel as opposed to a : | userland library/utility to provide this info? : : I agree. There are so many different flavours of HW monitoring chips : and several tools that can read them live in ports. Lots of them are : slightly different, intefaces can be i2c or direct I/O. We are already : somewhat battling with the various ways IPMI controllers can be attached : to the system. Now in the case of IPMI there is a good win in providing : a device driver interface for the HW and user land tools to get info. : out of them. I don't see a win with this in the various HW monitoring : chips. My big concern is the 'automatic' probing. It doesn't mix well with i2c eeprom chips :-( Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 08:22:02 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE12316A469 for ; Wed, 11 Jul 2007 08:22:02 +0000 (UTC) (envelope-from wieczyk@trzask.int.pl) Received: from trzask.int.pl (host-81-190-193-233.gizycko.mm.pl [81.190.193.233]) by mx1.freebsd.org (Postfix) with ESMTP id B56B813C459 for ; Wed, 11 Jul 2007 08:21:59 +0000 (UTC) (envelope-from wieczyk@trzask.int.pl) Received: from [192.168.0.99] (unknown [192.168.0.99]) by trzask.int.pl (Postfix) with ESMTP id E0A841A436 for ; Wed, 11 Jul 2007 12:08:51 +0200 (CEST) Message-ID: <4694AC5C.9040107@trzask.int.pl> Date: Wed, 11 Jul 2007 10:09:32 +0000 From: Pawel Wieczorek User-Agent: Thunderbird 2.0.0.0 (X11/20070529) MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20070708081511.GX1221@funkthat.com> <200707101833.l6AIX0xl049962@ambrisko.com> <20070710.205751.-1962670861.imp@bsdimp.com> In-Reply-To: <20070710.205751.-1962670861.imp@bsdimp.com> Content-Type: multipart/mixed; boundary="------------020003070002010103050303" Subject: new friend of sys/queue.h and sys/tree.h 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, 11 Jul 2007 08:22:03 -0000 This is a multi-part message in MIME format. --------------020003070002010103050303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I did something like sys/queue.h and sys/tree.h: sys/bds.h bds - Basic Data Structures. Hash table are basic data structure, it is good to have it in kernel, but i did not see some easy to use framework like sys/queue.h in our kernel. At current time it have only hash table and multi-value hash table, but i want to add in near future something else. I did not done full documentation how to use it(yet), but i did two examples. One is how to use it user-space and one how to use it in kernel-space. I tested code on "cc" on OpenSolaris (because cc on sunos is more pedantic) and "cc" "c++" "c89" "c99" on FreeBSD 6.2-RELEASE. I develop sys/bds.h for my private usage, but i think it can be used in freebsd kernel programming, because is safe, easy to use and similar to sys/queue.h. I am waiting for comments... --------------020003070002010103050303 Content-Type: application/octet-stream; name="bdsm.tar" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bdsm.tar" YmRzbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDc1NSAA MDAxNzUxIAAwMDE3NTAgADAwMDAwMDAwMDAwIDEwNjQ1MTI0Mjc2IDAxMjU3NwAgNQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHdpZWN6 eWsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa29udGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAwMDAwMDAgADAwMDAwMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL01ha2VmaWxlAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMDAwNzU1IAAwMDE3NTEgADAwMTc1MCAAMDAwMDAwMDAxNzIg MTA2NDUxMjM3NDMgMDE0MzE3ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABr b250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAwMDAwIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFNV QkRJUj1leGFtcGxlMCBleGFtcGxlMQoKbG9hZDoKCWNkIGV4YW1wbGUxL2RldjsgbWFrZSBs b2FkCgoKY29weToKCWNwIGV4YW1wbGUxL3V0aWwvYmRzY3RsIC4KCgoKLmluY2x1ZGU8YnNk LnN1YmRpci5taz4KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYmRzbS9tYW4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAwMDc1NSAAMDAxNzUxIAAwMDE3NTAgADAwMDAwMDAwMDAwIDEw NjQ0MTc3NzQyIDAxMzM1NwAgNQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB1c3RhcgAwMHdpZWN6eWsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa29u dGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAgADAwMDAwMCAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNt L3N5cwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwNzU1IAAwMDE3 NTEgADAwMTc1MCAAMDAwMDAwMDAwMDAgMTA2NDUxMjQ3MzMgMDEzNDEzACA1AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrb250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADAwMDAwMCAAMDAwMDAwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAwMDAwMCAxMDY0 NTEyNDM0NCAwMTQzMDYAIDUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRh AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYmRzbS9l eGFtcGxlMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDc1NSAAMDAxNzUx IAAwMDE3NTAgADAwMDAwMDAwMDAwIDEwNjQ1MDIyNTA3IDAxNDMwNQAgNQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHdpZWN6eWsAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAa29udGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw MDAwMDAgADAwMDAwMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL1JFQURNRQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMDAwNjQ0IAAwMDAwMDAgADAwMTc1MCAAMDAwMDAwMDEyMTMgMTA2NDUx MjQxNzYgMDEzMDEyACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHVzdGFyADAwcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrb250YQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAwMDAwIAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEV4YW1wbGUg dXNhZ2Ugb2Ygc3lzL2Jkcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09CgpUbyBjb21w aWxlIHR5cGU6CiMgbWFrZQoKCmV4YW1wbGUwLwkJU21hbGwgcHJvZ3JhbW0gd2hpY2ggYWxs b3cgdGVzdAoJCQlvbmUgc3RydWN0dXJlIHVzZWQgYnkgTUFQIGFuZCBNTUFQLgoJCQlBZnRl ciBjb21waWxhdGlvbiB5b3UgY2FuIGV4ZWN1dGUKCQkJZXhhbXBsZTAvZXhhbXBsZTAgYmlu YXJ5LgoKCmV4YW1wbGUxCQlTbWFsbCBrZXJuZWwgbW9kdWxlIGFuZCB1dGlsaXR5IHByb2dy YW1tCgkJCXdoaWNoIGFsbG93IHRlc3QgTUFQIG9uIGtlcm5lbCBzaWRlLgoJCQlBZnRlciBj b21waWxhdGlvbiB5b3Ugc2hvdWxkIHR5cGUgCgkJCSMgbWFrZSBsb2FkIGNvcHkKCQkJdG8g bG9hZCBtb2R1bGUgaW50byBrZXJuZWwgYW5kIGNvcHkgYmRzY3RsCgkJCXV0aWxpdHkgdG8g eW91ciBjdXJyZW50IGRpcmVjb3RyeS4KCQkJUnVuIHV0aWxpdHkKCQkJIyAuL2Jkc2N0bAoJ CQkuLi5hbmQgaGF2ZSBmdW4uCgkJCVdBUk5JTkc6IEJlY2F1c2Uga2VybmVsIG1vZHVsZSBp cyB1c2luZwoJCQkJIHByaW50Zig5KSByb3V0aW5lLCBwbGVhc2UKCQkJCSBiZSBvbiBmaXJz dCB0ZXJtaW5hbCBvbiBjb25zb2xlCgkJCQkgb3Igd2F0Y2ggZG1lc2cuCgoJCQkKCgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL2V4YW1w bGUxL2RldgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwNzU1IAAwMDE3NTEgADAw MTc1MCAAMDAwMDAwMDAwMDAgMTA2NDUxMjQzNzEgMDE1MDY1ACA1AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABrb250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAw MCAAMDAwMDAwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTEvTWFrZWZpbGUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAwMDA1MSAxMDY0NTAzMDcy NSAwMTYwMjQAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU1VCRElSPWRldiB1 dGlsCgouaW5jbHVkZTxic2Quc3ViZGlyLm1rPgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABiZHNtL2V4YW1wbGUxL3V0aWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAMDAwNzU1IAAwMDE3NTEgADAwMTc1MCAAMDAwMDAwMDAwMDAgMTA2NDUxMjQ2MDMg MDE1MjYyACA1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyADAwd2llY3p5awAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrb250YQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAwMDAwIAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTEv dXRpbC9NYWtlZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDA2NDQgADAwMTc1MSAAMDAxNzUw IAAwMDAwMDAwMDExNSAxMDY0NTAzNzI0MiAwMTcwMDAAIDAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAw MDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUFJPRz1iZHNjdGwKU1JDUz1tYWluLmMKQ0ZMQUdTPS1JLi4vLi4gLUku Li9kZXYKTUFOPQoKLmluY2x1ZGU8YnNkLnByb2cubWs+CgoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL2V4YW1wbGUxL3V0 aWwvbWFpbi5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwNjQ0IAAwMDE3NTEgADAwMTc1MCAA MDAwMDAwMDcwMDAgMTA2NDUxMjQ1NjUgMDE2NDM1ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABrb250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAw MDAwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC8qLQogKiBDb3B5cmlnaHQgKGMpIDIwMDcgUGF3ZWwgV2llY3pvcmVrIDx3 aWVjenlrQGdtYWlsLmNvbT4KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoKICogUmVkaXN0 cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0CiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRo ZSBmb2xsb3dpbmcgY29uZGl0aW9ucwogKiBhcmUgbWV0OgogKgogKiAxLiBSZWRpc3RyaWJ1 dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAog KiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n IGRpc2NsYWltZXIuCiAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0 IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0 IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKICog ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KICoKICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBU SEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKICogSU1QTElFRCBXQVJS QU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FS UkFOVElFUwogKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgogKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCiAqIElOQ0lERU5U QUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNM VURJTkcsIEJVVAogKiBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVU RSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsCiAqIERBVEEsIE9SIFBST0ZJVFM7 IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQog KiBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElB QklMSVRZLCBPUiBUT1JUCiAqIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRgogKiBUSElTIFNPRlRXQVJF LCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgog KgogKi8KCiNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KI2luY2x1ZGUgPHN5cy9wcm9jLmg+CiNp bmNsdWRlIDxzeXMvaW9jdGwuaD4KI2luY2x1ZGUgInN5cy9iZHMuaCIKI2luY2x1ZGUgImti ZHMuaCIKCiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVk ZSA8ZmNudGwuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxhc3NlcnQuaD4KCmlu dCBfX2ZkOwoKdm9pZApvcGVuZGV2KCkKewoJX19mZCA9IG9wZW4oIi9kZXYvYmRzIixPX1JE V1IpOwoJYXNzZXJ0KCBfX2ZkICE9IC0xICk7Cn0KCgojZGVmaW5lIEZMX0ZJUlNUIDB4MDEK I2RlZmluZSBGTF9MQVNUIDB4MDIKI2RlZmluZSBGTF9JRCAweDA0CiNkZWZpbmUgRkxfUFJJ TlQgMHgwOAojZGVmaW5lIEZMX1JFTU9WRSAweDEwCiNkZWZpbmUgRkxfUkVTRVQgMHgyMAoK I2RlZmluZSBDX0lOU0VSVCAoRkxfRklSU1R8RkxfTEFTVCkKI2RlZmluZSBDX1BSSU5UIChG TF9QUklOVCkKI2RlZmluZSBDX0xPT0tVUCAoRkxfSUQpCiNkZWZpbmUgQ19SRVNFVCAoRkxf UkVTRVQpCiNkZWZpbmUgQ19SRU1PVkUgKEZMX1JFTU9WRSkKCnZvaWQKdXNhZ2UoKQp7Cglw cmludGYoImJkc2N0bCAtZiBbZmlyc3RdIC1sIFtsYXN0XWkJIyBhZGQgbmV3IHBlcnNvbiBp bnRvIGtlcm5lbCBjaXRpemVuIHJlZ2lzdHJ5XG4iKTsKCXByaW50ZigiYnNkY3RsIC1pIFtp ZF0JCQkjIGxvb2t1cCBLQ1IgZm9yIElEXG4iKTsKCXByaW50ZigiYnNkY3RsIC1wCQkJIyBy ZXF1ZXN0IGtlcm5lbCB0byBwcmludCBLQ1JcbiIpOwoJcHJpbnRmKCJic2RjdGwgLXIJCQkj IHJlc2V0IEtDUlxuIik7CglwcmludGYoImJzZGN0bCAtZCBbaWRdCQkJIyByZW1vdmUgZnJv bSBLQ1IgcGVyc29uIHdpdGggaWRcbiIpOwoJcHJpbnRmKCJXQVJOSU5HOiBmb3IgJ2FkZCcg J3Jlc2V0JyBjb21tYW5kcyBrZXJuZWwgaXMgcHJpbnRpbmcgb3V0cHV0IGJ5IHByaW50Zig5 KVxuIik7Cn0KCmludAptYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewoJY2hhciBjaDsK CXN0cnVjdCBrcGVyc29uIGs7CglpbnQgaWQ7CglpbnQgZmxhZyA9IDA7Cgl3aGlsZSAoIChj aCA9IGdldG9wdChhcmdjLGFyZ3YsImY6bDppOmQ6cnBoIikpICE9IC0xICkKCQlzd2l0Y2gg KGNoKSB7CgkJCWNhc2UgJ2YnOgoJCQkJZmxhZyB8PSBGTF9GSVJTVDsKCQkJCXN0cm5jcHko ay5maXJzdCxvcHRhcmcsRklSU1RfTUFYLTEpOwoJCQkJYnJlYWs7CgoJCQljYXNlICdsJzoK CQkJCWZsYWcgfD0gRkxfTEFTVDsKCQkJCXN0cm5jcHkoay5sYXN0LG9wdGFyZyxMQVNUX01B WC0xKTsKCQkJCWJyZWFrOwoKCQkJY2FzZSAnaSc6CgkJCQlmbGFnIHw9IEZMX0lEOwoJCQkJ aWQgPSBzdHJ0b2wob3B0YXJnLE5VTEwsMTApOwoJCQkJYnJlYWs7CgoJCQljYXNlICdkJzoK CQkJCWZsYWcgfD0gRkxfUkVNT1ZFOwoJCQkJaWQgPSBzdHJ0b2wob3B0YXJnLE5VTEwsMTAp OwoJCQkJYnJlYWs7CgkJCQoJCQljYXNlICdyJzoKCQkJCWZsYWcgfD0gRkxfUkVTRVQ7CgkJ CQlicmVhazsKCgkJCWNhc2UgJ3AnOgoJCQkJZmxhZyB8PSBGTF9QUklOVDsKCQkJCWJyZWFr OwoJCQlkZWZhdWx0OgoJCQljYXNlICdoJzoKCQkJCXVzYWdlKCk7CgkJCQlyZXR1cm4oMCk7 CgkJfQoJaWYgKGZsYWcgPT0gMCkgewoJCXVzYWdlKCk7CgkJcmV0dXJuKC0xKTsKCX0KCW9w ZW5kZXYoKTsKCWlmICggZmxhZyA9PSBDX0lOU0VSVCApIHsKCQlpb2N0bChfX2ZkLCBCRFNJ T1NQRVJTT04sICZrICk7CgkJcHJpbnRmKCJJbnNlcnRlZCB3aXRoIGlkICV1XG4iLGsuaWQp OwoJfSBlbHNlIGlmICggZmxhZyA9PSBDX1BSSU5UICkgewoJCWlvY3RsKF9fZmQsIEJEU0lP Q0tQUklOVCApOwoJfSBlbHNlIGlmICggZmxhZyA9PSBDX0xPT0tVUCApIHsKCQlrLmlkID0g aWQ7CgkJaW9jdGwoX19mZCwgQkRTSU9HUEVSU09OLCZrICk7CgkJaWYgKCBrLmlkID09IC0x ICkgewoJCQlwcmludGYoIk5vdCBmb3VuZFxuIik7CgkJfSBlbHNlIHsKCQkJcHJpbnRmKCIl LjR1CQklcwkJJXNcbiIsay5pZCxrLmZpcnN0LGsubGFzdCk7CgkJfQoJfSBlbHNlIGlmICgg ZmxhZyA9PSBDX1JFU0VUICkgewoJCWlvY3RsKF9fZmQsIEJEU0lPQ0tSRVNFVCApOwoJfSBl bHNlIGlmICggZmxhZyA9PSBDX1JFTU9WRSApIHsKCQlwcmludGYoInggJWx1ICV1XG4iLEJE U0lPQ1JFTU9WRSxpZCk7CgkJaW9jdGwoX19mZCwgQkRTSU9DUkVNT1ZFLCZpZCApOwoJfSBl bHNlCgkJdXNhZ2UoKTsKCXJldHVybiAoMCk7Cn0KYmRzbS9leGFtcGxlMS9kZXYvTWFrZWZp bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDc1NSAAMDAxNzUxIAAwMDE3NTAgADAwMDAwMDAw MTE0IDEwNjQ1MDM2MDQyIDAxNjYwMAAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHdpZWN6eWsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAa29udGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAgADAwMDAwMCAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABLTU9EPQliZHMKU1JDUz0JYmRzLmMgaGFzaF9zdXBwb3J0LmMKQ0ZMQUdTPSAtSS4uLy4u Ci5pbmNsdWRlIDxic2Qua21vZC5taz4KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTEvZGV2L2Jkcy5jAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAxMjU3 NCAxMDY0NTEyNDcwNCAwMTYwNzQAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AGtvbnRhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LyotCiAqIENvcHlyaWdodCAoYykgMjAwNyBQYXdlbCBXaWVjem9yZWsgPHdpZWN6eWtAZ21h aWwuY29tPgogKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBh bmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICog bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGlj ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ci4KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNl IHRoZSBhYm92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVu dGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJp YnV0aW9uLgogKgogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1Ig YGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUgogKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElO Q0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCiAq IE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UgQVJFIERJU0NMQUlNRUQuCiAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUg TElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKICogSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVU CiAqIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9S IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwKICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCiAqIFRIRU9SWSBP RiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9S IFRPUlQKICogKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJ TiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GCiAqIFRISVMgU09GVFdBUkUsIEVWRU4gSUYg QURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqLwoKI2lu Y2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8c3lzL3Vpby5oPgojaW5jbHVkZSA8c3lz L3Byb2MuaD4KI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgojaW5jbHVkZSA8c3lzL2tlcm5lbC5o PgojaW5jbHVkZSA8c3lzL2lvY2NvbS5oPgojaW5jbHVkZSA8c3lzL2NvbmYuaD4KI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KI2luY2x1ZGUgInN5 cy9iZHMuaCIKCiNpbmNsdWRlICJrYmRzLmgiCgoKCgoKc3RydWN0IGNpdGl6ZW5fcmVnaXN0 cnkgY2l0aXplbl9yZWdpc3RyeTsKCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogKiBEYXRhIG1hbmFnZW1l bnQKICovCgoKTUFMTE9DX0RFRklORShNX0tDUkVOVFJZLCAiS2VybmVsIENpdGl6ZW4gUmVn aXN0cnkgRW50cnkiLCAiIik7CgoKc3RhdGljIHZvaWQga2NyX2FkZCggc3RydWN0IGtwZXJz b24gKmsgKTsKc3RhdGljIHZvaWQga2NyX2dldCggc3RydWN0IGtwZXJzb24gKmsgKTsKc3Rh dGljIHZvaWQga2NyX3ByaW50KHZvaWQpOwpzdGF0aWMgdm9pZCBrY3JfcmVtb3ZlKCBpbnQg aWQgKTsKc3RhdGljIHZvaWQga2NyX3Jlc2V0KHZvaWQpOwoKdm9pZAprY3JfYWRkKCBzdHJ1 Y3Qga3BlcnNvbiAqcGFyYW0gKQp7CglzdGF0aWMgaW50IF9pZCA9IDB4NzQ2MTsKCXN0cnVj dCBrZXlfaWQga2lkOwoJc3RydWN0IGtwZXJzb24gKnBjb3B5OwoJcGFyYW0tPmlkID0ga2lk LmlkID0gX2lkKys7CglwYXJhbS0+Zmlyc3RbRklSU1RfTUFYLTFdID0gMDsKCXBhcmFtLT5s YXN0W0xBU1RfTUFYLTFdID0gMDsKCXBjb3B5ID0gKHN0cnVjdCBrcGVyc29uICopIG1hbGxv Yyggc2l6ZW9mKCpwY29weSksIE1fS0NSRU5UUlksIE1fV0FJVE9LICk7CgltZW1jcHkocGNv cHkscGFyYW0sc2l6ZW9mKCpwY29weSkpOwoJTUFQX0lOU0VSVCggJmNpdGl6ZW5fcmVnaXN0 cnksICZraWQsIHBjb3B5LCBjaXRyZWdfZW50cnkgKTsKfQoKdm9pZAprY3JfZ2V0KCBzdHJ1 Y3Qga3BlcnNvbiAqcGFyYW0gKQp7CglzdHJ1Y3Qga2V5X2lkIGtpZDsKCXN0cnVjdCBrcGVy c29uICpwY29weTsKCglraWQuaWQgPSBwYXJhbS0+aWQ7CglNQVBfTE9PS1VQKCAmY2l0aXpl bl9yZWdpc3RyeSwgJmtpZCwgcGNvcHksIGNpdHJlZ19lbnRyeSApOwoJaWYgKCBwY29weSAp IHsKCQltZW1jcHkocGFyYW0scGNvcHksc2l6ZW9mKCpwY29weSkpOwoJfSBlbHNlIHsKCQlw YXJhbS0+aWQgPSAtMTsKCX0KfQoKdm9pZAprY3JfcHJpbnQoKQp7CglzdHJ1Y3Qga3BlcnNv biAqazsKCXByaW50ZigiXG4tLS0tLUtlcm5lbCBDaXRpemVuIFJlZ2lzdHJ5LS0tLS0tLS0t LS0tXG4iKTsKCU1BUF9GT1JFQUNIKCBrLCAmY2l0aXplbl9yZWdpc3RyeSwgY2l0cmVnX2Vu dHJ5ICkgewoJCXByaW50ZigiJS40dQkJJXMJCSVzXG4iLGstPmlkLGstPmZpcnN0LGstPmxh c3QpOwoJfQoJcHJpbnRmKCItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tXG4iKTsKfQoKdm9pZAprY3JfcmVtb3ZlKGludCBpZCApCnsKCXN0cnVjdCBrcGVyc29u ICpwZXJzb247CglzdHJ1Y3Qga2V5X2lkIGtpZDsKCWtpZC5pZCA9IGlkOwoJTUFQX0xPT0tV UCggJmNpdGl6ZW5fcmVnaXN0cnksICZraWQsIHBlcnNvbiwgY2l0cmVnX2VudHJ5ICk7Cglp ZiAoIHBlcnNvbiApIHsKCQlNQVBfUkVNT1ZFKCAmY2l0aXplbl9yZWdpc3RyeSwgcGVyc29u LCBrcGVyc29uLCBjaXRyZWdfZW50cnkgKTsKCQlmcmVlKHBlcnNvbixNX0tDUkVOVFJZKTsK CX0gZWxzZSB7CgkJcHJpbnRmKCJObyBwZXJzb24gd2l0aCBpZCAlaVxuIixpZCk7Cgl9Cn0K CnZvaWQKa2NyX3Jlc2V0KCkKewoJc3RydWN0IGtwZXJzb24gKnBlcnNvbjsKCU1BUF9GT1JF QUNIX1NBRkUoIHBlcnNvbiwgJmNpdGl6ZW5fcmVnaXN0cnksIGNpdHJlZ19lbnRyeSApIHsK CQlNQVBfUkVNT1ZFKCAmY2l0aXplbl9yZWdpc3RyeSwgcGVyc29uLCBrcGVyc29uLCBjaXRy ZWdfZW50cnkgKTsKCQlmcmVlKHBlcnNvbixNX0tDUkVOVFJZKTsKCX0KfQoKCi8qLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQogKiBEZXZpY2UgCiAqLwoKc3RhdGljIGludCBiZHNkZXZfb3BlbihzdHJ1Y3Qg Y2RldiAqZGV2LCBpbnQgZmxhZywgaW50IG90eXAsIHN0cnVjdCB0aHJlYWQgKnRkKTsKc3Rh dGljIGludCBiZHNkZXZfY2xvc2Uoc3RydWN0IGNkZXYgKmRldiwgaW50IGZsYWcsIGludCBv dHlwLCBzdHJ1Y3QgdGhyZWFkICp0ZCk7CnN0YXRpYyBpbnQgYmRzZGV2X2lvY3RsKHN0cnVj dCBjZGV2ICpkZXYsIHVfbG9uZyBjbWQsIGNhZGRyX3QgYXJnLCBpbnQgbW9kZSwgc3RydWN0 IHRocmVhZCAqdGQpOwpzdGF0aWMgaW50IGJkc2Rldl93cml0ZShzdHJ1Y3QgY2RldiAqZGV2 LCBzdHJ1Y3QgdWlvICp1aW8sIGludCBpb2ZsYWcpOwpzdGF0aWMgaW50IGJkc2Rldl9yZWFk KHN0cnVjdCBjZGV2ICpkZXYsIHN0cnVjdCB1aW8gKnVpbywgaW50IGlvZmxhZyk7CgoKaW50 CmJkc2Rldl9vcGVuKHN0cnVjdCBjZGV2ICpkZXYsIGludCBmbGFnLCBpbnQgb3R5cCwgc3Ry dWN0IHRocmVhZCAqdGQpCnsKCXJldHVybiAoMCk7Cn0KCmludApiZHNkZXZfY2xvc2Uoc3Ry dWN0IGNkZXYgKmRldiwgaW50IGZsYWcsIGludCBvdHlwLCBzdHJ1Y3QgdGhyZWFkICp0ZCkK ewoJcmV0dXJuICgwKTsKfQoKaW50CmJkc2Rldl9pb2N0bChzdHJ1Y3QgY2RldiAqZGV2LCB1 X2xvbmcgY21kLCBjYWRkcl90IGFyZywgaW50IG1vZGUsCiAgICBzdHJ1Y3QgdGhyZWFkICp0 ZCkKewoJaW50IGVycm9yID0gMDsKCXVuaW9uIHsKCQljYWRkcl90IGFyZzsKCQlzdHJ1Y3Qg a3BlcnNvbiAqcGVyc29uOwoJCWludCAqaWQ7Cgl9IEFSRzsKCgkKCUFSRy5hcmcgPSBhcmc7 Cglzd2l0Y2goY21kKSB7CgkJY2FzZSBCRFNJT1NQRVJTT046CgkJCWtjcl9hZGQoQVJHLnBl cnNvbik7CgkJCWJyZWFrOwoJCWNhc2UgQkRTSU9HUEVSU09OOgoJCQlrY3JfZ2V0KEFSRy5w ZXJzb24pOwoJCQlicmVhazsKCQljYXNlIEJEU0lPQ0tQUklOVDoKCQkJa2NyX3ByaW50KCk7 CgkJCWJyZWFrOwoJCWNhc2UgQkRTSU9DS1JFU0VUOgoJCQlrY3JfcmVzZXQoKTsKCQkJYnJl YWs7CgkJY2FzZSBCRFNJT0NSRU1PVkU6CgkJCWtjcl9yZW1vdmUoKkFSRy5pZCk7CgkJCWJy ZWFrOwoJCWRlZmF1bHQ6CgkJCWVycm9yID0gRUlOVkFMOwoJCQlicmVhazsKCX0KCXJldHVy biAoZXJyb3IpOwp9CgppbnQKYmRzZGV2X3dyaXRlKHN0cnVjdCBjZGV2ICpkZXYsIHN0cnVj dCB1aW8gKnVpbywgaW50IGlvZmxhZykKewogICAgcmV0dXJuKEVOT1RTVVApOwp9CgppbnQK YmRzZGV2X3JlYWQoc3RydWN0IGNkZXYgKmRldiwgc3RydWN0IHVpbyAqdWlvLCBpbnQgaW9m bGFnKQp7CiAgICByZXR1cm4oRU5PVFNVUCk7Cn0KCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogKiBNb2R1 bGUKICovCgpzdGF0aWMgc3RydWN0IGNkZXZzdyBiZHNfYmRzZGV2c3cgPSB7CgkuZF92ZXJz aW9uID0gRF9WRVJTSU9OLAoJLmRfb3BlbiA9IGJkc2Rldl9vcGVuLAoJLmRfY2xvc2UgPSBi ZHNkZXZfY2xvc2UsCgkuZF9yZWFkID0gYmRzZGV2X3JlYWQsCgkuZF93cml0ZSA9IGJkc2Rl dl93cml0ZSwKCS5kX2lvY3RsID0gYmRzZGV2X2lvY3RsLAoJLmRfbmFtZSA9ICJiZHMiCn07 CgpzdGF0aWMgc3RydWN0IGNkZXYgKnNkZXY7CgoKc3RhdGljIGludApiZHNkZXZfbG9hZCht b2R1bGVfdCBtb2QsIGludCBjbWQsIHZvaWQgKmFyZykKewogICAgaW50ICBlcnIgPSAwOwog ICAgc3dpdGNoIChjbWQpIHsKICAgIGNhc2UgTU9EX0xPQUQ6CgloYXNoX2luaXQoJmNpdGl6 ZW5fcmVnaXN0cnkpOwoJc2RldiA9IG1ha2VfZGV2KCZiZHNfYmRzZGV2c3csIDAsIFVJRF9S T09ULCBHSURfV0hFRUwsIDA2MDAsICJiZHMiKTsKCWJyZWFrOwoKICAgIGNhc2UgTU9EX1VO TE9BRDoKCWtjcl9yZXNldCgpOwoJZGVzdHJveV9kZXYoc2Rldik7CglicmVhazsKICAgIGRl ZmF1bHQ6CgllcnIgPSBFT1BOT1RTVVBQOwoJYnJlYWs7CiAgICB9CgogICAgcmV0dXJuKGVy cik7Cn0KCkRFVl9NT0RVTEUoYmRzZGV2LCBiZHNkZXZfbG9hZCwgTlVMTCk7CgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTEvZGV2L2hhc2hfc3VwcG9ydC5jAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAwMzc0NCAxMDY0NTAyNjA1 MCAwMjAwMzUAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyotCiAqIENvcHly aWdodCAoYykgMjAwNyBQYXdlbCBXaWVjem9yZWsgPHdpZWN6eWtAZ21haWwuY29tPgogKiBB bGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9u LCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25z CiAqIGFyZSBtZXQ6CiAqCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0 IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVk aXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBj b3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgog KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFO RCBBTlkgRVhQUkVTUyBPUgogKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCiAqIE9GIE1FUkNIQU5U QUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NM QUlNRUQuCiAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwKICogSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUCiAqIE5PVCBMSU1J VEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBM T1NTIE9GIFVTRSwKICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBU SU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCiAqIFRIRU9SWSBPRiBMSUFCSUxJVFks IFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQKICogKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9V VCBPRiBUSEUgVVNFIE9GCiAqIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU SEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqLwojaW5jbHVkZSA8c3lzL3Bh cmFtLmg+CgojaW5jbHVkZSA8c3lzL3F1ZXVlLmg+CiNpbmNsdWRlICJzeXMvYmRzLmgiCgoj aW5jbHVkZSAia2Jkcy5oIgoKc3RhdGljIHVuc2lnbmVkIGludCBrZXlfaWRfaGFzaCggY29u c3Qgc3RydWN0IGtleV9pZCAqayApOwpzdGF0aWMgaW50IGtleV9pZF9jbXAoIGNvbnN0IHN0 cnVjdCBrZXlfaWQgKmsxLCBjb25zdCBzdHJ1Y3Qga2V5X2lkICprMiApOwpzdGF0aWMgdm9p ZCBrZXlfaWRfY3AoIHN0cnVjdCBrZXlfaWQgKmRzdCwgY29uc3Qgc3RydWN0IGtleV9pZCAq c3JjICk7CgoKc3RhdGljIHVuc2lnbmVkIGludAprZXlfaWRfaGFzaCggY29uc3Qgc3RydWN0 IGtleV9pZCAqayApCnsKCXJldHVybihrLT5pZCk7Cn0KCnN0YXRpYyBpbnQKa2V5X2lkX2Nt cCggY29uc3Qgc3RydWN0IGtleV9pZCAqazEsIGNvbnN0IHN0cnVjdCBrZXlfaWQgKmsyICkK ewoJcmV0dXJuKCBrMS0+aWQgPT0gazItPmlkICk7Cn0KCnN0YXRpYyB2b2lkCmtleV9pZF9j cCggc3RydWN0IGtleV9pZCAqZHN0LCBjb25zdCBzdHJ1Y3Qga2V5X2lkICpzcmMgKQp7Cglk c3QtPmlkID0gc3JjLT5pZDsKfQoKCnZvaWQKaGFzaF9pbml0KCBzdHJ1Y3QgY2l0aXplbl9y ZWdpc3RyeSAqaCApCnsKCU1BUF9JTklUKGgsa2V5X2lkX2hhc2gsa2V5X2lkX2NtcCxrZXlf aWRfY3ApOwp9CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL2V4YW1wbGUxL2Rl di9rYmRzLmgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwNzU1IAAwMDE3NTEgADAwMTc1MCAA MDAwMDAwMDM2NjIgMTA2NDUxMjQ2MzEgMDE2MjUxACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABrb250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAw MDAwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC8qLQogKiBDb3B5cmlnaHQgKGMpIDIwMDcgUGF3ZWwgV2llY3pvcmVrIDx3 aWVjenlrQGdtYWlsLmNvbT4KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoKICogUmVkaXN0 cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0CiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRo ZSBmb2xsb3dpbmcgY29uZGl0aW9ucwogKiBhcmUgbWV0OgogKgogKiAxLiBSZWRpc3RyaWJ1 dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAog KiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n IGRpc2NsYWltZXIuCiAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0 IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0 IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKICog ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KICoKICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBU SEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKICogSU1QTElFRCBXQVJS QU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FS UkFOVElFUwogKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgogKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCiAqIElOQ0lERU5U QUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNM VURJTkcsIEJVVAogKiBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVU RSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsCiAqIERBVEEsIE9SIFBST0ZJVFM7 IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQog KiBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElB QklMSVRZLCBPUiBUT1JUCiAqIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRgogKiBUSElTIFNPRlRXQVJF LCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgog KgogKi8KCiNpZm5kZWYgS19CRFNfSAojZGVmaW5lIEtfQkRTX0gKCgoKc3RydWN0IGtleV9p ZCB7CglpbnQgaWQ7Cn07CgojZGVmaW5lIEZJUlNUX01BWCAxMDAKI2RlZmluZSBMQVNUX01B WCAxMDAKCnN0cnVjdCBrcGVyc29uIHsKCWludCBpZDsKCWNoYXIgZmlyc3RbRklSU1RfTUFY XTsKCWNoYXIgbGFzdFtGSVJTVF9NQVhdOwoJTUFQX0VOVFJZKGtwZXJzb24sa2V5X2lkKSBj aXRyZWdfZW50cnk7Cn07CgoKI2RlZmluZSBCRFNJT1NQRVJTT04JX0lPV1IoJ3AnLCAxLCBz dHJ1Y3Qga3BlcnNvbikKI2RlZmluZSBCRFNJT0dQRVJTT04JX0lPV1IoJ3AnLCAyLCBzdHJ1 Y3Qga3BlcnNvbikKI2RlZmluZSBCRFNJT0NLUFJJTlQJX0lPKCdjJywzKQojZGVmaW5lIEJE U0lPQ0tSRVNFVAlfSU8oJ2MnLDQpCiNkZWZpbmUgQkRTSU9DUkVNT1ZFCV9JT1coJ3AnLDUs aW50KQoKI2lmZGVmIF9LRVJORUwKCi8qIEtlcm5lbCB3b3JsZCwga2VybmVsIGNpdGl6ZW5z IF09O10gKi8KCk1BUF9IRUFEKCBjaXRpemVuX3JlZ2lzdHJ5LCBrcGVyc29uLCAxMyApOwoK dm9pZCBoYXNoX2luaXQoIHN0cnVjdCBjaXRpemVuX3JlZ2lzdHJ5ICpoICk7CgojZW5kaWYg LyogX0tFUk5FTCAqLwoKI2VuZGlmIC8qIEtfQkRTX0ggKi8KAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAYmRzbS9leGFtcGxlMC9NYWtlZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAw MDc1NSAAMDAxNzUxIAAwMDE3NTAgADAwMDAwMDAwMTMyIDEwNjQ1MTI0MzM2IDAxNjAyNQAg MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAw MHdpZWN6eWsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa29udGEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAwMDAwMDAgADAwMDAwMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDQz1jYwpQUk9HPWV4YW1wbGUwClNS Q1M9bWFpbi5jIGhhc2hfc3VwcG9ydC5jCkNGTEFHUz0gLUkuLiAKTUFOPQoKCi5pbmNsdWRl PGJzZC5wcm9nLm1rPgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGJkc20vZXhhbXBsZTAvbWFpbi5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDA3 NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAxNTYwMSAxMDY0NTEyMjczMCAwMTU0NjAAIDAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDB3 aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyotCiAqIENvcHlyaWdodCAoYykgMjAw NyBQYXdlbCBXaWVjem9yZWsgPHdpZWN6eWtAZ21haWwuY29tPgogKiBBbGwgcmlnaHRzIHJl c2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmlu YXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0 dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6 CiAqCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0 aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVkaXN0cmlidXRpb25z IGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKICog ICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRl cmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgogKiBUSElTIFNPRlRX QVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBBTlkgRVhQUkVT UyBPUgogKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCiAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCiAqIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJ TkRJUkVDVCwKICogSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFV RU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUCiAqIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwK ICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVS IENBVVNFRCBBTkQgT04gQU5ZCiAqIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4g Q09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQKICogKElOQ0xVRElORyBORUdM SUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNF IE9GCiAqIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJ VFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqLwoKI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgojaW5j bHVkZSAic3lzL2Jkcy5oIgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8c3RkbGliLmg+CgojaW5jbHVkZSAiZXhhbXBsZTAuaCIKCgpzdHJ1Y3Qg d29ya2Vyc19ieV9pZCB3cmtzX2J5X2lkOwpzdHJ1Y3Qgd29ya2Vyc19ieV9sYXN0IHdya3Nf YnlfbGFzdDsKCgovKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KICogRGF0YSBtYW5hZ2VtZW50IHJvdXRpbmVz CiAqLwoKCgpzdGF0aWMgdm9pZAp3b3JrZXJfYWRkKCBzdHJ1Y3Qgd29ya2VyICp3b3JrZXIg KQp7CglzdGF0aWMgaW50IF9rZXkgPSAweDEyMzQ7CglzdHJ1Y3Qga2V5X2lkIGtpZDsKCXN0 cnVjdCBrZXlfbGFzdCBrbGFzdDsKCgl3b3JrZXItPmlkID0gX2tleSsrOwoJa2lkLmlkID0g d29ya2VyLT5pZDsKCU1BUF9JTlNFUlQoJndya3NfYnlfaWQsICZraWQsIHdvcmtlciwgaGFz aF9ieV9pZCApOwoKCXN0cmNweShrbGFzdC5sYXN0LHdvcmtlci0+bGFzdCk7CglNTUFQX0lO U0VSVCgmd3Jrc19ieV9sYXN0LCZrbGFzdCwgd29ya2VyLCBoYXNoX2J5X2xhc3QgKTsKCQp9 CgpzdGF0aWMgc3RydWN0IHdvcmtlciAqCndvcmtlcl9sb29rdXAoIGludCBpZCApCnsKCXN0 cnVjdCB3b3JrZXIgKndvcmtlcjsKCXN0cnVjdCBrZXlfaWQgazsKCglrLmlkID0gaWQ7CglN QVBfTE9PS1VQKCZ3cmtzX2J5X2lkLCAmaywgd29ya2VyLCBoYXNoX2J5X2lkICk7CglyZXR1 cm4gKHdvcmtlcik7Cn0KCgpzdGF0aWMgaW50Cndvcmtlcl9yZW1vdmVfYnlfbGFzdCggY29u c3QgY2hhciAqIGxhc3QgKQp7CglzdHJ1Y3Qgd29ya2VyICp3b3JrZXI7CglzdHJ1Y3Qga2V5 X2xhc3Qga2xhc3Q7CglzdHJjcHkoa2xhc3QubGFzdCxsYXN0KTsKCU1NQVBfTE9PS1VQX0ZP UkVBQ0hfU0FGRSggJndya3NfYnlfbGFzdCwgJmtsYXN0LCB3b3JrZXIsIGhhc2hfYnlfbGFz dCApIHsKCQlNQVBfUkVNT1ZFKCZ3cmtzX2J5X2lkLHdvcmtlcix3b3JrZXIsaGFzaF9ieV9p ZCApOwoJCU1NQVBfUkVNT1ZFKCZ3cmtzX2J5X2xhc3Qsd29ya2VyLHdvcmtlcixoYXNoX2J5 X2xhc3QpOwkJCgkJcHJpbnRmKCIlLjR1ICUtMTVzICUtMTVzICUuMnUgJS0xNXNcbiIsd29y a2VyLT5pZCx3b3JrZXItPmZpcnN0LHdvcmtlci0+bGFzdCx3b3JrZXItPmFnZSx3b3JrZXIt PmNpdHkpOwkKCX0KCXJldHVybigwKTsKfQoKc3RhdGljIGludAp3b3JrZXJfcmVtb3ZlKCBp bnQgaWQgKQp7CglzdHJ1Y3Qgd29ya2VyICp3b3JrZXI7Cgl3b3JrZXIgPSB3b3JrZXJfbG9v a3VwKCBpZCApOwoKCWlmICggd29ya2VyID09IE5VTEwgKSByZXR1cm4oLTEpOwoJTUFQX1JF TU9WRSgmd3Jrc19ieV9pZCx3b3JrZXIsd29ya2VyLGhhc2hfYnlfaWQgKTsKCU1NQVBfUkVN T1ZFKCZ3cmtzX2J5X2xhc3Qsd29ya2VyLHdvcmtlcixoYXNoX2J5X2xhc3QpOwoKCWZyZWUo d29ya2VyKTsKCXJldHVybigxKTsKfQoKCnN0YXRpYyB2b2lkCndvcmtlcl9saXN0X2J5X2xh c3QoY29uc3QgY2hhciAqbGFzdCkKewoJc3RydWN0IHdvcmtlciAqd29ya2VyOwoJc3RydWN0 IGtleV9sYXN0IGtsYXN0OwoJc3RyY3B5KGtsYXN0Lmxhc3QsbGFzdCk7CglNTUFQX0xPT0tV UF9GT1JFQUNIKCAmd3Jrc19ieV9sYXN0LCAma2xhc3QsIHdvcmtlciwgaGFzaF9ieV9sYXN0 KSB7CgkJcHJpbnRmKCIlLjR1ICUtMTVzICUtMTVzICUuMnUgJS0xNXNcbiIsd29ya2VyLT5p ZCx3b3JrZXItPmZpcnN0LHdvcmtlci0+bGFzdCx3b3JrZXItPmFnZSx3b3JrZXItPmNpdHkp OwkKCX0KfQoKc3RhdGljIHZvaWQKd29ya2VyX2xpc3QoKQp7CglzdHJ1Y3Qgd29ya2VyICp3 b3JrZXI7CglNQVBfRk9SRUFDSCggIHdvcmtlciwgJndya3NfYnlfaWQsIGhhc2hfYnlfaWQp IHsKCQlwcmludGYoIiUuNHUgJS0xNXMgJS0xNXMgJS4ydSAlLTE1c1xuIix3b3JrZXItPmlk LHdvcmtlci0+Zmlyc3Qsd29ya2VyLT5sYXN0LHdvcmtlci0+YWdlLHdvcmtlci0+Y2l0eSk7 CQoJfQp9CgoKLyo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09CiAqIFVzZXIgaW50ZXJmYWNlIGhhbmRsZXJzCiAq LwoKc3RhdGljIGludCBfX2dldChjaGFyICprLGNoYXIgKmRhdGEsIGludCBsZW4pOwojZGVm aW5lIF9fR0VUKCBrb20sIGQsIGwgKSBpZiAoX19nZXQoa29tLGQsbCkgKSByZXR1cm47Cgpz dGF0aWMgdm9pZCB1aV9pbnNlcnQoKTsKc3RhdGljIHZvaWQgdWlfc2VsZWN0X2lkKCk7Cgpz dGF0aWMgaW50Cl9fZ2V0KGNoYXIgKmssY2hhciAqZGF0YSwgaW50IGxlbikKewoJaW50IG47 CglwcmludGYoIiVzOiAiLGspOwoJZmZsdXNoKHN0ZG91dCk7CglkYXRhWzBdID0gMDsKCWZw dXJnZShzdGRpbik7CglpZiAoIGZnZXRzKGRhdGEsbGVuLHN0ZGluKSA9PSBOVUxMICkgcmV0 dXJuKDEpOwoJbiA9IHN0cmxlbihkYXRhKTsKCWlmICggbiA+IDEgKQoJZGF0YVtuLTFdID0g MDsKCXJldHVybigwKTsKfQoKc3RhdGljIHZvaWQKdWlfbGlzdCgpCnsKCXdvcmtlcl9saXN0 KCk7Cn0KCnN0YXRpYyB2b2lkCnVpX3NlbGVjdF9pZCgpCnsKCXN0cnVjdCB3b3JrZXIgKndv cmtlcjsKCWNoYXIgaWRbMTBdOwoJaW50IF9pZDsKCglfX0dFVCgiSUQiLGlkLHNpemVvZihp ZCkpOwoJX2lkID0gc3RydG9sKGlkLE5VTEwsMTApOwoKCXdvcmtlciA9IHdvcmtlcl9sb29r dXAoX2lkKTsKCWlmICggd29ya2VyID09IE5VTEwgKSB7CgkJcHJpbnRmKCJFcnJvcjogY2Fu bm90IGZpbmQgd29ya2VyIHdpdGggaWQgJS40dVxuIixfaWQpOwoJCXJldHVybjsKCX0KCXBy aW50ZigiRm91bmQ6ICUuNHUgJS0xNXMgJS0xNXMgJS4ydSAlLTE1c1xuIix3b3JrZXItPmlk LHdvcmtlci0+Zmlyc3Qsd29ya2VyLT5sYXN0LHdvcmtlci0+YWdlLHdvcmtlci0+Y2l0eSk7 CQp9CgoKc3RhdGljIHZvaWQKdWlfc2VsZWN0X2xhc3QoKQp7CgljaGFyIGxhc3RbTEFTVF9N QVhdOwoKCV9fR0VUKCJMYXN0IixsYXN0LHNpemVvZihsYXN0KSk7CgoJd29ya2VyX2xpc3Rf YnlfbGFzdChsYXN0KTsKfQoKc3RhdGljIHZvaWQKdWlfcmVtb3ZlX2lkKCkKewoJY2hhciBp ZFsxMF07CglpbnQgX2lkOwoKCV9fR0VUKCJJRCIsaWQsc2l6ZW9mKGlkKSk7CglfaWQgPSBz dHJ0b2woaWQsTlVMTCwxMCk7CgoJaWYgKCB3b3JrZXJfcmVtb3ZlKF9pZCkgKSB7CgkJcHJp bnRmKCJFcnJvcjogbm8gdXNlciB3aXRoIHRoaXMgaWRcbiIpOwoJfSBlbHNlIHsKCQlwcmlu dGYoIlJlbW92ZWRcbiIpOwoJfQp9CgpzdGF0aWMgdm9pZAp1aV9yZW1vdmVfbGFzdCgpCnsK CWNoYXIgbGFzdFtMQVNUX01BWF07CglfX0dFVCgiTGFzdCIsbGFzdCxzaXplb2YobGFzdCkp OwoKCXdvcmtlcl9yZW1vdmVfYnlfbGFzdChsYXN0KTsKfQoKCnN0YXRpYyB2b2lkCnVpX2lu c2VydCgpCnsKCXN0cnVjdCB3b3JrZXIgKndvcmtlcjsKCXN0cnVjdCB3b3JrZXIgdGVtcDsK CWNoYXIgYWdlWzEwXTsKCglwdXRzKCI9PT4gQWRkaW5nIG5ldyB3b3JrZXIgaW50byBtZW1v cnkiKTsKCV9fR0VUKCJGaXJzdCBuYW1lIix0ZW1wLmZpcnN0LHNpemVvZih0ZW1wLmZpcnN0 KSk7CglfX0dFVCgiTGFzdCBuYW1lIix0ZW1wLmxhc3Qsc2l6ZW9mKHRlbXAubGFzdCkpOwoJ X19HRVQoIkFnZSIsYWdlLHNpemVvZihhZ2UpKTsKCV9fR0VUKCJDaXR5Iix0ZW1wLmNpdHks c2l6ZW9mKHRlbXAuY2l0eSkpOwoJCgl0ZW1wLmFnZSA9IHN0cnRvbChhZ2UsTlVMTCwxMCk7 CgkKCXdvcmtlciA9IChzdHJ1Y3Qgd29ya2VyKikgbWFsbG9jKCBzaXplb2YoKndvcmtlcikp OwoJbWVtY3B5KHdvcmtlciwmdGVtcCxzaXplb2YoKndvcmtlcikpOwoKCXdvcmtlcl9hZGQo d29ya2VyKTsKCXByaW50ZigiQWRkZWQgd2l0aCBpZCAlLjR1XG4iLHdvcmtlci0+aWQpOwoK fQoKCgovKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KICogTWFpbiBtZW51CiAqLwoKCmVudW0gb3B0aW9uX3Yg ewoJT1BfSU5WQUxJRCwKCU9QX1FVSVQsCglPUF9JTlNFUlQsCglPUF9MSVNULAoJT1BfU0VM RUNUX0lELAoJT1BfU0VMRUNUX0xBU1QsCglPUF9SRU1PVkVfSUQsCglPUF9SRU1PVkVfTEFT VAp9OwoKCnN0cnVjdCBvcHRpb24gewoJY29uc3QgY2hhciAqdGV4dDsKCWVudW0gb3B0aW9u X3YgdmFsdWU7Cn07CgoKc3RhdGljIGVudW0gb3B0aW9uX3YgZmluZF9vcHRpb24oY2hhciBj KTsKc3RhdGljIGVudW0gb3B0aW9uX3YgZ2V0X29wdGlvbl9mcm9tX3VzZXIodm9pZCk7Cgpz dHJ1Y3Qgb3B0aW9uIG9wdGlvbnNbXSA9IHsKCXsgIlF1aXQiLCBPUF9RVUlUIH0sCgl7ICJJ bnNlcnQgbmV3IHBlcnNvbiB0byBtZW1vcnkiLCBPUF9JTlNFUlQgfSwKCXsgIkxpc3QgcGVy c29ucyBmcm9tIG1lbW9ydCIsIE9QX0xJU1QgfSwKCXsgIkNoZWNrIHBlcnNvbiBJRCIsIE9Q X1NFTEVDVF9JRCB9LAoJeyAiU2hvdyBwZXJzb25zIGJ5IGxhc3QgbmFtZSIsIE9QX1NFTEVD VF9MQVNUIH0sCgl7ICJSZW1vdmUgYnkgSUQiLCBPUF9SRU1PVkVfSUQgfSwKCXsgIlJlbW92 ZSBieSBsYXN0IiwgT1BfUkVNT1ZFX0xBU1QgfSwKCXsgTlVMTCwgT1BfSU5WQUxJRCB9LAp9 OwoKCnN0YXRpYyBlbnVtIG9wdGlvbl92CmZpbmRfb3B0aW9uKGNoYXIgYykKewoJc3RydWN0 IG9wdGlvbiAqb3AgPSBvcHRpb25zOwoJd2hpbGUgKCBvcC0+dGV4dCAmJiBjLS0gKSB7CgkJ b3ArKzsKCX0KCQoJcmV0dXJuIChvcC0+dmFsdWUpOwp9CgpzdGF0aWMgZW51bSBvcHRpb25f diAKZ2V0X29wdGlvbl9mcm9tX3VzZXIoKQp7CgljaGFyIGM7CglmcHVyZ2Uoc3RkaW4pOwoJ YyA9IGZnZXRjKHN0ZGluKSAtICcwJzsKCWlmICggZmVvZihzdGRpbikgKSB7CgkJcmV0dXJu IChPUF9RVUlUKTsKCX0KCXJldHVybiAoZmluZF9vcHRpb24oYykpOwoJCn0KCgpzdGF0aWMg aW50Cm1haW5fbWVudSgpCnsKCWludCBpOwoJaW50IHIgPSAxOwoJc3RydWN0IG9wdGlvbiAq b3AgPSBvcHRpb25zOwoJcHJpbnRmKCItLS0tLVxuIik7Cglmb3IgKGkgPSAwOyBvcC0+dGV4 dDsgaSsrLG9wKysgKSB7CiAJCXByaW50ZigiIC0gJS4xdQkJJXNcbiIsaSxvcC0+dGV4dCk7 Cgl9CglwcmludGYoIlxuUHJlc3Mgb3B0aW9uIG51bWJlciBrZXkgYW5kIGhpdCBlbnRlcjog Iik7Cglzd2l0Y2ggKCBnZXRfb3B0aW9uX2Zyb21fdXNlcigpICkgewoJCWNhc2UgT1BfUVVJ VDoKCQkJciA9IDA7CgkJCWJyZWFrOwoKCQljYXNlIE9QX0lOU0VSVDoKCQkJdWlfaW5zZXJ0 KCk7CgkJCWJyZWFrOwoKCQljYXNlIE9QX0xJU1Q6CgkJCXVpX2xpc3QoKTsKCQkJYnJlYWs7 CgoJCWNhc2UgT1BfU0VMRUNUX0lEOgoJCQl1aV9zZWxlY3RfaWQoKTsKCQkJYnJlYWs7CgoJ CWNhc2UgT1BfU0VMRUNUX0xBU1Q6CgkJCXVpX3NlbGVjdF9sYXN0KCk7CgkJCWJyZWFrOwoK CQljYXNlIE9QX0lOVkFMSUQ6CgkJCWJyZWFrOwoKCQljYXNlIE9QX1JFTU9WRV9JRDoKCQkJ dWlfcmVtb3ZlX2lkKCk7CgkJCWJyZWFrOwoKCQljYXNlIE9QX1JFTU9WRV9MQVNUOgoJCQl1 aV9yZW1vdmVfbGFzdCgpOwoJCQlicmVhazsKCgl9CglyZXR1cm4gKHIpOwp9CgppbnQKbWFp bigpCnsKCWlkX2hhc2hfaW5pdCgmd3Jrc19ieV9pZCk7CglsYXN0X2hhc2hfaW5pdCgmd3Jr c19ieV9sYXN0KTsKCXdoaWxlICggbWFpbl9tZW51KCkgKTsKCXJldHVybiAoMCk7Cn0KAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJkc20vZXhhbXBsZTAvaGFzaF9zdXBwb3J0LmMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAwNDQ3MyAxMDY0NTAwMTMx NSAwMTcyNTMAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdXN0YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyotCiAqIENvcHly aWdodCAoYykgMjAwNyBQYXdlbCBXaWVjem9yZWsgPHdpZWN6eWtAZ21haWwuY29tPgogKiBB bGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9u LCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25z CiAqIGFyZSBtZXQ6CiAqCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0 IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVk aXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBj b3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgog KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFO RCBBTlkgRVhQUkVTUyBPUgogKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCiAqIE9GIE1FUkNIQU5U QUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NM QUlNRUQuCiAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwKICogSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUCiAqIE5PVCBMSU1J VEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBM T1NTIE9GIFVTRSwKICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBU SU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCiAqIFRIRU9SWSBPRiBMSUFCSUxJVFks IFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQKICogKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9V VCBPRiBUSEUgVVNFIE9GCiAqIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU SEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqLwoKI2luY2x1ZGUgPHN5cy9x dWV1ZS5oPgojaW5jbHVkZSAic3lzL2Jkcy5oIgoKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNs dWRlIDxzdHJpbmcuaD4KCiNpbmNsdWRlICJleGFtcGxlMC5oIgoKCnN0YXRpYyB1bnNpZ25l ZCBpbnQKa2V5X2lkX2hhc2goIGNvbnN0IHN0cnVjdCBrZXlfaWQgKmsgKQp7CglyZXR1cm4o ay0+aWQpOwp9CgpzdGF0aWMgaW50CmtleV9pZF9jbXAoIGNvbnN0IHN0cnVjdCBrZXlfaWQg KmsxLCBjb25zdCBzdHJ1Y3Qga2V5X2lkICprMiApCnsKCXJldHVybiggazEtPmlkID09IGsy LT5pZCApOwp9CgpzdGF0aWMgdm9pZAprZXlfaWRfY3AoIHN0cnVjdCBrZXlfaWQgKmRzdCwg Y29uc3Qgc3RydWN0IGtleV9pZCAqc3JjICkKewoJZHN0LT5pZCA9IHNyYy0+aWQ7Cn0KCgp2 b2lkCmlkX2hhc2hfaW5pdCggc3RydWN0IHdvcmtlcnNfYnlfaWQgKmhhc2ggKQp7CglNQVBf SU5JVChoYXNoLGtleV9pZF9oYXNoLGtleV9pZF9jbXAsa2V5X2lkX2NwKTsKfQoKCgpzdGF0 aWMgdW5zaWduZWQgaW50CmtleV9sYXN0X2hhc2goIGNvbnN0IHN0cnVjdCBrZXlfbGFzdCAq ayApCnsKCWludCBoID0gMjk7Cgljb25zdCBjaGFyICpwOwoJZm9yICggcCA9IGstPmxhc3Q7 ICpwICE9ICdcMCc7IHArKyApIHsKCQloICs9ICpwOwoJfQoJcmV0dXJuIChoKTsKfQoKc3Rh dGljIGludAprZXlfbGFzdF9jbXAoIGNvbnN0IHN0cnVjdCBrZXlfbGFzdCAqazEsIGNvbnN0 IHN0cnVjdCBrZXlfbGFzdCAqazIgKQp7CglyZXR1cm4gKHN0cmNhc2VjbXAoazEtPmxhc3Qs azItPmxhc3QpID09IDApOwp9CgoKc3RhdGljIHZvaWQKa2V5X2xhc3RfY3AoIHN0cnVjdCBr ZXlfbGFzdCAqZHN0LCBjb25zdCBzdHJ1Y3Qga2V5X2xhc3QgKnNyYyApCnsKCXN0cmNweShk c3QtPmxhc3Qsc3JjLT5sYXN0KTsKfQoKdm9pZApsYXN0X2hhc2hfaW5pdCggc3RydWN0IHdv cmtlcnNfYnlfbGFzdCAqaGFzaCApCnsKCU1NQVBfSU5JVChoYXNoLGtleV9sYXN0X2hhc2gs a2V5X2xhc3RfY21wLGtleV9sYXN0X2NwKTsKfQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGJkc20vZXhhbXBsZTAvZXhhbXBsZTAuaAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwMDA3NTUgADAwMTc1MSAAMDAxNzUwIAAwMDAwMDAwMzYzMCAxMDY0NDc3MTMxNyAwMTYy NjUAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0 YXIAMDB3aWVjenlrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtvbnRhAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyotCiAqIENvcHlyaWdodCAo YykgMjAwNyBQYXdlbCBXaWVjem9yZWsgPHdpZWN6eWtAZ21haWwuY29tPgogKiBBbGwgcmln aHRzIHJlc2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUg cGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFy ZSBtZXQ6CiAqCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJl dGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVkaXN0cmli dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmln aHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhl ciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgogKiBUSElT IFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBBTlkg RVhQUkVTUyBPUgogKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBM SU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCiAqIE9GIE1FUkNIQU5UQUJJTElU WSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQu CiAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElS RUNULCBJTkRJUkVDVCwKICogSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBD T05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUCiAqIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9G IFVTRSwKICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCiAqIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRI RVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQKICogKElOQ0xVRElO RyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBU SEUgVVNFIE9GCiAqIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9T U0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqLwoKI2lmbmRlZiBFWEFNUExFXzAKI2Rl ZmluZSBFWEFNUExFXzAKCiNkZWZpbmUgUFJJTUVfTlVNQkVSIDEzCgoKI2RlZmluZSBGSVJT VF9NQVggMTIwCiNkZWZpbmUgTEFTVF9NQVggMTIwCiNkZWZpbmUgQ0lUWV9NQVggMTIwCgpz dHJ1Y3Qga2V5X2lkIHsKCWludCBpZDsKfTsKCnN0cnVjdCBrZXlfbGFzdCB7CgljaGFyIGxh c3RbTEFTVF9NQVhdOwp9OwoKc3RydWN0IHdvcmtlciB7CglpbnQgaWQ7CgljaGFyIGZpcnN0 W0ZJUlNUX01BWF07CgljaGFyIGxhc3RbTEFTVF9NQVhdOwoJaW50IGFnZTsKCWNoYXIgY2l0 eVtDSVRZX01BWF07CgoJTUFQX0VOVFJZKHdvcmtlcixrZXlfaWQpIGhhc2hfYnlfaWQ7CglN TUFQX0VOVFJZKHdvcmtlcixrZXlfbGFzdCkgaGFzaF9ieV9sYXN0Owp9OwoKTUFQX0hFQUQo d29ya2Vyc19ieV9pZCx3b3JrZXIsUFJJTUVfTlVNQkVSKTsKTU1BUF9IRUFEKHdvcmtlcnNf YnlfbGFzdCx3b3JrZXIsUFJJTUVfTlVNQkVSKTsKCnZvaWQgaWRfaGFzaF9pbml0KCBzdHJ1 Y3Qgd29ya2Vyc19ieV9pZCAqdGFibGUgKTsKdm9pZCBsYXN0X2hhc2hfaW5pdCggc3RydWN0 IHdvcmtlcnNfYnlfbGFzdCAqdGFibGUgKTsKCgojZW5kaWYKAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiZHNtL3N5cy9iZHMuaAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwNzU1IAAwMDE3NTEgADAwMTc1MCAAMDAwMDAw MjI3MDMgMTA2NDUxMjQ3MjQgMDE0NDIyACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwd2llY3p5awAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABrb250YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAwMDAwIAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAC8qLQogKiBDb3B5cmlnaHQgKGMpIDIwMDcgUGF3ZWwgV2llY3pvcmVrIDx3aWVjenlr QGdtYWlsLmNvbT4KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoKICogUmVkaXN0cmlidXRp b24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0 CiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xs b3dpbmcgY29uZGl0aW9ucwogKiBhcmUgbWV0OgogKgogKiAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAogKiAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2Ns YWltZXIuCiAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKICogICAgZG9j dW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRp c3RyaWJ1dGlvbi4KICoKICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKICogSU1QTElFRCBXQVJSQU5USUVT LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElF UwogKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFIEFSRSBESVNDTEFJTUVELgogKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9S IEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCiAqIElOQ0lERU5UQUwsIFNQ RUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcs IEJVVAogKiBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09E UyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsCiAqIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJV U0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQogKiBUSEVP UlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZ LCBPUiBUT1JUCiAqIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRgogKiBUSElTIFNPRlRXQVJFLCBFVkVO IElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogKgogKi8K CiNpZm5kZWYgU1lTX0JEU19ICiNkZWZpbmUgU1lTX0JEU19ICgoKLyoKICogVGhpcyBmaWxl IGNvbnRhaW4gYmFzaWMgZGF0YSBzdHJ1Y3R1cmVzLiBUaGV5IGFyZSBzaW1pbGFyIHRvIHN0 cnVjdHVyZXMKICogaW4gc3lzL3F1ZXVlLmgsIHBsZWFzZSByZWFkIGRvY3VtZW50YXRpb24g Zm9yIGl0IGZpcnN0LiAKICoKICogISEgSW5jbHVkZSBzeXMvcXVldWUuaCBiZWZvcmUgdGhp cyBmaWxlLgogKiAKICogQSBtYXAgKCBkaWN0aW9uYXJ5LCBoYXNoLXRhYmxlLCBhc3NvY2lh dGl2ZSBhcnJheSApIHN0cnVjdHVyZSBpcyBoZWFkZWQKICogYnkgTUFQX0hFQUQgbWFjcm8u IFRoaXMgc3RydWN0dXJlIGNvbnRhaW5zIHRhYmxlIG9mIGxpc3RzIHJlcHJlc2VudGVkCiAq IGJ5IFNMSVNUIHN0cnVjdHVyZSBmcm9tIHN5cy9xdWV1ZS5oLiBUaGUgbGVuZ3RoIG9mIHRh YmxlIGlzIHR5cGVkIGJ5IHVzZXIKICogYXMgcHJpbWUtbnVtYmVyLXBhcmFtZXRlciBpbiBI RUFEIG1hY3JvLiBTdHJ1Y3R1cmVzIGFyZSB1c2VkIHRvCiAqIGRlY3Jhc2UgdGltZSBvZiBp dGVtIGFjY2VzcyAuIFVzZXIgaGFkIHRvIHNwZWNpZnkgYSBzdHJ1Y3R1cmUKICogd2hpY2gg d2lsbCBiZSB1c2VyIGFzIGtleS4KICogVGhlIGluaXRpYWxpemVyIChNQVBfSU5JVCkgbmVl ZCBwb2ludGVycyB0byBoYXNoLWZ1bmN0aW9uLCBrZXktY29weSBhbmQKICoga2V5LWNvbXBh cmUgcm91dGluZXMuIE1lbW9yeSBhZGRyZXNzZXMgb2YgdGhlbiB0aGVtIHdpbGwgYmUgc3Rv cmVkCiAqIGluIGRhdGEgc3RydWN0dXJlIGZvciBsYXRlciB1c2FnZS4gUGxlYXNlIHNlZSBk ZWZpbml0aW9uIG9mIGJkc18qIHR5cGVzCiAqIGluIHRoaXMgZmlsZSBmb3IgbW9yZSBpbmZv cm1hdGlvbi4KICogQSBtdWx0aSBtYXAgc3RydWN0dXJlIGlzIGhlYWRlZCBieSBNTUFQX0hF QUQgbWFjcm8gdG8gcmVkdWNlIGxpbmVzIG9mIGNvZGUKICouKGxlc3MgcHJvYmFsaXR5IHRv IG1ha2UgYnVnKS4gSXQgaXMgaWRlbnRpY2FsIHRvCiAqIHNpbmdsZSBtYXAgd2l0aCBkaWZm ZXJlbmNlIHRoYXQgY2FuIHN0b3JlIG1hbnkgdmFyaWFibGVzIGZvciB0aGlzIHNhbWUga2V5 LgogKiBGb3IgdGhpcyBmZWF0dXJlIGl0IGlzIGltcGxlbWVudGluZyBhZGRpdGlvbmFsIG1h Y3JvOiBfTE9PS1VQX0ZPUkVBQ0gKICogKGFuZCBfU0FGRSB2ZXJzaW9uKS4KICogSW4gaW1w bGVtZW50YXRpb24gdGhlIE1BUCBhbmQgTU1BUCBhcmUgaWRlbnRpY2FsLCBpdCBoYXZlIGRp ZmZlcmVudCBuYW1lcwogKiBmb3IgbG9naWNhbCBzZXBlcmF0aW9uLiBJdCBpcyBhbHNvIHVz aW5nIGludGVybmFsIHRlbXBsYXRlIGZvciBnZW5lcmF0ZQogKiBhbm90aGVyIGludGVybmFs IG5hbWVzIGZvciBNQVAgYW5kIE1NQVAsIGluIHRoaXMgd2F5IGNvbXBpbGVyIGNhbiBnZW5l cmF0ZQogKiBlcnJvciAgd2hlbiBwcm9ncmFtbWVyIHdpbGwgdXNlIGZvciBleGFtcGxlIE1B UCBtYWNybyBvbiBNTUFQIHN0cnVjdHVyZS4KICoKICogICAgICAgICAgICAgICAgICAgICAg ICAgIE1BUCAgICBNTUFQCiAqIF9IRUFEICAgICAgICAgICAgICAgICAgICArICAgICAgKwog KiBfSEVBRF9JTklUSUFMSVpFUiAgICAgICAgLSAgICAgIC0KICogX0VOVFJZICAgICAgICAg ICAgICAgICAgICsgICAgICArCiAqIF9JTklUICAgICAgICAgICAgICAgICAgICArICAgICAg KwogKiBfRU1QVFkgICAgICAgICAgICAgICAgICAgKyAgICAgICsKICogX0ZJUlNUICAgICAg ICAgICAgICAgICAgIC0gICAgICAtCiAqIF9ORVhUICAgICAgICAgICAgICAgICAgICAtICAg ICAgLQogKiBfUFJFViAgICAgICAgICAgICAgICAgICAgLSAgICAgIC0KICogX0xBU1QgICAg ICAgICAgICAgICAgICAgIC0gICAgICAtCiAqIF9LRVkgICAgICAgICAgICAgICAgICAgICAr ICAgICAgKwogKiBfRk9SRUFDSCAgICAgICAgICAgICAgICAgKyAgICAgICsKICogX0ZPUkVB Q0hfU0FGRSAgICAgICAgICAgICsgICAgICArCiAqIF9GT1JFQUNIX1JFVkVSU0UgICAgICAg ICAtICAgICAgLQogKiBfRk9SRUFDSF9SRVZFUlNFX1NBRkUgICAgLSAgICAgIC0KICogX0lO U0VSVCAgICAgICAgICAgICAgICAgICsgICAgICArCiAqIF9JTlNFUlRfSEVBRCAgICAgICAg ICAgICAtICAgICAgLQogKiBfSU5TRVJUX0JFRk9SRSAgICAgICAgICAgLSAgICAgIC0KICog X0lOU0VSVF9BRlRFUiAgICAgICAgICAgIC0gICAgICAtCiAqIF9JTlNFUlRfVEFJTCAgICAg ICAgICAgICAtICAgICAgLQogKiBfQ09OQ0FUICAgICAgICAgICAgICAgICAgLSAgICAgIC0K ICogX1JFTU9WRV9IRUFEICAgICAgICAgICAgIC0gICAgICAtCiAqIF9SRU1PVkUgICAgICAg ICAgICAgICAgICArICAgICAgKwogKiBfTE9PS1VQICAgICAgICAgICAgICAgICAgKyAgICAg ICsKICogX0xPT0tVUF9GT1JFQUNIICAgICAgICAgIC0gICAgICArCiAqIF9MT09LVVBfRk9S RUFDSF9TQUZFICAgICAtICAgICAgKwogKgogKiBJbXBsZW1lbnRhdGlvbiBub3RlcwogKiAt LS0tLS0tLS0tLS0tLS0tLS0tLQogKgogKi8KCgp0eXBlZGVmIHVuc2lnbmVkIGludCBiZHNf aGFzaF9mdW5jX3QoIGNvbnN0IHZvaWQgKmtleSApOwp0eXBlZGVmIGludCBiZHNfa2V5X2Nt cF9mdW5jX3QgKCBjb25zdCB2b2lkICprZXkxLCBjb25zdCB2b2lkICprZXkyICk7CnR5cGVk ZWYgdm9pZCBiZHNfa2V5X2NwX2Z1bmNfdCggdm9pZCAqa2V5ZHN0LCBjb25zdCB2b2lkICpr ZXlzcmMgKTsKCi8qCiAqIEdlbmVyaWMgbWFwIHRlbXBsYXRlCiAqLwoKI2RlZmluZSBfdE1B UF9QUklNRV9USU5ZCTQ5CiNkZWZpbmUgX3RNQVBfUFJJTUVfU01BTEwJMTQ5CiNkZWZpbmUg X3RNQVBfUFJJTUVfTUVESVVNCTk3NwojZGVmaW5lIF90TUFQX1BSSU1FX0xBUkdFCTEyNzcK I2RlZmluZSBfdE1BUF9QUklNRV9IVUdFCTI0NTkKCgojZGVmaW5lIF90TUFQX0xPT0tVUF9G Uk9NX0xJU1QoaGVhZCwgbGlzdCxrZXksdmFyLGZpZWxkLF90ZmllbGQpIGRvIHsJXAoJaW50 IF9oaWZvdW5kID0gMDsJCQkJCQlcCglTTElTVF9GT1JFQUNIKHZhciwgbGlzdCwgZmllbGQu X3RmaWVsZCApIHsJCQlcCgkJaWYgKCBoZWFkLT5jbXBmdW5jKGtleSwmdmFyLT5maWVsZC5r ZXljb3B5KSApIHsJXAoJCQlfaGlmb3VuZCA9IDE7CQkJCQlcCgkJCWJyZWFrOwkJCQkJCVwK CQl9CQkJCQkJCVwKCX0JCQkJCQkJCVwKCWlmICggIV9oaWZvdW5kICkgdmFyID0gTlVMTDsJ CQkJCVwKfSB3aGlsZSgwKQoKI2RlZmluZSBfdE1BUF9JTlNFUlRfSU5UT19MSVNUKGhlYWQs bGlzdCxrZXksdmFyLGZpZWxkLF90ZmllbGQpIGRvIHsJXAoJaGVhZC0+Y3BmdW5jKCYodmFy LT5maWVsZC5rZXljb3B5KSxrZXkpOwkJCVwKCWhlYWQtPmNvdW50Kys7CQkJCQkJCVwKCVNM SVNUX0lOU0VSVF9IRUFEKCBsaXN0LCB2YXIsIGZpZWxkLl90ZmllbGQgKTsJCQlcCn0gd2hp bGUoMCkKCgojZGVmaW5lIF90TUFQX0xJU1QoaGVhZCxpKSAmKChoZWFkKS0+bGlzdFtpXSkK CiNkZWZpbmUgX3RNQVBfTEVOR1RIKGhlYWQpICAoc2l6ZW9mKChoZWFkKS0+bGlzdCkvc2l6 ZW9mKChoZWFkKS0+bGlzdFswXSkpCgojZGVmaW5lIF90TUFQX0lOREVYKGhlYWQsa2V5KSAo KChoZWFkKS0+aGZ1bmMoa2V5KSklX3RNQVBfTEVOR1RIKGhlYWQpKQoKCiNkZWZpbmUgX3RN QVBfSEVBRChuYW1lLHR5cGUscHJpbWUpCQkJCQlcCnN0cnVjdCBuYW1lIHsJCQkJCQkJCVwK CXVuc2lnbmVkIGludCB0bXBfaTsJCQkJCQlcCglzdHJ1Y3QgdHlwZSAqdG1wX3Y7CQkJCQkJ XAoJaW50IGNvdW50OwkJCQkJCQlcCgliZHNfaGFzaF9mdW5jX3QgKmhmdW5jOwkJCQkJCVwK CWJkc19rZXlfY21wX2Z1bmNfdCAqY21wZnVuYzsJCQkJCVwKCWJkc19rZXlfY3BfZnVuY190 ICpjcGZ1bmM7CQkJCQlcCglTTElTVF9IRUFEKCx0eXBlKSBsaXN0W3ByaW1lXTsJCQkJCVwK fQoKCiNkZWZpbmUgX3RNQVBfRU5UUlkodHlwZSxrZXl0eXBlLF90ZmllbGQpCQkJCVwKc3Ry dWN0IHsJCQkJCQkJCVwKCVNMSVNUX0VOVFJZKHR5cGUpIF90ZmllbGQ7CQkJCQlcCglzdHJ1 Y3Qga2V5dHlwZSBrZXljb3B5OwkJCQkJCVwKfQoKCiNkZWZpbmUgX3RNQVBfSU5JVChoZWFk LF9oZnVuYyxfY21wZnVuYyxfY3BmdW5jKSBkbyB7CQkJXAoJdW5zaWduZWQgaW50IF9oaWw7 CQkJCQkJXAoJKGhlYWQpLT5oZnVuYyA9IChiZHNfaGFzaF9mdW5jX3QqKV9oZnVuYzsJCQlc CgkoaGVhZCktPmNtcGZ1bmMgPSAoYmRzX2tleV9jbXBfZnVuY190KilfY21wZnVuYzsJCVwK CShoZWFkKS0+Y3BmdW5jID0gKGJkc19rZXlfY3BfZnVuY190KilfY3BmdW5jOwkJCVwKCSho ZWFkKS0+Y291bnQgPSAwOwkJCQkJCVwKICAgIGZvciAoIF9oaWwgPSAwOyBfaGlsIDwgX3RN QVBfTEVOR1RIKGhlYWQpOyBfaGlsKysgKSB7CQlcCgkJU0xJU1RfSU5JVCggX3RNQVBfTElT VChoZWFkLF9oaWwpICk7CQkJXAogICAgfQkJCQkJCQkJCVwKfSB3aGlsZSgwKQoKI2RlZmlu ZSBfdE1BUF9FTVBUWShoZWFkKSAoKGhlYWQpLT5jb3VudCA9PSAwKQoKI2RlZmluZSBfdE1B UF9LRVkodmFyLGZpZWxkKSAoJih2YXIpLT5maWVsZC5rZXljb3B5KQoKCiNkZWZpbmUgX3RN QVBfSU5TRVJUKGhlYWQsIGtleSwgdmFyLCBmaWVsZCxfdGZpZWxkICkgZG8gewkJXAoJdW5z aWduZWQgaW50IF9oaWwgPSBfdE1BUF9JTkRFWChoZWFkLGtleSk7CQkJXAoJX3RNQVBfSU5T RVJUX0lOVE9fTElTVCgoaGVhZCksIF90TUFQX0xJU1QoaGVhZCxfaGlsKSwJCVwKCQkJa2V5 LHZhcixmaWVsZCxfdGZpZWxkKTsJCQkJXAp9IHdoaWxlKDApCgoKI2RlZmluZSBfdE1BUF9G T1JFQUNIKHZhciwgaGVhZCwgZmllbGQsX3RmaWVsZCkJCQkJXApmb3IgKCAoaGVhZCktPnRt cF9pID0gMDsJCQkJCQlcCgkJKGhlYWQpLT50bXBfaSA8IF90TUFQX0xFTkdUSChoZWFkKTsJ CQlcCgkJKGhlYWQpLT50bXBfaSsrICkJCQkJCVwKCVNMSVNUX0ZPUkVBQ0godmFyLCBfdE1B UF9MSVNUKGhlYWQsKGhlYWQpLT50bXBfaSksIGZpZWxkLl90ZmllbGQpCgoKI2RlZmluZSBf dE1BUF9GT1JFQUNIX1NBRkUodmFyLCBoZWFkLCBmaWVsZCwgX3RmaWVsZCApCQkJXApmb3Ig KCAoaGVhZCktPnRtcF9pID0gMDsJCQkJCQlcCgkJKGhlYWQpLT50bXBfaSA8IF90TUFQX0xF TkdUSChoZWFkKTsJCQlcCgkJKGhlYWQpLT50bXBfaSsrICkJCQkJCVwKCVNMSVNUX0ZPUkVB Q0hfU0FGRSh2YXIsIF90TUFQX0xJU1QoaGVhZCwoaGVhZCktPnRtcF9pKSwgZmllbGQuX3Rm aWVsZCwoaGVhZCktPnRtcF92ICkKCgoKI2RlZmluZSBfdE1BUF9SRU1PVkUoIGhlYWQsIHZh ciwgdHlwZSwgZmllbGQsIF90ZmllbGQgKSBkbyB7CQlcCglpbnQgX2hpbCA9IF90TUFQX0lO REVYKGhlYWQsICYodmFyKS0+ZmllbGQua2V5Y29weSk7CQlcCglTTElTVF9SRU1PVkUoIF90 TUFQX0xJU1QoaGVhZCxfaGlsKSwgdmFyLCB0eXBlLGZpZWxkLl90ZmllbGQgKTtcCn0gd2hp bGUoMCkKCQoKCiNkZWZpbmUgX3RNQVBfTE9PS1VQKCBoZWFkLCBrZXksIHZhciwgZmllbGQs X3RmaWVsZCApIGRvIHsJCVwKCXVuc2lnbmVkIGludCBfaGlsID0gX3RNQVBfSU5ERVgoaGVh ZCxrZXkpOwkJCVwKCV90TUFQX0xPT0tVUF9GUk9NX0xJU1QoIChoZWFkKSwgX3RNQVBfTElT VChoZWFkLF9oaWwpLAkJXAoJCQlrZXksIHZhciwgZmllbGQsIF90ZmllbGQpOwkJCVwKfSB3 aGlsZSgwKQoKCiNkZWZpbmUgX3RNQVBfTE9PS1VQX0ZPUkVBQ0goaCwga2V5LCB2YXIsZmll bGQsX3RmaWVsZCkJCQlcCglTTElTVF9GT1JFQUNIKHZhciwgX3RNQVBfTElTVChoLF90TUFQ X0lOREVYKGgsa2V5KSksIGZpZWxkLl90ZmllbGQpXAoJCWlmICggKGgpLT5jbXBmdW5jKGtl eSwmdmFyLT5maWVsZC5rZXljb3B5KSApCgkKCiNkZWZpbmUgX3RNQVBfTE9PS1VQX0ZPUkVB Q0hfU0FGRShoLCBrLCBkLGYsIF90ZmllbGQpCQkJXAoJU0xJU1RfRk9SRUFDSF9TQUZFKGQs IF90TUFQX0xJU1QoaCxfdE1BUF9JTkRFWChoLGspKSwgZi5fdGZpZWxkLChoKS0+dG1wX3Yp XAoJCWlmICggKGgpLT5jbXBmdW5jKGssJmQtPmYua2V5Y29weSkgKQoKCi8qCiAqIE1hcCBk ZWZpbml0aW9ucwogKi8KCgojZGVmaW5lIF9NQVBfTEZJRUxECW1wZmxkCgojZGVmaW5lIE1B UF9IRUFEKG5hbWUsdHlwZSxwcmltZSkJCQkJCVwKCV90TUFQX0hFQUQobmFtZSx0eXBlLHBy aW1lKQoKI2RlZmluZSBNQVBfRU5UUlkodHlwZSxrZXl0eXBlKQkJCQkJCVwKCV90TUFQX0VO VFJZKHR5cGUsa2V5dHlwZSxfTUFQX0xGSUVMRCkKCiNkZWZpbmUgTUFQX0tFWSh2YXIsZmll bGQpCQkJCQkJXAoJX3RNQVBfS0VZKHZhcixmaWVsZCkKCiNkZWZpbmUgTUFQX0lOSVQoaGVh ZCxfaGZ1bmMsX2NtcGZ1bmMsX2NwZnVuYykJCQkJXAoJX3RNQVBfSU5JVChoZWFkLF9oZnVu YyxfY21wZnVuYyxfY3BmdW5jKQoKI2RlZmluZSBNQVBfRU1QVFkoaGVhZCkJCQkJCQkJXAoJ X3RNQVBfRU1QVFkoaGVhZCkKCiNkZWZpbmUgTUFQX0ZPUkVBQ0goIHZhciwgaGVhZCwgZmll bGQpCQkJCQlcCglfdE1BUF9GT1JFQUNIKCB2YXIsIGhlYWQsIGZpZWxkLF9NQVBfTEZJRUxE KQoKI2RlZmluZSBNQVBfRk9SRUFDSF9TQUZFKCB2YXIsIGhlYWQsIGZpZWxkICkJCQkJXAoJ X3RNQVBfRk9SRUFDSF9TQUZFKCB2YXIsIGhlYWQsIGZpZWxkLCBfTUFQX0xGSUVMRCApCgoj ZGVmaW5lIE1BUF9SRU1PVkUoIGhlYWQsIHZhciwgdHlwZSwgZmllbGQgKQkJCQlcCglfdE1B UF9SRU1PVkUoIGhlYWQsIHZhciwgdHlwZSwgZmllbGQsX01BUF9MRklFTEQgKQoKI2RlZmlu ZSBNQVBfUkVNT1ZFX0JZX0tFWSggaGVhZCwga2V5LCB0eXBlLCBmaWVsZCApCQkJXAoJX3RN QVBfUkVNT1ZFX0JZX0tFWSggaGVhZCwga2V5LCB0eXBlLCBmaWVsZCxfTUFQX0xGSUVMRCAp CgojZGVmaW5lIE1BUF9MT09LVVAoIGhlYWQsIGtleSwgdmFyLCBmaWVsZCApCQkJCVwKCV90 TUFQX0xPT0tVUCggaGVhZCwga2V5LCB2YXIsIGZpZWxkLF9NQVBfTEZJRUxEICkKCiNkZWZp bmUgTUFQX0lOU0VSVChoZWFkLCBrZXksIHZhciwgZmllbGQgKQkJCQlcCglfdE1BUF9JTlNF UlQoaGVhZCwga2V5LCB2YXIsIGZpZWxkLF9NQVBfTEZJRUxEICkKCi8qCiAqIE11bHRpIG1h cCBkZWZpbml0aW9ucwogKi8KCiNkZWZpbmUgX01NQVBfTEZJRUxECW1tcGZsZAoKI2RlZmlu ZSBNTUFQX0hFQUQobmFtZSx0eXBlLHByaW1lKQkJCQkJXAoJX3RNQVBfSEVBRChuYW1lLHR5 cGUscHJpbWUpCgojZGVmaW5lIE1NQVBfRU5UUlkodHlwZSxrZXl0eXBlKQkJCQkJXAoJX3RN QVBfRU5UUlkodHlwZSxrZXl0eXBlLF9NTUFQX0xGSUVMRCkKCiNkZWZpbmUgTU1BUF9LRVko dmFyLGZpZWxkKQkJCQkJCVwKCV90TUFQX0tFWSh2YXIsZmllbGQpCgojZGVmaW5lIE1NQVBf SU5JVChoZWFkLF9oZnVuYyxfY21wZnVuYyxfY3BmdW5jKQkJCQlcCglfdE1BUF9JTklUKGhl YWQsX2hmdW5jLF9jbXBmdW5jLF9jcGZ1bmMpCgojZGVmaW5lIE1NQVBfRU1QVFkoaGVhZCkJ CQkJCQlcCglfdE1BUF9FTVBUWShoZWFkKQoKI2RlZmluZSBNTUFQX0ZPUkVBQ0goIHZhciwg aGVhZCwgZmllbGQpCQkJCQlcCglfdE1BUF9GT1JFQUNIKCB2YXIsIGhlYWQsIGZpZWxkLF9N TUFQX0xGSUVMRCkKCiNkZWZpbmUgTU1BUF9GT1JFQUNIX1NBRkUoIHZhciwgaGVhZCwgZmll bGQgKQkJCQlcCglfdE1BUF9GT1JFQUNIX1NBRkUoIHZhciwgaGVhZCwgZmllbGQsX01NQVBf TEZJRUxEICkKCiNkZWZpbmUgTU1BUF9SRU1PVkUoIGhlYWQsIHZhciwgdHlwZSwgZmllbGQg KQkJCQlcCglfdE1BUF9SRU1PVkUoIGhlYWQsIHZhciwgdHlwZSwgZmllbGQsX01NQVBfTEZJ RUxEICkKCiNkZWZpbmUgTU1BUF9SRU1PVkVfQllfS0VZKCBoZWFkLCBrZXksIHR5cGUsIGZp ZWxkICkJCQlcCglfdE1BUF9SRU1PVkVfQllfS0VZKCBoZWFkLCBrZXksIHR5cGUsIGZpZWxk LF9NTUFQX0xGSUVMRCApCgojZGVmaW5lIE1NQVBfTE9PS1VQKCBoZWFkLCBrZXksIHZhciwg ZmllbGQgKQkJCQlcCglfdE1BUF9MT09LVVAoIGhlYWQsIGtleSwgdmFyLCBmaWVsZCxfTU1B UF9MRklFTEQgKQoKI2RlZmluZSBNTUFQX0xPT0tVUF9GT1JFQUNIKCBoZWFkLCBrZXksIHZh ciwgZmllbGQgKQkJCVwKCV90TUFQX0xPT0tVUF9GT1JFQUNIKCBoZWFkLCBrZXksIHZhciwg ZmllbGQsX01NQVBfTEZJRUxEICkKCiNkZWZpbmUgTU1BUF9MT09LVVBfRk9SRUFDSF9TQUZF KCBoZWFkLCBrZXksIHZhciwgZmllbGQgKQkJXAoJX3RNQVBfTE9PS1VQX0ZPUkVBQ0hfU0FG RSggaGVhZCwga2V5LCB2YXIsIGZpZWxkLF9NTUFQX0xGSUVMRCApCgojZGVmaW5lIE1NQVBf SU5TRVJUKGhlYWQsIGtleSwgdmFyLCBmaWVsZCApCQkJCVwKCV90TUFQX0lOU0VSVChoZWFk LCBrZXksIHZhciwgZmllbGQsX01NQVBfTEZJRUxEICkKCgoKI2VuZGlmIC8qIFNZU19CRFNf SCAqLwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA== --------------020003070002010103050303 Content-Type: text/plain; name="bds.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bds.h" /*- * Copyright (c) 2007 Pawel Wieczorek * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * */ #ifndef SYS_BDS_H #define SYS_BDS_H /* * This file contain basic data structures. They are similar to structures * in sys/queue.h, please read documentation for it first. * * !! Include sys/queue.h before this file. * * A map ( dictionary, hash-table, associative array ) structure is headed * by MAP_HEAD macro. This structure contains table of lists represented * by SLIST structure from sys/queue.h. The length of table is typed by user * as prime-number-parameter in HEAD macro. Structures are used to * decrase time of item access . User had to specify a structure * which will be user as key. * The initializer (MAP_INIT) need pointers to hash-function, key-copy and * key-compare routines. Memory addresses of then them will be stored * in data structure for later usage. Please see definition of bds_* types * in this file for more information. * A multi map structure is headed by MMAP_HEAD macro to reduce lines of code *.(less probality to make bug). It is identical to * single map with difference that can store many variables for this same key. * For this feature it is implementing additional macro: _LOOKUP_FOREACH * (and _SAFE version). * In implementation the MAP and MMAP are identical, it have different names * for logical seperation. It is also using internal template for generate * another internal names for MAP and MMAP, in this way compiler can generate * error when programmer will use for example MAP macro on MMAP structure. * * MAP MMAP * _HEAD + + * _HEAD_INITIALIZER - - * _ENTRY + + * _INIT + + * _EMPTY + + * _FIRST - - * _NEXT - - * _PREV - - * _LAST - - * _KEY + + * _FOREACH + + * _FOREACH_SAFE + + * _FOREACH_REVERSE - - * _FOREACH_REVERSE_SAFE - - * _INSERT + + * _INSERT_HEAD - - * _INSERT_BEFORE - - * _INSERT_AFTER - - * _INSERT_TAIL - - * _CONCAT - - * _REMOVE_HEAD - - * _REMOVE + + * _LOOKUP + + * _LOOKUP_FOREACH - + * _LOOKUP_FOREACH_SAFE - + * * Implementation notes * -------------------- * */ typedef unsigned int bds_hash_func_t( const void *key ); typedef int bds_key_cmp_func_t ( const void *key1, const void *key2 ); typedef void bds_key_cp_func_t( void *keydst, const void *keysrc ); /* * Generic map template */ #define _tMAP_PRIME_TINY 49 #define _tMAP_PRIME_SMALL 149 #define _tMAP_PRIME_MEDIUM 977 #define _tMAP_PRIME_LARGE 1277 #define _tMAP_PRIME_HUGE 2459 #define _tMAP_LOOKUP_FROM_LIST(head, list,key,var,field,_tfield) do { \ int _hifound = 0; \ SLIST_FOREACH(var, list, field._tfield ) { \ if ( head->cmpfunc(key,&var->field.keycopy) ) { \ _hifound = 1; \ break; \ } \ } \ if ( !_hifound ) var = NULL; \ } while(0) #define _tMAP_INSERT_INTO_LIST(head,list,key,var,field,_tfield) do { \ head->cpfunc(&(var->field.keycopy),key); \ head->count++; \ SLIST_INSERT_HEAD( list, var, field._tfield ); \ } while(0) #define _tMAP_LIST(head,i) &((head)->list[i]) #define _tMAP_LENGTH(head) (sizeof((head)->list)/sizeof((head)->list[0])) #define _tMAP_INDEX(head,key) (((head)->hfunc(key))%_tMAP_LENGTH(head)) #define _tMAP_HEAD(name,type,prime) \ struct name { \ unsigned int tmp_i; \ struct type *tmp_v; \ int count; \ bds_hash_func_t *hfunc; \ bds_key_cmp_func_t *cmpfunc; \ bds_key_cp_func_t *cpfunc; \ SLIST_HEAD(,type) list[prime]; \ } #define _tMAP_ENTRY(type,keytype,_tfield) \ struct { \ SLIST_ENTRY(type) _tfield; \ struct keytype keycopy; \ } #define _tMAP_INIT(head,_hfunc,_cmpfunc,_cpfunc) do { \ unsigned int _hil; \ (head)->hfunc = (bds_hash_func_t*)_hfunc; \ (head)->cmpfunc = (bds_key_cmp_func_t*)_cmpfunc; \ (head)->cpfunc = (bds_key_cp_func_t*)_cpfunc; \ (head)->count = 0; \ for ( _hil = 0; _hil < _tMAP_LENGTH(head); _hil++ ) { \ SLIST_INIT( _tMAP_LIST(head,_hil) ); \ } \ } while(0) #define _tMAP_EMPTY(head) ((head)->count == 0) #define _tMAP_KEY(var,field) (&(var)->field.keycopy) #define _tMAP_INSERT(head, key, var, field,_tfield ) do { \ unsigned int _hil = _tMAP_INDEX(head,key); \ _tMAP_INSERT_INTO_LIST((head), _tMAP_LIST(head,_hil), \ key,var,field,_tfield); \ } while(0) #define _tMAP_FOREACH(var, head, field,_tfield) \ for ( (head)->tmp_i = 0; \ (head)->tmp_i < _tMAP_LENGTH(head); \ (head)->tmp_i++ ) \ SLIST_FOREACH(var, _tMAP_LIST(head,(head)->tmp_i), field._tfield) #define _tMAP_FOREACH_SAFE(var, head, field, _tfield ) \ for ( (head)->tmp_i = 0; \ (head)->tmp_i < _tMAP_LENGTH(head); \ (head)->tmp_i++ ) \ SLIST_FOREACH_SAFE(var, _tMAP_LIST(head,(head)->tmp_i), field._tfield,(head)->tmp_v ) #define _tMAP_REMOVE( head, var, type, field, _tfield ) do { \ int _hil = _tMAP_INDEX(head, &(var)->field.keycopy); \ SLIST_REMOVE( _tMAP_LIST(head,_hil), var, type,field._tfield );\ } while(0) #define _tMAP_LOOKUP( head, key, var, field,_tfield ) do { \ unsigned int _hil = _tMAP_INDEX(head,key); \ _tMAP_LOOKUP_FROM_LIST( (head), _tMAP_LIST(head,_hil), \ key, var, field, _tfield); \ } while(0) #define _tMAP_LOOKUP_FOREACH(h, key, var,field,_tfield) \ SLIST_FOREACH(var, _tMAP_LIST(h,_tMAP_INDEX(h,key)), field._tfield)\ if ( (h)->cmpfunc(key,&var->field.keycopy) ) #define _tMAP_LOOKUP_FOREACH_SAFE(h, k, d,f, _tfield) \ SLIST_FOREACH_SAFE(d, _tMAP_LIST(h,_tMAP_INDEX(h,k)), f._tfield,(h)->tmp_v)\ if ( (h)->cmpfunc(k,&d->f.keycopy) ) /* * Map definitions */ #define _MAP_LFIELD mpfld #define MAP_HEAD(name,type,prime) \ _tMAP_HEAD(name,type,prime) #define MAP_ENTRY(type,keytype) \ _tMAP_ENTRY(type,keytype,_MAP_LFIELD) #define MAP_KEY(var,field) \ _tMAP_KEY(var,field) #define MAP_INIT(head,_hfunc,_cmpfunc,_cpfunc) \ _tMAP_INIT(head,_hfunc,_cmpfunc,_cpfunc) #define MAP_EMPTY(head) \ _tMAP_EMPTY(head) #define MAP_FOREACH( var, head, field) \ _tMAP_FOREACH( var, head, field,_MAP_LFIELD) #define MAP_FOREACH_SAFE( var, head, field ) \ _tMAP_FOREACH_SAFE( var, head, field, _MAP_LFIELD ) #define MAP_REMOVE( head, var, type, field ) \ _tMAP_REMOVE( head, var, type, field,_MAP_LFIELD ) #define MAP_REMOVE_BY_KEY( head, key, type, field ) \ _tMAP_REMOVE_BY_KEY( head, key, type, field,_MAP_LFIELD ) #define MAP_LOOKUP( head, key, var, field ) \ _tMAP_LOOKUP( head, key, var, field,_MAP_LFIELD ) #define MAP_INSERT(head, key, var, field ) \ _tMAP_INSERT(head, key, var, field,_MAP_LFIELD ) /* * Multi map definitions */ #define _MMAP_LFIELD mmpfld #define MMAP_HEAD(name,type,prime) \ _tMAP_HEAD(name,type,prime) #define MMAP_ENTRY(type,keytype) \ _tMAP_ENTRY(type,keytype,_MMAP_LFIELD) #define MMAP_KEY(var,field) \ _tMAP_KEY(var,field) #define MMAP_INIT(head,_hfunc,_cmpfunc,_cpfunc) \ _tMAP_INIT(head,_hfunc,_cmpfunc,_cpfunc) #define MMAP_EMPTY(head) \ _tMAP_EMPTY(head) #define MMAP_FOREACH( var, head, field) \ _tMAP_FOREACH( var, head, field,_MMAP_LFIELD) #define MMAP_FOREACH_SAFE( var, head, field ) \ _tMAP_FOREACH_SAFE( var, head, field,_MMAP_LFIELD ) #define MMAP_REMOVE( head, var, type, field ) \ _tMAP_REMOVE( head, var, type, field,_MMAP_LFIELD ) #define MMAP_REMOVE_BY_KEY( head, key, type, field ) \ _tMAP_REMOVE_BY_KEY( head, key, type, field,_MMAP_LFIELD ) #define MMAP_LOOKUP( head, key, var, field ) \ _tMAP_LOOKUP( head, key, var, field,_MMAP_LFIELD ) #define MMAP_LOOKUP_FOREACH( head, key, var, field ) \ _tMAP_LOOKUP_FOREACH( head, key, var, field,_MMAP_LFIELD ) #define MMAP_LOOKUP_FOREACH_SAFE( head, key, var, field ) \ _tMAP_LOOKUP_FOREACH_SAFE( head, key, var, field,_MMAP_LFIELD ) #define MMAP_INSERT(head, key, var, field ) \ _tMAP_INSERT(head, key, var, field,_MMAP_LFIELD ) #endif /* SYS_BDS_H */ --------------020003070002010103050303-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 08:46:21 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97EEE16A4ED; Wed, 11 Jul 2007 08:46:21 +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 52BC713C45B; Wed, 11 Jul 2007 08:46:21 +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 CFF0C17382; Wed, 11 Jul 2007 08:46:19 +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 l6B8kJ7m055755; Wed, 11 Jul 2007 08:46:19 GMT (envelope-from phk@critter.freebsd.dk) To: "Constantine A. Murenin" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 10 Jul 2007 20:13:45 -0400." <469420B9.20401@FreeBSD.org> Date: Wed, 11 Jul 2007 08:46:19 +0000 Message-ID: <55754.1184143579@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 08:46:21 -0000 In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: >If you want to have no such framework that could potentially diagnose or >predict system failure, it's your choice, [...] I would love to have that, but the OpenBSD code isn't that. -- 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 Wed Jul 11 10:12:25 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 580CB16A41F; Wed, 11 Jul 2007 10:12:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF9713C484; Wed, 11 Jul 2007 10:12:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9E0A947A7B; Wed, 11 Jul 2007 06:12:24 -0400 (EDT) Date: Wed, 11 Jul 2007 11:12:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <55754.1184143579@critter.freebsd.dk> Message-ID: <20070711104247.P58526@fledge.watson.org> References: <55754.1184143579@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 10:12:25 -0000 On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: > >> If you want to have no such framework that could potentially diagnose or >> predict system failure, it's your choice, [...] > > I would love to have that, but the OpenBSD code isn't that. In the general spirit of SoC, I would suggest that a more constructive line of commenting might come with suggestions, not just rejections :-). Are you arguing that the current proposed framework offers little incremental benefit over simply having the sysctl framework in the first place and having each source of information (i.e., device driver) just export it directly? It seems clear that people would like all these measurements to be available, even if not by the precise mechanism proposed. So far the specific technical criticals have been: - There's such a diversity of motherboard devices and probe mechanisms that any kernel driver would become rapidly over-burdened and needlessly complicated. This doesn't argue for doing nothing, just that perhaps a kernel device driver is the wrong place. - A moderate number of user space tools exist to do this already in the ports collection, and user space is the right place to do this as it doesn't need to be in kernel. Part of the argument here has to do with code becoming stale, and one possible outcome of a more actively maintained in-OS framework is that it is better maintained, and that code is shared across platforms. Also, I have to say that I don't run monitoring tools on several of my boxes because I can never figure out which are the right ones to run, and the ones I try inevitably don't work. - This service is redundant with respect to existing IPMI interfaces, and that perhaps the IPMI interfaces are preferred as they interact better with simultaneous ROM flashing, etc. Undoubtably true. However, the proposed sensor framework isn't just about motherboard monitoring, but also about monitoring a range of devices, and if you've never struggled to get IPMI to just work on a box then you haven't used IPMI :-). It seems you have a more structural argument, but I think the nature of that argument will become more clear if you say what it is you'd like to see in terms of an alternative approach. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 10:52:37 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41B8816A421; Wed, 11 Jul 2007 10:52:37 +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 EEC5C13C459; Wed, 11 Jul 2007 10:52:36 +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 4710517382; Wed, 11 Jul 2007 10:52:35 +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 l6BAqYLf056114; Wed, 11 Jul 2007 10:52:34 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 11:12:24 +0100." <20070711104247.P58526@fledge.watson.org> Date: Wed, 11 Jul 2007 10:52:34 +0000 Message-ID: <56113.1184151154@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 10:52:37 -0000 In message <20070711104247.P58526@fledge.watson.org>, Robert Watson writes: >On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: >It seems clear that people would like all these measurements to be available, >even if not by the precise mechanism proposed. So far the specific technical >criticals have been: > >- There's such a diversity of motherboard devices and probe mechanisms that > any kernel driver would become rapidly over-burdened and needlessly > complicated. Not to mention size. Anything that sensibly can be done from userland should be done in userland. >This doesn't argue for doing nothing, just that perhaps a kernel device driver >is the wrong place. 100% agreement here. I would prefer to see the kernel drivers only offer transport and have all the MIB stuff happen in userland. In other words, I think the right way to think about this is: "Assume the existence of sensord(8), design client (sensors) and server (apps that want to know what the sensors show) APIs" Another thing to remember is that not all sensors relating to a system lives inside the system. Voltage, Fire, Temperature and other relevant sensors may need network or serial port communication instead if i2c or IPMI, but that doesn't mean that it shouldn't be possible to integrate it in the sensor MIB. -- 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 Wed Jul 11 11:15:14 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8F8716A469; Wed, 11 Jul 2007 11:15:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE8013C4BC; Wed, 11 Jul 2007 11:15:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0E79647C3C; Wed, 11 Jul 2007 07:15:14 -0400 (EDT) Date: Wed, 11 Jul 2007 12:15:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <56113.1184151154@critter.freebsd.dk> Message-ID: <20070711115332.I67691@fledge.watson.org> References: <56113.1184151154@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 11:15:14 -0000 On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: >> This doesn't argue for doing nothing, just that perhaps a kernel device >> driver is the wrong place. > > 100% agreement here. > > I would prefer to see the kernel drivers only offer transport and have all > the MIB stuff happen in userland. > > In other words, I think the right way to think about this is: "Assume the > existence of sensord(8), design client (sensors) and server (apps that want > to know what the sensors show) APIs" > > Another thing to remember is that not all sensors relating to a system lives > inside the system. Voltage, Fire, Temperature and other relevant sensors > may need network or serial port communication instead if i2c or IPMI, but > that doesn't mean that it shouldn't be possible to integrate it in the > sensor MIB. OK, so perhaps some more back-to-basics consideration is required. The presumed goal of a "kernel sensors framework" is to do things like provide common accessor methods, event management, and a registration mechanism for things that are "sensor-like". I don't think we need to introspect too much on the meaning of "sensor-like". We already have the sysctl framework available as a way to export lightly typed data from the kernel via a MIB. The usual way that we "group" related entries is to have them in a common part of the name space -- i.e., security, hw, or perhaps hw.sensors. This falls down a bit when you want to group things by more than one paramater -- i.e., bus location or node type, as we have support for very few node types, so there's a tension between putting information about devices in, say, dev.fdc.* and hw.sensor.fdc.*, where putting it in the former groups it by the device driver / device instance, and via the latter groups it as "sensor-like". I think this is where the registration bit comes in -- just as being able to iterate through general sysctl nodes is useful, being able to identify nodes of particular interest for monitoring (i.e., sensor-like) is quite useful for allowing the automated generation of log data, etc. A question I've not yet seen answered about the OpenBSD sensor framework is whether it addresses the issue of asynchronous notification -- one that we've still been coming to grips with for things like hardware device arrival via devd. The obvious comparison comes up here with SNMP, which offers a MIB, registration (by definition things in SNMP are of interest to monitoring), and event management (trap notification). Should we simply be turning on bsnmpd by default for the loopback interface and fleshing out the local monitoring tool suite to be able to use SNMP? Something I've wanted for a long time is the ability to use most of our existing management tools on remote boxes via SNMP -- i.e., "vmstat -z -H remote.host". Does sensord provide specific infrastructure beyond what already exists in our SNMP daemon or via the SNMP protocol -- is it reasonable to merge that functionality into an SNMP daemon? So it sounds like it would be useful for Constantine to help flesh out a few pieces of understanding: - How does having the kernel sensor framework compare with simply using sysctl as it stands today? - Does the sensor framework provide a trap mechanism, something that has historically been missing from our sysctl framework? - Does the stronger typing associated with sensor framework nodes, by virtue of imposed structure, significantly help in writing management tools? - The same functional comparisons with SNMP/bsnmpd/snmp tools and libraries. I think one of the observations made earlier in this thread -- that sensor events can come from the kernel, user space, or even distributed systems, is key to understanding what we may need out of a general sensor abstraction. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 11:19:42 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82FEA16A46B; Wed, 11 Jul 2007 11:19:42 +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 3C1B113C448; Wed, 11 Jul 2007 11:19:41 +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 7752F17383; Wed, 11 Jul 2007 11:19:40 +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 l6BBJeSV056224; Wed, 11 Jul 2007 11:19:40 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 12:15:13 +0100." <20070711115332.I67691@fledge.watson.org> Date: Wed, 11 Jul 2007 11:19:40 +0000 Message-ID: <56223.1184152780@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 11:19:42 -0000 In message <20070711115332.I67691@fledge.watson.org>, Robert Watson writes: >On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: >So it sounds like it would be useful for Constantine to help flesh out a few >pieces of understanding: Add to this: - Is it possible to correctly identify the hardware platform, so that we know where to find the sensors and know what they measure, without bloating the kernel with a lot of tables. The major technical challenge is that sensors are not documented on the majority of systems, unless you know in advance where to look for them. IPMI and ACPI tries to do something here, but the former is only available on serverhardware and the latter more often than not, comes only with the minimum necessary to avoid melted plastic. -- 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 Wed Jul 11 11:52:19 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 232D416A400; Wed, 11 Jul 2007 11:52:19 +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 9D7BB13C45B; Wed, 11 Jul 2007 11:52:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55763.dip.t-dialin.net [84.165.87.99]) by redbull.bpaserver.net (Postfix) with ESMTP id A0B7B2E25F; Wed, 11 Jul 2007 13:52:11 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 4A3F55B4902; Wed, 11 Jul 2007 13:50:00 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6BBnx3x077797; Wed, 11 Jul 2007 13:49:59 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 11 Jul 2007 13:49:59 +0200 Message-ID: <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 11 Jul 2007 13:49:59 +0200 From: Alexander Leidinger To: Robert Watson References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org> In-Reply-To: <20070711104247.P58526@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 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=-13.404, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 11:52:19 -0000 Quoting Robert Watson (from Wed, 11 Jul 2007 =20 11:12:24 +0100 (BST)): > On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > >> In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: >> >>> If you want to have no such framework that could potentially =20 >>> diagnose or predict system failure, it's your choice, [...] >> >> I would love to have that, but the OpenBSD code isn't that. > > In the general spirit of SoC, I would suggest that a more constructive > line of commenting might come with suggestions, not just rejections > :-). Are you arguing that the current proposed framework offers little > incremental benefit over simply having the sysctl framework in the > first place and having each source of information (i.e., device driver) > just export it directly? > > It seems clear that people would like all these measurements to be > available, even if not by the precise mechanism proposed. So far the > specific technical criticals have been: > > - There's such a diversity of motherboard devices and probe mechanisms tha= t > any kernel driver would become rapidly over-burdened and needlessly > complicated. > > This doesn't argue for doing nothing, just that perhaps a kernel device > driver is the wrong place. On the other hand you don't want to allow an userland tool to directly =20 mess around with the registers on your RAID or NIC to get some status... This SoC project is not about writting a driver for the sensors, it's =20 about importing a framework which provides interfaces to get sensor =20 information and uses some standardized driver interfaces to get this =20 information. At least as far as I have understand it (I haven't looked =20 at the code). So I think about it as something which allows to add =20 some code to e.g. the ATA driver which registers itself with the =20 sensors framework. The user doesn't has to learn how to query the ATA =20 stats when he already knows how to use the userland part of the =20 sensors framework (like we have with ifconfig for network cards), and =20 the driver writters doen't have to invent the wheel again and again =20 (like we have with cam or maybe in some way the NIC phys). What Poul-Henning is talking about looks to me like a presentation =20 layer, while I see the sensors framework (as far as I understand it) =20 as an infrastructure layer. If not, please be more verbose =20 Poul-Henning. It may be the case that the presentation layer needs =20 some more meta information about a sensor which maybe the driver has =20 to provide in some way, but without an infrastructure layer we don't =20 get to the presentation layer. Bye, Alexander. --=20 We may not return the affection of those who like us, but we always respect their good judgement. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 12:27:52 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 840B916A41F; Wed, 11 Jul 2007 12:27:52 +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 2204313C48A; Wed, 11 Jul 2007 12:27:52 +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 9913F173B4; Wed, 11 Jul 2007 12:27:50 +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 l6BCRnb7056439; Wed, 11 Jul 2007 12:27:50 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 13:49:59 +0200." <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> Date: Wed, 11 Jul 2007 12:27:49 +0000 Message-ID: <56438.1184156869@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 12:27:52 -0000 In message <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net>, Alexander Leidinger writes: >What Poul-Henning is talking about looks to me like a presentation >layer, while I see the sensors framework (as far as I understand it) >as an infrastructure layer. I think you will only confuse things by adopting the seven layer OSI mistake: the communications aspect of this is absolutely trivial. -- 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 Wed Jul 11 12:44:56 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F0C016A400; Wed, 11 Jul 2007 12:44:56 +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 D77B913C48A; Wed, 11 Jul 2007 12:44:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55763.dip.t-dialin.net [84.165.87.99]) by redbull.bpaserver.net (Postfix) with ESMTP id 8F83F2E29D; Wed, 11 Jul 2007 14:44:52 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3C2395B4902; Wed, 11 Jul 2007 14:42:41 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6BCgfJk086578; Wed, 11 Jul 2007 14:42:41 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 11 Jul 2007 14:42:40 +0200 Message-ID: <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 11 Jul 2007 14:42:40 +0200 From: Alexander Leidinger To: Poul-Henning Kamp References: <56438.1184156869@critter.freebsd.dk> In-Reply-To: <56438.1184156869@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 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=-12.8, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, IMPRONONCABLE_2 1.50, J_CHICKENPOX_27 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 12:44:56 -0000 Quoting Poul-Henning Kamp (from Wed, 11 Jul 2007 12:27:49 +0000): > In message <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net>, > Alexander Leidinger writes: > >> What Poul-Henning is talking about looks to me like a presentation >> layer, while I see the sensors framework (as far as I understand it) >> as an infrastructure layer. > > I think you will only confuse things by adopting the seven layer OSI > mistake: the communications aspect of this is absolutely trivial. I was not thinking about 7-layer-OSI, I was thinking about 3 layers: presentation, infrastructure and "low-level" data acquiring stuff (I prefer the pragmatic way of looking at things). Bye, Alexander. -- The wonderful thing about a dancing bear is not how well he dances, but that he dances at all. 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 Jul 11 13:54:43 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7E6D16A421; Wed, 11 Jul 2007 13:54:43 +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 A159913C44C; Wed, 11 Jul 2007 13:54:43 +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 C9D3A17380; Wed, 11 Jul 2007 13:54:41 +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 l6BDsexK056737; Wed, 11 Jul 2007 13:54:40 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 14:42:40 +0200." <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net> Date: Wed, 11 Jul 2007 13:54:40 +0000 Message-ID: <56736.1184162080@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 13:54:44 -0000 In message <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net>, Alexander Leidinger writes: >I was not thinking about 7-layer-OSI, I was thinking about 3 layers: >presentation, infrastructure and "low-level" data acquiring stuff (I >prefer the pragmatic way of looking at things). This again misses the point, because you assume a simple bottom-up architecture will work like it does for PCI devices. In this case however, the majority of systems need some piece of code to identify them, look up in a table (which we get from where ?) and configure the sensors. Sensor hardware is not context-free and selfidentifying like PCI and USB devices, in fact, it is about as far from PnP as you can get. Finding an LM75 and reading the temperature is worth next to nothing if you don't know where the LM75 is mounted. Reading an ADC is worth absolutely nothing, if you don't know what it measures and what voltage dividers are in front of it. Finding an I2C sensor and trying to read it is a catastrophe when it turns out not to be a sensor but the motherboard clock generator or voltage regulater. IFF we want to do something more comprehensive than the gaggle of ports, then we want to do it properly so that it doesn't weigh down the kernel with tons of, on average unused, junk, doesn't imperil hardware and delivers sensor readings which come with the necessary context to have a real physical meaning. Access to I2C busses and I/O registers should happen in the kernel, but maintaining a database of all sorts of weird systems should not. -- 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 Wed Jul 11 14:07:38 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A58516A469 for ; Wed, 11 Jul 2007 14:07:38 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id 14E5813C48A for ; Wed, 11 Jul 2007 14:07:38 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a1.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by sumo.dreamhost.com (Postfix) with ESMTP id E1412196AAF for ; Wed, 11 Jul 2007 06:50:04 -0700 (PDT) Received: from sauron.lan.box (200-180-186-51.paemt706.dsl.brasiltelecom.net.br [200.180.186.51]) by spunkymail-a1.g.dreamhost.com (Postfix) with ESMTP id 08298FE3AF for ; Wed, 11 Jul 2007 06:50:01 -0700 (PDT) Date: Wed, 11 Jul 2007 10:49:49 -0300 From: Ricardo Nabinger Sanchez To: freebsd-arch@freebsd.org Message-Id: <20070711104949.7cc844e9.rnsanchez@wait4.org> In-Reply-To: <4694AC5C.9040107@trzask.int.pl> References: <20070708081511.GX1221@funkthat.com> <200707101833.l6AIX0xl049962@ambrisko.com> <20070710.205751.-1962670861.imp@bsdimp.com> <4694AC5C.9040107@trzask.int.pl> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.11; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: new friend of sys/queue.h and sys/tree.h 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, 11 Jul 2007 14:07:38 -0000 On Wed, 11 Jul 2007 10:09:32 +0000 Pawel Wieczorek wrote: > Hash table are basic data structure, it is good to have it in kernel, > but i did not see some easy to use framework like sys/queue.h in our > kernel. >From what I understood, the actual implementation is based on lists (SLIST, specifically)? -- Ricardo Nabinger Sanchez rnsanchez@wait4.org Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 14:25:03 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3110F16A400 for ; Wed, 11 Jul 2007 14:25:03 +0000 (UTC) (envelope-from wieczyk@trzask.int.pl) Received: from trzask.int.pl (host-81-190-193-233.gizycko.mm.pl [81.190.193.233]) by mx1.freebsd.org (Postfix) with ESMTP id 952AC13C46E for ; Wed, 11 Jul 2007 14:25:02 +0000 (UTC) (envelope-from wieczyk@trzask.int.pl) Received: from [192.168.0.99] (unknown [192.168.0.99]) by trzask.int.pl (Postfix) with ESMTP id B9A721A436; Wed, 11 Jul 2007 18:25:13 +0200 (CEST) Message-ID: <4695048F.9020408@trzask.int.pl> Date: Wed, 11 Jul 2007 16:25:51 +0000 From: Pawel Wieczorek User-Agent: Thunderbird 2.0.0.0 (X11/20070529) MIME-Version: 1.0 To: Ricardo Nabinger Sanchez References: <20070708081511.GX1221@funkthat.com> <200707101833.l6AIX0xl049962@ambrisko.com> <20070710.205751.-1962670861.imp@bsdimp.com> <4694AC5C.9040107@trzask.int.pl> <20070711104949.7cc844e9.rnsanchez@wait4.org> In-Reply-To: <20070711104949.7cc844e9.rnsanchez@wait4.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: new friend of sys/queue.h and sys/tree.h 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, 11 Jul 2007 14:25:03 -0000 Ricardo Nabinger Sanchez wrote: > On Wed, 11 Jul 2007 10:09:32 +0000 > Pawel Wieczorek wrote: > >> Hash table are basic data structure, it is good to have it in kernel, >> but i did not see some easy to use framework like sys/queue.h in our >> kernel. > >>From what I understood, the actual implementation is based on lists > (SLIST, specifically)? > Yes, MAP is getting hash-number of key and selecting which list should be used. In this way we dont need to find for example one element in 1000 elements in list, but in 10 elements list. I used SLIST because it is done and tested, if i will did this self it will be lost time and do bigger probality to get bug. :) --- Selecting way is easy, if we have for example 14 lists, and hash number is 15 we are doing: INDEX = 15 mod 14 = 1 It is better to use prime numbers as dividers because the bits in result value are more changed. For example if you are dividing by power of 2 the bits are only shifted and it is bigger probability that more of items will be selected to have this same index. Sorry if my english is sometime too much complicated, i am not a expert of this language. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 17:04:33 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82B1816A421; Wed, 11 Jul 2007 17:04:33 +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 1E4C713C480; Wed, 11 Jul 2007 17:04:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55763.dip.t-dialin.net [84.165.87.99]) by redbull.bpaserver.net (Postfix) with ESMTP id AB1472E11E; Wed, 11 Jul 2007 19:04:25 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 62C295B4902; Wed, 11 Jul 2007 19:02:14 +0200 (CEST) Date: Wed, 11 Jul 2007 19:05:46 +0200 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20070711190546.4b202080@deskjail> In-Reply-To: <56736.1184162080@critter.freebsd.dk> References: <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net> <56736.1184162080@critter.freebsd.dk> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-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=3.2, required 8, BAYES_50 2.50, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: sss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 17:04:33 -0000 Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 13:54:40 +0000): > In message <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net>, Alexander Leidinger writes: > > >I was not thinking about 7-layer-OSI, I was thinking about 3 layers: > >presentation, infrastructure and "low-level" data acquiring stuff (I > >prefer the pragmatic way of looking at things). > > This again misses the point, because you assume a simple bottom-up > architecture will work like it does for PCI devices. > > In this case however, the majority of systems need some piece of code > to identify them, look up in a table (which we get from where ?) and > configure the sensors. > > Sensor hardware is not context-free and selfidentifying like PCI and > USB devices, in fact, it is about as far from PnP as you can get. > > Finding an LM75 and reading the temperature is worth next to nothing > if you don't know where the LM75 is mounted. > > Reading an ADC is worth absolutely nothing, if you don't know what > it measures and what voltage dividers are in front of it. > > Finding an I2C sensor and trying to read it is a catastrophe when > it turns out not to be a sensor but the motherboard clock generator > or voltage regulater. You are focusing on physical devices which are specially build as a sensor for some specific stuff. I put my focus on the kernel framework which allows to unify the handling of sensoric data from kernel devices. This is a difference. You are talking about stuff which really needs to be handled in userland. I talk about stuff like instrumenting cam to use the sensors framework to present interesting data of SCSI devices/enclosures/whatever in an unified way, about instrumenting gvinum/gmirror/graid/whatever to provide status information, ... You are talking about stuff which belongs into userland and which collects sensoric data which comes from either userland devices which reads temperature sensors like LM75 _and_ from e.g. the hw.sensors framework this thread is all about. The presentation layer which you talk about in my opinion when you talk about namespaces, would use several infrastructure layers in parallel, and the framework we are talking about would be one of those infrastructure frameworks. To me it sounds like we are talking about a bottum-up vs. a top-down approach. You need to get some information from existing kernel devices out of the kernel to feed it into "your sensors framework", and this GSoC project is about this. And it seems to me that you say we should start with the userland part and do the kernel part when we have everything done what can be done in userland. But this is not what the proposal was all about when we rated the GSoC projects. It may be the case that the use of the temperature sensor we've seen here for the testing of the framework is not a good idea because the temperature sensor reading code belongs into the userland, but I think for development purposes to get the framework integrated in a sane way without breaking other stuff, it is not bad. When the kernel framework works as intended, work can start to enhance existing drivers which can present some interesting data via this framework. I talk about data which can not and should not be collected by an userland program directly. I hope this clarifies my view of the things at hand. > IFF we want to do something more comprehensive than the gaggle of > ports, then we want to do it properly so that it doesn't weigh down > the kernel with tons of, on average unused, junk, doesn't imperil I agree. > hardware and delivers sensor readings which come with the necessary > context to have a real physical meaning. I'm sure the framework can be enhanced to deliver some meta-data from the driver where the data is collected to the userland. But before the framework can be extend I think it is important to get it up and running. And AFAIK getting it up and running is what this GSoC project is about. > Access to I2C busses and I/O registers should happen in the kernel, > but maintaining a database of all sorts of weird systems should not. I agree. The more important question ATM is probably: Do you or I or Robert, or whoever lurks and has an opinion have/has the right expectations about what this framework is about? Bye, Alexander. -- Isn't air travel wonderful? Breakfast in London, dinner in New York, luggage in Brazil. 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 Jul 11 17:33:55 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F05316A468; Wed, 11 Jul 2007 17:33:55 +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 DE15813C447; Wed, 11 Jul 2007 17:33:54 +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 E429817380; Wed, 11 Jul 2007 17:33: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 l6BHXpJx057628; Wed, 11 Jul 2007 17:33:51 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 11 Jul 2007 19:05:46 +0200." <20070711190546.4b202080@deskjail> Date: Wed, 11 Jul 2007 17:33:51 +0000 Message-ID: <57627.1184175231@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 17:33:55 -0000 In message <20070711190546.4b202080@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 13:54:40 +0000): >You are focusing on physical devices which are specially build as a >sensor for some specific stuff. I put my focus on the kernel framework >which allows to unify the handling of sensoric data from kernel >devices. I'm trying to point out that your kernel framework belongs in userland. There is no benefit from having it in the kernel. -- 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 Wed Jul 11 17:49:54 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91BD316A46F; Wed, 11 Jul 2007 17:49:54 +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 441C713C48C; Wed, 11 Jul 2007 17:49:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55763.dip.t-dialin.net [84.165.87.99]) by redbull.bpaserver.net (Postfix) with ESMTP id 00D4D2E1E1; Wed, 11 Jul 2007 19:49:48 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id B5DD15B4902; Wed, 11 Jul 2007 19:47:37 +0200 (CEST) Date: Wed, 11 Jul 2007 19:51:10 +0200 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20070711195110.48820aff@deskjail> In-Reply-To: <57627.1184175231@critter.freebsd.dk> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-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.3, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 17:49:54 -0000 Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 17:33:51 +0000): > In message <20070711190546.4b202080@deskjail>, Alexander Leidinger writes: > >Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 13:54:40 +0000): > > >You are focusing on physical devices which are specially build as a > >sensor for some specific stuff. I put my focus on the kernel framework > >which allows to unify the handling of sensoric data from kernel > >devices. > > I'm trying to point out that your kernel framework belongs in userland. It's not my framework. > There is no benefit from having it in the kernel. You need to get some information out of the kernel somehow (you cut this part of my mail). And as far as I understand the high level description (presentation in the net) of this framework, this does this in an unified way. Do you propose to get the information out of the kernel in a non-uniform way? Bye, Alexander. -- Interchangeable parts --- won't. 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 Jul 11 17:53:25 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF43216A468; Wed, 11 Jul 2007 17:53:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D6E5213C468; Wed, 11 Jul 2007 17:53:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AE8491A4DA5; Wed, 11 Jul 2007 10:53:25 -0700 (PDT) Date: Wed, 11 Jul 2007 10:53:25 -0700 From: Alfred Perlstein To: Alexander Leidinger Message-ID: <20070711175325.GQ45894@elvis.mu.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711195110.48820aff@deskjail> User-Agent: Mutt/1.4.2.3i Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 17:53:26 -0000 * Alexander Leidinger [070711 10:49] wrote: > Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 17:33:51 +0000): > > > In message <20070711190546.4b202080@deskjail>, Alexander Leidinger writes: > > >Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 13:54:40 +0000): > > > > >You are focusing on physical devices which are specially build as a > > >sensor for some specific stuff. I put my focus on the kernel framework > > >which allows to unify the handling of sensoric data from kernel > > >devices. > > > > I'm trying to point out that your kernel framework belongs in userland. > > It's not my framework. > > > There is no benefit from having it in the kernel. > > You need to get some information out of the kernel somehow (you cut > this part of my mail). And as far as I understand the high level > description (presentation in the net) of this framework, this does this > in an unified way. Do you propose to get the information out of the > kernel in a non-uniform way? Possibly, one way to do that is to provide a well thought out userland library that can make for a nice interface. If by doing it userland the kernel implementation can be kept smaller and more simple it might be a win. That said, it may be a loss if you wind up having to duplicate work over and over for different devices it may be a loss. Remember, once the kernel interface is exposed it has to be there almost forever, while a userland interface and much more easily be adapted. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 17:53:29 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D568016A468; Wed, 11 Jul 2007 17:53:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id A50ED13C459; Wed, 11 Jul 2007 17:53:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I8gBC-0009s4-3u; Wed, 11 Jul 2007 13:40:46 -0400 Date: Wed, 11 Jul 2007 13:40:46 -0400 From: Gary Palmer To: Poul-Henning Kamp Message-ID: <20070711174046.GB91325@in-addr.com> Mail-Followup-To: Poul-Henning Kamp , Robert Watson , Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, "Constantine A. Murenin" References: <20070711115332.I67691@fledge.watson.org> <56223.1184152780@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56223.1184152780@critter.freebsd.dk> Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 17:53:29 -0000 On Wed, Jul 11, 2007 at 11:19:40AM +0000, Poul-Henning Kamp wrote: > In message <20070711115332.I67691@fledge.watson.org>, Robert Watson writes: > >On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > > > >So it sounds like it would be useful for Constantine to help flesh out a few > >pieces of understanding: > > Add to this: > > - Is it possible to correctly identify the hardware platform, so that we know > where to find the sensors and know what they measure, without bloating the > kernel with a lot of tables. Why would the tables have to be in the kernel? Even if they are in the kernel, what is stopping something loading the correct table on boot based on some userland tool run out of /etc/rc.d? I'm also not sure what the benefit to having the tables in the kernel would be. A userland tool which watches the data from the sensors (however they are presented, whether it is a sysctl MIB or data passed via RFC 1149) and acts appropriately would appear to be a more flexible solution (ala devd) From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:04:31 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9620816A400; Wed, 11 Jul 2007 18:04:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4C85713C484; Wed, 11 Jul 2007 18:04:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BD75B47B88; Wed, 11 Jul 2007 14:04:30 -0400 (EDT) Date: Wed, 11 Jul 2007 19:04:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20070711175325.GQ45894@elvis.mu.org> Message-ID: <20070711185530.R68820@fledge.watson.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711175325.GQ45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , freebsd-arch@FreeBSD.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 18:04:31 -0000 On Wed, 11 Jul 2007, Alfred Perlstein wrote: >>> I'm trying to point out that your kernel framework belongs in userland. >> >> It's not my framework. >> >>> There is no benefit from having it in the kernel. >> >> You need to get some information out of the kernel somehow (you cut this >> part of my mail). And as far as I understand the high level description >> (presentation in the net) of this framework, this does this in an unified >> way. Do you propose to get the information out of the kernel in a >> non-uniform way? > > Possibly, one way to do that is to provide a well thought out userland > library that can make for a nice interface. If by doing it userland the > kernel implementation can be kept smaller and more simple it might be a win. > > That said, it may be a loss if you wind up having to duplicate work over and > over for different devices it may be a loss. > > Remember, once the kernel interface is exposed it has to be there almost > forever, while a userland interface and much more easily be adapted. The flip side of the user/kernel, of course, is that userland implementations may require more privilege to invoke than kernel implementations, since they may need to frob with /dev/pci, /dev/mem, etc, rather than accessing a very narrow sysctl interface using essentially unprivileged access. Compare, for example, the old ps(1) which required root or kmem privilege in order to be able to grope through kernel memory, and the new ps(1) that uses a set of controlled APIs that not only let it run as any user, but also scope the process information exposed by requesting process. However, the point I think that you specifically are making is that if we define a user API to access the information, then the implementation can be flexible, and what we really want to know is how applications will interact with the data. I think this is precisely the right point -- what we should not do is lock ourselves into a particular sysctl representation of the data and approach, which has happened to quite a few of our monitoring interfaces and makes it quite hard to abstract things, change the implementation, etc. Consider directly accessing sysctls (as done in most of netstat) and the slightly more abstract libkvm interfaces, which allow you to access information as data and hide the method (allowing the method to be /dev/kmem, sysctls, coredumps, etc). Since Constantine already has monitoring tools from the OpenBSD side, he can probably say a bit more about what their requirements are. I suspect right now they are pretty thin wrappers since the data processing happens before it goes out the sysctl interface...? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:14:21 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F9D216A400; Wed, 11 Jul 2007 18:14:21 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 176D813C455; Wed, 11 Jul 2007 18:14:21 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id ED5BB1A4DAA; Wed, 11 Jul 2007 11:14:20 -0700 (PDT) Date: Wed, 11 Jul 2007 11:14:20 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070711181420.GS45894@elvis.mu.org> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711175325.GQ45894@elvis.mu.org> <20070711185530.R68820@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711185530.R68820@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , freebsd-arch@FreeBSD.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 18:14:21 -0000 * Robert Watson [070711 11:05] wrote: > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > > >Possibly, one way to do that is to provide a well thought out userland > >library that can make for a nice interface. If by doing it userland the > >kernel implementation can be kept smaller and more simple it might be a > >win. > > > >That said, it may be a loss if you wind up having to duplicate work over > >and over for different devices it may be a loss. > > > >Remember, once the kernel interface is exposed it has to be there almost > >forever, while a userland interface and much more easily be adapted. > > The flip side of the user/kernel, of course, is that userland > implementations may require more privilege to invoke than kernel > implementations, since they may need to frob with /dev/pci, /dev/mem, etc, > rather than accessing a very narrow sysctl interface using essentially > unprivileged access. Compare, for example, the old ps(1) which required > root or kmem privilege in order to be able to grope through kernel memory, > and the new ps(1) that uses a set of controlled APIs that not only let it > run as any user, but also scope the process information exposed by > requesting process. > > However, the point I think that you specifically are making is that if we > define a user API to access the information, then the implementation can be > flexible, and what we really want to know is how applications will interact > with the data. I think this is precisely the right point -- what we should > not do is lock ourselves into a particular sysctl representation of the > data and approach, which has happened to quite a few of our monitoring > interfaces and makes it quite hard to abstract things, change the > implementation, etc. Consider directly accessing sysctls (as done in most > of netstat) and the slightly more abstract libkvm interfaces, which allow > you to access information as data and hide the method (allowing the method > to be /dev/kmem, sysctls, coredumps, etc). Yes, this was the point I was trying to put across, well said. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:29:53 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 442F016A46B for ; Wed, 11 Jul 2007 18:29:53 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id DFA0A13C465 for ; Wed, 11 Jul 2007 18:29:52 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 11 Jul 2007 18:03:11 -0000 Date: Wed, 11 Jul 2007 21:03:10 +0300 From: Nikolay Pavlov To: Alexander Leidinger Message-ID: <20070711180310.GA33283@zone3000.net> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711195110.48820aff@deskjail> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 18:29:53 -0000 On Wednesday, 11 July 2007 at 19:51:10 +0200, Alexander Leidinger wrote: > Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 17:33:51 +0000): > > > In message <20070711190546.4b202080@deskjail>, Alexander Leidinger writes: > > >Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 13:54:40 +0000): > > > > >You are focusing on physical devices which are specially build as a > > >sensor for some specific stuff. I put my focus on the kernel framework > > >which allows to unify the handling of sensoric data from kernel > > >devices. > > > > I'm trying to point out that your kernel framework belongs in userland. > > It's not my framework. > > > There is no benefit from having it in the kernel. > > You need to get some information out of the kernel somehow (you cut > this part of my mail). And as far as I understand the high level > description (presentation in the net) of this framework, this does this > in an unified way. Do you propose to get the information out of the > kernel in a non-uniform way? I think he wants to say that you could have a broader look at this problem. Placing the code into kernel is not a necessary requriemet here to create a unified framework. It can be done much easier in the user environment. Or don't you forget a mocrokernel approach? -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:42:43 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9DA616A47B; Wed, 11 Jul 2007 18:42:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2B07B13C4E3; Wed, 11 Jul 2007 18:42:43 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l6BIgemH086193; Wed, 11 Jul 2007 14:42:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 11 Jul 2007 11:45:26 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org> <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> In-Reply-To: <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707111145.27741.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, 11 Jul 2007 14:42:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3637/Wed Jul 11 12:27:26 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: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 11 Jul 2007 18:42:43 -0000 On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > Quoting Robert Watson (from Wed, 11 Jul 2007 > 11:12:24 +0100 (BST)): > > > On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > > > >> In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: > >> > >>> If you want to have no such framework that could potentially > >>> diagnose or predict system failure, it's your choice, [...] > >> > >> I would love to have that, but the OpenBSD code isn't that. > > > > In the general spirit of SoC, I would suggest that a more constructive > > line of commenting might come with suggestions, not just rejections > > :-). Are you arguing that the current proposed framework offers little > > incremental benefit over simply having the sysctl framework in the > > first place and having each source of information (i.e., device driver) > > just export it directly? > > > > It seems clear that people would like all these measurements to be > > available, even if not by the precise mechanism proposed. So far the > > specific technical criticals have been: > > > > - There's such a diversity of motherboard devices and probe mechanisms that > > any kernel driver would become rapidly over-burdened and needlessly > > complicated. > > > > This doesn't argue for doing nothing, just that perhaps a kernel device > > driver is the wrong place. > > On the other hand you don't want to allow an userland tool to directly > mess around with the registers on your RAID or NIC to get some status... Err, that's how all the RAID utilities I've used work. They send firmware commands from userland and parse the replies in userland. One exception I've seen so far is that for software RAID the firmware you are talking to is the driver, not firmware on the card, so you use ioctls directly rather than an ioctl that sends a command to the firmware on the card. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:50:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DA9716A46B for ; Wed, 11 Jul 2007 18:50:40 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id CEBAC13C468 for ; Wed, 11 Jul 2007 18:50:39 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (h2g4qodhkru1tcf0@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6BIobh0051318; Wed, 11 Jul 2007 11:50:37 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6BIoZ4W051317; Wed, 11 Jul 2007 11:50:35 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jul 2007 11:50:34 -0700 From: John-Mark Gurney To: Pawel Wieczorek Message-ID: <20070711185034.GG1221@funkthat.com> Mail-Followup-To: Pawel Wieczorek , freebsd-arch@freebsd.org References: <20070708081511.GX1221@funkthat.com> <200707101833.l6AIX0xl049962@ambrisko.com> <20070710.205751.-1962670861.imp@bsdimp.com> <4694AC5C.9040107@trzask.int.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4694AC5C.9040107@trzask.int.pl> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-arch@freebsd.org Subject: Re: new friend of sys/queue.h and sys/tree.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 18:50:40 -0000 Pawel Wieczorek wrote this message on Wed, Jul 11, 2007 at 10:09 +0000: > Hash table are basic data structure, it is good to have it in kernel, > but i did not see some easy to use framework like sys/queue.h in our kernel. > > At current time it have only hash table and multi-value hash table, > but i want to add in near future something else. Why not flesh out hashinit(9) and friends? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 18:57:28 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EF1C16A41F; Wed, 11 Jul 2007 18:57:28 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id A7B5713C45B; Wed, 11 Jul 2007 18:57:27 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (npjo3c49hd1whw7x@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6BIvO8P051480; Wed, 11 Jul 2007 11:57:24 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6BIvJcR051479; Wed, 11 Jul 2007 11:57:19 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jul 2007 11:57:19 -0700 From: John-Mark Gurney To: Alexander Leidinger Message-ID: <20070711185718.GH1221@funkthat.com> Mail-Followup-To: Alexander Leidinger , Poul-Henning Kamp , Rui Paulo , Shteryana Shopova , freebsd-arch@FreeBSD.org, Robert Watson , "Constantine A. Murenin" References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711195110.48820aff@deskjail> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 18:57:28 -0000 Alexander Leidinger wrote this message on Wed, Jul 11, 2007 at 19:51 +0200: > Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 17:33:51 +0000): > > There is no benefit from having it in the kernel. > > You need to get some information out of the kernel somehow (you cut > this part of my mail). And as far as I understand the high level > description (presentation in the net) of this framework, this does this > in an unified way. Do you propose to get the information out of the > kernel in a non-uniform way? No you don't. The kernel is just another "transport" layer so to say.. We are proposing a unified way via a userland front end... The userland library knows and can adapt to different ways of extracting the data.. If you hard code the kernel interface, when someone comes along and wants to write a complicated sensor in userland, he will then need to hack a "kernel frontend" to take his userland generated data, shove it into the kernel, just for another userland app to pull the data out.. I've thought about making a userland cdev interface so that we can emulate "v4l" in userland... If the v4l was a userland interface, I wouldn't need to add such a hack to the kernel.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 19:07:52 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7410216A494; Wed, 11 Jul 2007 19:07:52 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2FCC813C468; Wed, 11 Jul 2007 19:07:52 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (k5zrgw2yb6x95bvf@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6BJ7k9k051645; Wed, 11 Jul 2007 12:07:46 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6BJ7jLp051643; Wed, 11 Jul 2007 12:07:45 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jul 2007 12:07:45 -0700 From: John-Mark Gurney To: "Constantine A. Murenin" Message-ID: <20070711190745.GI1221@funkthat.com> Mail-Followup-To: "Constantine A. Murenin" , Poul-Henning Kamp , Rui Paulo , Shteryana Shopova , Robert Watson , freebsd-arch@FreeBSD.org References: <53705.1184107078@critter.freebsd.dk> <469420B9.20401@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469420B9.20401@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Rui Paulo , Poul-Henning Kamp , Robert Watson , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 19:07:52 -0000 Constantine A. Murenin wrote this message on Tue, Jul 10, 2007 at 20:13 -0400: > If you want to have no such framework that could potentially diagnose or > predict system failure, it's your choice, and I'm not going to argue > against it. However, there are many people who desire to have this > feature in an operating system, and these people include FreeBSD users > and developers. No one is saying that we don't want a framekwork to provide this information... We want to put the framework in the proper place that will be the most maintainable, testable and extensible location possible: userland... A single bug in the kernel framework and associated drivers could take the entire system down... The worse a userland app can do is core dump... Having recently written an HDTV driver... It was a god-send to have the tuner logic and related items in userland, and only use the kernel part as a bit mover.. It made testing very quick, and will enable people to develope additional tuners w/o having to go through crashing their machine as they load/unload drivers that contain bugs.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 20:24:19 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9346A16A468 for ; Wed, 11 Jul 2007 20:24:19 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 59B4D13C46E for ; Wed, 11 Jul 2007 20:24:19 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6BKQ9SY007696 for ; Wed, 11 Jul 2007 15:26:09 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Wed, 11 Jul 2007 15:24:01 -0500 (CDT) From: "Sean C. Farley" To: freebsd-arch@FreeBSD.org Message-ID: <20070711134721.D2385@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: Subject: Assembly string functions in i386 libc 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, 11 Jul 2007 20:24:19 -0000 While looking at increasing the speed of strlen(), I noticed that on i386 platforms (PIII, P4 and Athlon XP) the performance is abysmal in libc compared to the version I was writing. After more testing, I found it was only the assembly version that is really slow. The C version is fairly quick. Is there a need to continue to use the assembly versions of string functions on i386? Does it mainly help slower systems such as those with i386 or i486 CPU's? I have the results from my P4 (Id = 0xf24 Stepping = 4) system and the test program here[1]. strlen.tar.bz2 is the archive of it for anyone's testing. In the strlen/results subdirectory, there are the results for strings of increasing lengths. I would appreciate it if anyone could see if strlen and strlen2 perform any better on an amd64. Although the current C version of strlen() in 7-CURRENT is faster than mine for smaller values, they perform better for larger strings. I doubt people would want either of my versions in CURRENT just before the freeze :), but it would be nice to use the C version we do have instead of the assembly version. I cannot speak about the other string functions as I have not tested them. Sean 1. http://www.farley.org/freebsd/tmp/ -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 21:02:23 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE31F16A46D for ; Wed, 11 Jul 2007 21:02:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 6B27E13C4B9 for ; Wed, 11 Jul 2007 21:02:23 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A0CDE8BFB22; Wed, 11 Jul 2007 22:43:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T466EK+DkWJN; Wed, 11 Jul 2007 22:43:16 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5CA928BF8A4; Wed, 11 Jul 2007 22:43:16 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l6BKhGu9049748; Wed, 11 Jul 2007 22:43:16 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 11 Jul 2007 22:43:16 +0200 From: Roman Divacky To: "Sean C. Farley" Message-ID: <20070711204315.GA49688@freebsd.org> References: <20070711134721.D2385@thor.farley.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711134721.D2385@thor.farley.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 21:02:23 -0000 On Wed, Jul 11, 2007 at 03:24:01PM -0500, Sean C. Farley wrote: > While looking at increasing the speed of strlen(), I noticed that on > i386 platforms (PIII, P4 and Athlon XP) the performance is abysmal in > libc compared to the version I was writing. After more testing, I found > it was only the assembly version that is really slow. The C version is > fairly quick. Is there a need to continue to use the assembly versions > of string functions on i386? Does it mainly help slower systems such as > those with i386 or i486 CPU's? > > I have the results from my P4 (Id = 0xf24 Stepping = 4) system and the > test program here[1]. strlen.tar.bz2 is the archive of it for anyone's > testing. In the strlen/results subdirectory, there are the results for > strings of increasing lengths. just to state facts... glibc 2.3.6 uses almost exactly the same asm code for i386 (cld;repn[ez] scasb) From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 22:13:41 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0307E16A41F for ; Wed, 11 Jul 2007 22:13:41 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 2E38113C44B for ; Wed, 11 Jul 2007 22:13:39 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l6BMDc0H032248; Thu, 12 Jul 2007 08:13:38 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l6BMDcPL032247; Thu, 12 Jul 2007 08:13:38 +1000 (EST) (envelope-from peter) Date: Thu, 12 Jul 2007 08:13:38 +1000 From: Peter Jeremy To: "Sean C. Farley" Message-ID: <20070711221338.GC20178@turion.vk2pj.dyndns.org> References: <20070711134721.D2385@thor.farley.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: <20070711134721.D2385@thor.farley.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@freebsd.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 22:13:41 -0000 --dkEUBIird37B8yKS Content-Type: multipart/mixed; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-11 15:24:01 -0500, "Sean C. Farley" wrote: >libc compared to the version I was writing. After more testing, I found >it was only the assembly version that is really slow. The C version is >fairly quick. Is there a need to continue to use the assembly versions >of string functions on i386? Does it mainly help slower systems such as >those with i386 or i486 CPU's? The performance of string instructions has varied wildly across various x86 implementations. Definitely, for short strings, the overhead in initialising the various registers outweighs any actual difference in loop performance. For any recent CPU, the location of the string in the memory hierarchy far outweighs implementation issues. bde@ has done various testing in the last and posted results. Some comments: - comparing the strlen() in a shared libc with a statically linked one is unfair - especially on the i386. - Your results don't include non-aligned inputs - Your results don't include non-power-of-2 lengths >I would appreciate it if anyone could see if strlen and strlen2 perform >any better on an amd64. Although the current C version of strlen() in >7-CURRENT is faster than mine for smaller values, they perform better >for larger strings. I've tested on: FreeBSD 6.2-STABLE #28: Fri Jun 22 11:44:13 EST 2007 root@turion.vk2pj.dyndns.org:/usr/obj/usr/src/sys/turion CPU: AMD Turion(tm) 64 Mobile ML-40 (2194.52-MHz K8-class = CPU) Origin =3D "AuthenticAMD" Id =3D 0x20f42 Stepping =3D 2 Features=3D0x78bfbff Features2=3D0x1 AMD Features=3D0xe2500800 AMD Features2=3D0x1 There is no asm strlen so libcstrlen and basestrlen should be identical (and disassembling [x]strlen() shows that the code _is_ identical) but there are significant differences for short strings and measurable differences for all lengths except 32 bytes. This indicates that your program is not able to accurately compare strlen() performance. I've tried statically linking all the test programs and this removes the libcstrlen/basestrlen differences. The very poor results for 4 and 8 byte strings are unexpected but (as expected), your unrolled strlen() implementations behave better for longer strings. The attached results all reflect your code with '-static' added to every gcc/link step. --=20 Peter Jeremy --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.01" x libcstrlen.01 + basestrlen.01 * strlen.01 % strlen2.01 +--------------------------------------------------------------------------+ | % | | * * % | | * * % | | ** *x %% | |* ** * * ** + % %%%+# x +| ||____M_A______| ||______M______AA_________|_A|__| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.056836 0.076297 0.0571435 0.0600979 0.0065785842 + 10 0.056941 0.079997 0.0571135 0.0605826 0.0075392895 No difference proven at 95.0% confidence * 10 0.045764 0.057498 0.047954 0.0489822 0.0031965751 Difference at 95.0% confidence -0.0111157 +/- 0.00485944 -18.496% +/- 8.08587% (Student's t, pooled s = 0.00517184) % 10 0.0642 0.067644 0.0662535 0.0662219 0.00087897572 Difference at 95.0% confidence 0.006124 +/- 0.00440962 10.19% +/- 7.33739% (Student's t, pooled s = 0.0046931) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.02" x libcstrlen.02 + basestrlen.02 * strlen.02 % strlen2.02 +--------------------------------------------------------------------------+ | % | | % | | * * % | | ** *x %% | | * *** * +*xx + * x %% % % * %| ||_________M____|_A_|MA|A______|___| |___M__A_____| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.06611 0.076365 0.0663895 0.0673789 0.0031655271 + 10 0.065865 0.068425 0.0662385 0.0664137 0.00072301053 No difference proven at 95.0% confidence * 10 0.059657 0.08414 0.06171 0.0648375 0.0073763495 No difference proven at 95.0% confidence % 10 0.079855 0.089286 0.0801355 0.0812853 0.0029096056 Difference at 95.0% confidence 0.0139064 +/- 0.00285662 20.6391% +/- 4.23963% (Student's t, pooled s = 0.00304026) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.04" x libcstrlen.04 + basestrlen.04 * strlen.04 % strlen2.04 +--------------------------------------------------------------------------+ | * * % | | * * % | | * * * % % | | x ****x +***** + % %%% + % %| ||____|MM|____|A_|___________| |______M___A__________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.082714 0.086885 0.08454 0.0848665 0.0011530442 + 10 0.084376 0.113232 0.0852015 0.0900253 0.0098820415 No difference proven at 95.0% confidence * 10 0.089334 0.091925 0.089935 0.090297 0.00094932268 Difference at 95.0% confidence 0.0054305 +/- 0.000992314 6.39887% +/- 1.16926% (Student's t, pooled s = 0.00105611) % 10 0.105559 0.131599 0.1080435 0.1111049 0.0078954972 Difference at 95.0% confidence 0.0262384 +/- 0.00530137 30.9173% +/- 6.24671% (Student's t, pooled s = 0.00564218) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.08" x libcstrlen.08 + basestrlen.08 * strlen.08 % strlen2.08 +--------------------------------------------------------------------------+ | ** % * | | ** %%% % ** * | | +** +x +x %%%% % *** * *| ||__MM_A____| |_MA__| |__M_A_____| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.121139 0.146324 0.1226245 0.125436 0.0079127939 + 10 0.12069 0.145306 0.1219265 0.1250433 0.0076468179 No difference proven at 95.0% confidence * 10 0.194276 0.218771 0.1965875 0.1998421 0.0075342985 Difference at 95.0% confidence 0.0744061 +/- 0.00725919 59.318% +/- 5.78717% (Student's t, pooled s = 0.00772586) % 10 0.162464 0.173597 0.164107 0.1656017 0.0041219019 Difference at 95.0% confidence 0.0401657 +/- 0.00592774 32.0209% +/- 4.72571% (Student's t, pooled s = 0.00630882) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.16" x libcstrlen.16 + basestrlen.16 * strlen.16 % strlen2.16 +--------------------------------------------------------------------------+ | % | | % | | % * * | | %% ** x*+ + | | %% %% % *** * * * * x*++ x*+ x *| ||_M__A____| |__M_A_____| ||M_M_A____|| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.267459 0.292087 0.2683745 0.2740531 0.0087043756 + 10 0.267893 0.292362 0.2707545 0.2747774 0.0078299701 No difference proven at 95.0% confidence * 10 0.212733 0.236073 0.2156615 0.2196616 0.007802558 Difference at 95.0% confidence -0.0543915 +/- 0.00776649 -19.8471% +/- 2.83394% (Student's t, pooled s = 0.00826577) % 10 0.185465 0.208264 0.186767 0.1902279 0.0071633648 Difference at 95.0% confidence -0.0838252 +/- 0.0074897 -30.5872% +/- 2.73294% (Student's t, pooled s = 0.0079712) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.32" x libcstrlen.32 + basestrlen.32 * strlen.32 % strlen2.32 +--------------------------------------------------------------------------+ | % * | | % * * x + + | | % % % * * xx ++ + | |%%% % % * ** * * +xx+** * xx| ||M_A__| |__A__| |__|MA_|_| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.414594 0.45129 0.4222915 0.4275801 0.014180339 + 10 0.412549 0.438513 0.426586 0.4282437 0.0078657702 No difference proven at 95.0% confidence * 10 0.249627 0.276534 0.260869 0.2597264 0.0093742772 Difference at 95.0% confidence -0.167854 +/- 0.0112939 -39.2567% +/- 2.64135% (Student's t, pooled s = 0.01202) % 10 0.212447 0.236769 0.2154385 0.2202512 0.0093600922 Difference at 95.0% confidence -0.207329 +/- 0.0112887 -48.4889% +/- 2.64014% (Student's t, pooled s = 0.0120144) --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.64" x libcstrlen.64 + basestrlen.64 * strlen.64 % strlen2.64 +--------------------------------------------------------------------------+ |% ** | |% % ** | |%%% ** +**+ x| |%%% % ** * ******| ||A| |A| ||A_| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 0.709884 0.744587 0.7251365 0.7276627 0.011059351 + 10 0.711416 0.742595 0.723867 0.7256684 0.010705189 No difference proven at 95.0% confidence * 10 0.324096 0.345875 0.330732 0.33092 0.0067527522 Difference at 95.0% confidence -0.396743 +/- 0.0086092 -54.5229% +/- 1.18313% (Student's t, pooled s = 0.00916267) % 10 0.267484 0.290712 0.273968 0.2746264 0.0073885214 Difference at 95.0% confidence -0.453036 +/- 0.00883668 -62.2591% +/- 1.21439% (Student's t, pooled s = 0.00940477) --FkmkrVfFsRoUs1wW-- --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlVYS/opHv/APuIcRAqoBAKCzXMdchhSIPMG45ppHii3kW6Kv7ACgv7E2 iM1384/vPqaZSmdHun+3iJg= =ET/D -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 22:31:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0747516A46D; Wed, 11 Jul 2007 22:31:40 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id C9B8A13C44B; Wed, 11 Jul 2007 22:31:39 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l6BML7tQ062858; Wed, 11 Jul 2007 15:21:07 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l6BML722062857; Wed, 11 Jul 2007 15:21:07 -0700 (PDT) Date: Wed, 11 Jul 2007 15:21:07 -0700 (PDT) From: Matthew Dillon Message-Id: <200707112221.l6BML722062857@apollo.backplane.com> To: Peter Jeremy References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> Cc: "Sean C. Farley" , freebsd-arch@freebsd.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 22:31:40 -0000 Long ago I decided that strlen() was simply not in the critical path for virtually any program. A few nanoseconds here or there is not going to result in any noticeable improvement for any program other then a benchmark designed to test strlen(). It isn't worth the effort to optimize. -Matt From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 23:43:19 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF9B016A400 for ; Wed, 11 Jul 2007 23:43:19 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id A499B13C459 for ; Wed, 11 Jul 2007 23:43:19 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6BNj8CB010685; Wed, 11 Jul 2007 18:45:08 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Wed, 11 Jul 2007 18:43:00 -0500 (CDT) From: "Sean C. Farley" To: Matthew Dillon In-Reply-To: <200707112221.l6BML722062857@apollo.backplane.com> Message-ID: <20070711183217.C2385@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 23:43:20 -0000 On Wed, 11 Jul 2007, Matthew Dillon wrote: > Long ago I decided that strlen() was simply not in the critical > path for virtually any program. A few nanoseconds here or there is > not going to result in any noticeable improvement for any program > other then a benchmark designed to test strlen(). It isn't worth > the effort to optimize. Since strlen() is used in every program directly or indirectly through libc, I thought it was beneficial to make it faster. In the case of i386, the C version used by all the other architectures, except for ARM, is much faster that the assembly version. This is without any optimization on its part. I need to test out grep (FreeGrep) to see how it behaves when calling regexec() (may use strlen() in certain cases) many times (i.e., grep -R on the source tree) using both versions. Sean -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 23:46:30 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53A0216A400 for ; Wed, 11 Jul 2007 23:46:30 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0149513C484 for ; Wed, 11 Jul 2007 23:46:29 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6BNmJqD010761; Wed, 11 Jul 2007 18:48:19 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Wed, 11 Jul 2007 18:46:11 -0500 (CDT) From: "Sean C. Farley" To: Peter Jeremy In-Reply-To: <20070711221338.GC20178@turion.vk2pj.dyndns.org> Message-ID: <20070711171829.Y2385@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 23:46:30 -0000 On Thu, 12 Jul 2007, Peter Jeremy wrote: > On 2007-Jul-11 15:24:01 -0500, "Sean C. Farley" wrote: >> libc compared to the version I was writing. After more testing, I >> found it was only the assembly version that is really slow. The C >> version is fairly quick. Is there a need to continue to use the >> assembly versions of string functions on i386? Does it mainly help >> slower systems such as those with i386 or i486 CPU's? > > The performance of string instructions has varied wildly across > various x86 implementations. Definitely, for short strings, the > overhead in initialising the various registers outweighs any actual > difference in loop performance. For any recent CPU, the location of > the string in the memory hierarchy far outweighs implementation > issues. bde@ has done various testing in the last and posted results. > > Some comments: > - comparing the strlen() in a shared libc with a statically linked one > is unfair - especially on the i386. I had been testing with strlen.S linked into the test program, but the results were the same (at least for me) as linking against libc. > - Your results don't include non-aligned inputs I ran the test again but skipping to the next byte in a given string. They are in a results-non-aligned directory. The string given to the program was always one byte bigger than before to allow the results to match up between aligned and non-aligned. > - Your results don't include non-power-of-2 lengths I have tested values of various lengths. The Makefile in the main directory shows other values I have tried. I can output some more outputs including the assembly file compiled directly into the program. >> I would appreciate it if anyone could see if strlen and strlen2 >> perform any better on an amd64. Although the current C version of >> strlen() in 7-CURRENT is faster than mine for smaller values, they >> perform better for larger strings. > > I've tested on: > FreeBSD 6.2-STABLE #28: Fri Jun 22 11:44:13 EST 2007 > root@turion.vk2pj.dyndns.org:/usr/obj/usr/src/sys/turion > CPU: AMD Turion(tm) 64 Mobile ML-40 (2194.52-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 > Features=0x78bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x1 > > There is no asm strlen so libcstrlen and basestrlen should be > identical (and disassembling [x]strlen() shows that the code _is_ > identical) but there are significant differences for short strings and > measurable differences for all lengths except 32 bytes. This > indicates that your program is not able to accurately compare strlen() > performance. I am not sure I understand. The 32-byte test results show a measurable difference in your output and mine. I just switched the program to use getrusage() from gettimeofday. This should show more accurate results for 32 bytes and the 4- and 8-byte tests below. > I've tried statically linking all the test programs and this removes > the libcstrlen/basestrlen differences. The very poor results for 4 > and 8 byte strings are unexpected but (as expected), your unrolled > strlen() implementations behave better for longer strings. > > The attached results all reflect your code with '-static' added to > every gcc/link step. I redid my tests with everything compiled statically. Also, getrusage() was used instead of gettimeofday(). Sean -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jul 11 23:51:23 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 953AD16A400; Wed, 11 Jul 2007 23:51:23 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 17E7813C45A; Wed, 11 Jul 2007 23:51:23 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l6BNpMes063848; Wed, 11 Jul 2007 16:51:22 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l6BNpMUN063847; Wed, 11 Jul 2007 16:51:22 -0700 (PDT) Date: Wed, 11 Jul 2007 16:51:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200707112351.l6BNpMUN063847@apollo.backplane.com> To: "Sean C. Farley" References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 11 Jul 2007 23:51:23 -0000 :Since strlen() is used in every program directly or indirectly through :libc, I thought it was beneficial to make it faster. In the case of :i386, the C version used by all the other architectures, except for ARM, :is much faster that the assembly version. This is without any :optimization on its part. : :I need to test out grep (FreeGrep) to see how it behaves when calling :regexec() (may use strlen() in certain cases) many times (i.e., grep -R :on the source tree) using both versions. : :Sean :-- :scf@FreeBSD.org Yes, but there's a difference between using strlen() a couple of times in the program and using it in a core processing loop or other high-performance element of the program. And even if it is used in such places it isn't going to be used so often that the program would actually benefit from the few nanoseconds of improvement you might get from it. The chances of that are nearly zero. -Matt From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 04:19:49 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 933EC16A400 for ; Thu, 12 Jul 2007 04:19:49 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 458E613C45B for ; Thu, 12 Jul 2007 04:19:49 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6C4LcE5014404; Wed, 11 Jul 2007 23:21:38 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Wed, 11 Jul 2007 23:19:30 -0500 (CDT) From: "Sean C. Farley" To: Matthew Dillon In-Reply-To: <200707112351.l6BNpMUN063847@apollo.backplane.com> Message-ID: <20070711231412.K4613@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <200707112351.l6BNpMUN063847@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 04:19:49 -0000 On Wed, 11 Jul 2007, Matthew Dillon wrote: > :Since strlen() is used in every program directly or indirectly through > :libc, I thought it was beneficial to make it faster. In the case of > :i386, the C version used by all the other architectures, except for ARM, > :is much faster that the assembly version. This is without any > :optimization on its part. > : > :I need to test out grep (FreeGrep) to see how it behaves when calling > :regexec() (may use strlen() in certain cases) many times (i.e., grep -R > :on the source tree) using both versions. > > Yes, but there's a difference between using strlen() a couple of > times in the program and using it in a core processing loop or > other high-performance element of the program. And even if it is > used in such places it isn't going to be used so often that the > program would actually benefit from the few nanoseconds of > improvement you might get from it. The chances of that are nearly > zero. I tested it with diff and saw no difference :) between the assembly version and mine. I would still recommend to use the C version (src/lib/libc/string/strlen.c) over the assembly version since the assembly version adds no value while the C version is used already for most of the other architectures. Obviously, there is no rush. Sean -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 06:04:33 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18FDC16A469; Thu, 12 Jul 2007 06:04:33 +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 AC02D13C46A; Thu, 12 Jul 2007 06:04:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5559D.dip.t-dialin.net [84.165.85.157]) by redbull.bpaserver.net (Postfix) with ESMTP id 1DCDC2E22D; Thu, 12 Jul 2007 08:04:25 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 64AE45B5A49; Thu, 12 Jul 2007 08:02:13 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6C62Bgu066090; Thu, 12 Jul 2007 08:02:11 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 12 Jul 2007 08:02:10 +0200 Message-ID: <20070712080210.j1gquzf3koogssso@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 12 Jul 2007 08:02:10 +0200 From: Alexander Leidinger To: John-Mark Gurney References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711185718.GH1221@funkthat.com> In-Reply-To: <20070711185718.GH1221@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 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=-12.827, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_PH 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Robert, Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 12 Jul 2007 06:04:33 -0000 Quoting John-Mark Gurney (from Wed, 11 =20 Jul 2007 11:57:19 -0700): > Alexander Leidinger wrote this message on Wed, Jul 11, 2007 at 19:51 +0200= : >> Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 =20 >> 17:33:51 +0000): >> > There is no benefit from having it in the kernel. >> >> You need to get some information out of the kernel somehow (you cut >> this part of my mail). And as far as I understand the high level >> description (presentation in the net) of this framework, this does this >> in an unified way. Do you propose to get the information out of the >> kernel in a non-uniform way? > > No you don't. The kernel is just another "transport" layer so to say.. > > We are proposing a unified way via a userland front end... The userland Nothing prevents you to do that. I just say that Constantine focuses =20 on getting data out of the kernel (as far as I understand his =20 project). The userland front end you propose needs also some kernel =20 data. How do you want to get this kernel data to userland? I'm =20 repeating me here. I already asked this to phk and he cut this part =20 away in his answers. Do you want to extend each _existing_ kernel driver which is able to =20 provide some interesting data (RAID status, HD status, ACPI battery =20 status, ... you can even export some or all process info with it) on =20 your own via hand-rolled code each time? I don't want that. I would =20 like to prefer an unified way which is able to get 80-95% of the =20 interesting data out of the kernel in a sane way (it's like asking if =20 we should integrate each NIC driver into the network stack, or if we =20 should design an unified interface which each NIC has to comply to; I =20 think it is also similar to the mixer interface on soundcards, most of =20 the cards use the unified mixer interface to provide you the =20 possibility to change the volume of several channels). For the =20 remaining 5-20% which don't fit into an unified interface in a sane =20 way we can extend existing drivers by hand. The userland front end you =20 propose then can be configured with a simple config file for the =20 unified way and with some plugins or whatever for the remaining 5-20% =20 stuff. For me Constantin's project is about providing a transport interface =20 of in-kernel sensor data from the kernel to userland. This can be used =20 in a lot of ways. Maybe hand it over to another transport layer to =20 export it to another system (SNMP comes to mind), or just look at it =20 via sysctl, or use a simple top-like display, or feed it to =20 MRTG/nagios/whatever in some way, or write a super mega sensor front =20 end which not only takes the kernel data but also some more data (you =20 could see nagios as such a front end, if you want). As another step you could extend Constantin's framework with a =20 connection to the kevent subsystem, so that interesting stuff provides =20 notification events. For example for continuous sensors (voltage, =20 temperature) you could register an event handler for a temperature =20 threshold which triggers at crossing. > library knows and can adapt to different ways of extracting the data.. > If you hard code the kernel interface, when someone comes along and > wants to write a complicated sensor in userland, he will then need to > hack a "kernel frontend" to take his userland generated data, shove it > into the kernel, just for another userland app to pull the data out.. No. The kernel is not supposed to handle all sensor data. The kernel =20 is only supposed to provide existing in-kernel sensor data to =20 userland. Maybe it also needs to provide some (more) meta data about =20 the sensor data to userland. So before you all repeat here saying that this project should be done =20 differently, please tell us how you want to get interesting sensor =20 data from existing kernel stuff out of the kernel without the need of =20 a high privilege userland process. In case you want to augment =20 existing drivers with some way to export this data, please also =20 describe how you approach is different from what Constantine is doing =20 ATM. Bye, Alexander. --=20 A day without sunshine is like night. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 07:02:26 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2D5D16A421; Thu, 12 Jul 2007 07:02:25 +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 A1E9813C44B; Thu, 12 Jul 2007 07:02:25 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5559D.dip.t-dialin.net [84.165.85.157]) by redbull.bpaserver.net (Postfix) with ESMTP id 8BB582E22D; Thu, 12 Jul 2007 09:02:20 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 2295B5B5A49; Thu, 12 Jul 2007 09:00:09 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6C708uS075844; Thu, 12 Jul 2007 09:00:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 12 Jul 2007 09:00:08 +0200 Message-ID: <20070712090008.yc6d6zptwkow04oc@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 12 Jul 2007 09:00:08 +0200 From: Alexander Leidinger To: John Baldwin References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org> <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> <200707111145.27741.jhb@freebsd.org> In-Reply-To: <200707111145.27741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 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=-12.904, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Shteryana, Poul-Henning Kamp , "Constantine A. Murenin" , Shopova , Robert Watson , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 12 Jul 2007 07:02:26 -0000 Quoting John Baldwin (from Wed, 11 Jul 2007 11:45:26 -0400= ): > On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: >> On the other hand you don't want to allow an userland tool to directly >> mess around with the registers on your RAID or NIC to get some status... > > Err, that's how all the RAID utilities I've used work. They send firmware > commands from userland and parse the replies in userland. One exception I= 've That's sad... they should provide this functionality in the driver =20 instead, it would allow to use access restrictions for some parts. > seen so far is that for software RAID the firmware you are talking to is t= he > driver, not firmware on the card, so you use ioctls directly rather than a= n > ioctl that sends a command to the firmware on the card. But you have to run this tool as root, don't you? You don't want to =20 let a user run such a tool (and nowadays even desktops start to have =20 RAID, so whoever sits at the machine may be interested to see some =20 status on his desktop). Bye, Alexander. --=20 CCI Power 6/40: one board, a megabyte of cache, and an attitude... http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 10:37:37 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4230016A46D for ; Thu, 12 Jul 2007 10:37:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id D55C213C4C6 for ; Thu, 12 Jul 2007 10:37:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6CAbXVQ003905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 20:37:34 +1000 Date: Thu, 12 Jul 2007 20:37:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Sean C. Farley" In-Reply-To: <20070711134721.D2385@thor.farley.org> Message-ID: <20070712191616.A4682@delplex.bde.org> References: <20070711134721.D2385@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 10:37:37 -0000 On Wed, 11 Jul 2007, Sean C. Farley wrote: > While looking at increasing the speed of strlen(), I noticed that on > i386 platforms (PIII, P4 and Athlon XP) the performance is abysmal in > libc compared to the version I was writing. After more testing, I found > it was only the assembly version that is really slow. The C version is > fairly quick. Is there a need to continue to use the assembly versions > of string functions on i386? Does it mainly help slower systems such as > those with i386 or i486 CPU's? I think you are mistaken about the asm version being slow. In my tests (mainly on P4 and AXP), all versions are just mediocre, with the asm version usually slightly faster. It is hard to handle all cases efficiently, so generic string routines tend to be mediocre (even if they are bloated with special handling for all cases, the bloat tends to make them mediocre, especially for the usual (?) case of short strings). Anyway, the asm version is almost never used on amd64 or i386. gcc's builtin strlen is used at optimization levels >= 1 unless you do something to turn it off. gcc generates essentially the same mediocre code as the i386 asm version (repnz scasb, with not much other overhead except for the usual overhead for string instructions). Perhaps I misremember the asm version being faster. All string instructions except movs and stos are quite slow. On AXP they take: rep movs 24 + 4/3*count rep stos 24 + 1*count rep scas 15 + 5/2*count others are worse I think the C loop for strlen() takes N + 2*count on AXP. On A64 in i386 mode it does take N+2.0*count, while the builtin and the library (asm rep scasb) both take N+2.1*count. The speed of the C version depends on lots of pipelines which AXP and A64 have (not sure about P4). The critical loop is: 1: incl %eax cmpb $0,(%eax) jne 1b The cmpb in this takes 2 cycles, but the loop overhead takes no more due to pipelining. (On AXP and A64, all small loops take 2 cycles. You can add a one or two independent integer instructions in the loop without slowing it down, since up to 6 integer micro-ops can be executed in 2 cycles (2 cycles times 3 integer pipelines), and the above takes 4 or 5. memcmp() is more interesting than strlen() since it takes 5, 6 or 7.) The above loop is far from optimal. It could be unrolled, but this would be just a pessimization on AXP and A64, since the loop overhead is already null. It could use a better algorithm involving comparing 4 bytes at a time on i386 and 8 bytes on amd64. glibc (tege) implemented such algorithms almost 20 years ago. It is unclear if they are actually better, since they have more overhead outside of the loop. I suspect that the C version seems to be much better in your benchmarh because you only tested short strings. For short strings, the setup and finalization overhead (or more perhaps main memory overhead) dominates and both i386 string instructions and sophisticated algorithms lose because theor overheads are higher than for the simple C version. As to slower systems: versions using the string instructions are much better on older systems, because the old systems only have 1 slow pipeline instead of 2 or 3 fast pipelines, and they have slow branches and no branch cache; however they had string instructions only slightly larger (or even smaller) parameters than the above. libc/i386/string also has micro-optimizations for original i386's. libc/amd64/string is better, mainly by being almost empty, but it is still too muuch like libc/i386/string, having micro-optimizations for original i386's. E.g., it does things like using rep movsb in bcopy.S to copy the last 0-7 bytes without checking if the count is nonzero. This may have been a good optimization for original i386's, but it is one that the axp and amd64 optimization manuals say not to do. No one notices because it is only a minor pessimization. The kernel i386 bcopy has somehow always been optimized for AXP's and not for original i386's. > I have the results from my P4 (Id = 0xf24 Stepping = 4) system and the > test program here[1]. strlen.tar.bz2 is the archive of it for anyone's > testing. In the strlen/results subdirectory, there are the results for > strings of increasing lengths. Sorry, I didn't look at this. I just wrote a quick re-test and ran it on an A64 in i386 mode. In a previous test on P4, I tried to benchmark mainly branch overhead because the loop overhead is uninteresting ("all loops take 2 cycles"). I tried to randomize string lengths in a way the would defeat branch caches in the same way as average usage. The results were inconclusive. I don't know what average usage is, but I suspect average usage is to rarely usage strlen() so its efficiency doesn't matter %-). Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 06:58:29 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DD1016A400; Thu, 12 Jul 2007 06:58:29 +0000 (UTC) (envelope-from brians@ca.sophos.com) Received: from lightroast.ca.sophos.com (gw.ca.sophos.com [209.17.183.249]) by mx1.freebsd.org (Postfix) with ESMTP id 35FF913C46E; Thu, 12 Jul 2007 06:58:29 +0000 (UTC) (envelope-from brians@ca.sophos.com) Received: from smtp3.ca.sophos.com (smtp3.ca.sophos.com [192.168.3.19]) by lightroast.ca.sophos.com (8.13.8/8.13.8) with ESMTP id l6C6kqFY013113; Wed, 11 Jul 2007 23:46:52 -0700 (PDT) (envelope-from brians@ca.sophos.com) Received: from dev.lan.Awfulhak.org (ssh1.ActiveState.com [192.168.3.32]) by smtp.ca.sophos.com (8.13.4/8.13.4) with ESMTP id l6C6kpuf020335; Wed, 11 Jul 2007 23:46:51 -0700 (envelope-from brians@ca.sophos.com) Date: Wed, 11 Jul 2007 23:46:51 -0700 From: Brian Somers To: mjacob@FreeBSD.org Message-ID: <20070711234651.5efc1c66@dev.lan.Awfulhak.org> In-Reply-To: <20070706190843.X78793@ns1.feral.com> References: <200707070054.l670slr1007427@repoman.freebsd.org> <20070706183517.512b6dab@conflict> <20070706190843.X78793@ns1.feral.com> Organization: Sophos X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PerlMx-Spam: CA, Deliver, Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-SpamReport: No antispam rules were triggered by this message X-PMX-Version: CA 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.11.232533 X-Mailman-Approved-At: Thu, 12 Jul 2007 11:30:02 +0000 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Brian Somers , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if.c if_var.h src/sys/netinet in.c in_var.h 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, 12 Jul 2007 06:58:29 -0000 On Fri, 6 Jul 2007 19:08:57 -0700 (PDT) mjacob@FreeBSD.org wrote: > > Cool. Can we put this in regression tests? To be honest, I've never looked in tools/regression... until now. It looks like a bit of a mess. According to the README (last updated in 2001) it should be possible to ``prove -r'' everything. This is far from true, so forgive me for ranting if I've got the wrong end of the stick. Here's what I'd expect: - ``prove -r'' works - ``make test'' works in a similar way to ``prove -r'', sets PATH to /usr/obj/... and fails if tests fail. - .t files build test programs as required. - .t files skip() tests (or plan a different number) when required resources aren't available. - comments on ok/not ok lines are mandatory It would also be nice to bring libtap into the base system. If there are no objections, I'll look at doing this after -current un-slushes. If there are any suggestions about other improvements, please follow-up to freebsd-arch. -- Brian Somers Tel: +1 604 484 6434 Mob: +1 604 315 1343 Sophos - security and control Web: www.sophos.com From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 11:32:36 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A6E016A468; Thu, 12 Jul 2007 11:32:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 9D42813C46E; Thu, 12 Jul 2007 11:32:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6CBWV60027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 21:32:33 +1000 Date: Thu, 12 Jul 2007 21:32:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20070712191616.A4682@delplex.bde.org> Message-ID: <20070712211245.M8625@besplex.bde.org> References: <20070711134721.D2385@thor.farley.org> <20070712191616.A4682@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Sean C. Farley" , freebsd-arch@freebsd.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 11:32:36 -0000 On Thu, 12 Jul 2007, Bruce Evans wrote: > On Wed, 11 Jul 2007, Sean C. Farley wrote: > >> While looking at increasing the speed of strlen(), I noticed that on >> i386 platforms (PIII, P4 and Athlon XP) the performance is abysmal in >> libc compared to the version I was writing. After more testing, I found >> it was only the assembly version that is really slow. The C version is >> fairly quick. Is there a need to continue to use the assembly versions >> of string functions on i386? Does it mainly help slower systems such as >> those with i386 or i486 CPU's? > > I think you are mistaken about the asm version being slow. In my tests > ... Partly. >> I have the results from my P4 (Id = 0xf24 Stepping = 4) system and the >> test program here[1]. strlen.tar.bz2 is the archive of it for anyone's >> testing. In the strlen/results subdirectory, there are the results for >> strings of increasing lengths. > > Sorry, I didn't look at this. I just wrote a quick re-test and ran it Now I've looked at it. I think it is not testing strlen() at all, except for the libc case, because __pure prevents more than 1 call to strlen(). (The existence of __pure is also a bug. __pure was the FreeBSD spelling of the __const__ attribute in gcc-1. It was removed when special support for gcc-1 was dropped, and should not have been recycled.) __pure is a syntax error in the old version of FreeBSD that I tested on. I first tried __pure2, which is the FreeBSD spelling of the __const__ attribute in gcc-2. I think it is weaker than the __pure__ attribute in gcc-3. After removing __pure* and adding -static -g to CFLAGS, with gcc-3.3.3: On a old Celeron (400MHz) (all P2's probably behave like this): %%% libcstrlen: time spent executing strlen(string) = 64: 7.786868 basestrlen: time spent executing strlen(string) = 64: 3.816736 strlen: time spent executing strlen(string) = 64: 3.364313 strlen2: time spent executing strlen(string) = 64: 2.662973 %%% rep scasb is apparently very slow on P2's. On an A64 in i386 mode: %%% libcstrlen: time spent executing strlen(string) = 64: 0.709657 basestrlen: time spent executing strlen(string) = 64: 0.691397 strlen: time spent executing strlen(string) = 64: 0.527339 strlen2: time spent executing strlen(string) = 64: 0.441090 %%% Now rep scasb is only slightly slower than the simple C loop (since all small loops take 2 cycles on AXP and A64...). strlen and strlen2 are marginally faster since their loops do more. basestrlen is fastest for lengths <= 5 on the Celeron. basestrlen is fastest for lengths <= 9 on the A64. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 18:05:48 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBB1F16A400; Thu, 12 Jul 2007 18:05:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 419B913C4C4; Thu, 12 Jul 2007 18:05:48 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l6CI5iYB095452; Thu, 12 Jul 2007 14:05:46 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alexander Leidinger Date: Thu, 12 Jul 2007 14:04:33 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <200707111145.27741.jhb@freebsd.org> <20070712090008.yc6d6zptwkow04oc@webmail.leidinger.net> In-Reply-To: <20070712090008.yc6d6zptwkow04oc@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707121404.34168.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]); Thu, 12 Jul 2007 14:05:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3648/Thu Jul 12 12:59:27 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: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , Robert Watson , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 12 Jul 2007 18:05:48 -0000 On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > Quoting John Baldwin (from Wed, 11 Jul 2007 11:45:26 -0400): > > > On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > > >> On the other hand you don't want to allow an userland tool to directly > >> mess around with the registers on your RAID or NIC to get some status... > > > > Err, that's how all the RAID utilities I've used work. They send firmware > > commands from userland and parse the replies in userland. One exception I've > > That's sad... they should provide this functionality in the driver > instead, it would allow to use access restrictions for some parts. Not really, it avoids having to duplicate a lot of work in drivers that can be written once in a cross-platform userland utility. Drivers aren't really the place to be monitoring raid status sending pages, e-mails, etc. It's best to let userland invoke sendmail, not the kernel. :) > > seen so far is that for software RAID the firmware you are talking to is the > > driver, not firmware on the card, so you use ioctls directly rather than an > > ioctl that sends a command to the firmware on the card. > > But you have to run this tool as root, don't you? You don't want to > let a user run such a tool (and nowadays even desktops start to have > RAID, so whoever sits at the machine may be interested to see some > status on his desktop). Whatever talks directly to the driver needs to run as root, yes, but you could always write a proxy app that receives requests from utilities running as non-root and does its own access restrictions. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 21:03:07 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7312516A46D for ; Thu, 12 Jul 2007 21:03:07 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9A313C458 for ; Thu, 12 Jul 2007 21:03:06 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6CL4tx4031666; Thu, 12 Jul 2007 16:04:56 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 12 Jul 2007 16:02:47 -0500 (CDT) From: "Sean C. Farley" To: Bruce Evans In-Reply-To: <20070712211245.M8625@besplex.bde.org> Message-ID: <20070712142024.Q8789@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070712191616.A4682@delplex.bde.org> <20070712211245.M8625@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 21:03:07 -0000 On Thu, 12 Jul 2007, Bruce Evans wrote: > On Thu, 12 Jul 2007, Bruce Evans wrote: > >> On Wed, 11 Jul 2007, Sean C. Farley wrote: >> >>> While looking at increasing the speed of strlen(), I noticed that on >>> i386 platforms (PIII, P4 and Athlon XP) the performance is abysmal >>> in libc compared to the version I was writing. After more testing, >>> I found it was only the assembly version that is really slow. The C >>> version is fairly quick. Is there a need to continue to use the >>> assembly versions of string functions on i386? Does it mainly help >>> slower systems such as those with i386 or i486 CPU's? >> >> I think you are mistaken about the asm version being slow. In my >> tests ... > > Partly. > >>> I have the results from my P4 (Id = 0xf24 Stepping = 4) system and >>> the test program here[1]. strlen.tar.bz2 is the archive of it for >>> anyone's testing. In the strlen/results subdirectory, there are the >>> results for strings of increasing lengths. >> >> Sorry, I didn't look at this. I just wrote a quick re-test and ran >> it > > Now I've looked at it. I think it is not testing strlen() at all, > except for the libc case, because __pure prevents more than 1 call to > strlen(). (The existence of __pure is also a bug. __pure was the > FreeBSD spelling of the __const__ attribute in gcc-1. It was removed > when special support for gcc-1 was dropped, and should not have been > recycled.) __pure is a syntax error in the old version of FreeBSD > that I tested on. I first tried __pure2, which is the FreeBSD > spelling of the __const__ attribute in gcc-2. I think it is weaker > than the __pure__ attribute in gcc-3. >From what I could find, strlen() should not have the __const__ (__pure2) attribute since it is being passed a pointer, but __pure__ (__pure) should work. Are you saying that __pure used to mean __const__ in gcc-1 but now it means __pure__ for gcc-2.96 and above? The redefinition of __pure is what you are saying is a bug. Yes? > After removing __pure* and adding -static -g to CFLAGS, with > gcc-3.3.3: > > On a old Celeron (400MHz) (all P2's probably behave like this): > > %%% > libcstrlen: time spent executing strlen(string) = 64: 7.786868 > basestrlen: time spent executing strlen(string) = 64: 3.816736 > strlen: time spent executing strlen(string) = 64: 3.364313 > strlen2: time spent executing strlen(string) = 64: 2.662973 > %%% > > rep scasb is apparently very slow on P2's. > > On an A64 in i386 mode: > > %%% > libcstrlen: time spent executing strlen(string) = 64: 0.709657 > basestrlen: time spent executing strlen(string) = 64: 0.691397 > strlen: time spent executing strlen(string) = 64: 0.527339 > strlen2: time spent executing strlen(string) = 64: 0.441090 > %%% > > Now rep scasb is only slightly slower than the simple C loop (since > all small loops take 2 cycles on AXP and A64...). strlen and strlen2 > are marginally faster since their loops do more. > > basestrlen is fastest for lengths <= 5 on the Celeron. > > basestrlen is fastest for lengths <= 9 on the A64. I removed __pure from main.c and added -static -g. Athlon XP 2100 (1.72 GHz): libcstrlen: time spent executing strlen(string) = 64: 0.994755 asmstrlen: time spent executing strlen(string) = 64: 0.989012 basestrlen: time spent executing strlen(string) = 64: 0.879722 strlen: time spent executing strlen(string) = 64: 0.626727 strlen2: time spent executing strlen(string) = 64: 0.587162 P4 1.6 GHz: libcstrlen: time spent executing strlen(string) = 64: 2.412558 asmstrlen: time spent executing strlen(string) = 64: 2.413904 basestrlen: time spent executing strlen(string) = 64: 1.049927 strlen: time spent executing strlen(string) = 64: 0.543575 strlen2: time spent executing strlen(string) = 64: 0.547015 PIII 450MHz: libcstrlen: time spent executing strlen(string) = 64: 6.976066 asmstrlen: time spent executing strlen(string) = 64: 6.974106 basestrlen: time spent executing strlen(string) = 64: 3.464854 strlen: time spent executing strlen(string) = 64: 2.541872 strlen2: time spent executing strlen(string) = 64: 2.339469 The Athlon XP did much better with the assembly version than either Intel CPU for me. For all three CPU's using various string lengths from 1 to 256, the C versions always beat the assembly version although it came somewhat close for the 9 to 32 byte lengths to basestrlen. Even if this does not show that the assembly version should be replaced, I find this performance testing interesting. I learned something new. Sean -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 21:07:15 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E60216A421; Thu, 12 Jul 2007 21:07:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C069613C484; Thu, 12 Jul 2007 21:07:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6715720A4; Thu, 12 Jul 2007 22:51:16 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 460F5208A; Thu, 12 Jul 2007 22:51:16 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E15E4528C; Thu, 12 Jul 2007 22:51:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> Date: Thu, 12 Jul 2007 22:51:15 +0200 In-Reply-To: <20070711183217.C2385@thor.farley.org> (Sean C. Farley's message of "Wed\, 11 Jul 2007 18\:43\:00 -0500 \(CDT\)") Message-ID: <86lkdl5osc.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 21:07:15 -0000 "Sean C. Farley" writes: > On Wed, 11 Jul 2007, Matthew Dillon wrote: > > Long ago I decided that strlen() was simply not in the critical > > path for virtually any program. > Since strlen() is used in every program directly or indirectly through > libc, I thought it was beneficial to make it faster. The first rule of optimization is: don't do it. The second rule of optimization is: don't do it yet. The third rule of optimization is: don't optimize what you haven't measured. Can you show us an actual application that spends a significant part of its run time in strlen()? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 21:28:12 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11AF716A468 for ; Thu, 12 Jul 2007 21:28:12 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id ACBC113C4BC for ; Thu, 12 Jul 2007 21:28:11 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6CLTv5F031992; Thu, 12 Jul 2007 16:29:57 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 12 Jul 2007 16:27:49 -0500 (CDT) From: "Sean C. Farley" To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86lkdl5osc.fsf@dwp.des.no> Message-ID: <20070712161200.I8789@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <86lkdl5osc.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1187149148-1184274994=:8789" Content-ID: <20070712161640.S8789@thor.farley.org> X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 21:28:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1187149148-1184274994=:8789 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20070712161640.I8789@thor.farley.org> On Thu, 12 Jul 2007, Dag-Erling Sm=F8rgrav wrote: > "Sean C. Farley" writes: >> On Wed, 11 Jul 2007, Matthew Dillon wrote: >>> Long ago I decided that strlen() was simply not in the critical >>> path for virtually any program. >> Since strlen() is used in every program directly or indirectly >> through libc, I thought it was beneficial to make it faster. > > The first rule of optimization is: don't do it. > The second rule of optimization is: don't do it yet. > The third rule of optimization is: don't optimize what you haven't > measured. I am a rule breaker at least for the first two. :) I tried to follow the third rule. > Can you show us an actual application that spends a significant part > of its run time in strlen()? My test program that loops over strlen(). :) I already tested diff which showed that it does not spend enough time calling strlen() to matter, so I dropped the issue of optimization. I had looked into it while tweaking the *env() functions I wrote. It slowed them down a little, so I wanted to see what could be done with it. That is when I noticed that all platforms except for i386 and ARM use a faster (for me) C version already in the base. Currently, I am only suggesting that the C version, which is not optimized, be also used on i386. I did not test ARM. You could say the assembly version is going against the first rule of optimization. The dialog I am now having with Bruce is me trying to learn why I was seeing such a large difference between C and assembly. Sean --=20 scf@FreeBSD.org --0-1187149148-1184274994=:8789-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 22:03:24 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96F1416A41F; Thu, 12 Jul 2007 22:03:24 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 545E113C447; Thu, 12 Jul 2007 22:03:24 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6483820B0; Fri, 13 Jul 2007 00:03:20 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id DBB3F20AF; Fri, 13 Jul 2007 00:03:19 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id BC9D55292; Fri, 13 Jul 2007 00:03:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <86lkdl5osc.fsf@dwp.des.no> <20070712161200.I8789@thor.farley.org> Date: Fri, 13 Jul 2007 00:03:19 +0200 In-Reply-To: <20070712161200.I8789@thor.farley.org> (Sean C. Farley's message of "Thu\, 12 Jul 2007 16\:27\:49 -0500 \(CDT\)") Message-ID: <86hco95lg8.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 22:03:24 -0000 "Sean C. Farley" writes: > On Thu, 12 Jul 2007, Dag-Erling Sm=C3=B8rgrav wrote: > > The first rule of optimization is: don't do it. > > The second rule of optimization is: don't do it yet. > > The third rule of optimization is: don't optimize what you haven't > > measured. > I am a rule breaker at least for the first two. :) I tried to follow > the third rule. > > > Can you show us an actual application that spends a significant part > > of its run time in strlen()? > My test program that loops over strlen(). So the answer is no, and you don't understand the third rule which you claim to follow. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 22:18:18 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86F1616A400 for ; Thu, 12 Jul 2007 22:18:18 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4935C13C48C for ; Thu, 12 Jul 2007 22:18:18 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6CMK5CL032706; Thu, 12 Jul 2007 17:20:05 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 12 Jul 2007 17:17:57 -0500 (CDT) From: "Sean C. Farley" To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86hco95lg8.fsf@dwp.des.no> Message-ID: <20070712170748.W8789@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <86lkdl5osc.fsf@dwp.des.no> <20070712161200.I8789@thor.farley.org> <86hco95lg8.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1811604476-1184278677=:8789" X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 12 Jul 2007 22:18:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1811604476-1184278677=:8789 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 13 Jul 2007, Dag-Erling Sm=F8rgrav wrote: > "Sean C. Farley" writes: >> On Thu, 12 Jul 2007, Dag-Erling Sm=F8rgrav wrote: >>> The first rule of optimization is: don't do it. >>> The second rule of optimization is: don't do it yet. >>> The third rule of optimization is: don't optimize what you haven't >>> measured. >> I am a rule breaker at least for the first two. :) I tried to >> follow the third rule. >> >>> Can you show us an actual application that spends a significant part >>> of its run time in strlen()? >> My test program that loops over strlen(). > > So the answer is no, and you don't understand the third rule which you > claim to follow. I never claimed to succeed; I only tried. The two types of tests I can think would be useful were execution of strlen() by itself and within a common program. I had thought I had tested the first type of test. The second one I did later with different versions of strlen() using diff. What types of tests would have been better? I know about gprof for finding where a specific program is spending its time, but I was focusing on the strlen() call. Also, having two different versions in the source tree is still puzzling me. Sean --=20 scf@FreeBSD.org --0-1811604476-1184278677=:8789-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 04:38:16 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89C0916A402; Fri, 13 Jul 2007 04:38:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2689813C467; Fri, 13 Jul 2007 04:38:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6D4cA0r004417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 14:38:13 +1000 Date: Fri, 13 Jul 2007 14:38:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Sean C. Farley" In-Reply-To: <20070712142024.Q8789@thor.farley.org> Message-ID: <20070713135453.H8054@delplex.bde.org> References: <20070711134721.D2385@thor.farley.org> <20070712191616.A4682@delplex.bde.org> <20070712211245.M8625@besplex.bde.org> <20070712142024.Q8789@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Assembly string functions in i386 libc 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, 13 Jul 2007 04:38:16 -0000 On Thu, 12 Jul 2007, Sean C. Farley wrote: > On Thu, 12 Jul 2007, Bruce Evans wrote: >> Now I've looked at it. I think it is not testing strlen() at all, >> except for the libc case, because __pure prevents more than 1 call to >> strlen(). (The existence of __pure is also a bug. __pure was the >> FreeBSD spelling of the __const__ attribute in gcc-1. It was removed >> when special support for gcc-1 was dropped, and should not have been >> recycled.) __pure is a syntax error in the old version of FreeBSD >> that I tested on. I first tried __pure2, which is the FreeBSD >> spelling of the __const__ attribute in gcc-2. I think it is weaker >> than the __pure__ attribute in gcc-3. > >> From what I could find, strlen() should not have the __const__ (__pure2) > attribute since it is being passed a pointer, but __pure__ (__pure) > should work. Are you saying that __pure used to mean __const__ in gcc-1 > but now it means __pure__ for gcc-2.96 and above? The redefinition of > __pure is what you are saying is a bug. Yes? Yes to most of this. __pure2 is actually weaker than __pure[>2.96]. __pure2 has the very large effect of removing all calls to strlen() from the loop. This affected everything except libc strlen() since everything else was named xstrlen() and declared as __pure*, while libc strlen() was declared in without __pure*. OTOH, __pure[>2.96] has no effect on this benchmark, at least with gcc-3.3.3. I don't understand why it has no effect. It has no effect even when I change the arg to a literal. The context is very simple, with no aliasing problems in sight, at least with the literal arg (with the arg possibly being argv[2], maybe gcc has to worry about the arg being modified by a signal handler). If __pure[>2.96] doesn't work in this simple context, then it isn't clear when it can work. BTW, starting somewhere near gcc-3.4 for -O2 and gcc-4.2 for -O, simple loops like this don't always work in benchmarks, because the compiler removes the whole loop if it can see that it doesn't do anything. The compiler can see this if it can see inside any function calls in the loop (this currently requires the functions to be in the same source file or #included there), or if the functions are declared as sufficiently __pure. When I used __pure2 with gcc-3.3.3 -O, gcc removed the function calls but not the loop. gcc-4.2 would also remove the loop. > I removed __pure from main.c and added -static -g. > > Athlon XP 2100 (1.72 GHz): > libcstrlen: time spent executing strlen(string) = 64: 0.994755 > asmstrlen: time spent executing strlen(string) = 64: 0.989012 > basestrlen: time spent executing strlen(string) = 64: 0.879722 > strlen: time spent executing strlen(string) = 64: 0.626727 > strlen2: time spent executing strlen(string) = 64: 0.587162 That looks just like my results on A64 in 32-bit mode. (A64 is remarkably similar to AXP in most CPU resources including pipelines, so its performance is remarkably similar even when when its mode differs.) > ...[asm version more than twice as slow on P3-P4] > The Athlon XP did much better with the assembly version than either > Intel CPU for me. For all three CPU's using various string lengths from > 1 to 256, the C versions always beat the assembly version although it > came somewhat close for the 9 to 32 byte lengths to basestrlen. Intel CPUs are remarkably different from AXP :-). I'm surprised at the sign of the difference here -- I would have expected them to be better for the string instructions. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 05:39:53 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2EFE16A400; Fri, 13 Jul 2007 05:39:53 +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 713E513C491; Fri, 13 Jul 2007 05:39:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A564A4.dip.t-dialin.net [84.165.100.164]) by redbull.bpaserver.net (Postfix) with ESMTP id 46C7D2E11E; Fri, 13 Jul 2007 07:39:45 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BC5625B5A27; Fri, 13 Jul 2007 07:37:33 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6D5bXYS008459; Fri, 13 Jul 2007 07:37:33 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 13 Jul 2007 07:37:33 +0200 Message-ID: <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 13 Jul 2007 07:37:33 +0200 From: Alexander Leidinger To: John Baldwin References: <55754.1184143579@critter.freebsd.dk> <200707111145.27741.jhb@freebsd.org> <20070712090008.yc6d6zptwkow04oc@webmail.leidinger.net> <200707121404.34168.jhb@freebsd.org> In-Reply-To: <200707121404.34168.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 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=-13.404, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Shteryana, Poul-Henning Kamp , "Constantine A. Murenin" , Shopova , Robert Watson , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 05:39:53 -0000 Quoting John Baldwin (from Thu, 12 Jul 2007 14:04:33 -0400= ): > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: >> Quoting John Baldwin (from Wed, 11 Jul 2007 > 11:45:26 -0400): >> >> > On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: >> >> >> On the other hand you don't want to allow an userland tool to directly >> >> mess around with the registers on your RAID or NIC to get some status.= .. >> > >> > Err, that's how all the RAID utilities I've used work. They send firmw= are >> > commands from userland and parse the replies in userland. One exceptio= n > I've >> >> That's sad... they should provide this functionality in the driver >> instead, it would allow to use access restrictions for some parts. > > Not really, it avoids having to duplicate a lot of work in drivers =20 > that can be > written once in a cross-platform userland utility. Drivers aren't really = the If the sensor querying is already cross-platform, it can also be used =20 in the kernel. You have the driver just call the cross-platform =20 function to get back a firmware command it then can send to the =20 hardware. > place to be monitoring raid status sending pages, e-mails, etc. It's best= to > let userland invoke sendmail, not the kernel. :) I fully agree, but nobody wants to send mails from the kernel. We just =20 want to get the sensor data out of the kernel without the possibility =20 to fuck up the device from userland. You don't have a userland tool =20 for each NIC (which you need if you go the cross-platform-tool way), =20 we have a well defined interface there which allows to get back some =20 sensor data (wire speed, MAC address, IP address(es), ...) already and =20 we display it in ifconfig. There's one tool to query it (ifconfig), =20 and nobody complains about it being hard to do it in the driver =20 instead of in a cross-platform userland tool (and Sam enhanced =20 ifconfig to be able to get rid of the special tools for each WLAN NIC, =20 and everybody was happy about this). The sensors framework tries to =20 accomplish the same for sensor data. A driver (or something else in =20 the kernel) registers himself with the sensor framework, and then you =20 can use a generic tool to query all sensor data. No need to reinvent =20 the wheel (how to export, how to name, what unit to use), and a good =20 consistency (e.g. units used). >> > seen so far is that for software RAID the firmware you are talking to i= s > the >> > driver, not firmware on the card, so you use ioctls directly rather tha= n > an >> > ioctl that sends a command to the firmware on the card. >> >> But you have to run this tool as root, don't you? You don't want to >> let a user run such a tool (and nowadays even desktops start to have >> RAID, so whoever sits at the machine may be interested to see some >> status on his desktop). > > Whatever talks directly to the driver needs to run as root, yes, but =20 > you could > always write a proxy app that receives requests from utilities running as > non-root and does its own access restrictions. That's a lot of infrastructure you want to create for such a simple =20 task as displaying "resyncing 50% done" or "0 hotspares" or similar... Bye, Alexander. --=20 In Christianity, a man may have only one wife. This is called Monotony. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 09:29:16 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D13DB16A405; Fri, 13 Jul 2007 09:29:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9D813C48E; Fri, 13 Jul 2007 09:29:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 62FBE20A4; Fri, 13 Jul 2007 11:29:10 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D0D2D208A; Fri, 13 Jul 2007 11:29:09 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id B64D952A6; Fri, 13 Jul 2007 11:29:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <20070711134721.D2385@thor.farley.org> <20070711221338.GC20178@turion.vk2pj.dyndns.org> <200707112221.l6BML722062857@apollo.backplane.com> <20070711183217.C2385@thor.farley.org> <86lkdl5osc.fsf@dwp.des.no> <20070712161200.I8789@thor.farley.org> <86hco95lg8.fsf@dwp.des.no> <20070712170748.W8789@thor.farley.org> Date: Fri, 13 Jul 2007 11:29:09 +0200 In-Reply-To: <20070712170748.W8789@thor.farley.org> (Sean C. Farley's message of "Thu\, 12 Jul 2007 17\:17\:57 -0500 \(CDT\)") Message-ID: <86d4yw649m.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 13 Jul 2007 09:29:16 -0000 "Sean C. Farley" writes: > I never claimed to succeed; I only tried. The two types of tests I can > think would be useful were execution of strlen() by itself and within a > common program. I had thought I had tested the first type of test. You did, but it's worthless. If you wrote a test program that did nothing but add two numbers together, then profiled that program, would you then conclude that addition needs optimizing? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 12:22:25 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80E0B16A405; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2E19313C481; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l6DCMJHK003289; Fri, 13 Jul 2007 08:22:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 13 Jul 2007 07:17:06 -0400 User-Agent: KMail/1.9.6 References: <20070711134721.D2385@thor.farley.org> <20070712170748.W8789@thor.farley.org> <86d4yw649m.fsf@dwp.des.no> In-Reply-To: <86d4yw649m.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707130717.07585.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]); Fri, 13 Jul 2007 08:22:20 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 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: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , "Sean C. Farley" Subject: Re: Assembly string functions in i386 libc 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, 13 Jul 2007 12:22:25 -0000 On Friday 13 July 2007 05:29:09 am Dag-Erling Sm=C3=B8rgrav wrote: > "Sean C. Farley" writes: > > I never claimed to succeed; I only tried. The two types of tests I can > > think would be useful were execution of strlen() by itself and within a > > common program. I had thought I had tested the first type of test. >=20 > You did, but it's worthless. >=20 > If you wrote a test program that did nothing but add two numbers > together, then profiled that program, would you then conclude that > addition needs optimizing? Um, des, he's asking to _remove_ the assembly optimization on i386 and just= =20 use the C version that other archs use. Unless there is a compelling reaso= n=20 to keep the asm versions I agree that the C version should just be used=20 instead. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 12:22:25 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D344316A400; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3FD13C48D; Fri, 13 Jul 2007 12:22:25 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l6DCMJHL003289; Fri, 13 Jul 2007 08:22:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alexander Leidinger Date: Fri, 13 Jul 2007 07:40:15 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <200707121404.34168.jhb@freebsd.org> <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> In-Reply-To: <20070713073733.3yk6m2vec0cs88sw@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707130740.17680.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]); Fri, 13 Jul 2007 08:22:23 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3656/Fri Jul 13 07:24:51 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: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , Robert Watson , freebsd-arch@freebsd.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 12:22:26 -0000 On Friday 13 July 2007 01:37:33 am Alexander Leidinger wrote: > Quoting John Baldwin (from Thu, 12 Jul 2007 14:04:33 -0400): > > > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > >> Quoting John Baldwin (from Wed, 11 Jul 2007 > > 11:45:26 -0400): > >> > >> > On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > >> > >> >> On the other hand you don't want to allow an userland tool to directly > >> >> mess around with the registers on your RAID or NIC to get some status... > >> > > >> > Err, that's how all the RAID utilities I've used work. They send firmware > >> > commands from userland and parse the replies in userland. One exception > > I've > >> > >> That's sad... they should provide this functionality in the driver > >> instead, it would allow to use access restrictions for some parts. > > > > Not really, it avoids having to duplicate a lot of work in drivers > > that can be > > written once in a cross-platform userland utility. Drivers aren't really the > > If the sensor querying is already cross-platform, it can also be used > in the kernel. You have the driver just call the cross-platform > function to get back a firmware command it then can send to the > hardware. Not if the cross-platform code is in userland (think vendor-supplied binaries). > > place to be monitoring raid status sending pages, e-mails, etc. It's best to > > let userland invoke sendmail, not the kernel. :) > > I fully agree, but nobody wants to send mails from the kernel. We just > want to get the sensor data out of the kernel without the possibility > to fuck up the device from userland. You don't have a userland tool > for each NIC (which you need if you go the cross-platform-tool way), > we have a well defined interface there which allows to get back some > sensor data (wire speed, MAC address, IP address(es), ...) already and > we display it in ifconfig. There's one tool to query it (ifconfig), > and nobody complains about it being hard to do it in the driver > instead of in a cross-platform userland tool (and Sam enhanced > ifconfig to be able to get rid of the special tools for each WLAN NIC, > and everybody was happy about this). The sensors framework tries to > accomplish the same for sensor data. A driver (or something else in > the kernel) registers himself with the sensor framework, and then you > can use a generic tool to query all sensor data. No need to reinvent > the wheel (how to export, how to name, what unit to use), and a good > consistency (e.g. units used). ifconfig doesn't use strings from sysctl. It uses a more sophisticated interface with data structures, etc. If you wanted to add a standard RAID monitoring interface, then I would add ioctl's for different RAID operations along with a set of generic RAID structures (probably based at least conceptually on DDF) so that there's an ioctl to return the current RAID config that gives you a list of virtual disks, basic virtual disks, etc. You need to be able to enumerate volumes, enumerate disks, have generic state enums for volumes and disks, etc. > > Whatever talks directly to the driver needs to run as root, yes, but > > you could > > always write a proxy app that receives requests from utilities running as > > non-root and does its own access restrictions. > > That's a lot of infrastructure you want to create for such a simple > task as displaying "resyncing 50% done" or "0 hotspares" or similar... Strings are a horrible data interface. The stuff I work on needs to send e-mails that are more like: volume X on controller Y is degraded the following disks(s) need to be replaced: drive 5 (enclosure 1, slot 2), drive 7 (enclosure 1, slot 4) To do that sanely, I need to have access to data structures, not just arbitrary strings from a sysctl. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 13:16:03 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40D2116A405; Fri, 13 Jul 2007 13:16:03 +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 EA56713C4C1; Fri, 13 Jul 2007 13:16:02 +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 795CF17380; Fri, 13 Jul 2007 13:16:01 +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 l6DDG0gp080514; Fri, 13 Jul 2007 13:16:00 GMT (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 Jul 2007 07:40:15 -0400." <200707130740.17680.jhb@freebsd.org> Date: Fri, 13 Jul 2007 13:16:00 +0000 Message-ID: <80513.1184332560@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Rui Paulo , "Constantine A. Murenin" , Shteryana Shopova , Robert Watson , freebsd-arch@freebsd.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 13:16:03 -0000 In message <200707130740.17680.jhb@freebsd.org>, John Baldwin writes: >ifconfig doesn't use strings from sysctl. It uses a more sophisticated >interface with data structures, etc. If you wanted to add a standard RAID >monitoring interface, then I would add ioctl's for different RAID operations >along with a set of generic RAID structures [...] I wouldn't. The amount of time and code it takes to encapsulate instructions in binary structures, and then unpack and validate those same structures is utterly wasted for complex interfaces like that. The reason why we started out on the struct+bitmap method, was that the structs were copies of the hardware or kernel structures, so there were no work involved in receiving and sending them from the kernel. But we are increasingly using abstract representations for reasons of portability and multi-everything-support, and now we end up having to treat the binary structures and bitmaps as very complex communication protocols and look for all the sorts of evil you can have in binary data (overruns, underruns etc etc.) For complex low-frequency interfaces, like RAID management, I would (and have: see GEOM) simply send text strings to the kernel and deal with all the parsing and validation there. Part of the reason for this is that their very complex nature makes the struct representation particularly unwieldy, whereas the good old command line metaphor manages to capture complex data forms in a readable and easily parseable format: find . -type file -name '*.c -print >Strings are a horrible data interface. The stuff I work on needs to send >e-mails that are more like: > >volume X on controller Y is degraded >the following disks(s) need to be replaced: drive 5 (enclosure 1, slot 2), > drive 7 (enclosure 1, slot 4) > >To do that sanely, I need to have access to data structures, not just >arbitrary strings from a sysctl. I thought a lot about that with GEOM, and that's why the output from the kernel is highly structured, but free form (ie: XML). Overall I think the assymetric API GEOM got, and in a lighter degree nmount, are the way forward. The age of the intricate struct + bitmap is a cul-de-sac, which leads to unreadable and buggy code to encapsulate and decode a binary format at the syscall interface, which nobody really cares about. ifconfig is a primary candidate for being rototilled like this: if you compare the length of the average ifconfig argument list to the number of structures and bitflags manipulated, it will soon be seen that shipping argv[] to the kernel and only parsing once would be much more economical and less bugprone. Move with the times people... -- 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 Jul 13 14:19:12 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0BEF16A403 for ; Fri, 13 Jul 2007 14:19:12 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 62CB413C47E for ; Fri, 13 Jul 2007 14:19:12 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6DEKw0Y048729; Fri, 13 Jul 2007 09:20:58 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 13 Jul 2007 09:18:50 -0500 (CDT) From: "Sean C. Farley" To: Bruce Evans In-Reply-To: <20070713135453.H8054@delplex.bde.org> Message-ID: <20070713085330.H21970@thor.farley.org> References: <20070711134721.D2385@thor.farley.org> <20070712191616.A4682@delplex.bde.org> <20070712211245.M8625@besplex.bde.org> <20070712142024.Q8789@thor.farley.org> <20070713135453.H8054@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 13 Jul 2007 14:19:12 -0000 On Fri, 13 Jul 2007, Bruce Evans wrote: > On Thu, 12 Jul 2007, Sean C. Farley wrote: > >> On Thu, 12 Jul 2007, Bruce Evans wrote: > >>> Now I've looked at it. I think it is not testing strlen() at all, >>> except for the libc case, because __pure prevents more than 1 call >>> to strlen(). (The existence of __pure is also a bug. __pure was >>> the FreeBSD spelling of the __const__ attribute in gcc-1. It was >>> removed when special support for gcc-1 was dropped, and should not >>> have been recycled.) __pure is a syntax error in the old version of >>> FreeBSD that I tested on. I first tried __pure2, which is the >>> FreeBSD spelling of the __const__ attribute in gcc-2. I think it is >>> weaker than the __pure__ attribute in gcc-3. >> >>> From what I could find, strlen() should not have the __const__ >>> (__pure2) attribute since it is being passed a pointer, but __pure__ >>> (__pure) should work. Are you saying that __pure used to mean >>> __const__ in gcc-1 but now it means __pure__ for gcc-2.96 and above? >>> The redefinition of __pure is what you are saying is a bug. Yes? > > Yes to most of this. __pure2 is actually weaker than __pure[>2.96]. > __pure2 has the very large effect of removing all calls to strlen() > from the loop. This affected everything except libc strlen() since > everything else was named xstrlen() and declared as __pure*, while > libc strlen() was declared in without __pure*. Actually, the reason I had __pure in main.c was because it exists in string.h. > OTOH, __pure[>2.96] has no effect on this benchmark, at least with > gcc-3.3.3. I don't understand why it has no effect. It has no effect > even when I change the arg to a literal. The context is very simple, > with no aliasing problems in sight, at least with the literal arg > (with the arg possibly being argv[2], maybe gcc has to worry about the > arg being modified by a signal handler). If __pure[>2.96] doesn't > work in this simple context, then it isn't clear when it can work. Using or not using __pure with gcc-3.4.6 has no effect for me even with the literal argument regardless of optimization (-O0, -O1, or -O2). > BTW, starting somewhere near gcc-3.4 for -O2 and gcc-4.2 for -O, > simple loops like this don't always work in benchmarks, because the > compiler removes the whole loop if it can see that it doesn't do > anything. The compiler can see this if it can see inside any function > calls in the loop (this currently requires the functions to be in the > same source file or #included there), or if the functions are declared > as sufficiently __pure. When I used __pure2 with gcc-3.3.3 -O, gcc > removed the function calls but not the loop. gcc-4.2 would also > remove the loop. Interesting. I need to remember this. Just to note, __pure2 is not valid with strlen() since it examines data passed via a pointer, according to the GCC docs. > ...[A64 in 32-bit mode similar to AXP] BTW, does AXP refer to Athlon XP or Alpha AXP? When I first saw you write AXP, I thought it was an Alpha. :) >> ...[asm version more than twice as slow on P3-P4] > >> The Athlon XP did much better with the assembly version than either >> Intel CPU for me. For all three CPU's using various string lengths >> from 1 to 256, the C versions always beat the assembly version >> although it came somewhat close for the 9 to 32 byte lengths to >> basestrlen. > > Intel CPUs are remarkably different from AXP :-). I'm surprised at > the sign of the difference here -- I would have expected them to be > better for the string instructions. That is what has been confusing me. Possibly, Intel has not touched the basics of these string instructions for a longer time than AMD. Sean -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 15:48:34 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF04016A404; Fri, 13 Jul 2007 15:48:34 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4115C13C4A8; Fri, 13 Jul 2007 15:48:31 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6DFmPRp003137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 19:48:28 +0400 Message-ID: <46979EC3.20803@FreeBSD.org> Date: Fri, 13 Jul 2007 11:48:19 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: John Baldwin References: <55754.1184143579@critter.freebsd.dk> <200707111145.27741.jhb@freebsd.org> <20070712090008.yc6d6zptwkow04oc@webmail.leidinger.net> <200707121404.34168.jhb@freebsd.org> In-Reply-To: <200707121404.34168.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , Robert Watson , freebsd-arch@FreeBSD.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 15:48:35 -0000 On 12/07/2007 14:04, John Baldwin wrote: > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > >>Quoting John Baldwin (from Wed, 11 Jul 2007 > > 11:45:26 -0400): > >>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: >> >>>>On the other hand you don't want to allow an userland tool to directly >>>>mess around with the registers on your RAID or NIC to get some status... >>> >>>Err, that's how all the RAID utilities I've used work. They send firmware >>>commands from userland and parse the replies in userland. One exception > > I've > >>That's sad... they should provide this functionality in the driver >>instead, it would allow to use access restrictions for some parts. > > > Not really, it avoids having to duplicate a lot of work in drivers that can be > written once in a cross-platform userland utility. Drivers aren't really the > place to be monitoring raid status sending pages, e-mails, etc. It's best to > let userland invoke sendmail, not the kernel. :) John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't implement SMTP and don't do emails, they only provide updates to the sensors framework when there are some changes in the state of the drive. :) sensorsd(8) is used to send alerts and emails based on the information from the sensors framework, and user configuration. bioctl(8) is used to configure RAID for _all drivers_. There are no separate utilities for RAID configuration based on brand-name, just like nowadays there are no separate utilities for configuring Ethernet adapters. [0] To my knowledge, this RAID drive status monitoring functionality was already ported to NetBSD's envsys/sysmon a short while ago -- on 2007-05-01. It appears in OpenBSD since 2005-11-30 and is appraised by many users and developers worldwide. This project that I am working on is about porting the generic sensors framework that is used by RAID drives amongst other devices. The amount of work or bookkeeping that is done in the device drivers to provide sensors to this framework is very minimal. Types of sensors in the framework are very well defined. This sensors framework, by itself, provides only general status reporting in regards to RAID drives [1] -- bioctl(8) does most of the things in regards to RAID, and it goes separately from the sensors framework. Cheers, Constantine. [0]http://marc.info/?l=openbsd-tech&m=113772381621199&w=2 [1]http://opengrok.creo.hu/openbsd/xref/src/sys/sys/sensors.h#SENSOR_DRIVE_EMPTY From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 16:14:38 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 747F716A409; Fri, 13 Jul 2007 16:14:38 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id EA62213C4C9; Fri, 13 Jul 2007 16:14:37 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6DGEWdO001821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 20:14:35 +0400 Message-ID: <4697A4E3.5070901@FreeBSD.org> Date: Fri, 13 Jul 2007 12:14:27 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Robert Watson References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org> In-Reply-To: <20070711104247.P58526@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Poul-Henning Kamp , "Constantine A. Murenin" , Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 16:14:38 -0000 On 11/07/2007 06:12, Robert Watson wrote: > On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > >> In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: >> >>> If you want to have no such framework that could potentially diagnose >>> or predict system failure, it's your choice, [...] >> >> >> I would love to have that, but the OpenBSD code isn't that. > > > In the general spirit of SoC, I would suggest that a more constructive > line of commenting might come with suggestions, not just rejections > :-). Are you arguing that the current proposed framework offers little > incremental benefit over simply having the sysctl framework in the first > place and having each source of information (i.e., device driver) just > export it directly? > > It seems clear that people would like all these measurements to be > available, even if not by the precise mechanism proposed. So far the > specific technical criticals have been: > > - There's such a diversity of motherboard devices and probe mechanisms that > any kernel driver would become rapidly over-burdened and needlessly > complicated. > > This doesn't argue for doing nothing, just that perhaps a kernel device > driver is the wrong place. Most consumer motherboards that are on the market today have either Winbond or ITE Tech Super I/O. All of these chips are supported by two drivers: lm(4) and it(4). All of these Super I/O attach at isa. I don't have exact numbers, but in reality, these chips cover almost every recent and not so recent motherboard manufactured by Asus, ECS, Gigabyte, MSI, AOpen etc. Documentation for these chips is readily available via anonymous http, directly from Winbond and ITE Tech. (Granted, there are a few problems with resistor recommendations that phk mentioned, but this should not stop us from having _simple_ drivers for these chips -- they are already written and available in OpenBSD and NetBSD, and lm(4) is mostly ported in perforce to FreeBSD, too.) > - A moderate number of user space tools exist to do this already in the > ports > collection, and user space is the right place to do this as it doesn't > need > to be in kernel. > > Part of the argument here has to do with code becoming stale, and one > possible outcome of a more actively maintained in-OS framework is that > it is better maintained, and that code is shared across platforms. > Also, I have to say that I don't run monitoring tools on several of my > boxes because I can never figure out which are the right ones to run, > and the ones I try inevitably don't work. That's exactly what this is about -- most people don't run these monitoring tools from the ports tree because there are just too many options to choose from, whereas in reality few of them have desired functionality. One other important distinction between all of those tools and sysctl framework is the lack of a namespace in those tools and artificial limitations (e.g. healthd from ports supports exactly 3 temperature sensors etc). Other important factor is that those monitoring tools from ports must be run as root, and some of them by default accept non-local connections from the network, which poses additional security risks. All sysctl hw.sensors tools can be run as an unprivileged user. Tools are already in place to perform local and remote monitoring, all of which can be done as an unprivileged user. Cheers, Constantine. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 13 16:52:23 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E08516A50F; Fri, 13 Jul 2007 16:52:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id A98CA13C4EC; Fri, 13 Jul 2007 16:52:22 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l6DGqDG6005050; Fri, 13 Jul 2007 12:52:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 13 Jul 2007 12:52:06 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <200707121404.34168.jhb@freebsd.org> <46979EC3.20803@FreeBSD.org> In-Reply-To: <46979EC3.20803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131252.08792.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]); Fri, 13 Jul 2007 12:52:20 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3658/Fri Jul 13 11:27:31 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: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 13 Jul 2007 16:52:23 -0000 On Friday 13 July 2007 11:48:19 am Constantine A. Murenin wrote: > On 12/07/2007 14:04, John Baldwin wrote: > > > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > > > >>Quoting John Baldwin (from Wed, 11 Jul 2007 > > > > 11:45:26 -0400): > > > >>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > >> > >>>>On the other hand you don't want to allow an userland tool to directly > >>>>mess around with the registers on your RAID or NIC to get some status... > >>> > >>>Err, that's how all the RAID utilities I've used work. They send firmware > >>>commands from userland and parse the replies in userland. One exception > > > > I've > > > >>That's sad... they should provide this functionality in the driver > >>instead, it would allow to use access restrictions for some parts. > > > > > > Not really, it avoids having to duplicate a lot of work in drivers that can be > > written once in a cross-platform userland utility. Drivers aren't really the > > place to be monitoring raid status sending pages, e-mails, etc. It's best to > > let userland invoke sendmail, not the kernel. :) > > John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't > implement SMTP and don't do emails, they only provide updates to the > sensors framework when there are some changes in the state of the drive. :) > > sensorsd(8) is used to send alerts and emails based on the information > from the sensors framework, and user configuration. > > bioctl(8) is used to configure RAID for _all drivers_. There are no > separate utilities for RAID configuration based on brand-name, just like > nowadays there are no separate utilities for configuring Ethernet > adapters. [0] According to the various manpages on www.openbsd.org you cannot configure arrays on the OS for at least mfi(4), ciss(4), twe(4), mpi(4) (like mpt(4) in FreeBSD) or ami(4) (like amr(4) in FreeBSD). You can only do monitoring via hw.sensors for ciss(4) and ami(4), and the example for monitoring ami(4) in the manpage shows that you can only get volume level data, and as a _string_ and that you can't get backing physical drive status to know which physical drive has failed and needs to be replaced: $ sysctl hw.sensors.ami0 hw.sensors.ami0.drive0=online (sd0), OK hw.sensors.ami0.drive1=degraded (sd1), WARNING hw.sensors.ami0.drive2=failed (sd2), CRITICAL -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Jul 14 04:25:53 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D41A16A401; Sat, 14 Jul 2007 04:25:53 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 85AB613C478; Sat, 14 Jul 2007 04:25:52 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l6E4Pk92029829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 08:25:50 +0400 Message-ID: <46985043.8010204@FreeBSD.org> Date: Sat, 14 Jul 2007 00:25:39 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: John Baldwin References: <55754.1184143579@critter.freebsd.dk> <200707121404.34168.jhb@freebsd.org> <46979EC3.20803@FreeBSD.org> <200707131252.08792.jhb@freebsd.org> In-Reply-To: <200707131252.08792.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Robert Watson , freebsd-arch@FreeBSD.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 14 Jul 2007 04:25:53 -0000 On 13/07/2007 12:52, John Baldwin wrote: > On Friday 13 July 2007 11:48:19 am Constantine A. Murenin wrote: > >>On 12/07/2007 14:04, John Baldwin wrote: >> >> >>>On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: >>> >>> >>>>Quoting John Baldwin (from Wed, 11 Jul 2007 >>> >>>11:45:26 -0400): >>> >>> >>>>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: >>>> >>>>>>On the other hand you don't want to allow an userland tool to directly >>>>>>mess around with the registers on your RAID or NIC to get some status... >>>>> >>>>>Err, that's how all the RAID utilities I've used work. They send > > firmware > >>>>>commands from userland and parse the replies in userland. One exception >>> >>>I've >>> >>> >>>>That's sad... they should provide this functionality in the driver >>>>instead, it would allow to use access restrictions for some parts. >>> >>> >>>Not really, it avoids having to duplicate a lot of work in drivers that > > can be > >>>written once in a cross-platform userland utility. Drivers aren't really > > the > >>>place to be monitoring raid status sending pages, e-mails, etc. It's best > > to > >>>let userland invoke sendmail, not the kernel. :) >> >>John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't >>implement SMTP and don't do emails, they only provide updates to the >>sensors framework when there are some changes in the state of the drive. :) >> >>sensorsd(8) is used to send alerts and emails based on the information >>from the sensors framework, and user configuration. >> >>bioctl(8) is used to configure RAID for _all drivers_. There are no >>separate utilities for RAID configuration based on brand-name, just like >>nowadays there are no separate utilities for configuring Ethernet >>adapters. [0] > > > According to the various manpages on www.openbsd.org you cannot configure > arrays on the OS for at least mfi(4), ciss(4), twe(4), mpi(4) (like mpt(4) in > FreeBSD) or ami(4) (like amr(4) in FreeBSD). You can only do monitoring via > hw.sensors for ciss(4) and ami(4), and the example for monitoring ami(4) in > the manpage shows that you can only get volume level data, and as a _string_ > and that you can't get backing physical drive status to know which physical > drive has failed and needs to be replaced: > > $ sysctl hw.sensors.ami0 > hw.sensors.ami0.drive0=online (sd0), OK > hw.sensors.ami0.drive1=degraded (sd1), WARNING > hw.sensors.ami0.drive2=failed (sd2), CRITICAL I'm not an expert on RAID monitoring and rebuilding, so I don't think I can answer your questions about bioctl(8). You might want to refer to a presentation that was done at BSDCan 2006 by David Gwynne. [b] However, I can tell you that in this sysctl(8) output that you've quoted, "online" etc and "OK" etc fields are represented as enums (in sensor datastructure), not strings. I trust that bioctl(8) gives further status on which exact drive has failed, again, see dlg's presentation. (Note that the sensors part of that presentation is now a bit outdated.) As far as RAID drivers providing sensors are concerned -- a grep for SENSOR_DRIVE_ONLINE reveals that it is being referenced from ami(4), arc(4), ciss(4), mfi(4) and softraid(4). From what I could see in the man pages, mpi(4) chips usually don't provide any raid functionality and twe(4) lacks programming documentation from the manufacturer, thus unavailability of RAID sensors from those two drivers doesn't come as a surprise. ;) Cheers, Constantine. [b] http://www.openbsd.org/papers/bsdcan06-biosensors.pdf