From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 11 14:29:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C101106568F for ; Sun, 11 Oct 2009 14:29:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C30BE8FC12 for ; Sun, 11 Oct 2009 14:29:24 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DBE251CC4F; Sun, 11 Oct 2009 16:29:23 +0200 (CEST) Date: Sun, 11 Oct 2009 16:29:23 +0200 From: Ed Schouten To: Paul B Mahol Message-ID: <20091011142923.GT71731@hoeg.nl> References: <3a142e750910100150g7459e037u7b84b4b4bbc2bf8@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jZNlLGxhPb4urluq" Content-Disposition: inline In-Reply-To: <3a142e750910100150g7459e037u7b84b4b4bbc2bf8@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Alexander Best Subject: Re: sysinstall colours X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 14:29:25 -0000 --jZNlLGxhPb4urluq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Paul B Mahol wrote: > This have nothing to do with ncurses, colors you like simple can not > be displayed in current syscons(4) and making support for 256 colors > or even true bit color in sysinstall(so that it looks amazing in > konsole) is waste of time. Yes. As of recently, our terminal emulator gained 256 color support, but this gets smashed down to 8 colors, simply because Syscons cannot handle more than 16 foreground and 8 background colors. This is how colors are converted: http://80386.nl/pub/xterm-256.png http://80386.nl/pub/teken-256.png --=20 Ed Schouten WWW: http://80386.nl/ --jZNlLGxhPb4urluq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrR68MACgkQ52SDGA2eCwUihACeOP1eVfV5fEpiRcT5m/dDGil8 jhEAn0j7EalAHPPP26T1cU+crKgyzBUP =FOYf -----END PGP SIGNATURE----- --jZNlLGxhPb4urluq-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 11 14:50:23 2009 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A55BC1065692 for ; Sun, 11 Oct 2009 14:50:23 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6429D8FC1A for ; Sun, 11 Oct 2009 14:50:22 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9BEoLV2046819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Oct 2009 16:50:21 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n9BEoLxu046818 for hackers@FreeBSD.org; Sun, 11 Oct 2009 16:50:21 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 11 Oct 2009 16:50:21 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: hackers@FreeBSD.org Message-ID: <20091011145021.GG36937@acme.spoerlein.net> Mail-Followup-To: hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 14:50:23 -0000 --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear -hackers, I would like you to give me your thoughts on the attached patch. There are no functional changes, what I'm trying to do is introduce WARNS?=6 for all top-level Makefiles and override that on a subdir basis. Why the churn? Because I think it sticks out more, if there's a WARNS=0 in your Makefile rather than the default being WARNS=0. Perhaps this gets more incentive going for fixing these WARNS. There's also a lot of work done by the DragonflyBSD folks which I intend to port peu a peu. Note: There are lots of style changes for games/ and sbin/, which I can seperate out for easier review. But I'd like to make some sweeping patches to bring them more inline with style.Makefile(5) Comments? Committers? Uli --Pd0ReVV5GZGQvF3a Content-Type: application/octet-stream Content-Disposition: attachment; filename="warns.diff.gz" Content-Transfer-Encoding: base64 H4sICNq3zEoCA3dhcm5zLmRpZmYA7b17d9s4si/6t/MpsNN993Qvj+z4Gbvv8T6jyEqiHVvy keR0MqfP0qFJymJbfDRJ+dGz890vCg8SAAmKoKienr1uVrdFolBF8ocCUAAKBcebz1EnRm/O 745ODg7dM9c9h/u3d+6bozP77s3Z3RG684J920r3r60Hd+4t3VedTgdZ+2ryznTlopGdojen 6PDop+Oznw7P0OGbN+do9w3+92p3dxfdFbl+dh3K9RYdnPx0fPTTyTnnwj+v/vY31Dn86yna PfzrCfrb316h79D372PXfTe5/P4VeoVuxqMPFztY4qvOz93xcPI/L3ZOIX3PC+zlynHR/7hL nL0oDu/3/If/eOXU/eDVynPu3aDso1VS/Q8vcNb4+AP4+IOqj2dSWwTg3vLdJHtLkMQ+v0io 9/ElfLU+/QQ+/S399J2//fDdj5KIs70D9MM7N35wl+7Lj+hk/+hg//xIRWk3h2X3FXo3GF4O xvhuf5XE9L1eofeDq/6EJn//j8nH7riPb74xqgFid7ajKkyRYIKYxFerpryFmnKqVxYsUVKU 6+6QJO7B9dVg+GnCblEUpZBo8v225SZWXA6BQjNBQWWtBcTBISBx8Kaq0QCxr3YJBPQGf/Au R4GnoDhMD44Aisub7uUlqMjV4N31t1fo6pLcd5b+KzTpjQc308kFzZwsXnVksR2t2E7rFXdu 2WmoKQaFZlIMKmuNYjj668EZ2j366yEtBvXjwqeAfBuupHs33enHn9D3/9jr3Y5J7dvb249i D2rgLi8x+gYY7HFvwu/2bBTFs/RuuYcbqd77q+6Hye5FZ1AuiJQJ48uKeveCpyCaD0h5s4FB 4GKRRi75sDl++etPs9FNfziZXH1D/3aBXgfha+GlLj92P/d5BlGqTJD0rDf+ejMdicpmxy9R GuInugHWCfzsjvxVHf1XdSjKO6Uf0WlF9cI4XQWuvu8oy2CkhGX8tfqSI+hLjogeQmG5z16S Jj/IUOD/RME/YsQ4JK8rc75GoMM182Zl1wBY9ftLwVUzNQG4IKMGyMfQ/RyzDptVWSqGdTTs DhpTXr0OxQpy2X93+6FQy5I0Jp8q1pjqnPpmFDUBnYmtBl3N1AT0goxabexbaGJPWQtLYc+A ILCzu72zrBtCWRJaBfgaSIKdxDurYi7UZitBhFajKmdpgqkioSmiRMwrNBzNAFKpz9Z2D+vV 0QC0+9ixy7GSKCYQyYy1WtFzaEVLraoOwQkhBFJf7VLU6DVRQrhUKj6kMwbonWi/hxDp+IYY x0l/8u1Vh/Z8CHWWgb2KE2IQ7Ip9ZJZ1N+skec5WkPdDLKsceplkgr3CWUstz0EtD95Ieknk sHpOrsF6yW2X3DTp9j4Ohv1Zd9z7+A1dYOPEOzo7fY3+679KiZbvnB5nxgsibe7kpt/91B9f /PJ633Ef95PIxW8f//Jaapi1mXKDpYUiCVb+natpOhSaSaGorLVK5aTYWFA5rFToTUmxbApC FPrlCIgEk8+X+Gp8+ynMTZz+9Zh8e9XoSGwuW7Ez8eBU8+lR2uzTo3TzPgILEXqIvKlraVxH DXXNd8s0o09XWGsZeqeqoceHQnRsFllp6saBMDjjoxA7R0isD5XaUwujBGbYSsYdhfR62BTZ TA1g3VhXmIOCh+R141CcqxLHlJdfh93rQW88Gk1p6wzjSoCRzlXh/F/7EwOULOdX3CYH6e+q LmmoBoiVMNef5HxbZVZkkrltkSfQdja7x2bqbo7phlWPflVq2WGQxuGyHLEi2QSyEm7TWXFe C3NZHJQsQTbx20HFh/+x/Ll3rwGmLIcRNqUC6sBz/tczjM951kTrzCAr9l9nTTU6wkN+d4kt KhGr3HIhM8WAKnulvYW7jFB2O8Mmj2e7JNUAyDvLSVw7LYVQpRmAV2CtpVWAGrY09TPIVCqz 6tmdUuXE1vz2/URsz1fzhM1Y5axtKCNmW1p3bnkFLRBNUCzw1mnQjkiLdsSatGxmncnCA2rH Sx7YtaBgHESkgPihP7r+RgdGuDS+XF+xmwmGV0T33g19PFDCz3n2l/giuVvNjTpQ2/KrWroS sgGUZdw1wCQ1mVdkDlUL1VmaZ+1ei5DSy9vp4EqaerV8hin+WaXe0gRY26loKItUE1iLzLX6 3LfQ51asFWVyiytGGYnW3oKqmgCzjL1yTESCCRwSX9MhHEjhH4sv27cp7LC6poUb1bSwUU0j rdaRYlPksjgeWUL7NgUWnFTDUqQb4VLCXqtbPMkXVnNgMmEZMllK+wrjLOyl5wblZkKBaABK kbeOqpyTWsObZb7+yWV1Ejv2YDhMcOGp0O/xS2g/9k7y+6VrJXh8SFKiThilHgYT3/7yCu0o UreALR6alrfMMsUEVZmx1ujxDEaPp8KomgjhIMI1aW/l2ZSse3p49OWm+NNnGEqbwLDyo3IU RIIJCBJfnV7phEwxn6jTnCAIfyo1o77/Bx1CfyPyUX4bk2zCgtL48vb65lWHTkp4qee7ezby LQ9mJrCKweoxsMQ+1keUWhGQ09h6dGEi1UarwGY8tmUvXJi8oEWBeaAkuF1H71HM0nfbe56g 5+IsK/2uVjQfv8480Rb6PGla7POk5YEHFcrGHfSmybAj42wLvTDQohcGTdELg5aNOSq0aMnR 9JbgmMOophQNmWIAhsJYC4uDA7JKdVCCRrmjCazVvST7MHoSvE3gydxnBK4BJOZ6Qm5tBAwz /y6euYENjQMH95g7ZTC2jsb1QnwuN6N3DYZ8u9oxn2GZzSL7/ExfcDLZtPQU7npFSNw1Do7+ mCKEF1xXhqhGGXbYIuaOVIhsCXMnKy22fCln2pVLtJ36OE+8YB6WF6xCMylVlbVOkZIGnvwl MyIEWiqHNj75YoDQf7+fzHJPjw/j0c/QqosdYWmGtR0BEhx7JGyR/A9WmjcvhMTWtIkiwQR+ ia9+33qm7x1AJK8n+FKoJnBno3kC0x1kFcd1A7GaHPJqwtja0FosajbXGCUFoiFwMm/9tYkS 8GSX5J2zvUPRHfl4//Dt/vnJugYL6yPUJ4Xoh6sgFdox9uLMAt4VTWBOQ0rSyiz78d4hLi42 30Y60ANmjFFFcDwwXl1LVAYvCB3BwI2sJDngv3fs4pD9HuFfGMrB9TFLO8G/iZuuIjB9sUhs MMMKIcKvN0tWdzG7TK27JUm//zVcxYG1ZKLu3dQPUmxWJ1pDWXDIKXjnUIzXthUljmp15K7p 8quKvZ065Nxp6o9AMKo7Il89F2wyZ3JwWuK/r/run+6flLnul1YcQYP1wIp1x7nj/Q2+FJs2 545os3PH9JlMNVTo+VoF58rNFd1QwaXBjNarLGsMOvligeQP1b8cTJmxOO2Pr3vdG1GpXcdL sZWYurFvWxH3utJzlqtxvUJoQ5Pv7xy3VJMlgoEmy3z1e4Bm44l9/DSsD7vlzQB15t6PvV8D x3KXazMmC+swV234Eu5dhy9z1SZ3NkpdP1paKZm3AALuCPiTOtbyvjNP0lJS5DES+fpTYowf 8i4wXwzVaih95/X2MsOmUxebznpsOvi1rvrdIVmoxa8mQsAsFQ6V5HJyKS75IMEsFzxRHLbq gzIL3UCL3aKzVpFgosWuobMW2xv0VlgOdzBz4Do/jPuT3m3/R/AFzJMwipP+rDe+HfY+/lg+ +rGXuI3bj6w4BcUt1gSJjoqcZP2zQApjV03zvYQp4wEZRXBdZNqOoeAjObqkyod1+MnQApOW Nvc7QuUbRWQ1Jq/RuZxMu9NBbwa6MOtddSeT/gTrmKGxUSFLt8orrEJKo391SZIN/tmaZDYH QBYnG+un6j1VIDbV0/q7NbSbHiXHawBxRnyp9pfe3X5h3Py6sPXCEBGqp+7S09fdYhZTdEok 1MDojFjpZ4KRjtvw6MFOTh4PhVYdWkXS+GU6e1SxoSn7D9rv8hayuCOJNIx8W1JeQEdgA+t2 ZEkPKriE4sI0tRJyINkgYV2JqdmalVpBisns1mGZfus6TdIGas0NQkWsSlzssNeiKx+7tImc sUQYGYKtmTeeCgVtpiDKIIp2m8QY/Gdog+/FcXEz5JpczXRBFVK/oTvdmiLQdzLvCvKuex10 Up5mwMki6q+UcluGfSuIERu6Y3EoTzvEjjC726qaxZbnHK2DSs7UDCtFxp9Bx8grNVWxRy9O 0vUVVM3WDLyClC3Ch/RNHH0l9jLVMNeWkhdHnmJQIPd4jKS3/wpUE/iLzPVjPxxVW4Cdtmw9 8o7kr1OuiWUZjEFQ+WttsTmHLTbn+aIJFSKM9ek9HvLc83GuvvvG1mDsOjCDIHbdN9OP4373 Uuy1o3QRu5Yjdto6YZ02Jnni8Ekz4a+QTEBXOGvBfXAMeDPTDKveh/eTy3cfLuQNjiCXeZVk 93vCpkdCZ8VFiWdynAdufHFOZUBOH/ojN98QJtyt7iHCAZ19gZUpZtlxym4eD6BqaauF9az7 Ry9YaSYzZJJJWSmc9czoY2JGnzSalyMPFObS6D2vVOQOKhW9WNAJBXIzI3qf+QKxHGdiVdnR zIitnTcQjWu5jkIFvRoM+8r0LL277H+GyQV2B25f5VNYUKWXWMPy+V985biPSWrBnPDDo5/P bXVqIthG9fcCr9zOlAgG6iTz1VCmE7AoT7i7PpQriIBSvRn3e4PR7YSoySs0GGKkr65I4V10 7lDn3d6d9SB1Sko8g8nH/tUVTP/0MY59fHE1+jAYznDp4eve6BrDPJt8nXyeDYaDaTHIgRm7 vJyVT2aSUfs3xSDmw3YjU8GL5lpDQaWZlJjKWq8FOCMtAFuc3ZHMhKrKiP8jfrreHTzYg9pg zLCfhuEyWctGhrTr81S+D5k67E9HUOSz2e1gNOt/uRlN+msH6gWhpgzsI9exkcZtfZ7K99F+ JC5LrMGDm/cXO2Bqj979JxeMh2ygN/Rnz2KLWbskH2URmkTmhiNTqdfsLpdfLV5221GkZ/47 qnAkL0nsvOylFiwe0t9F1TiipEB2ftH3beXZUS258JX1MxOtqJ/dtwLDFkZsDtQWRqQZtjAS q8lU3bF2a+rODhbKXYwxHB/6w4+X48k3BDpjw1879CN6NXthv7BEcYd/KT5g2JE+B0TtnRHO Y/L3BP9d7h3n4cN2yD3iyArZ5tyjPks4ZSlS87OHaxdWzsEVtiBm727ec6MVPoIuJereIYsK 0+QVmMHbFB6N4VT4GFwo7AHkO7CgBRO8gMaB2cz5W7za5dnV3Ls8t5BZrcny14hvb9yjejon 7ALRXOOTzbe6gBRuFxX9rtuwANmrplZaCUNqpZsgkRqHHj14Q5xYDhgcw9GHXq8/Ho/GFzvf 8fGa3BbAQ7L2gN1LNZwknGWdFUJsC6IU8IakY/uMRbzJiwGk8w0GmfCs5jLZYn2ROi05VA7x Nm0nVI4Ic+omlaUo0c1LUWav1YofkpHi4VGZnUigunhT2a2W2S77gZvi0k/l0oeX0/QGQAKP H+pTFM3msXVPr6DUXHoZQHkSXwcsbYbL4Jk2KzNrlS7o1YL4C9HrZRg+EPeijAP3zEyobQXs 6gVcm+EqXlFPOp47e5dlSF8F2FlDRi6XQsvMmOYsEb8pywlXkOY74PAUW473rO/fCAoHgkYT xDIF5uSy/sIIwF1T/HZN4NttgN5uU/CkwUze4eGBoNj/wVgQd0yXSMoy+nR7Q0tOSJ70ukMx 2+TrsCeJ+jS5vYb+VXBj3DGuF+UhNJu9/26z18eNmmAPUKgXGfyLvJwWeektkGoLoDLLAQpF Ywzgzy2nKPZDwWhQqWykwK8WhRwFNTJurH3N9qUi1bih9o03MUFnmzva7ZQb2z5sYyprYDGB QIF/GShwtRRbH59sdcraHhDFWx5GKml39HLlion1+X23d4F/sN72uldviApqdvCVZ871dZe9 E1NE+myNKpqWeVBpZAWbmFiBlW6jzANL06nS1r6sImRlDlnOWNZj9nsijahIChdWMmTKFQbe gytMuVxhlFQitky99J+gG/Wsa9ba0RJoDivURCIb64nMbR56UqMnILZcUcq65gff9bMUUWXI /QknnOm0gTyNq4PKU1bUdV6iZqGX9FvtFHvsJm7gVBS8ksG46FX+1gqfChaGXjSBgAumFb9L 7sjUQxKSrU3Hx1YciYXP8h0YzbPhC/JwVG0v6dgylWLfwJUqfxc+4jP6pq0M0teox2bKYawa h389JHHQDt+uGaHnpTnsT7HuYEBpCAEPjybzhxNbc6ci09IK7mHZUBfeL9dHRRvFcsN3YUSb fZDH2gRyudxb8tIkZrtOTaliIHZxos59X4nz3Z3lMlcxScFUKZmeNXnbXfVl1VWYSuTr5iUF oLTIunXV6gfWzEtLXGqL5UmVK2k+ZVmYJyzCRlprob2WkoUWZJ2qdtaraueVUGw/5dcvZPL+ a7fX+4Y6DjRy3asrLAQPUnb8R8RXKXD6tDv+0J+a9yRrpoE2mwUyngQqTOWtr8DSXA69JUUI FwmvHGt6Ez6fUa/1MSj9vELTCRRecU3ekrcC/CXb7y7YEppOCxSyoRao3HW0AMIV7x6esvnt nZ3UjmbzpXUPSOFr4RI3eYFFQtaix1MvzK8x4dFarly20W/n0YKNfI9ufBcmruxrf1jsKczd TPE3PukQfGqI3VMT+6siOAuIzCfxnnL3NLg7pGFv/JfApar5eJrvGqbDH2uZ/iZvK1d8dzuS 7Da0szLOmLdJlDGvUYyxyqAXzNkskwybTZ0V2aQKowcWjM9Gy/CeoAqznXyLKfiRQpNE/dcy EVnAfSUA4vVlHnSfxzz0nayB2eANeIuVvQFTmMROvGzpUAighqT486VuUiTIPBFAfH48Czxf O98JbPfckQbmMsmJA9rnGbhnlT5397ucK3/sbnmcSYB5Vwkt6TutqPbD0lkFy9AqN9OLVAPV LmGu0+qekWDFZ0pkwUwYW1rM7tuPK7isir653CD45rJZ7E04nkyzpZjZH8ss+CateO5yvvAC 0qNzEnToC+hPYI9jFIUx2c57dUl2xBWHrTin++za+3G6dDpWuErLvdawvhMR3yC8yrjfx681 645up6wJXuaRP8H1j5s1lAX6PuX1d1WuXbPvkWti+ZvttqAhvnNSqhxiuoFeSGx1VIKG8OIb DXZgOegAw2Ed4J9fxITDk1Nsq8k7IX9+Pxpfd6f45kB1HIV2xgSFinrib1BP/Ib15M26erLj ZxWF2ty+oKDZJG+eiB6DXBXZGSqyrgoCstlcDb9oMHc0rpeVgbyQ3D3UZSs6cmoiP7dRL3yN a4pMMdIFf97owAnaffAyzSPYfP8PKMhvQkwbEkll5mdeKzvkmXnMxt0LnoKyrGKv01K34z8k gRVpgxmVkE1gLOE26XyOam9pYuGISudDs5g1rC5lL8VHAHkK2ZcvxOxhpxbl9LOqTaLsJerY aEIcnXxTxXA0uR1c/kjO37geXfYvTk7emBQlyCwvRYliUoAyo8EkRkUoLwYTOxBqRYLufod+ dpETouFoirwgSa3lEqULVyyNIzweC1Bk3bt7WcERbptVkELxocd5svRInBDRjhAfjC1xwyeX OLCrI0HDIgPHj1BX/8oymBZggb9WHTyTBtQD5yfE+f/6iA72ToHjeP/N+f6bM/QGv8Lbn3Ct vYu9+0WK+s8R+r68OxTfiJaFmAIlwk+foYfP7ApKw9kE3cn5xHqnHGDTSkNJnmY756enbyqK SslgXFQqfz3nMWqDnJfHsToS41gdkaBvx4XdSNej2+H0Yk2rSjJ9y7ckia8sFQpNyudYpFSl je2U8e0qbSd7shw8etAbDT+Lte/Bw4bPI4mjo/+cTplgecvmd2jouk6C0hDd4cbhJbB8z8YN wwtaesEDLpF5GCMaANxaImcZRm7ww4/Ism03AS6QsErceGkFDoI5QPpa4nlIw5HUl/HXaE1R 3ef0sLJNUTIYK6rK38BX/Y9WVPrKkqLSJFVRWWqFouZ8lbqmDZfG9XmbKrCIKhVgEW1S/Atz r23YDHlYulHhuw0LdhEpxbqIioVK0iqKlPPUazzyQoTTsW/eT6T4sMViLWvOMs7WitxPnDCp LHU1h3HBFwTUWwKnK1vn7Zc9ex+p+FmaqgE8uUIJcs7/vwfaUBeDSj0MNtHBwLztIfGF+TZM o07l9noI+2lLpitXSbxH3iqO7L0VVigLvBgUfcUXTEJBdYNsj36eoA5hCIEsdGdH6PKcwvEO QiIbDAXuE82za/CAaq01BSIPsyX0fZfD9xOpCRwI+AiRuVDJWRrZNxSmUejXSnvCi+i3qNpp tW6nGyl32rB1PXzTfusKLyM1rZCgtqskraJRZTy7Gn/7LTWuZW3rm/8ubetquaxWQTmDuRIq /CbRLg7/OdY9fWVZWUlSQV1papXCcr5Oc1U7rWsFtmj+xa6H9bJSMQpZjFWjKMFEOY506yTo AsnyaddYSC4rN1TMdWaqS9I8U/YOojaJskV90r0ZBOdRXgsFpOXheRYImhCpO57HoY+S2Bbn X5kSIlRYM5X0EJUZlMAjqCL6o1QxSZ0KLRSpxgooMdfTvfOq+bHD8oZpp62GCb+vbObhBM1C Q0Yu2HYkkWmT4z4SS48suhaoc8dN7Ao67uRwqVbl4OR1kxtrvkk8Pb1yxFM6YNYbgPhRBQOQ QMKCMq/PzSDC+U3VeuXMK9RapBqrtcRcT61p1PeyQ8k30Vf8IlK7h+/VLhSSKvpPyiHYewea +Q9NYKktjbHXh4FXNBMd/HH2orEmBvh5lV29msNcI1UB/wJWIHtnWYFpWkGJWXKVImec/zKW IB4Ka7RCphhog8JYyxsCt0q7x/xolbXnoWVrw+RRrPDIdW5s0Vsb+Q+szEJ/hjFip6KZnLJY R15HOldHeh99KWEKOKpDMRN3j1ednWQhfnaMlQVneHOwh9NhN4qWinuycuIbYP0v/BwXzfaI Yz0cCQPa0fHugzB2O76V2gsvuO9AIL3kglUsllsS6c65BNdehKi7XKIp+OSjGytJXMdU6+js qV73FLqpBqrs9YPmnQpHSmx4JHsbNXSeeGG5dayQTBBSOOuft1FxJCcVWjySk6a35OYeze20 3MVdphiAoTDWd3c4M4mhzLdKRnP6wOrjZITcEHqijlQISqbd4ll4emVAUeXpdaTC0zNNoI+g pU+u8WCBxN+K5hBaBH5JEBK44I7r+CpM9k744Yqn5HDFt8JhEIhImoHp5Hu/C4cAYQKNZOKm 6m4VYSTxM7jqdH72vSSB1g6rXhqmL5Gb4MQg7OC+m/i9L7FoR+JL8CfaqcQwWI8vMtJpjIqj UWqJZKTVMufG0y61FBueWVMLSVZBZcg92xfCbmFPhueQEJpwVKP3mLhRfoUHZnAoWTYeZjzE +soDP9OgsHTPjRQkOg83S92yOtx0MHy26DO7W/mE3dK3asPZO8IqXa4/IsFEeyS+Wn0neGGe cN2hBYKFQLOPh9Ojn/F9HIZp7q54fHJyAh+vMcXks6p4f/xvugOdhCi1g5tJv6eE6IEUpIS7 xGnSwcOwD9HO+m4z8E+16J82hf+02fGEx9KWFCJIKI5TWj0UsDBEn7rX/dmkN7rpDyBi0S2G dvy+d3h4fvhuMCE7czuXH7uf+7Ob0dXV7CNid9gqOh53h5eja8kCrixzpIshU/dddte+y65c E2lZs31Kwn6lXMFI2cOOJbprSdpKpuVuoeL+tgpTy164miN1S8gGWlTGveGB4/WOvaw46VJz +GU+MM9fmg3s8oR8SC6kZWf45udbCkdTFg/2lcR1Ko6D1L1pG8Ue22HsuOWnhKg0gwIvsDbp 9Om/74duiotcceM9QAfn5+f7Bwf7h0fozQl+k58O3yA/vq/y4cXS2IvlZwy42BoLIQrdwkog jB3LkG+q5Bx8d5U2P23b+D0ZZCin5JR4YEuDlO/Qly9fsGBc5DA35+MP/ktCH/S/7cX/kfwR RuPL/piFrzEobvcON4PlpS2TTApb4azVSZyvGcNRodJsVBG+jgIwLQHCiQ39wH1O6WW+KpER F9YSfrL7uZWwzHIazYffi7z2GzIceMsGXIWJfsopzNsDN6qg86cqSwCl+UDWq7JtTYI5R2GY 9MaDmymZK2IIJIt2WgvXDh/d2PGSB40OFelGilTCXqvleKs7SSjTpkxyvQ2wZpUKjgVyNYjI NCM0FNZ6xu8BMX4PJOOLiSrVWEIRdZRnFmyz8bg/mY7IIQmzbu9qdjMefO5O++JS2C6re4RX 3OCXJaE4p/IJbRqpwAtSN7bs1Ht0aeglkstGjhfDFGfy4tOQKakVucqBz+Rk6ZUfxX4eCjh/ TKfyJTRhNHUf20oFCle6k5AUkomiKJz1+toTqa8FZvR/qaT/S3ofVon0PSnJm3ekHok6HkSr NA9BgbPQ+8iK/USIwgo10SYlSgPGprj4XV6AmXAowcntO6yWFyhOf1u58UvWK9On89gJbTyb aTB/8i578g5/snjyYnEncEc3SesdnZ2+hhOAS2dwfef0+LV89BadxN0tk/dvmbx///dSIpUn +nTnM8AGWpommugdMsVER2XGOipKJsEP+NExSrNOY/dc7FT4dMITHcmwZgF/hEEBT8lbSuDi zRMVASoDF6Bic2Llh3cuSwSz3wDYxHp0bV1XUSAawFvkrR98pmLLIxcrnbBFqgmnqOd9/10c y/7OGmQxcwuNaFKxkz5pvpE+abCPHnZO7x4zy4Nhxra8U2M0yba0wz1vzPahErcdFSpZrFIn fCqPOlwgmgBT4K1/kqiEDJPDoWG31GFH2kZQmLP5ML652AkjbCWQAxiFWRyTncZJFEVVsYnK 6CY4lbE3PRhCEMbxylPaPyYiebIiTcBqhWQCiMJZb/bwkMweHlW0SkQsb1vIDehQwbalJKQk zOcs6+7avGR5SnkKtyh5CmJCxQgIEo0sOimLQWu3Ypv01ukqcDWuEwrJoOhUzlpFRzarVMQy o0IZpPRG0eR1LhAy54aKD6YCfGvJoWtlpHrolXLWX9UuOw4J5dvCsfR92BnegQAAvdD3XTx0 csDWJTY7BABIPd9Fdy6seECmARldBQ64gcGEEs7jJRC6wVotU2SlKAlx/iQlUQI632VhOg7z csFtshGeVmKp2lhGMsNT4jRtVEu1EUuUfD3bUaZiBPgSiuGnG0Z+p5NUb/iZi6zBstK9A3QH PjYs7hFJsNLf5NvYF+NVvmHqV7KCgsgSiiE2/n6CLaJID5GawRSpAn+ts2nfwtG0Sv8LYvhA wMY1jZxVQFJndIQpTSRJbnG90XA6Hrz7xpaMINBQ/0P/ejRVw3CwZLaUM+xPP4y7Nx/57Yfu 9PqbIcJPD1psnx6aovr0YIjnKeD5VjD9sAiOJb68jy1/7wXBlM7ShSE5DU3GBu54vJ7Qpe7Q pvM+8Sqg43T4eeGH+5X7aV9+7E5mg8m7q+7wEz3IDBdI9+dPEIAXopuNbvrD2XX3y8XpcSGg lyHYd1YQFJdONFQzyFXmGqgfQYN3pGgxlcMMSHqzd7qFVu/OSlyI46oHQ6GbwqGyNweESsrb RZ6CWz/Hi+nVNhDCmbXoiDRDZCTWVvpFELkNAHD1ddylHgSVbghEgb3WDMjJmoUDLnYbgPzu RYdaNCSiIRQyb/0ocG9lr+d3fz+UJ8eIYF27O4Og7LPR+/eT/nT2bjCdlLSwWOK3BiCx1ZtK rNQ8DSAriGgZOSZfAnA4mkHb3JZO2WfnOpREkhk4EmcrtQpL3EKFss/1H3/e+OPPW//48618 vLXEozxLW0kKdEMYCuy1euBT6IHfSj0wl8TsQYQQT4EJ9hCW/Sw40CFMUjem9mDysLCUjXmD 4bQ/vkDZP8eddad7g8lodnZ2ct45OIGUyz6k0AQ0j2fvx8I9iTC/iGcf88RDtFjNPt4K9/Fq Nr7d+zQanHXGaPUwu+3Sm1vcroFhDxZE/gbi805Miw8PKx6cO33xKXTT4lPZWzEVuNit6HPq W4EeDolqCobMXKtWkz2LJ1VQgNAWo2tnb7vQTylINEMQFobTCiegDSeKOQ1S2OgCLuVF9dYA cO2HQN+wKWRTGBTuduoFlboVMB7cFz0UItEUCIm3Tp0gzTv+S+csRTtvfNObfM48VbnveW/8 9WY6Eud048hOHom3Kzih2/FLBNtOlcWgVmB7SFa+FjaJaAibzGtaj9j0EgiBox5imzr2k+iw OO2A/hxS2tEhiUKvLnMQbnHlYuXno1sq+gCRv9vQR187mSeSDEH1o81H+lhIhq8fkUmm4CE7 MgPF7v1qSWyOJHJtz1oqBkZL8BRXGstIhvBssr5Y3l6Fy+18vB2nFd8vUo0hkJjbQgEL3Q4Q S8edVyAhkY2hkLlrYUGO9lMMcyqIVxo6DfuCyHHdS3Zs2UJC54qM/nFDfoY6Xj4ZwGdduWdO 2Ta1pXcH/9v7yxDMf4H5sje6uupO+zNyyAvqXH79OsOj5Nvhze3UGPbYrwA99ptDHvvtK1/s b0f3Vn5QgYJINYZBYm4LByx0K0D4FcrgN9cFv31V8LejCX6E33HmVjTJhRzGYBQEmE6iCSgw WcIqHEvJVoleyALSEiJhWPG9JniP2h4pe0Cx2Jkbx23CHLtJUgWyRDeHWGavZXO+LdicTA6G 8neI/FJuWrJMgnW5CniiYGRyWQcoJ2NzUx4M090t5GHIS1AQplCIKQrnsP5nEy9kPJCkb3Nk CHrkhVrARZoh2BKrKdBs6jdxQMwrhCt572Ywmn3ujyeD0XA2mY4Hww8Xh3tv995kpRKRGTDb dyAIBr7CiklWRmloDKL36YLcKgvQ4vAL/IEHn/ts2PV3ftgNTL6LM/aaF/rlNS7tUtK3X15L Am5wPw3nI816o+H7wYfZR8xL/R1nc9yqQR1aYBbzkiw74FSfoUGZGh9yenJESvYoa7dvQdHB /QYca2Bogax7Cw7iQI5PtojhTGxHL+pcEccdYuqA1YPHunkmwXNAyMUbIupBcHndvboa9ViB X5DqROYYWNwWpmMzFhUFN3Wjd/9JqqtIQZ0ICSTcBDIqFEbePJqW1yqp6FFkqmlJycxtzNPB dDMRu42ZuiRaenooZKohFApzOwsRROg2LI3Uutf3fxLREAaZt/ESBIjhTW4P2tuUHk47D2Pm ZbL0kkiYi0kxeOB7Ytm21sgQalBbOK702rRqrEqr1sfNq20okVP08C8jmX28Y3pOnhz/pbhv hB0zvuOQQxbx30WYKMFfBCUh56/zY6cZRgoV7KwZocMQ2Uvs/e//MZj0Zt3p6HrQo1t9clZT SOMqJx2VbApt3I6LDhOUr41vQbdWWgxWTT9/1XIQK2elte82cRnn7+sG3r2v9dNVqGZQqMy1 7OZTsJvflm+rpgKFQQhZKcjHH5SORx8knZzhKeqMdEwwrEGI2DFRpuA96pF7bAzbY5OuTT75 14UQnSxSQfAIA4jgkQeIbN3gcZ8jK3C0SMhUQzAU5qaNCZUjqAq5JwNVfrmF9mVuLRNtMysT zWBReFvpvonMbYDg4lGqFgSJaAiCzFtrgultvhmNf/cOkYO738kUYtkSvxzpmFLWbtCG431/ inverOHALQdjZ/t0P83As3gyuaIbcYPQcNwLn6IFS6QZYiWx1tGXt2Rt4G1mMl93Pwx6YPfw /SfJwordfVhG0zthE6aLv7yGPcqM/du+b9179uu/8ChJfNJAcZ4vXyggvKbNNHzzoV2FqkA1 x1Vkrj8gq/AhoUKlzbYtVUVP30xLNFMQDJtoqR7yb4bmmfZYcA2jsFVgQ1RqGIYl+b4AtnDL d4GSS5YNfLnu3dSxUnfvJcPvVNkXgHVu8nUymw6u++8gWJc0YvtK17LMVSy413umKlRjdO+N vVFPSvC9d2MB4XsIVoSWfGQbkNn0hN/SwFXMpYflPkCcjQTI3EZX4WsHuiLJED+/7YEulriN jw+X+sop0gw/X2Jt5/shoMIWAIhD7cqcRDMEQGJtBwAschsAJKnex08mGkIg89bA4Bxa6HOG QX50waOfb8N/8F0/3wZ4CLsA5aFFvpQ/+/T5evZ5iPMZt6sQllcPiUg0hUTira8WcjhLIkYJ 39aKKqRafyqRZPjNqZk/1QFZkD04lrbwYSG5P5WT0FUquj8PlvyWbkpCNoW+ZcewhkXMY/hN I2FvHwYFFgfviOcVdNsxHDFBI9jyzketYMy+Hgz709PZ5PbmZjSe5la22MeTLGaA35fFYykn moF+bxyPpXQAS8RkQ/rl3Kahse7p7xYao3s3sPWtkUI1hERhbsXxmgrdwuwGNijB4NEjIZNN oVC4Tdcy+McTMSwiElmKD3CjH9PDQYi9BmsZvkcO6YK1Y5YGkNAJouQloWn6g49yK7l31e8O YaMXTFfnz6r5BLrngrPBJG/CWelNxk5vOSO9+8W4+PD4oKL0RKpx4UnMxrYF1150gaisbdRj zKZXXolo+PUyb60N4Sf5BvsdMtQgQvgC29KDNRP04MaBS0YfRMOwdpNM86WVIpbfWi7vGZmF /6JnEZEzsmBGYgs4/u5pu2SJZoiixFoDxDOwzM6y3kGanPq7NDH1uzyNJXSh7/4+uDks6UJ5 PPKmuzQXrqUdwkg0M4xk1vp+rRW9BYjkbhTtdRULN/GCeaiHQCaboqBwGy/+75QCQaRuocIs 3GeIyKkHQyabgqFw1wCDzGi+ZVrBFwKYoL0DtIA1gOKiE8sgrDqFTlnkqGK+hbMFawTWlbWQ ho29oWTWllfE6Vo4+jMviXvadstr2mp5G8yJypoCwfHY+Vy00nqyZhV01hPPjLyPw1WUlKms lO1pEVq+x2b8PFgao4z4gpJw7TCDNHDcQKurCtUQWoW5aXA9KofbzPSO7z5eus+eFIVmxhz9 8I0V3ydbGXR5ka3fqiATDRGTeZvuDSFiMrzgBuCKVGco6QDMz9LBKWQKqcxZChZ5sKTEGLCk Aq+kOVxJK2glAlhJI6zM8Pg19LSbPCSaGR4yq7nhUX1Gxyk9o4OhBs/aQtX6NUz1wKSNcWl7 bQFL3MLHP1RZYg8b2GEPxlaY5OKTrcETObyu0DvSEEPUTDwihPtZsroj+zTJjxCWULUixBbl gUT1XrcNjcxWZ1MauLKWPNcQcPdlGd7r62KBbgh7gb3+HNpbvfJxsYoGlmzpLmzebgJPqPdr LWZoAlC4attXOpO7jUrqLZfWUrtRWCUbAqJyt6MwVKq2Q/vPruyh+Ktl7qFIq7AWFZlqCIrC 3GxpnUrhjdcDO0eAt1N8pIkY4QDx322oUBpXtvQK2Rgt49a+hgpRqUY2ERmjMMa9MzOIlpbW wBZJZtBInK3YAVjiFvRjaelnDySa6ecnaevfn6RbAqBqB3CBbg6E8U7gUgdeLok3K/yehKyw nNi1BVde1Nr00tLRToSIJENUHKeJiXjCpkIqzlPJp5mS0CGn67FjTgoz3y1A41qP2m5IJhrC I/O2U31A5jbqT8WO5mXz3cxL053MUmzhnV9XPLKLy34CEkhnmbwkqesTv4P4gXoKgleh6jOI b9K7JQk2J58YlPLYc2HisfwYNz8ivnKuFRPPBpCQePcBxI5BbAdZmr4QR4dHN04In1QW/GA2 +OzIi9y9ZIF+hxtyQBujDuHQUSGHmFvuIqf98TUc7WtelK69CKuKU6KbF6nM3nQahUvKmkJ2 r4VXGMqhLPOBVAVey0NASf/2aJjv1+ZwVsTkUsnmYJrG5dJiiQWJUOLb2khC3u0D+awH8bkx gM9mditpYA5OM/jYzASJgmMj24a67swt2FlDJvbuyYmvsotyQOg8QgVxesAILulRdtBI3C1p SKqXFxL/XJ7TuMrmNLxEmuHYU5wxBkPyau+xjCv32Y33FuaAw4pKBegi2Rx4ids8Dghu4Uhw zWWQxwolWwE8ukP37uXlKbYiRXWHo9nNoHehuI5Npt2rqyuIyd9odwb1UtEiJVMNgVKYTQ1H Vr+JlBrbBNtfmYSABam7f+dBWH8tRKWZDJEql2GqWAwwImyPChPiMNNlMYZg/0ufnRi3zjWK tIFEZMuw2qHjrgFVytIIUllCK2f9MHxBsnCSaCliyAT+3bWyWoWf/VQXgJKpURGoMkxt4VKt hJ1Y190bXEKdSxpO7QficEUOCfoRdUaH6IeDN/8POejYjX/MDdRVBHtpnDswUP0H+m70zg7B 3ZJcs/kYVtIHiF1kvGowWCa8pHzRHpxelNixF6XIg2O4WN5vxoX2UFFWD82L6KGF9uZBd5QO OUlnuzuW4fHzKmjmG2DT9qELROY2BrHhfcVmLYVqCsO9+Wat+o4fVHyh896qZ3zlOtYmi1jm K1ila4d0xYoPaOAGrEL4nc3vyMaE8kAtl1ejD9gYLLGVaJysm+61ajUBzIPh7eSK0MxRTCph TDbBMWnZnZ4K3YqZeF8VfEQlG0NhHHxkvbMok7qN6dYwrOiowuYdVfiwPXeNc8ldA561jTY6 eZzrq4tENMRG5m2nsoDMLdQV/1iHgEAx+3yRsZa3+UnubZ43nf0v0/7wsn+Zz4y4j2T6032O yEYQrBSF6ZD7YOUfiwett640+Hna5XOJZoiZxGp+9GKfuZWAnL24LMAmUARfzGv51i/ePuce zETqAbqmP37+81yMacK9dLMBEwvfYIjyg6tH+cFtjPKD23wnBK6DqaBxWIxyhCDMui3cJZl9 S6kf0XxOJuwhYOwOzM7RfYfo0SLr9lJ9xgNTusME337tT+TtrdfdT30eIvPil9cn+AWP35wd HL4xDXoJr/20sFIvqcJXyWGOsiqglXX8nVyyPI9ZuUMlG2kK7Hsk9CUMLM3AcxNtpDiJZgiY xNrK4hyI3Ebr5wVe1S6lAt0QiAJ7K3rDxcoR5bnV/btsnoP60EZsRxch5ndz0Kq23Rfo5qAZ b77Xj4xzyECodq5AGrgY+xD7D3NPv4lJoRrCoTC3Yp5Todswvx7oqQR6KBS6KRgqeysBA7lY CRBqpJG4pTxWOj/JQZwybHBggymkuPPV4ykSTcGUeNtpp0HmNhrqh9TVO+kpVFMYZOZW5uGo 0K0Asarqr2SqKRAr076KzaMXj7H6+ze5R9rCwVR+oo+ULNEMUUjuk7abFyxSG5E080TJ8Urd 2LetyLih0PfIjfvitn0UtxIGSh/upnGsG8NAN9IsK/1SiHFDu5DATW2L7IFLQ9+zyVa5JLQf Eu3Ozs7l4GbS7wkq4UWJa8uKQ7J8M0UqgogBerhksilmCncrxi6TWrG/Ytjjx+QNbr6I9Qiz IoDu2Rykqgn8At0cpk2n8QuzIVwoUpNg3wUqHyjk8FTCaQie+3Qfa/snhWoInMLcjnoRoWuW EFGpUwhZTUTNYkjjx1Z4vilUY5iMz6OkOB38K5xHGcyTqsGnSjbETuU2dRos1zEqVdPUD99P OOQIFfZvILp/wwwiT7/5R6IZguPZbftcg8htGATaKe2g6YR2sGx5hBBs49zIIIFlhJW+/VXp hiAU2LcT9oI/RzaQ/kSxL4KEuurocVbopjir7G3izKX/adENI8+tCgpUoJuhW2RvetAel6Qz 47VzQcAo5xvdDPoYz8n0mzQMGGIb/3bcn40+98fjwWXfHMgKM0Mlm8NoamhoUSQO9n9eECHK 5pNThaOSwxxKVcAmaFJZf1ZAI3CZ1GEpE81gVHi3G3ODPGwLXTgJ5Lh40OMjk00RUrhbMWWY 1G2A4cZxqJ38VqiGUCjM7SBBhG4DCD0IjQGIN48GFWXh8YkPi0tDcm7FUYV4X1ecHlSgm6Kh srcywOFitwXIvBKO+SZgzFtec6RCt7Dm+NsqTLXHcclEMxgU3qZnJhIxigP72mgx5VNO2SwL mXMyQil2q6YFFKoZTipz04DdVA7bG0FvCjsh2lCY2H3U4/DYGIS22w4scTsfHz5U6IFENYYg fGjkSXys6AHI2crsYVw5sx9vMq8fm8/qr586jMuCS1VshTEDI7Krhtkq2RAOldt0lYPaFUxM drAOvz/Tn6AFWzmuuzetVRjtKnPcdI05Tv6oUUqcbKMJSRZ6SBaNMVm0XXeShcEA2H12bVaH nUIlM4NHP/8aN556jVdtr3xhiVsPWoefAfslK+CQyMaQyNxbrkr0cduoT3CQi76VkammGMnM tSB6WznKRReISlVM+S1oz1NFbD+ZaIjKk3lcv5O1oDypYf1a0o4nfcAZiWaKwSL8w6oOftYW kKG7nnXYKFQzdFTmVjokKrTcGYM6EZTEoDCExNXOUoskQzDcFo4TxkLyk3b8iMS6UXY7wZ4T iOi0jemjBM7UsoLAXerxKeQwhakooI1ZRYRQLnob0CzCJz9c6QPPFzMYAlPkb6xFXBQbDmT3 W5koSPw7qJdaXBSyISoqd9MAVUwQr13sFoItrfwoxdrEN3ezXYawro4ePfeJHyJUqHBiMzS5 fscmoz4NeqPhZ7FTx48C/xTPDoNHQ2SjpafXN4loiKrM28pEDJG5DfVaaRFYNf38VfMVxDWB FJJVhZZsLQgAhCPUe3spVEOsXox9vWDr5O4Zj6GIK9o8oQcBs3Md8RXIhIrlkaCGyZNForLT oGWwY9IPHZecagAbKW2e+ugzPqhKNLCiN2dCvTmlmZ7uyPw94Nmn5ImnpiHZU+tOOyyRaGbA y6ytDGZBpNaJsz0X+9RaPugBWT40BmS5cZQckJEZWCQUP/47S2MrSCwbNMvxcDtmvdDzDWeW 48QJu/bmNPw2XJMDA5lSeoGXzoANtCd49MgxpfSkF9yNzEg/AnsbyJbg5UPFKR292/GkP5Gc Z1dx4ibm+Mf7qat3YC/QTctBZa9TFickGs1J1oPcBuzYG5SGEFn1AVn32M5NUuT4eIgY2jgT wQFmK6/g4XRnGMxC4e40zyTsMhNy8Va6c3k76c8ur7tXV6MeP5iNjMTthWs/IPiQn3ZwU46/ agY3uET39oV71IGjt/ZG7/6Tz4RRIqAvBEs0KyA7jLT+RjLRsGhk3lb6dSJzC/166mpnvESS IQBu2863WOJWPn6Je0H990tUUwhkZvOwEiwkKdRPKyCdKxuBYrlPIYl3jA3ie3ry6gxAYCev 0kdDQ4c7Do/GLQbLxks9N6k4oe3y09Xt5Yf+Fe6jYZGGVVrokAYjfNMffp597PY+4UtwtaLP gvnpaf8K9+rZjtL8FhoJhoNx41lxQnba/Ijs1PSM7NJF8lQ4JJuVSUrPv4afZHWXVHQv/csB 36RR0te7jgfbNJp2+RXz1xtMXhvPXK93sCCz03xOtjXvijTUK03YWGfCRudQipVYqMO5ZeNb 9oJGNE9sjA/RopDb2DBpDeYNq7qJFMKZW8uJd++4ib23IIw0rMZCt9L4sfu5P/vQn45upvxu Mh33x+PRGGr0+LI/1oaXhFo9umHXe8ZaGa7shb5cRKJpyUi87XQ0IHMbXU2kPw1JohlCEK3a nvkFkY2GJzzWi710rdg4vos+bkDjoAGGEQNKJ/HSzGvQ9snw2E5I30qDDKXxViaA03ilb8dF mikeq9btMixyOwAEVRF5C3RjIALjOLzrPWp3uNztIKI/mkMmGmORtBYwTwyhOBzNfibdy4Wg LEmiGE64NpGxObZh4dj3RLxcZCcEKifEdObE3DVEMKkw9ZPmhn7ippvPi4OUHJkoX2dKMkse fujdU0zvK+Y4K9ppQ9DCuAI1kWgKm8TbTmMEMrdR91L9NEHaeJIgbX2KIN3GBMFKu6S0arqa tFq2bLKsln9AVVhVxbVdbRDVdmUc03YD9wbysG2oSeA+R3iMowdIoZtipLI3Nei4pPw0gm2A 4f2mB0KgmYIgsrbSZoDI7QCgP0dFJhpDYHyKiqAE2UfDISosbCu521t6dyyFHVxA44FmQVS3 gdGjV4HRo9cco0cvaV1PHr1kKyBURAiTiaYgmMeyXOtLSIQyIxdRK7c3mV5iin1+znodfEO6 HTBUB5/7vNtBEB0DTpTzHl1DiJK7hedYNhxQp0WqLI8hYKUijLvnne+Hboph+wlxGX99RAd7 x8B1uE/+QwenP50c/3R4ih5d9z5E/ecIiaomvIiicflCPcmjLOtP3n0cXH5rAi4eZFQjK2Zo AqvE33TaORPFBwo0oWKumUNSBM4UpQqf301cfs09fms0VcTft/2m6tHCQ/uKOligm0FRZG96 YgaXxNWE3+tOyoD4Gf3h5XV3cEWjZCSxjYqp2VouzAALIYH6P1++Q/h3NJ1xBpE+e/9+PLsa 4GYScpE7ckaRIfj3sac3LhWqIfAKc9Pq+TgPg9R18m3GsXuPTU2YuecUzTmh9A3IUUvMJqEp 7jzZg7KQ7vacO5T6lr1HUxkLOU1UyicIaQT1uD/tT6ZrEFcyNQJeldFw7xUHO3bBX4CcFVwS SVpn9YPLg7Vc/mTaMj56WoS8prB4ZrpI/LyOzqRQOjt5SBx7WZL46NUIuIGEyDqoNMqOEv19 yF1nDCFM9BgmjUFMNo8YACYvb0M9mJmch0vH207IAOpUpwXC38B3UGVu3MAROcyZmTkBnmlt j8v+58m0y5e6IUwci8vXvxbS1U3jjvsIcmkkOYjQ5/rsvknkwicdnk8NoXza1PPtiSvU3Cee l/EMVsLZfoIZbDawYrh9yjaRPu0dILqbSznvQwQ7h1cFlMJIwfvu3WD4YXxzgR4wrIZIVuxu 2mBzk/HeptLJc7KZieGapi9+Ak4xkKjUVPb5ZKI024p8CFuRTfVKG8T3qWkQ3ye7SXtV4WHx ZIt73nbbaaXgBA/tpy8at1AyayujABC5hWb6aeHpfRlkoikEXuu+DETmVkAI9RCEjQH4w7b4 bWeHH5aqt2RkojEyxtbMuhUTIrPESR8PF7zAdX6YjHqfJj+K4ziSYohI7OmX8GWiISIyb7NZ YCJE7QfELqJ9FXm2Yv05ADLRDBCF1/RwcQ4JEcN7UnJDPV0C8GkEu7f9gEjPbOSlRUWlGwJT YK9vt4kHr+9wQTQBhtsXO1kSMdT4LTbTMphaxGnpBek+/DnQQlWSxRCtMgmmLo/0tGjYqvcW tx9X/e6QTmognla+qXiJyFlGolXLd2ldf6s4xaYpjIfrYTzcGMbD5id9s6MnQYjoMnOIa+TC ShZkpsMCn29sy9O/QLIXD3SjC0S482GsSn4Oya4YD7dqJE5x2RyI9sB10AYSxX9Kclx0rDt3 Ef9uajNTUOjfSuTlLE2QVySY7pVjzR9RVwavqNUHNWOVMuDEYD/j/vvBl4tfXoM77ehqMqMJ 3355bQxmxTFLz81PWXo2PWRpg4Nln7dz+BKcgaVDRqKZISOzmp6sSpSHnM51gF5e5h4c3Vk8 FwMyCGdi3MF9fg4oY7+jv9tAztWaJiLJEDe37eUdLHEbHx/Z+pGtTDQEQOZtBwKQuRUQfCvV D29VsikQCndLUBCpWwGjcqyvkk3B2MZ4n0ltGYzkTogUCMIEJAq0+jAUWWthcJSHYFQwoO0m /mqy/xTECwcGnBp+r2VHHvljh0Fp3NqKXIYYaIQ0HcNxSazX4bd7Zy0P3uR3h/Ad62GScjWF SRZiClMOEsgRQIJbiNRIrT9IgVPQ8M8MHArYNclkbw1Jz0qW1ShKOZogKAuos9ZK3P1PDrI5 d4IYiKmKa9nt3Qxm3cnVrDe6vsHDv7HsNgCeALC59F1//Kl/1f86+9rtwRFydISBOh7q3HST ZY8GX4pNsfSdygZLpZviqLKbnFp1xlDUBTAR8NytOrtVs1cPBh7Z8ixM6LnPXpImP8h751mO H01xjXy9dgo0UzxFVtPpGVp/Ix+UkZvK5Bbhv6zhg0yT23fg2In2la0kW6nLke9UAeVsgJTT 3FFCRME7OsuODQap0L7hH3p0MFxFVpy4ey/5McLatUdpudFoiZZ+08opj65UQjWFS2Y234LP OgsQwzUNrgsNnwjHu4kUUugu8ZtB4lRj4mwEitPsyD1xfoTKAb2Bi9mTFQf8xpmx/VkCZs5a 0Jjb7O3lYHqpIAius0RIMyhj11mVh5PX5mkCqipiI32jwkQEaUph+ql13UsXUYXFK5ONYZK5 zXWPaR9CiMrShrMoO9wcdwdp7N3t41eI5sSPFgYRX758Qd2r6f/6yRCpu+XKTcMwXezfpQvP 0ddXbUZD9PRyas1Hvc3no3Z2EjfhwQSUw9KyeXVpEYO4bM6oebbTuc9dv1D2j2rg1W1/OhpN P3J3FFOnbPql+CtxBwSGlnCpxbcytynI1cKazSXnkvIoLt//40N/CGRcY9nVRZZvhi2PdG+B 5IRZ8ghbQpXEZyeuqAWX0/fTG3DgvfjlNQl/Aty/vKbmeBaWbTiYCMHYBO6vN82LDjbxwm2t kitmbl5wJbJMV1/Yln8uqGF52UuyhGBUYCS+hrRuJjzZsCySwI8c/qMthNJcpuiXC6nTwB+T fTfHvGma0ymdzzTaiYxE6DkQ7ISGCSU/C9ZD0gfvHSD49UNn70gy7MW96Mxj+sN4dHuDZb67 Hryb4Pbt/aQZuvduABfwNusgLsvaDOdSSaY6np262RsNp+PBu2+i2HxCSUzU9rSZCLKPTmhA /tdt9/L99fTiL6+Xy9Xrv7CULzzpmSSxaDSXg+F09rEYtQYnT7/e9CeY1qiIsD6slm6yD3ez CuNmTfZmRaWVVmukC9H6Mq/k6xE266J5dozZfAZCC/NRXyZfr3GNcO9dP0xv5q+IcoOFiPm/ zUi1cdy5KZTp87KiDZGopkDJzPVnAI7zGQAiI5++o7c2cpfzBWlr2z2dh772Kg7sCkhksikm Cnf9ac5jYSRBpXCIyA0Zhm0BDfvB8RL9OF4hG6KhcpvOfFA0qJR8BEHvwWkitgsdsjisupbG o775KJRERJotQ/sh0SNUkscUpjIRjSbUBEmgMLWOy2BRPVucR4PpO+9ej5hMNgVL4a6B0zk0 x+esOX5wcXWC+UX7p/w69aMl2DBY4KGN/mIvrDgjJmn8v/8PukD/+Av6y1/ffPt//4L+hxC6 dF+Sgf5DkC9X2ApPKFTuPjV5d/ve1HS0oxUZLYf69YiSLKZFUCKhUeufC8q7ACENfJ9SF37J CGxLDWAcsj9awAo5TPEqCjDdhULhwiIEoODORo6VWndWApa1E85YxEJ882t4B0EI6RpYFEZu UDXavBp9GAxnve4NuDt1r1WV7I1HQyH0urhlxRTtVWAv2A+2UCtA12Q0xl4nx3Q7FeuMuKC8 GFgC6ZDg2nVmyQOorTgIwiirVHm5X6H+lCfQiQfcPCUL1HHFtsd/IJlxupCo8KH/UJ+7QYl5 jluvxMSMm5SYJMe00ogF5EFEfMB52h1/6E/JItL/JMa1tKpUFv5e4PiGLi4QrMGgf/93NbgZ J0mbrGED9aw7up2aop765H8t2ArdFGOVvd6A/5QM+PmM7nA0/dqfQiR4f+Y6hdZFMrwKZlkz PGaO+9vKXbnrcCnka4ZPUYzpWJ177GZB8zOZMMqBg7zrz4QDc4wr9bI9Q419JpG6FlM5V0NE FSG1qvRJPpjmS8WZqL0DBNcJu4YYvCqNA34glgLNkJfBFnyv+CcntdBN2kA3MUa3bLzFBZWq b1IJXC3lNYfRf+hNryshlHM0gE8R0Mw68B+wKAG2LQ5Nn+/v0rDKzFczmGJS4K8FyTlAcvBG VCcmKFMidr9uQ0PZSmDykuw77iN5uYJnUm+ETa0Ps+nRbNz/MIGEj/2ryWAE85D98bB7pQSM 6Ghq+S9oGKLAfVp6gYusFLmBg8I5IiDvttIyOHiEk9iaPbmaHIbFVyKgmUpngtggJLuvcCMr LThx7THb/G4KXJAkrt1xknkc+g/uix4/XUZTGLVy6lhMZD/nwaE6b8/icWTx4HfUp8BYjiTx eqI5+UGI7bEKvGch1I8+6McuifoBTrczcg+Dud746810lN/fTD+O+12eoVkZ4c+Ar1lad+5y XTGV5m1WUuWitlBY4oP+m5RX1Xi8PFfjMjIdiTcoHTok/5cvl8S7D34PA3ddyRTyNSubopgt lA5/yL90+cCRL76l955X6YblUWBvdoQJE5M59fH7ys67cVg5pIsrZ4qtiy0r/eyHQjZFVuGu NaZ/C2N6YVcgFaI6KSeRFdunxxn4NJONzcenWRhBML+E3dHjU3ULBLL9hPPTTQ8tDUznlpcu 9CugCtkQXZW7TvNBXK8OzsS5biomn+1m9/w8S3psUxS7sCmzYl6b+CHcjK6uwD+hLficdUss xRymIDrNFlgktwNqv2eiMiSdfH1l7pjo4dyBreu8gBxh6cYYwXkY+xXDn0IGY/xU/lpTIW9h KkSMNcLl5NjRexE6ZAZe5r1H547JtPHryD4/e20MIgisgFAiGwMoc9caO56poVr4N3PwWOSD cug6FchIu/F751jj9vCo3JsbQ6YNbVNKNwbNPMAN8zqtCAjGpG5jwwtuRTuY9fkF3L/cRzeo qJH6rKYoVUhq6Ka7ms/JMqf7KFy6xIfzgU+2L8N7shAK0eVQ4i5dcmAtWKIWUcWPl2PosQnb os7MBplrZj1M72rU+wSntE0H132R8L43nOK+ByeZlcy9m859y9YWh0o3LIMCeyM/JYQQE8T6 BHa3LV8lLD5aA0q0GShRW6BEEijRFkHxQl0A0jKyISQqd7PgmVQK34EasgCkyDwEaWXEUWMr xItO4YRqTRB5XRZTBEskNI1rm8viWGYJSkDXtnQrmj9FdsUYt5DBGB2Vv97WojOytehU2tnM RNWvZ5iTnl/9/Q+960vTTbW/Vi3q/brBWt6vpkt4bwGOtwwNsR79Jx56a8LLwkPy4LylVtin GTbCpqezye3NzWg8Ld9nQrI0tMZ+dZ9dfWMuU00xlJkb+VISGaoXZU1It2Cr/brU+6CKNFOk lkmT9eLjcmVT4NhOj/dw51TNuylkQzxU7mYxKqmUklhRlCBEi3r0HDhlIPdsoDn2DhCjtB4z inzm0rfXeOkWcxgiWSKg2QpkJohHc+P3lUYEbpg+jLs3H0WdDNz0PraihbGpsIzifXvxEMVe kFb1h7p8ptDpxJi6H1G30VyS4D0qJOJh0IPn57e1HZJC3w+DWRKuYtsteDHfjL81QVmUWY1z ac4mSJcLquVYfpI7lnMvA/ztmcPMDpUNrqHp0gvmYX6S+G9kS2lqL34N4dx5FJAjQmHouCMU TAy+S2SzQ+xTj15s9MapY7l+4WAYtWnAw+smLQNGBH9/6sbJXrzafwi9w7OTk8qSqMjeoDiq pDVrQJgYnV9O9dZzRcXbaX2Ln2ktUxOMxeybYyxJa44xFvOnxLgOsC2guXHMWNgiaAjf9rBb RnYlbiK9AWYSe62m9hSaWooXj/ZNm8E8Fjhih0K003tRM79/OeAzEdmJtE3QdNag6WyG5mbx hUD5hMU2uIHVNdwN0U4ndu1HeoVJsDsKOq/QcZN/rrGwjH5bg+pvm6H6W/Opaa2Onrapo41A i9eAFm8GWrxJoJg/M2z+Otz8DYHzNwlC9CdGDqbZ1mAnZWmEniyh6WFZVM4/v/uNrOruN7I2 6n4jw3WOEnMlylY4Ira68U/SsHSdO0ZJFmPI0iYOGSVb+3NJWcebio4UW5gvg10XsFSit4OL OQzxKRHQbCk3E5Q5rOUp23NZ28RVDd7vKbaiyI0r8VXzNEC4IMI0fphyyrAygV2YuWaz+khY EgCIfh53b27642xBAP3Xf1EixzBfKjCF8sGtmtlV6cYQKuxNVZSIERSU3v+5PSp911/XTJZk MUW4REL9Y6/keNi5LI5zlrCdmNi+91xVhSWqKS4yc7OegwjhWMD11vqLpXP628qN9btrijlM ASkKaOgnmknKR6+QVOUTOriZ9Hv4FwJZj9/3Dg/PD98NJu3p0fJ5bU0rZjEG8HmDEBwSfs/F EBxZEAm2zkIDccRzywZPqsx5z3DzVzvohqsgnSX+3bzCnCnJY4pvmYhaTdnbot+GICzT0TwJ I3rvpn6QhhExe8SmjRaRkPeMxhO7HU7B4XynCHX28ua4Jq5TBalINkdT4m7mTUql5KDgG6kJ JC1gwcBBJb5DoMGNXIb8KLXulvp1KZVuipPKXusoJ2gTqxxImdRt9JmB5btOx1649kPlgRu6 fIb4aMW0uUdJeQg5nA1fd4p7lAqblLCezeiOIzGs09Z3IglvXLlTTJeveSlsb6eY8pB/lVKo xn4jxM06emJAHvPZrZ2d5ZNzH9xZMIOPr+K7gF4FYRiRq8S1YnvBV6DJgNteWEHgVqLN9tx3 xx8mF6/hfLz8/tsvr18XglTX3cWHiuVoWBiOfhgp0kwLwjF0VSTLVgfnosWFZeSmFtzg/t9P D5ehbVWaVcpBIhVx0lM7ovvFpGNbZhevXxt3eME8se8qtFomm6KpcDf1i6VyOLzkZjv+sFh2 JRabILFBJNUMBQEDjADCP4/He8fgMoL7/9glriN7J9sZNcIzsdJBy+FWYlTI1ACroowNdCeT JqDHk7amR7H7GD5UAqXkMEdJFbABRFRUjg+93xI494swfNAjI5NNYVG4TXdVMkSIFA4HuRGm H2i4Ptnaru2ZaIhVuAzvPX3UBpVuipbK3nRVjQniiNG7vRPEr1RFmny9LrjOsrxoX3w18w4t jSrPGFPppoip7PWnP81OGIPY4LOrUa97RfZEdseTPt/uzOIgfXyFhtMbEkMcIUybfJ3M3o/7 fTw4hIEi2bJGqKYIPsaWfiVcppqiJzM3iilLZKj78qPwyY2jLUWQZdvztZCodENQCuyNYGFS 8maKJ0jhCLaCT2RXn8ap0g3xKbCb+j+xqPxUDAw0hcUdnnr2T5rujB7uZyxk2b7jLt0K26oi qymiFZJM99FXQEWOnJD6yZ/fj8bX3Sm+OVA7zcFwMu1e8b0318ajc/GbwBG7FoxSxg1AlOX8 OSB835/2PrYC5ypyrNQL7mtBWsi8AaxFWX8MtOgPg/aRnqZTC1k17wbAFkT9t1BZ37aCIKwc n5blMcWxTEQt/M7U6COCKN4d5Sklq7+sIxPy2O11RGTTVeWqZkkWc+yarGqeAXRnJRtgb66l Ay+weD1mWVCcNiGr3Jqv0s3BMt6cr0Wqf/W+sN0e0CtZPHOX82zTPX4Hto6mQZXs9bcRv1rw qxkJx9Ee1EFU3akrdFOoVfZmgZWZGF6X6V0z07KVCEJRGKdJYEXEMwo3/o77rEewIq8pmlWi Gq+xZ7LyPTTyFAydR+D6/qXPFpyaYhYt0jS6d9P1iBVyNsWrKKgpWlzStrHCo26nAiCJbIyK zN0YCiKH10lyU/AvW+s1aYhLFFUFHVHIprgo3M2281EpHBVyU7nbmq2cVuyZErrhdAGBwHDH AcEo8U/qxthmicz1K7aWnpW4ek+gYg5TNIsCmnmNZoLyqYUs5c/tOYrfs/Kod5VujrDxce8S vkxhY/G4d3a37UO3o2r7biPrzti2OwXbTopRGvFIS3wynSWg5MnKbQ/ZchMRyk1BtdGj1h+L HmOI2ZMesKfGaD01382ycx+v6H7HJ/oLUuiV69zH4YpEGk0cMp4i7hF3LKQusiPHi8ne/Flc eRIhcTTRYGnHL1HaFM04cOwOzFBWxe4uzWSIcLmMOi4QxBA+OFnr8SM+YZ2X6abOJH+YUxB8 VGW5bFIe2yuH/z74h6vUPdXboCrdtBRU9mYB8pgY1myzuwqzYCthjePI3oOTQyvAKuQwhaso oH7HdiYdAJWJwt0Z++WmFpzACQFVluzc9uTRJvE/IRP9hfQsjRyXut7x6rIPB12Duicx1+x9 foTqd4wTHarDBXbsannTT9lRo0EEAADdeXVxyTkaFJcioJZ+n4F+n+V2SCZHCOcN6+M2SvwZ 2VnAyojf7i0QzQ9BCEK7MsrAXg30i4femmO98gMyN16FtpqnAd4FEfWnmk5lxJmkHHMxEcI3 rII0te7oqq8AIccZvWm1aXmJyHKNW62vxVwNMCwRYjqo2HmJZuyEM0SF4YtM7ixx40cSZvgX mtW5W4bhA7EUyR2J2Mxv6BIqv+PSFI3+Tmjdv95UzAK+RPDwgj8omyCEkMoQ+vAlep7H5tYk AQ9zriskKUujEpIlNDvbgkphbQe9wS0HT+VFJJQkKy3Ltt0kyXiyA1YrOoDLL+/H78BjZjL4 e//i9OTk6ETX1hhDjn8q8Zbo5mDL7M1mL4jv/ewONxnQJoPQGZvZp9eP9uyY3XgkS4QHSKxg AHSeS2SwyckYiWuvcGWBI6+erNinLqpr95hdQkTSa3JaMUYeNiRLu5Q1gUsNSyZ2g5VfUTIK 3bRkVPaGGyCZnD3ipnKC+G3e6nM6QpEVw3HQL2jpwvbR5dotkoWDyr+SLLgfNT+wME4t57EC TZlsCqbC3RRLIiaDkt7lSDIqwxiOJXceaZg+by5ulkw9n7Q81L9qjRXfHfeOx93h5ehatuvx 3Xh0O+0Phu9H7XXEaRR7YUUhSGTjQpC5Tc92ZWMhIoWHTkVCqFRKERI8h2ZlYwJEM+wdIErY TuTUOE3CZZUeS2RjCGXuBltM+PiISMKDI3IhKjFJt1k6U12MxZ2baSyhVY6JqlVX7RkbHPQY Py3CCpAlqinGMrPpXtRMT0EMbzfgGlaNsCGNvnz5gu5i13pIUBig7jJaWBhXF6UhspbefeC7 QQptRZLG2O5Ik9z43jnehsImlhZHgWQIoshZf8JV8EdNLNVjHjkQXy4if/FzHBp3znJi196W Z2riBk7l4cyFDKYwFfjrqBtB64jPT3+Hrq0Iuc+pG4BTVgIA3kAffIl/4ajb/hdc/S6Hk2ti BekXkq6zfWN1Vo++/8flu+vLPnELGQ4mmPFy2rthsV8mxP3gZmK+Jpy46dy7qwBcIhvDLXOb 7ngp3T5NhW6lZq455CXZ7JCXpMEhL5LjeGELBpOI5JQkP+sk4QfAIE7YVpCSZM1ZMMlmZ8Ek bZ0Fk0hnwSTbPQsm8e/8RO+Hq5BNIVG46yMiB/ahcjgg5CZzuGgzNgG4zFQ6hRUymAJS4G82 +8/lcEgCq9wxTPJCeT+RnFAgsogpPlFs6UP8yFRTZGTmZi4oRAjHBK4rAdHO9BrD8pJwN2gt NsUspgCVSKhj6xPtOeDqs4PFpK5PD8X0wHBnnjRwlb7ADNeKxJdZJdSoyqYsH63Ygz3Be9CW z568363Y+YYe3BdY115g63QFO8ndpOIkNBI+6cPfBzcXByYH95kVBuxktxf6zaAq3bAYCuym s2NEOZmU3J7lCTaaY8H04DkvcFMbhlqJbc3nZAimgRaP+/tdbJp1+9ejIVhoF7+8JotObG73 l9fsgLlJ/3N/PJh+vbgafZjBNAFMGbzvnR8dzOAYutHt9OLgDeA+HvX6k8lsdDMdjIYTfjzd aDKdzC77w68gH7/c/iJM0mTPcYMX/AieoXt1NfpZzoG1Nnz65XWDoiTnHVQWppyjQXEqAhoX KJEjFylN+jMUattTnfB1cRhVloxIb1AuEntT04EJEooJ320nGiCLoZH9VkFTlq8BRKVi6kBF lkaO+NrIDtu9A7rYu+p3h+8HV33w2RDSa5xuCTd4wHd5e32D9ZWufRengPK9xmqskdnMSiEa ySp1Z7MfflgFEK/rxx+NVTO2bJd4ROiLoJjFFP0SCY0CcJOA28ck3nYOfR3kKZqwRXvSv+r3 prOPFwdS6qj3aTAiqdBOcBKu/DMySyzmh8TB+9nlVSH7ZDruj8ejcZ73dnLV79+QbE3L5bRG wZxuXjKnZsN6uqn+MC+a0c/EtSZMhcjox1WR0TVxIsWpzsq6M+72+rRsePWhMyymQP+OB42r igZIoZsCrLI3M9aZGN4y07t6W1vU2eLLQRf3fcxjZogzTfoT0+nj1b3nzPWOpgrZEDKVuxli VAoDjN5Uj/g+DC7f/ywN+pgEU2ySuzVHvxVzmCJUFNBsaJwJ4jjx+9wyy5OyBTcRQoIWaNwS Z2zNOnj0nHW7IUuyGKJYJqFZ6OBcEkctTwHYXDt03G1Nsj9ZFXGOJKIhPjJv0zjTIIVpF1xu x5p8gqGDE947FUCoOYzRKAiopSxv1TCrmaCSCeCMhoppGYgsy94Z4tcFULM2LN9GILZ18rYD Q6iXVuC4dyt981bMYQp1UUDT2FqZKI4ev99ObK2n5Zqmv5DBGJpGZ34WDlDlcjJY8mZfjOvj HZ2dbgWnyCKTHVbFsV1leUzRKhNRR5VIV3nI+0o2ymCSiPsK4jeuFc1g4i9LwM+cRcmDcLqD 1kKDGaDuzaUw/JPsYzb2uxwPPvfHMwgr1Rjkmb306gAt5WsOtizG1PmQaqggineqQhK4s2Gg 7TSGDjZMZrBJomr8x8DsTcdXePCGhw7V1NntcPDF2PQDCHChJzP30Q0qzoPR5WuAeKkYU88g tjVFkEVjB7B4qnnq2bYaA1KYa3RUzdMArYII05MReXtJ5VRtIWmmcN8hN4CFA1hMQOEcObP0 JSK+LZ6DS8CbvyDQdOSE4NSBwI3ITZOGgEdWkkSL2ErctbiXZG0If5mkZi2ELI03EnIqzB0v rAPwx3dOKg+tYKcLzyYfuwfllOvLk0YtArxRsoqipWdbQboW6pKsDaEuk1Sn9yP7HQ5P5N5P Fkg6wTV9HHRxP990yeT51aDXHU5LJjp5Jk6BHdj7TuzBlN6aXHESkDcyLJKXaOY/OHoXGZVu CH6BvdGZ4kxKPgznCWyXQ+l2CL12cx/9iycrDp6rY6BIWxzKMgifCpsAjOvES1Tpka+QjeE3 9scvHtZKhYjgM7d7jGPkBfdVUNMlqNY6x5coCiuWyhWyMVgyt+lYgrfEVE4GHtxsx1TAslfJ ogoNkWyOhsRtvkKBR9cf+kPQGdzCsauLl4hsmsH2AjSbiD6FbtaoG4xes/kIjW96+CkXsOfj 3g1Qp2cMJ1TgCjglsjGcMneznTEvUbb/SNpypDSBQZLd0k1IGKEccVoAzA1W2K8k71Uiu2ZW TuWWgst3s16397FPvTVnzF2TLTxIcyxA+tagPNLK4kg3KY20jZqeuGlW0fH1dur5755dGUVa pRuCUWCvdQ7Qke4cIDlydAbA60IFFp/5+tX/ByFh55smcwIA --Pd0ReVV5GZGQvF3a-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 11 17:09:19 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 871D8106568B for ; Sun, 11 Oct 2009 17:09:19 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1138FC14 for ; Sun, 11 Oct 2009 17:09:19 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 624DD1CC4F; Sun, 11 Oct 2009 19:09:18 +0200 (CEST) Date: Sun, 11 Oct 2009 19:09:18 +0200 From: Ed Schouten To: FreeBSD Hackers Message-ID: <20091011170918.GU71731@hoeg.nl> References: <20091011145021.GG36937@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yIMHf/Pa6CzSkARF" Content-Disposition: inline In-Reply-To: <20091011145021.GG36937@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 17:09:19 -0000 --yIMHf/Pa6CzSkARF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ulrich, * Ulrich Sp=F6rlein wrote: > Comments? Committers? Wouldn't it better to address the root of the problem while there? ;-) Index: number.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- number.c (revision 197852) +++ number.c (working copy) @@ -88,9 +88,7 @@ int lflag; =20 int -main(argc, argv) - int argc; - char *argv[]; +main(int argc, char *argv[]) { int ch, first; char line[256]; @@ -275,7 +273,7 @@ pfract(len) int len; { - static char *pref[] =3D { "", "ten-", "hundred-" }; + static char const * const pref[] =3D { "", "ten-", "hundred-" }; =20 switch(len) { case 1: --=20 Ed Schouten WWW: http://80386.nl/ --yIMHf/Pa6CzSkARF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrSET4ACgkQ52SDGA2eCwWZJQCcDlRcPwKpLSdm4o4xOo4rOalM 330AniHp8JXcJVZZLm3xakUHOAXr+4M/ =rTK/ -----END PGP SIGNATURE----- --yIMHf/Pa6CzSkARF-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 11 17:54:29 2009 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427CE10656DE; Sun, 11 Oct 2009 17:54:29 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0BA8FC0C; Sun, 11 Oct 2009 17:54:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9BHsTe4004836; Sun, 11 Oct 2009 17:54:29 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9BHsTI8004835; Sun, 11 Oct 2009 17:54:29 GMT (envelope-from danger) Date: Sun, 11 Oct 2009 17:54:29 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20091011175428.GA3626@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, questions@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Reports April - September, 2009 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 17:54:29 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between April and September 2009. During that time a lot of work has been done on wide variety of projects, including the Google Summer of Code projects. The BSDCan conference was held in Ottawa, CA, in May. The EuroBSDCon conference was held in Cambridge, UK, in September. Both events were very successful. A new major version of FreeBSD, 8.0 is to be released soon. If you are wondering what's new in this long-awaited release, read Ivan Voras' excellent summary. Thanks to all the reporters for the excellent work! We hope you enjoy the reading. Please note that the next deadline for submissions covering reports between October and December 2009 is January 15th, 2010. __________________________________________________________________ Google Summer of Code * About Google Summer of Code 2009 * BSD-licensed iconv (Summer of Code 2009) * BSD-licensed text-processing tools (Summer of Code 2008) * Ext2fs Status report (Summer of Code 2009) * libnetstat(3) - networking statistics (Summer of Code 2009) * pefs - stacked cryptographic filesystem (Summer of Code 2009) Projects * BSD# Project * Clang replacing GCC in the base system * FreeBSD TDM Framework * Grand Central Dispatch - FreeBSD port * libprocstat(3) - process statistics * New BSD licensed debugger * NFSv4 ACLs * The Newcons project * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Ports Management Team * Release Engineering Status Report * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Modular Congestion Control * Network Stack Virtualization * Stream Control Transmission Protocol (SCTP) Kernel * FreeBSD/ZFS * hwpmc for MIPS Documentation * The FreeBSD Dutch Documentation Project * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * FreeBSD/sparc64 Ports * FreeBSD Gecko Project * Portmaster - utility to assist users with managing ports * Valgrind suite on FreeBSD Miscellaneous * EuroBSDcon 2009 * FreeBSD Developer Summit, Cambridge UK * New approach to the locale database * The FreeBSD Forums __________________________________________________________________ About Google Summer of Code 2009 URL: http://socghop.appspot.com/org/home/google/gsoc2009/freebsd URL: http://wiki.freebsd.org/SummerOfCode2009Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson 2009 was The FreeBSD Project's fifth year of participation in the Google Summer of Code. We had a total of 17 successful projects. Some GSoC code will be shipping with FreeBSD 8.0-RELEASE and others will be integrated into future releases. The FreeBSD GSoC admin team would like to thank Google and our students and mentors of another great year! __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain Tartičre The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. During the past year, the BSD# Team continued to track the Mono development and the lang/mono port have almost always been up-to-date (we however had to skip mono-2.2 because of some regression issues in this release). Most of our patches have been merged in the mono trunk upstream, and should be included in the upcoming mono-2.6 release. In the meantime, a few more .NET related ports have been updated or added to the FreeBSD ports tree. These ports include: * www/xsp and www/mod_mono that make it possible to use FreeBSD for hosting ASP.NET application; * lang/boo, a CLI-targeted programming language similar to Python; * lang/mono-basic, the Visual Basic .NET Framework for Mono; * devel/monodevelop, an Integrated Development Environment for .NET; * and much more... Open tasks: 1. Test mono ports and send feedback (we are especially interested in tests where NOPORTDOCS / WITH_DEBUG is enabled). 2. Port the mono-debugger to FreeBSD. 3. Build a debug live-image of FreeBSD so that Mono hackers without a FreeBSD box can help us fixing bugs more efficiently. __________________________________________________________________ BSD-licensed iconv (Summer of Code 2009) URL: http://wiki.freebsd.org/G%C3%A1borSoC2009 Contact: Gábor Kövesdán The code has been extracted from NetBSD and has been transformed into an independent shared library. The basic encodings are well supported. Almost all forward conversions (foo -> UTF-32) are compatible with GNU but the reverse ones are not so accurate because of GNU's advanced transliteration. Some extra encodings have also been added. There are two modules, which segfault; they need some debugging. I can keep working on this project as part of my BSc thesis, so I hope to be able to solve the remaining issues. Improved GNU compatibility is also very desired (extra command line options for iconv(1), iconvctl(), private interfaces, etc.). Open tasks: 1. Fix segfaults in Big5 and HZ modules 2. Improve transliteration in reverse encodings 3. Improve GNU compatibility by implementing extra features 4. Verify POSIX compatibility 5. Verify GNU compatibility 6. Check performance __________________________________________________________________ BSD-licensed text-processing tools (Summer of Code 2008) URL: http://wiki.freebsd.org/G%C3%A1borSoC2008 Contact: Gábor Kövesdán This project was started as part of Google Summer of Code 2008 but there is still a bit of work to complete some missing parts. The BSD-licensed grep implementation is feature-complete and has a good level of GNU compatibility. Our only current concern about the BSD-licensed version is to improve its performance. The GNU variant is much more complex, has about 8 KSLOC, while BSD grep is tiny, has only 1.5 KSLOC. GNU uses some shortcuts and optimizations to speed-up calls to the regex library; that is why it is significantly faster. My point of view is that such optimizations must be implemented in the regex library, keeping the dependent utilities clean and easy to read. BSD grep is so tiny that there is hardly any optimization opportunity by simplifying the code, so the regex library is the next important TODO. There is another issue with the current regex library. It does not support some invalid regular expressions, which work in GNU. We need to maintain compatibility, so we cannot just drop this feature. Actually, BSD grep is linked to the GNU regex library to maintain this feature but due to the lack of the mentioned shortcuts, it is still slower than GNU. Anyway, if we can live with this little performance hit until we get a modern regex library, I think grep is ready to enter HEAD. As for the regex library, NetBSD's result of the last SoC is worth taking a look. The sort utility has been rewritten from scratch. The existing BSD-licensed implementation could not deal with wide characters by design. The new implementation is still lacking some features but is quite complete. There is a performance issue, though. Sorting is a typical algorithmic subject but I am not an algorithmic expert, so my implementation is not completely optimal. Some help would be welcome with this part. The bc/dc utilities have been ported from OpenBSD. They pass OpenBSD's and GNU's regression tests but they arrived too late to catch 8.X, so they will go to HEAD after the release. Open tasks: 1. Improve sort's sorting and file merging algorithms 2. Complete missing features for sort 3. Get a modern regex library for FreeBSD __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The clang@FreeBSD team presents the status of clang/LLVM being able to compile FreeBSD system. The current status is: * i386 - kernel boots, world needs little hacks but works * amd64 - kernel boots, world needs little hacks but works * ppc - broken because of unknown RTLD bug * other - unknown All other platforms are untested. A lot has happened over the spring/summer: amd64 got proper mcmodel=kernel support, compiler-rt has been introduced (paving the way for libgcc replacement), we have run two experimental port builds to see how clang does there. The C++ support is able to parse devd.cc without warnings. We have got the kernel working with -O2. FreeBSD has been promoted to be an officially supported plaform in LLVM. As a result of all this work, many parts of FreeBSD that did not compile before now build without problems. Open tasks: 1. The "ClangBSD" branch of FreeBSD got a little stale and has not been updated for a while. 2. We also need to get some important fixes into LLVM to get libc compiling and some other smaller issues. 3. We can still appreciate more testers on minor platforms (mostly on ARM, PPC and MIPS, but testing on other platforms is also welcome). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.freebsdfoundation.org/projects.shtml URL: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart TCP appropriate byte counting (RFC 3465) support has been merged into the FreeBSD 8 branch and will ship in FreeBSD 8.0-RELEASE. The reassembly queue auto-tuning and SIFTR work was not ready in time to safely integrate for 8.0-RELEASE. Padding has been added to necessary TCP structs to facilitate MFCing features back to the 8-STABLE branch after 8.0 is released. Candidate patches against FreeBSD-CURRENT will be ready for wider testing in the coming weeks. The freebsd-net mailing list will be solicited for testing/feedback when everything is ready. Open tasks: 1. Solicit review/testing and integrate the ALQ kld and variable length message support patch into FreeBSD-CURRENT. 2. Solicit review/testing and integrate the SIFTR tool into FreeBSD-CURRENT. 3. Complete dynamic reassembly queue auto-tuning patch for FreeBSD-CURRENT. 4. Fix an identified bug in the SACK implementation's fast retransmit/fast recovery behavior. 5. Profit! __________________________________________________________________ EuroBSDcon 2009 URL: http://2009.eurobsdcon.org/ URL: http://2010.eurobsdcon.org/ Contact: Sam Smith Contact: Robert Watson EuroBSDcon 2009 happened in Cambridge, with over 160 users, developers, friends and others. Slides, papers and audio are now up on the website for those who could not make it to Cambridge. Next year's event in 2010 will take place in Karlsruhe from 8 to 10 October 2010. If you are interested in what you missed in 2009, or to join the mailing list so you do not miss out next year, visit http://2009.eurosbsdcon.org. __________________________________________________________________ Ext2fs Status report (Summer of Code 2009) URL: http://wiki.freebsd.org/SOC2009AdityaSarawgi Contact: Aditya Sarawgi FreeBSD's ext2fs had some parts under GPL. The aim of my project was to rewrite those parts and free ext2fs from GPL. I have been successful in rewriting the parts and NetBSD's ext2fs was a great help in this. Certain critical parts under GPL were also removed due to which the write performance suffered. I also implemented Orlov Block Allocator for ext2fs. Currently I am planning to make ext2fs Multiprocessor Safe (MPSAFE). My work resides in truncs_ext2fs branch of Perforce. Open tasks: 1. Ext4 support for FreeBSD 2. Directory indexing for ext2fs 3. Journaling in ext2fs using gjournal __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions. This list contains PRs, mostly with patches, that the Bugbusting Team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. A full list of all the automatically generated reports is also available at one of the cited URLs. Any recommendations for reports which not currently exist but which would be beneficial are welcomed. Gavin Atkinson gave a presentation on "The PR Collection Status" at the EuroBSDCon 2009 DevSummit, and discussed with other participants several other ideas to make the PR database more useful and usable. Several good ideas came from this, and will hopefully lead to more useful tools in the near future. Discussions also took place on how it may be possible to automatically classify non-ports PRs with a view towards notifying interested parties, although investigations into this have not yet begun. Mark Linimon also continues attempting to define the general problem and investigating possible new workflow models, and presented work on this at BSDCan 2009. Since the last status report, the number of open bugs has increased to around the 5900 mark, partially because of an increased focus on getting more information into the existing PRs, in an attempt to make sure all the information required is now available. As a result, although the number of open PRs has increased, they are hopefully of better quality. As always, more help is appreciated, and committers and non-committers alike are always invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Work on suggestions from developers who were at the EuroBSDCon DevSummit. 2. Try to find ways to get more committers helping us with closing the PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Developer Summit, Cambridge UK URL: http://wiki.FreeBSD.org/200909DevSummit Contact: Robert Watson Around 70 FreeBSD developers and guests attended the FreeBSD developer summit prior to EuroBSDCon 2009 in Cambridge, UK. Hosted at the University of Cambridge Computer Laboratory, the workshop-style event consisted of prepared presentations, as well as group hacking and discussion sessions. Talks covered topics including 802.11 mesh networking, virtual network stacks and kernels, a new BSD-licensed debugger, benchmarking, bugbusting, NetFPGA, a port of Apple's GCD (Grand Central Dispatch) to FreeBSD, security policy work, cryptographic signatures, FreeBSD.org system administration, time geeks, a new console driver, and the FreeBSD subversion migration. Slides for many talks are now available on the wiki page. A good time was had by all, including a punting outing on the River Cam! __________________________________________________________________ FreeBSD Gecko Project URL: https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO Contact: Beat Gaetzi Contact: Martin Wilke Contact: Andreas Tobler Andreas Tobler made the classic mistake of sending us a lot of powerpc and sparc64 related patches. The usual punishment, of giving him a commit bit to the Gecko repository, has been applied. We currently have some old ports in the ports tree: * www/mozilla is 5 year old now, no longer supported upstream, and has a lot of security vulnerabilities. We can use www/seamonkey instead. * www/xulrunner is superseeded by www/libxul. A patch that includes the following changes has been tested on pointyhat and is ready for commit: * Remove references to www/mozilla/Makefile.common and www/mozilla/bsd.gecko.mk * Switch USE_GECKO= xulrunner firefox mozilla to USE_GECKO= libxul and remove www/xulrunner We are also working on Firefox 3.6 (Alpha 2), Thunderbird 3.0 (Beta 4), new libxul 1.9.1.3 and Seamonkey 2.0 (Beta 2) ports. All of them are already committed to our Gecko repository. A current status and todo list can be found at http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO. Open tasks: 1. Remove mozilla, xulrunner and firefox2 from the ports tree. 2. The www/firefox35 port should be moved to www/firefox. 3. The old (and somewhat stale) Gecko providers mozilla, nvu, xulrunner, flock and firefox also need to be removed. __________________________________________________________________ FreeBSD KDE Team URL: http://freebsd.kde.org URL: http://miwi.bsdcrew.de/category/kde/ URL: http://blogs.freebsdish.org/tabthorpe/category/kde Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Martin Wilke Since the spring, the FreeBSD KDE team has been busy upgrading KDE from 4.2.0 up through to 4.3.1. As part of the ongoing maintenance of KDE, the team also updated Qt4 from 4.4.3 through to 4.5.2 We added two new committers/maintainers to the team, Kris Moore (kmoore@) and Dima Panov (fluffy@). We also granted enhanced area51 access to contributors Alberto Villa and Raphael Kubo da Costa. Alberto has been our key contributor updating and testing Qt 4.6.0-tp1. Raphael is a KDE developer, who has become our Gitorious liaison, he has been responsible for getting FreeBSD Qt patches merged in upstream. Markus Brüffer (markus@) spent a lot of time patching widgets and system plugins so they would work under FreeBSD. We would like to thank him for all his effort! Open tasks: 1. Update to Qt 4.6.0 2. Update to KDE 4.4.0 3. Work with our userbase on fixing an EOL for KDE3 in the ports tree __________________________________________________________________ FreeBSD Ports Management Team URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has soared to over 20,700. The PR count had been driven below 800 by some extraordinary effort, but once again is back to its usual count of around 900. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, sparc64-7, and sparc64-8. There have been preliminary runs of i386-9; however, to be able to continue builds on -9, we will either need to find places to host a number of new machines, or drop package building for -6. The mailing list discussion of the latter proved quite controversial. We have added some new i386 machines to help speed up the builds, but this only makes up for the disk failures on some of our older, slower, i386 nodes. We also appreciate the loan of more package build machines from several committers, including pgollucci@, gahr@, erwin@, Boris Kochergin, and Craig Butler. The portmgr@ team has also welcomed new members Ion-Mihai Tetcu (itetcu@) and Martin Wilke (miwi@). We also thank departing member Kirill Ponomarew (krion@) for his long service. Ion-Mihai has spent much time working on a system that does automatic Quality Assurance on new commits, called QAT. A second tinderbox called QATty has helped us to fix many problems, especially those involving custom PREFIX and LOCALBASE settings, and documentation inclusion options. Ports conformance to documented features / non-default configuration will follow. Between pav and miwi, over 2 dozen experimental ports runs have been completed and committed. We have added 5 new committers since the last report, and 2 older ones have rejoined. Open tasks: 1. We are currently trying to set up ports tinderboxes that can be made available to committers for pre-testing; those who can loan machines for this should contact Ion-Mihai (itetcu@) with details regarding the hardware and bandwidth. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have almost 4,700 unmaintained ports (see, for instance, the list on portsmon). (The percentage is down to 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk This work's purpose is a generic and flexible framework for systems equipped with Time Division Multiplexing (TDM) units, often found on embedded telecom chips. The framework is designed to support various controllers and many types of TDM channels e.g. voiceband, sound and miscellaneous data channels. Currently, voiceband infrastructure is being developed on Marvell RD-88F6281 reference board. It will serve as an example of how to use the TDM framework for other channel types. The direct objective of using TDM with voiceband channels is bringing a FreeBSD based VoIP system, capable of bridging analog telephone world with digital IP telephony. Together with third party VoIP software (e.g. Asterisk), the design can serve as VoIP Private Branch Exchange (PBX). Current state highlights: * TDM controller interface * TDM channel interface * TDM channel API for kernel modules * codec interface * voiceband channel character device driver * TDM controller driver for Marvell Kirkwood and Discovery SoCs * Si3215 SLIC driver * Si3050 DAA driver Open tasks: 1. Develop demo application showing example usage of voiceband channel. 2. Integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Noteworthy developments regarding FreeBSD/sparc64 since the last Status Reports are: * Cas(4), a driver for Sun Cassini/Cassini+, as well as National Semiconductor DP83065 Saturn Gigabit NICs has been committed and thus will be part of FreeBSD beginning with 8.0-RELEASE and 7.3-RELEASE, respectively. This means that the on-board NICs found in Fire V440, as well as the add-on cards based on these chips, are now supported, including on non-sparc64 machines. Unfortunately, the cas(4) driver triggers what seem to be secondary problems with the on-board NICs found in B100 blades and Fire V480, which due to lack of access to such systems could not be fixed so far. * Initial support for sun4u machines based on the "Fire" Host-PCI-Express bridge like Fire V215, V245, etc. has been completed (including support for the on-board ATA controller, which caused several problems at first, and MSI/MSI-X). Some code like the quirk handling for the ALi/ULi chips found in these machines needs to be revisited though and no stability tests have been conducted so far. If all goes well, the code will hit HEAD some time after FreeBSD 8.0-RELEASE has been released. In theory, machines based on the "Oberon" Host-PCI-Express bridge, at least for the most part, should also be supported with these changes, but due to lack of access to a Mx000 series machine the code could not be tested with these so far. * Some bugs in the snd_t4dwave(4) driver have been fixed, as well as some special handling for sparc64 has been added so it does 32-bit DMA and now generally works with the on-board ALi M5451 found for example in Blade 100 and Blade 1500. Unfortunately, it was only tested to work correctly in two out of three Blade 100. Why it still does not work correctly in the remaining one is currently unknown but at least no longer causes IOMMU-panics so testing snd_t4dwave(4) on sparc64 is no longer harmful. These changes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * Ata-marvell(4) has been fixed to work on sparc64 (actually also on anything that is not x86 with less than 4GB of RAM). These fixes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * A proper and machine-independent fix for the old problem that the loader leaves the NIC opened by the firmware, which could lead to panics during boot when netbooting, has been developed but not committed yet. Open tasks: __________________________________________________________________ FreeBSD/ZFS Contact: Pawel Dawidek We believe that the ZFS file system is now production-ready in FreeBSD 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer tagged as experimental. There is also ongoing work in Perforce to bring the latest ZFS version (v19) to FreeBSD. Open tasks: 1. Download 8.0 release candidates and test, test, test and report any problems to the freebsd-fs@FreeBSD.org mailing list. __________________________________________________________________ Grand Central Dispatch - FreeBSD port URL: http://libdispatch.macosforge.org/ Contact: Robert Watson Contact: Stacey Son Contact: libdispatch mailing list We have ported libdispatch, Apple's Grand Central Dispatch event and concurrency framework to FreeBSD: * Added new kqueue primitives required to support GCD, such as EVFILT_USER and EV_TRIGGER * Created autoconf and automake build framework for libdispatch * Modified libdispatch to use POSIX semaphores instead of Mach semaphores * Adapted libdispatch to use portable POSIX time routines Jordan Hubbard has also prepared a blocks-aware clang compiler package for FreeBSD. When compiled with clang, libdispatch provides blocks-based, as well as function-based callbacks. The port was presented at the FreeBSD Developer Summit in Cambridge, UK in September, and slides are online on the devsummit wiki page. A FreeBSD port is now available in the Ports Collection. After FreeBSD 8.0-RELEASE has shipped, the new kqueue primitives will be MFC'd so that libdispatch works out of the box on FreeBSD 8.1-RELEASE. Open tasks: 1. Complete porting of libdispatch test suite to FreeBSD. 2. Investigate pthread work queue implementation for FreeBSD. 3. Evaluate performance impact of some machine-dependent and OS-dependent optimizations present in the Mac OS X version of libdispatch to decide if they should be done for other platforms and OS's. 4. Explore whether FreeBSD base operating system tools would benefit from being modified to use libdispatch. __________________________________________________________________ hwpmc for MIPS URL: http://wiki.freebsd.org/FreeBSD/mips URL: http://wiki.freebsd.org/FreeBSD/mips/UBNT-RouterStationPro Contact: George Neville-Neil Currently working on board bringup. I have looked over the docs for how MIPS provides performance counters and will begin adding code soon. __________________________________________________________________ libnetstat(3) - networking statistics (Summer of Code 2009) URL: http://wiki.FreeBSD.org/PGJSoc2009 URL: http://p4web.freebsd.org/@md=d&cd=//&c=McZ@//depot/projects/soc2009/pgj _libstat/?ac=83 Contact: Gábor Páli The libnetstat(3) project provides a user-space library API to monitor networking functions with the following benefits: * ABI-robust interface making use of accessor functions in order to divorce monitoring applications from kernel or user ABI changes. * Supports running 32-bit monitoring tools on top of a 64-bit kernel. * Improved consistency for both kvm(3) and sysctl(3) when retrieving information. The supported abstractions are as follows: * Active sockets and socket buffers * Network interfaces and multicast interfaces * mbuf(9) statistics * bpf(4) statistics * Routing statistics, routing tables, multicast routing * Protocol-dependent statistics There is a sample application, called nettop(8), which provides a simple ncurses-based top(1)-like interface for monitoring active connections and network buffer allocations via the library. A modified version of netstat(1) has also been created to use libnetstat(3) as much as possible. __________________________________________________________________ libprocstat(3) - process statistics URL: http://svn.freebsd.org/viewvc/base/projects/libprocstat/ Contact: Stanislav Sedov Contact: Ulf Lilleengen The libprocstat project is an ongoing effort to develop a library that can be used to retrieve information about running processes and open files in the uniform and platform-independent way both from a running system or from core files. This will facilitate the implementation of file- or process-monitoring applications like lsof(1), fstat(1), fuser, etc. The libprocstat repository contains a preliminary version of the library. It also includes rewrites of the fstat and the fuser utilities ported to use this library instead of retrieving all the required information via the kvm(3) interface; one of the important advantages of the versions that use libprocstat is that these utilities are ABI independent. Open tasks: 1. Implement KVM-based namecache lookup to retrieve filesystem paths associated with file descriptors and VM objects. 2. Analyze possible ways of exporting file and process information from the kernel in an extensible and ABI-independent way. __________________________________________________________________ Modular Congestion Control URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/ Contact: Lawrence Stewart The patch has received some significant rototilling in the past few months to prepare it for merging to FreeBSD-CURRENT. Additionally, I completed an implementation of the CUBIC congestion control algorithm to complement the existing NewReno and H-TCP algorithm implementations already available. I have one further intrusive change to make, which will allow congestion control modules to be shared between the TCP and SCTP stacks. Once this is complete, I will be soliciting for review/testing in the hope of committing the patch to FreeBSD-CURRENT in time to be able to backport it for 8.1-RELEASE. Open tasks: 1. Abstract the congestion control specific variables out of the TCP and SCTP control blocks into a new struct that can be passed into the API instead of the control block itself. __________________________________________________________________ Network Stack Virtualization URL: http://wiki.freebsd.org/Image URL: http://wiki.freebsd.org/200909DevSummit Contact: Bjoern A. Zeeb Contact: Marko Zec Contact: Robert Watson The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail environment, each maintaining its private network interfaces, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more. During the last months the remaining pieces of the VIMAGE work were merged by Marko, Julian and Bjoern. Robert Watson developed a vnet allocator to overcome ABI issues. Jamie Gritton merged his hierachical jail framework that now also is the management interface for virtual network stacks. During the FreeBSD Developer Summit that took place at EuroBSDCon 2009 in Cambridge, UK, people virtualized more code. As a result SCTP and another accept filter were virtualized and more people became familiar with the design of VImage and the underlying concepts. Finally getting more hands involved was a crucial first step for the long term success of kernel virtualization. The next steps will be to finish the network stack virtualization, generalize the allocator framework before thinking of virtualizing further subsystems and to update the related documentation. Along with that a proper jail management framework will be worked on. Long term goals, amongst others, will be to virtualize more subsystems like SYS-V IPC, better privilege handling, and resource limits. In the upcoming FreeBSD 8.0 Release, vnets are treated as an experimental feature. As a result, they are not yet recommended for use in production environments. There was lots of time spent to finalize the infrastructure for vnets though, so that further changes can be merged and we are aiming to have things production ready for 8.2. In case you want to help to achieve this goal, feel free to contact us and support or help virtualizing outstanding parts like two firewalls, appletalk, netipx, ... as well as generating regression tests. __________________________________________________________________ New approach to the locale database URL: http://wiki.freebsd.org/LocaleNewApproach URL: svn://svn.freebsd.org/base/user/edwin/locale Contact: Edwin Groothuis Contact: i18n mailinglist Problem: Over the years the FreeBSD locale database (share/colldef, share/monetdef, share/msgdef, share/numericdef, share/timedef) has accumulated a total of 165 definitions (language - country-code - character-set triplets). The contents of the files for Western European languages are often low-ASCII but for Eastern European and Asian languages partly or fully high-ASCII. Without knowing how to display or interpret the character-sets, it is difficult to make sure by the general audience that the local language (language - country-code) definitions are displayed properly in various character-sets. Suggested approach: With the combination of the data in the Unicode project (whose goal is to define all the possible written characters and symbols on this planet) and the Common Locale Data Repository (whose goal is to document all the different data and definitions needed for the locale database), we can easily keep track of the data, without the need of being able to display the data in the required character sets or understand them fully when updates are submitted by third parties. Current status: Conversion of share/monetdef, share/msgdef, share/numericdef, share/timedef to the new design is completed. The Makefile infrastructure is converted. Regression checks are done. Most of the tools are in place, waiting on the import of bsdiconv to the base system. Open tasks: 1. At this moment the system is not self-hosted yet, because of the lack of an iconv-kind of program in the base operating system. Gabor@ is working on bsdiconv as a GSoC project and once that has been imported we will be able to perform a clean install from the definitions in Unicode text format to the required formats and character sets. __________________________________________________________________ New BSD licensed debugger URL: http://wiki.freebsd.org/TheBsdDebugger URL: http://people.freebsd.org/~dfr/ngdb.git URL: http://wiki.freebsd.org/200909DevSummit?action=AttachFile&do=view&targe t=NGDB-200909.pdf Contact: Doug Rabson <> I have been working recently on writing a new debugger, primarily for the FreeBSD platform. For various reasons, I have been writing it in a relatively obscure C-like language called D. So far, I have a pretty useful (if a little raw at the edges) command line debugger which supports ELF, Dwarf debugging information and (currently) 32 bit FreeBSD and Linux. The engine includes parsing and evaluation of arbitrary C expressions along with the usual debugging tools such as breakpoints, source code listing, single-step etc. All the code is new and BSD licensed. Currently, the thing supports userland debugging of i386 targets via ptrace and post-mortem core file debugging of the same. I will be adding amd64 support real soon (TM) and maybe support for GDB's remote debugging protocol later. __________________________________________________________________ NFSv4 ACLs URL: http://wiki.freebsd.org/NFSv4_ACLs Contact: Edward Tomasz Napierala During Google Summer of Code 2008, I have implemented native support for NFSv4 ACLs for both ZFS and UFS. Most of the code has already been merged to CURRENT. NFSv4 ACLs are unconditionally enabled in ZFS and the usual tools, like getfacl(1) and setfacl(1) can be used to view and change them. I plan to merge the remaining bits (UFS support) this month. It should be possible to MFC it in order to ship in FreeBSD 8.1-RELEASE. Open tasks: 1. UFS changes review 2. Support for NFSv4 ACLs in tar(1) __________________________________________________________________ pefs - stacked cryptographic filesystem (Summer of Code 2009) URL: http://blogs.freebsdish.org/gleb/ URL: http://wiki.freebsd.org/SOC2009GlebKurtsov Contact: Gleb Kurtsou Contact: Stanislav Sedov Pefs is a kernel level filesystem for transparently encrypting files on top of other filesystems (like zfs or ufs). It adds no extra information into files (unlike others), doesn't require cipher block sized io operations, supports per directory/file keys and key chaining, uses unique per file tweak for encryption. Supported algorithms: AES, Camellia, Salsa20. The code is ready for testing. Open tasks: 1. Implement encrypted name lookup/readir cache 2. Optimize sparse files handling and file resizing __________________________________________________________________ Portmaster - utility to assist users with managing ports URL: http://dougbarton.us/portmaster.html Contact: Doug Barton I am currently seeking funding for further development work on portmaster. There are several features that are regularly requested by the community (such as support for installing packages) that I would very much like to implement but that will take more time than I can reasonably volunteer to implement correctly. There is information about the funding proposal available at the link above. Meanwhile I have recently completed another round of bug fixes and feature enhancements. The often-requested ability to specify the -x (exclude) option more than once on the command line was added in version 2.12. Also in that version I added the --list-origins option to make it easier to reinstall ports after a major version upgrade, or install the same set of ports on another system. Open tasks: 1. See the funding proposal. __________________________________________________________________ Release Engineering Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team continues to work on FreeBSD 8.0-RELEASE. Public testing has turned up quite a few problems, many related to the low-level network (routing/ARP table) changes and their interactions with IPv6. Progress continues to be made on fixing up the issues that have been identified during the public testing. At this point in time we are shooting for two more public test builds (RC2 and RC3) followed by the release late October or early November. __________________________________________________________________ Stream Control Transmission Protocol (SCTP) Contact: Randall Stewart SCTP continues to have minor fixes added to it as well as some new features. First and foremost, we now have VIMAGE and SCTP working and playing together. This goal was accomplished with the help of bz@, my new mentee tuexen@ and myself working together at the FreeBSD DevSummit in Cambridge, UK. Also the non-renegable SACK feature contributed by the university of Delaware was fixed so that now its safe to turn on (its sysctl). If you are using SCTP with CMT (Conncurrent Multipath Transfer) you will want to enable this option (CMT is also a sysctl). With CMT enabled you will be able to send data to all the destinations of an SCTP peer. We welcomed a new mentee (soon to be a commiter) to FreeBSD. Michael Tuexen is now a mentee of rrs@. Michael has been contributing to the SCTP work for quite some time and also moonlights as a Professor at the University of Muenster in Germany (when not doing SCTP coding). __________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/docproj/translations.html#dutch Contact: René Ladan Contact: Remko Lodder The current translations (Handbook and some articles) are kept up to date with the English versions. Some parts of the website have been translated, more work is in progress. Open tasks: 1. Find more volunteers for translating the remaining parts of the website and the FAQ. __________________________________________________________________ The FreeBSD Forums URL: http://forums.freebsd.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since their public launch in November 2008, the FreeBSD Forums (the most recent addition to the user community and support channels for the FreeBSD Operating System) have witnessed a healthy and steady growth. The user population is now at over 8,000 registered users, who have participated in over 6,000 topics, containing over 40,000 posts in total. The sign-up rate hovers between 50-100 each week. The total number of visitors (including 'guests') is hard to gauge but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the Forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the Forums' success is their 'BSD-style' approach when it comes to administration and moderation. The Forums have a strong and unified identity, they are neatly divided into sub-forums (like 'Networking', 'Installing & Upgrading', etc.), very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. We expect the Forums to be, and to remain, a central hub in FreeBSD's community and support efforts. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.freebsdfoundation.org Contact: Deb Goodkin Kicking off our fall fund-raising campaign! Find out more at http://www.freebsdfoundation.org/donate/. We were a sponsor for EuroBSDCon 2009, and provided travel grants to 8 FreeBSD developers and users. We sponsored Kyiv BSD 2009, in Kiev Ukraine. We were also a sponsor of BSDCan, and sponsored 7 developers. We funded three new projects, New Console Driver by Ed Schouten, AVR32 Support by Arnar Mar Sig, and Wireless Mesh Support by Rui Paulo, which has completed. We continued funding a project that is making improvements to the FreeBSD TCP Stack by Lawrence Stewart. The project that made removing disk devices with mounted filesystems on them safe, by Edward Napierala, is now complete. We recognized the following FreeBSD developers at EuroBSDCon 2009: Poul-Henning Kamp, Bjoern Zeeb, and Simon Nielsen. These developers received limited edition FreeBSD Foundation vests. Follow us on Twitter now! __________________________________________________________________ The FreeBSD German Documentation Project URL: https://doc.bsdgroup.de URL: http://code.google.com/p/bsdcg-trans/wiki/BSDPJTAdede Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke In May 2009, Benedict Reuschling received his commit bit to the www/de and doc/de_DE.ISO8859-1 trees under the mentorship of Johann Kois. Since then, he has been working primarily on the Handbook, updating existing chapters and translating new ones. Most notably, the filesystems and DTrace chapters have been recently translated. Bugs found in the original documents along the way were reported back so that the other translation teams could incorporate them, as well. Christoph Sold has put his time in translating the wiki pages of the BSD Certification Group into the German language. This is very helpful for all German people who want to take the exam and like to read the information about it in their native language. Daniel Seuffert has sent valuable corrections and bugfixes. Thanks to both of them for their time and efforts! The website is translated and updated constantly. Missing parts will be translated as time permits. We appreciate any help from volunteers in proofreading documents, translating new ones and keeping them up to date. Even small error reports are of great help for us. You can find contact information at the above URL. Open tasks: 1. Update the existing documentation set (especially the Handbook). 2. Translate more articles to German. 3. Read the translations. Check for problems and mistakes. Send feedback. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli In the last months, we have not added new translations, although we have been working on the existing ones to have them updated. We need more translators and volunteers to keep the amount of the translated documentation growing, so feel free to contribute. Every line of submission or feedback is appreciated and highly welcome. If you want to join our work, please read the introduction to the project as well as the FDP Primer (both of them are available in Hungarian). Open tasks: 1. Translate news entries, press releases 2. Translate Release Notes for -CURRENT and 8.X 3. Translate articles 4. Translate web pages 5. Read the translations, send feedback __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/es URL: http://www.FreeBSD.org/doc/es URL: http://www.freebsd.org/doc/es/articles/fdp-es/ Contact: José Vicente Carrasco Vayá Contact: Gábor Kövesdán Recently, we have added one new article translation. The existing translations have not been updated, though. We need more human resources to keep up with the work and keep the translations up-to-date. Open tasks: 1. Update the Handbook translation 2. Update the web page translation __________________________________________________________________ The Newcons project URL: http://wiki.FreeBSD.org/Newcons URL: http://people.freebsd.org/~ed/newcons/patches/ Contact: Ed Schouten Some time ago I started writing a new driver for the FreeBSD kernel called vt(4), which is basically a replacement of syscons. There is still a lot of work that needs to be done but it is probably useful to mention what it does (and what does not). Right now there are just two graphics drivers for vt(4), namely a VGA driver for i386 and amd64 and a Microsoft Xbox graphics driver (because it was so easy to implement). I still have to figure out what I am going to do with VESA, because maybe it is better to just ignore VESA and figure out how hard it is to extend DRM to interact with vt(4). Some random features: it already supports both Unicode (UTF-8) input and output, it is MPSAFE and supports per-window graphical fonts of variable dimensions, containing an almost infinite amount of glyphs (both bold and regular). Open tasks: 1. Research needs to be done on DRM's codebase. 2. Syscons should already be migrated to TERM=xterm to make switching between drivers a bit easier. __________________________________________________________________ Valgrind suite on FreeBSD URL: http://wiki.freebsd.org/Valgrind Contact: Stanislav Sedov The Valgrind suite in the FreeBSD ports collection has been updated to version 3.5.0 (the latest available version). Most of the issues of the previous version should be resolved now: we expect memcheck, callgrind and cachegrind to be fully functional on both i386 and amd64 platforms as well as for i386 binaries running on amd64 system. DRD/hellgrind should work too, though they generate a lot of false-positives for now, so their output is a bit messy. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.freebsd.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Juergen Lock Contact: Martin Wilke VirtualBox has been committed to the Ports tree and synchronized with the latest trunk version from Sun. Several known problems are already fixed and some new features have been added: * VT-x support * Bridging support (Big Thanks to Fredrik Lindberg) * Host Serial Support * ACPI Support * Host DVD/CD access * SMP Support We would like to say thanks to all the people who helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox on FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 08:43:51 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77221065672 for ; Mon, 12 Oct 2009 08:43:51 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF898FC26 for ; Mon, 12 Oct 2009 08:43:51 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9C8heWD098282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 10:43:40 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n9C8hds5098281; Mon, 12 Oct 2009 10:43:39 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 12 Oct 2009 10:43:38 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ed Schouten Message-ID: <20091012084337.GI36937@acme.spoerlein.net> Mail-Followup-To: Ed Schouten , FreeBSD Hackers References: <20091011145021.GG36937@acme.spoerlein.net> <20091011170918.GU71731@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091011170918.GU71731@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 08:43:51 -0000 On Sun, 11.10.2009 at 19:09:18 +0200, Ed Schouten wrote: > Hi Ulrich, > > * Ulrich Spörlein wrote: > > Comments? Committers? > > Wouldn't it better to address the root of the problem while there? ;-) It sure would, but someone[TM] would have to fix all problems for a top-level dir in a short time frame before new code hits the repo. Or, we might end up with individual WARNS on 98% of the subdirs and need a big sweeping patch to then flip the default anyway, so why not now? It raises the bar for new code entering the tree and we need individual WARNS lowering anyway due to contrib code. The only question then is, when do we want to churn. Right now when a patch is available or do we wait and hope that someday all will be better? Anyway, interest seems low for such a big patch so I guess I'll have to divvy it up for better digestion. Regards, Uli From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 09:57:11 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE63D1065672 for ; Mon, 12 Oct 2009 09:57:11 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 85D1F8FC0C for ; Mon, 12 Oct 2009 09:57:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 674C014D984A; Mon, 12 Oct 2009 11:57:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9wXHLPhPNEEQ; Mon, 12 Oct 2009 11:57:08 +0200 (CEST) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id DE70014D9843; Mon, 12 Oct 2009 11:57:07 +0200 (CEST) Message-ID: <4AD2FD6E.8090208@FreeBSD.org> Date: Mon, 12 Oct 2009 11:57:02 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ed Schouten References: <20091011145021.GG36937@acme.spoerlein.net> <20091011170918.GU71731@hoeg.nl> In-Reply-To: <20091011170918.GU71731@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:57:11 -0000 Ed Schouten escribi: > Hi Ulrich, > > * Ulrich Sprlein wrote: > >> Comments? Committers? >> > > Wouldn't it better to address the root of the problem while there? ;-) > What I noticed is that the patch sets WARNS?=0 for a lot of utilities, which actually have higher WARNS-compliance. Even if we don't "address the root of the problem" right now, it would be nice to elaborate and set each WARNS level at the higher value possible.For example, usr.bin/ul is marked as 0 by the patch but it seems to me it is WARNS=6 clean. I don't know the last sources, though, but I'm sure it will compile with at least WARNS=3. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 10:30:38 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DD651065692; Mon, 12 Oct 2009 10:30:38 +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 F39E68FC12; Mon, 12 Oct 2009 10:30:37 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F2E786D41C; Mon, 12 Oct 2009 10:30:36 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B21C984503; Mon, 12 Oct 2009 12:30:36 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor Kovesdan References: <20091011145021.GG36937@acme.spoerlein.net> <20091011170918.GU71731@hoeg.nl> <4AD2FD6E.8090208@FreeBSD.org> Date: Mon, 12 Oct 2009 12:30:36 +0200 In-Reply-To: <4AD2FD6E.8090208@FreeBSD.org> (Gabor Kovesdan's message of "Mon, 12 Oct 2009 11:57:02 +0200") Message-ID: <8663aksy43.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , FreeBSD Hackers Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:30:38 -0000 Gabor Kovesdan writes: > What I noticed is that the patch sets WARNS?=3D0 for a lot of utilities, > which actually have higher WARNS-compliance. WARNS level 0 is the current default. All Ulrich's patch does is reverse the logic so that WARNS is 6 by default and anything that didn't already set WARNS explicitly sets it to 0, so the actual value of WARNS in each Makefile is the same as before. This is orthogonal to actually fixing whatever doesn't currently build at a higher WARNS level. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 10:34:42 2009 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D48E1065692 for ; Mon, 12 Oct 2009 10:34:42 +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 30AE68FC20 for ; Mon, 12 Oct 2009 10:34:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 103216D41B for ; Mon, 12 Oct 2009 10:34:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CF2E784503; Mon, 12 Oct 2009 12:34:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: hackers@FreeBSD.org References: <20091011145021.GG36937@acme.spoerlein.net> Date: Mon, 12 Oct 2009 12:34:40 +0200 In-Reply-To: <20091011145021.GG36937@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Sun, 11 Oct 2009 16:50:21 +0200") Message-ID: <861vl8sxxb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:34:42 -0000 Ulrich Sp=C3=B6rlein writes: > Comments? Committers? You can set WARNS to 4 for rwhod, since we don't do Alpha any more. (actually, you can set it to 6, but 4 is what was already there) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 10:52:06 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED501106568D for ; Mon, 12 Oct 2009 10:52:06 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id A2CE18FC08 for ; Mon, 12 Oct 2009 10:52:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 7CFBF14D9854; Mon, 12 Oct 2009 12:52:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mA64p0jtXCE0; Mon, 12 Oct 2009 12:52:01 +0200 (CEST) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AE6A514D9853; Mon, 12 Oct 2009 12:52:01 +0200 (CEST) Message-ID: <4AD30A4B.7060409@FreeBSD.org> Date: Mon, 12 Oct 2009 12:51:55 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <20091011145021.GG36937@acme.spoerlein.net> <20091011170918.GU71731@hoeg.nl> <4AD2FD6E.8090208@FreeBSD.org> <8663aksy43.fsf@ds4.des.no> In-Reply-To: <8663aksy43.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ed Schouten , FreeBSD Hackers Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:52:07 -0000 Dag-Erling Smørgrav escribió: > Gabor Kovesdan writes: > >> What I noticed is that the patch sets WARNS?=0 for a lot of utilities, >> which actually have higher WARNS-compliance. >> > > WARNS level 0 is the current default. All Ulrich's patch does is > reverse the logic so that WARNS is 6 by default and anything that didn't > already set WARNS explicitly sets it to 0, so the actual value of WARNS > in each Makefile is the same as before. This is orthogonal to actually > fixing whatever doesn't currently build at a higher WARNS level. > Yep, I understand that but what I'm saying is that once we are dealing with such a big patch, it would be nice to elaborate the highest WARNS level of each utility and set them accordingly, which doesn't require too much extra effort as opposed to making all of them WARNS=6 compliant. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 11:29:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E961065693 for ; Mon, 12 Oct 2009 11:29:11 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 147828FC0A for ; Mon, 12 Oct 2009 11:29:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxJ4j-0000d5-Mr for freebsd-hackers@freebsd.org; Mon, 12 Oct 2009 13:28:25 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 13:28:25 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 13:28:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 12 Oct 2009 13:27:28 +0200 Lines: 4 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) Sender: news Subject: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:29:11 -0000 I'm trying to work around some extreme brain damageness in PHP (yes, it sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so I'm wondering what are my other options? Is there a way to set TCP_NODELAY system-wide? From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 11:36:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2904B1065672 for ; Mon, 12 Oct 2009 11:36:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A79C08FC08 for ; Mon, 12 Oct 2009 11:36:24 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n9CBaMgg038885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Oct 2009 13:36:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n9CBaJ9A075097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 13:36:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n9CBaJb5053857; Mon, 12 Oct 2009 13:36:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n9CBaJrn053856; Mon, 12 Oct 2009 13:36:19 +0200 (CEST) (envelope-from ticso) Date: Mon, 12 Oct 2009 13:36:19 +0200 From: Bernd Walter To: Ivan Voras Message-ID: <20091012113619.GN48396@cicely7.cicely.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:36:25 -0000 On Mon, Oct 12, 2009 at 01:27:28PM +0200, Ivan Voras wrote: > I'm trying to work around some extreme brain damageness in PHP (yes, it > sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so > I'm wondering what are my other options? Is there a way to set > TCP_NODELAY system-wide? net.inet.tcp.delayed_ack net.inet.tcp.delacktime Depending on your application it may be sufficient to just reduce the time. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 11:42:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79667106568B for ; Mon, 12 Oct 2009 11:42:35 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 36B6D8FC1B for ; Mon, 12 Oct 2009 11:42:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxJIG-0007x8-67 for freebsd-hackers@freebsd.org; Mon, 12 Oct 2009 13:42:24 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 13:42:24 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 13:42:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 12 Oct 2009 13:42:08 +0200 Lines: 15 Message-ID: References: <20091012113619.GN48396@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <20091012113619.GN48396@cicely7.cicely.de> Sender: news Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:42:35 -0000 Bernd Walter wrote: > On Mon, Oct 12, 2009 at 01:27:28PM +0200, Ivan Voras wrote: >> I'm trying to work around some extreme brain damageness in PHP (yes, it >> sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so >> I'm wondering what are my other options? Is there a way to set >> TCP_NODELAY system-wide? > > net.inet.tcp.delayed_ack > net.inet.tcp.delacktime > > Depending on your application it may be sufficient to just reduce the > time. Really? Doesn't TCP_NODELAY (Nagle's algorithm) work on buffers to be sent rather than on ACKs on received data? From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 11:50:26 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3796E1065672; Mon, 12 Oct 2009 11:50:26 +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 EC3AC8FC12; Mon, 12 Oct 2009 11:50:25 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DCDFF6D41B; Mon, 12 Oct 2009 11:50:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7755684503; Mon, 12 Oct 2009 13:50:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor Kovesdan References: <20091011145021.GG36937@acme.spoerlein.net> <20091011170918.GU71731@hoeg.nl> <4AD2FD6E.8090208@FreeBSD.org> <8663aksy43.fsf@ds4.des.no> <4AD30A4B.7060409@FreeBSD.org> Date: Mon, 12 Oct 2009 13:50:24 +0200 In-Reply-To: <4AD30A4B.7060409@FreeBSD.org> (Gabor Kovesdan's message of "Mon, 12 Oct 2009 12:51:55 +0200") Message-ID: <86ws30rfun.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , FreeBSD Hackers Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:50:26 -0000 Gabor Kovesdan writes: > Yep, I understand that but what I'm saying is that once we are dealing > with such a big patch, it would be nice to elaborate the highest WARNS > level of each utility and set them accordingly, which doesn't require > too much extra effort as opposed to making all of them WARNS=3D6 > compliant. We can do that in a separate patch / commit. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 11:56:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5762106566B; Mon, 12 Oct 2009 11:56:03 +0000 (UTC) (envelope-from hunter@comsys.com.ua) Received: from mail.ice-tech.com.ua (mail.ice-tech.com.ua [77.120.117.100]) by mx1.freebsd.org (Postfix) with ESMTP id 71FB98FC12; Mon, 12 Oct 2009 11:56:03 +0000 (UTC) Received: from mail.mmg.in.ua ([91.195.53.2] helo=[192.168.17.115]) by mail.ice-tech.com.ua with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxGPn-000DoL-EO; Mon, 12 Oct 2009 11:37:59 +0300 Message-ID: <4AD31431.4060503@comsys.com.ua> Date: Mon, 12 Oct 2009 14:34:09 +0300 From: Sergey Smitienko User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:56:03 -0000 Ivan Voras пишет: > I'm trying to work around some extreme brain damageness in PHP (yes, > it sucks) which doesn't have a way to set TCP_NODELAY on stream > sockets so I'm wondering what are my other options? Is there a way to > set TCP_NODELAY system-wide? What's wrong with: From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 12:09:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54341065670 for ; Mon, 12 Oct 2009 12:09:37 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 62C498FC08 for ; Mon, 12 Oct 2009 12:09:37 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxJfR-0003u3-18 for freebsd-hackers@freebsd.org; Mon, 12 Oct 2009 14:06:21 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 14:06:21 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 14:06:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 12 Oct 2009 14:02:51 +0200 Lines: 21 Message-ID: References: <4AD31431.4060503@comsys.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4AD31431.4060503@comsys.com.ua> Sender: news Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:09:37 -0000 Sergey Smitienko wrote: > Ivan Voras пишет: >> I'm trying to work around some extreme brain damageness in PHP (yes, >> it sucks) which doesn't have a way to set TCP_NODELAY on stream >> sockets so I'm wondering what are my other options? Is there a way to >> set TCP_NODELAY system-wide? > What's wrong with: > > $socket = socket_create_listen(1223); > socket_set_option($socket, SOL_SOCKET, TCP_NODELAY, 1); > var_dump(socket_get_option($socket, SOL_SOCKET, TCP_NODELAY)); > ?> These "socket objects" are completely different from fsockopen() "stream socket objects", and socket_set_option() doesn't work on those. Consequently, you cannot use fgets() and friends to work with sockets created with socket_*() and there is apparently no way to wrap sockets in streams. It's an already finished application that uses stream-like functions (e.g. fgets() and friends) and rewriting it to use raw socket recv() and send() would be nasty. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 12:24:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4806106568D; Mon, 12 Oct 2009 12:24:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3E79E8FC08; Mon, 12 Oct 2009 12:24:28 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n9CCOQrA040610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Oct 2009 14:24:27 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n9CCOORb076603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 14:24:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n9CCONc7053968; Mon, 12 Oct 2009 14:24:23 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n9CCONTK053967; Mon, 12 Oct 2009 14:24:23 +0200 (CEST) (envelope-from ticso) Date: Mon, 12 Oct 2009 14:24:23 +0200 From: Bernd Walter To: Ivan Voras Message-ID: <20091012122423.GO48396@cicely7.cicely.de> References: <20091012113619.GN48396@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:24:28 -0000 On Mon, Oct 12, 2009 at 01:42:08PM +0200, Ivan Voras wrote: > Bernd Walter wrote: > >On Mon, Oct 12, 2009 at 01:27:28PM +0200, Ivan Voras wrote: > >>I'm trying to work around some extreme brain damageness in PHP (yes, it > >>sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so > >>I'm wondering what are my other options? Is there a way to set > >>TCP_NODELAY system-wide? > > > >net.inet.tcp.delayed_ack > >net.inet.tcp.delacktime > > > >Depending on your application it may be sufficient to just reduce the > >time. > > Really? Doesn't TCP_NODELAY (Nagle's algorithm) work on buffers to be > sent rather than on ACKs on received data? Good point. TCP_NODELAY disables both to my knowledge. And setting delacktime to 1 helped me in one buffer case. But I'm not sure anymore - a non delayed ack might piggypack payload much sooner of course. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 13:50:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B941065670 for ; Mon, 12 Oct 2009 13:50:26 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 257B68FC0A for ; Mon, 12 Oct 2009 13:50:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id EC1B1489C2; Mon, 12 Oct 2009 14:50:24 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIdwVa6mb7rn; Mon, 12 Oct 2009 14:50:18 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 5E065488CF; Mon, 12 Oct 2009 14:50:18 +0100 (BST) Message-ID: <4AD333F4.2020304@tomjudge.com> Date: Mon, 12 Oct 2009 13:49:40 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Ivan Voras References: <4AD31431.4060503@comsys.com.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 13:50:26 -0000 Ivan Voras wrote: > Sergey Smitienko wrote: >> Ivan Voras пишет: >>> I'm trying to work around some extreme brain damageness in PHP (yes, >>> it sucks) which doesn't have a way to set TCP_NODELAY on stream >>> sockets so I'm wondering what are my other options? Is there a way >>> to set TCP_NODELAY system-wide? >> What's wrong with: >> >> > $socket = socket_create_listen(1223); >> socket_set_option($socket, SOL_SOCKET, TCP_NODELAY, 1); >> var_dump(socket_get_option($socket, SOL_SOCKET, TCP_NODELAY)); >> ?> > > These "socket objects" are completely different from fsockopen() > "stream socket objects", and socket_set_option() doesn't work on > those. Consequently, you cannot use fgets() and friends to work with > sockets created with socket_*() and there is apparently no way to wrap > sockets in streams. It's an already finished application that uses > stream-like functions (e.g. fgets() and friends) and rewriting it to > use raw socket recv() and send() would be nasty. Is this for php java bridge by any chance? If so I believe we have a patch floating around so that it can use UNIX sockets rather than INET ones. TJ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 13:53:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898F1106568B for ; Mon, 12 Oct 2009 13:53:06 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 450848FC1B for ; Mon, 12 Oct 2009 13:53:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxLKj-0002dR-0N for freebsd-hackers@freebsd.org; Mon, 12 Oct 2009 15:53:05 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 15:53:04 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2009 15:53:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 12 Oct 2009 15:52:47 +0200 Lines: 28 Message-ID: References: <4AD31431.4060503@comsys.com.ua> <4AD333F4.2020304@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4AD333F4.2020304@tomjudge.com> Sender: news Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 13:53:06 -0000 Tom Judge wrote: > Ivan Voras wrote: >> Sergey Smitienko wrote: >>> Ivan Voras пишет: >>>> I'm trying to work around some extreme brain damageness in PHP (yes, >>>> it sucks) which doesn't have a way to set TCP_NODELAY on stream >>>> sockets so I'm wondering what are my other options? Is there a way >>>> to set TCP_NODELAY system-wide? >>> What's wrong with: >>> >>> >> $socket = socket_create_listen(1223); >>> socket_set_option($socket, SOL_SOCKET, TCP_NODELAY, 1); >>> var_dump(socket_get_option($socket, SOL_SOCKET, TCP_NODELAY)); >>> ?> >> >> These "socket objects" are completely different from fsockopen() >> "stream socket objects", and socket_set_option() doesn't work on >> those. Consequently, you cannot use fgets() and friends to work with >> sockets created with socket_*() and there is apparently no way to wrap >> sockets in streams. It's an already finished application that uses >> stream-like functions (e.g. fgets() and friends) and rewriting it to >> use raw socket recv() and send() would be nasty. > Is this for php java bridge by any chance? If so I believe we have a > patch floating around so that it can use UNIX sockets rather than INET > ones. No, something in-house. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 15:22:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409B3106566B; Mon, 12 Oct 2009 15:22:49 +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 311D38FC18; Mon, 12 Oct 2009 15:22:48 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 265B81A3C4A; Mon, 12 Oct 2009 08:22:48 -0700 (PDT) Date: Mon, 12 Oct 2009 08:22:48 -0700 From: Alfred Perlstein To: Ivan Voras Message-ID: <20091012152248.GJ79298@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:22:49 -0000 * Ivan Voras [091012 04:29] wrote: > I'm trying to work around some extreme brain damageness in PHP (yes, it > sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so > I'm wondering what are my other options? Is there a way to set > TCP_NODELAY system-wide? Ivan, many people write php extensions, maybe you can do that? -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 15:54:27 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5E63106566B for ; Mon, 12 Oct 2009 15:54:27 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8838FC1A for ; Mon, 12 Oct 2009 15:54:27 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9CFsOYY009259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 17:54:24 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n9CFsNUU009248; Mon, 12 Oct 2009 17:54:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 12 Oct 2009 17:54:22 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20091012155421.GJ36937@acme.spoerlein.net> Mail-Followup-To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , hackers@freebsd.org References: <20091011145021.GG36937@acme.spoerlein.net> <861vl8sxxb.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <861vl8sxxb.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:54:27 -0000 On Mon, 12.10.2009 at 12:34:40 +0200, Dag-Erling Smørgrav wrote: > Ulrich Spörlein writes: > > Comments? Committers? > > You can set WARNS to 4 for rwhod, since we don't do Alpha any more. > > (actually, you can set it to 6, but 4 is what was already there) Is there some easy way to do cross-compiles (like make universe) in just one of the subdirs? That would help tremendously. Bye, Uli From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 16:37:40 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B0D5106566B for ; Mon, 12 Oct 2009 16:37:40 +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 D1FE08FC1C for ; Mon, 12 Oct 2009 16:37:39 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B66416D41B for ; Mon, 12 Oct 2009 16:37:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 522D984513; Mon, 12 Oct 2009 18:37:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: hackers@freebsd.org References: <20091011145021.GG36937@acme.spoerlein.net> <861vl8sxxb.fsf@ds4.des.no> <20091012155421.GJ36937@acme.spoerlein.net> Date: Mon, 12 Oct 2009 18:37:38 +0200 In-Reply-To: <20091012155421.GJ36937@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Mon, 12 Oct 2009 17:54:22 +0200") Message-ID: <86zl7wpnzh.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 16:37:40 -0000 Ulrich Sp=C3=B6rlein writes: > Is there some easy way to do cross-compiles (like make universe) in just > one of the subdirs? That would help tremendously. % cd /usr/src % make toolchain TARGET=3Dpowerpc % make buildenv TARGET=3Dpowerpc %% cd usr.sbin/rwhod %% make ('make buildenv' starts a subshell) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 17:28:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6375F10656C0; Mon, 12 Oct 2009 17:28:48 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id C3FB88FC19; Mon, 12 Oct 2009 17:28:47 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so2106633eyf.9 for ; Mon, 12 Oct 2009 10:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=o36/OLHZTrx2Ty0eJUpkrHhKPxrZB/0rGvu1XH8Wml0=; b=moK0PIZP9vTCeC5yqVpFMpbO2En+HgQS1eYeVgD1h7qnquvUgc5prOfeldISZqaBB5 B55ge7TAimrS35EWe27NFnO93J3+SnB9mUGAF1mEuAfK1pcQPiwH8Pczq8lhsCBknYrT eqvccKiqQwWAmYqCcThq7m7IM2C3vnwqsvIyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=mg1j/ulwNfG++2cU/WmQQJDcfTNP14Mbp5yOpX/tYAoWlB1tPUuxKve+feHzUgte+2 +kspwh/o6PcUrBoGcBdWBz+Sm5ovpxSbGJk5Yk8S+dBpsIEvgbaeKDeiXvFrRbPY5ybr ivmdRst/bFyeqaRqIQe/lQfYPagYQtY5BuS9o= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.87.136 with SMTP id y8mr2037126wee.43.1255368526753; Mon, 12 Oct 2009 10:28:46 -0700 (PDT) In-Reply-To: <20091012152248.GJ79298@elvis.mu.org> References: <20091012152248.GJ79298@elvis.mu.org> From: Ivan Voras Date: Mon, 12 Oct 2009 19:28:26 +0200 X-Google-Sender-Auth: c483c279aade0b0a Message-ID: <9bbcef730910121028q7185cb47sd5780fbb0b8f59ad@mail.gmail.com> To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:28:48 -0000 2009/10/12 Alfred Perlstein : > * Ivan Voras [091012 04:29] wrote: >> I'm trying to work around some extreme brain damageness in PHP (yes, it >> sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so >> I'm wondering what are my other options? Is there a way to set >> TCP_NODELAY system-wide? > > Ivan, many people write php extensions, maybe you can do that? While writing PHP extensions isn't hard (I've done it before), I'm not yet convinced it's worth the effort in this case - I don't know if TCP_NODELAY will help at all. I'll think about it if time permits. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 18:15:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 138CB106568F; Mon, 12 Oct 2009 18:15:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E2A658FC0C; Mon, 12 Oct 2009 18:15:45 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5217F46B03; Mon, 12 Oct 2009 14:15:45 -0400 (EDT) Date: Mon, 12 Oct 2009 19:15:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: <9bbcef730910121028q7185cb47sd5780fbb0b8f59ad@mail.gmail.com> Message-ID: References: <20091012152248.GJ79298@elvis.mu.org> <9bbcef730910121028q7185cb47sd5780fbb0b8f59ad@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Alfred Perlstein Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:15:46 -0000 On Mon, 12 Oct 2009, Ivan Voras wrote: > 2009/10/12 Alfred Perlstein : >> * Ivan Voras [091012 04:29] wrote: >>> I'm trying to work around some extreme brain damageness in PHP (yes, it >>> sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so >>> I'm wondering what are my other options? Is there a way to set TCP_NODELAY >>> system-wide? >> >> Ivan, many people write php extensions, maybe you can do that? > > While writing PHP extensions isn't hard (I've done it before), I'm not yet > convinced it's worth the effort in this case - I don't know if TCP_NODELAY > will help at all. I'll think about it if time permits. Create a libc wrapper that calls setsockopt(2) whenever socket(2) is called to create a TCP socket in php, and inject it using LD_PRELOAD. This is a similar trick to what things like socks proxy library wrappers use, is easy to hack together, and avoids having to modify the kernel. When it doesn't work, move on, and if it does, change php :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 12 18:21:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994041065670; Mon, 12 Oct 2009 18:21:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id D13858FC0C; Mon, 12 Oct 2009 18:21:14 +0000 (UTC) Received: by ewy18 with SMTP id 18so3041824ewy.43 for ; Mon, 12 Oct 2009 11:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=M05wIYy5CzV2neyo8V8PtxYtiIpjt9z7bfyoJly+BVY=; b=CuJDZk3JEIOagnbWV8lAzgeICFl0V2DukHUvm0IwEelodE886ZIpSZp77YaQs7pUla //5DbEswQKFcaXoWIIxZAHhj1tWxEP1J1lk9Mf9QZgjUAcPSECmoOjOsUVJMjfzqSoCb VovpWdHAL52tPZ9FYtl/pSton1IStykNvYaTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=E+ZsXMXHY+sH7AhDAVbQtn8GFndEprs2wLjTdEh1IsecolVZFpwAbzw9xoYPmbQ58M tgLJTqGsf/7FAfotNwcaWZyVTB2IxUDfVTkv5UMhE7Z3yo59oj2UxcSXf3AvJ+wOsD2e bRihnHG3kgYhHN2NwSBLffe5kMaRLOZ0ZmyPQ= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.89.14 with SMTP id b14mr2149597wef.76.1255371673770; Mon, 12 Oct 2009 11:21:13 -0700 (PDT) In-Reply-To: References: <20091012152248.GJ79298@elvis.mu.org> <9bbcef730910121028q7185cb47sd5780fbb0b8f59ad@mail.gmail.com> From: Ivan Voras Date: Mon, 12 Oct 2009 20:19:43 +0200 X-Google-Sender-Auth: 2f89235ead7d5470 Message-ID: <9bbcef730910121119r3f7809dfo23c5f2ecdf7b289c@mail.gmail.com> To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alfred Perlstein Subject: Re: "global" TCP_NODELAY? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:21:15 -0000 2009/10/12 Robert Watson : > Create a libc wrapper that calls setsockopt(2) whenever socket(2) is call= ed > to create a TCP socket in php, and inject it using LD_PRELOAD. =C2=A0This= is a > similar trick to what things like socks proxy library wrappers use, is ea= sy > to hack together, and avoids having to modify the kernel. This is actually the sanest idea I've yet come across, including modifying PHP :) From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 13 00:16:29 2009 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C5A2106566B for ; Tue, 13 Oct 2009 00:16:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id DDE5E8FC14 for ; Tue, 13 Oct 2009 00:16:28 +0000 (UTC) Received: (qmail 20863 invoked by uid 399); 12 Oct 2009 23:49:48 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 23:49:48 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3C09B.70801@FreeBSD.org> Date: Mon, 12 Oct 2009 16:49:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: hackers@FreeBSD.org References: <20091011145021.GG36937@acme.spoerlein.net> In-Reply-To: <20091011145021.GG36937@acme.spoerlein.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 00:16:29 -0000 Ulrich Spörlein wrote: > Dear -hackers, > > I would like you to give me your thoughts on the attached patch. There > are no functional changes, what I'm trying to do is introduce WARNS?=6 > for all top-level Makefiles and override that on a subdir basis. > > Why the churn? Because I think it sticks out more, if there's a WARNS=0 > in your Makefile rather than the default being WARNS=0. Perhaps this > gets more incentive going for fixing these WARNS. I don't see how this provides an incentive at all. I also object to this change on the grounds that down the road debugging is potentially going to be more difficult when someone forgets that there is a default WARNS level of 6. One of the strengths of the BSD-style make is the amount of routine stuff that goes on behind the scenes to make it easier to write good makefiles. However I don't think this should be one of those things. > There's also a lot of > work done by the DragonflyBSD folks which I intend to port peu a peu. Can you elaborate on this? What work are you planning to port over, and how does it depend on this default WARNS level issue? > Note: There are lots of style changes for games/ and sbin/, which I can > seperate out for easier review. But I'd like to make some sweeping > patches to bring them more inline with style.Makefile(5) Putting these two changes in the same patch is not a good thing. It makes it harder to read diffs, and commits that address separate issues should be done separately anyway. That said, I think that the style-compliance issue is a valid one, and I personally would be in favor of that happening after the 8.0-release, FWIW. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 13 07:04:20 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9522106566B; Tue, 13 Oct 2009 07:04:19 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D06C8FC08; Tue, 13 Oct 2009 07:04:19 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9D74IWj003132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Oct 2009 09:04:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n9D74IfW003131; Tue, 13 Oct 2009 09:04:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Tue, 13 Oct 2009 09:04:18 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Doug Barton Message-ID: <20091013070417.GK36937@acme.spoerlein.net> Mail-Followup-To: Doug Barton , hackers@freebsd.org References: <20091011145021.GG36937@acme.spoerlein.net> <4AD3C09B.70801@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4AD3C09B.70801@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 07:04:20 -0000 Hi Doug, On Mon, 12.10.2009 at 16:49:47 -0700, Doug Barton wrote: > Ulrich Spörlein wrote: > > Dear -hackers, > > > > I would like you to give me your thoughts on the attached patch. There > > are no functional changes, what I'm trying to do is introduce WARNS?=6 > > for all top-level Makefiles and override that on a subdir basis. > > > > Why the churn? Because I think it sticks out more, if there's a WARNS=0 > > in your Makefile rather than the default being WARNS=0. Perhaps this > > gets more incentive going for fixing these WARNS. > > I don't see how this provides an incentive at all. > > I also object to this change on the grounds that down the road > debugging is potentially going to be more difficult when someone > forgets that there is a default WARNS level of 6. The "default" would be the setting inherited by, eg, src/bin/Makefile.inc. This already has a WARNS=6, are you saying that debugging stuff under bin/ has been made more difficult by that change? Why do we want bin/ to be WARNS-clean and not care about usr.bin/? To make things clear, no changes will be made to /usr/share/mk, if that's what you are afraid if. Unless you do ".include ../Makefile.inc" somewhere under src/*, you won't get WARNS at all. > One of the strengths of the BSD-style make is the amount of routine > stuff that goes on behind the scenes to make it easier to write good > makefiles. However I don't think this should be one of those things. One of the strengths of BSD in general that I have come to love is its higher consistency compared to most other systems. With WARNS=6 under bin/ and WARNS=2 under sbin/ this consistency is violated. > > There's also a lot of > > work done by the DragonflyBSD folks which I intend to port peu a peu. > > Can you elaborate on this? What work are you planning to port over, > and how does it depend on this default WARNS level issue? See http://gitweb.dragonflybsd.org/dragonfly.git?a=search&h=HEAD&st=commit&s=WARNS6 It depends in no way on the included WARNS level, but "the big switch" needs to be done anyway, so why not upfront? > > Note: There are lots of style changes for games/ and sbin/, which I can > > seperate out for easier review. But I'd like to make some sweeping > > patches to bring them more inline with style.Makefile(5) > > Putting these two changes in the same patch is not a good thing. It > makes it harder to read diffs, and commits that address separate > issues should be done separately anyway. > > That said, I think that the style-compliance issue is a valid one, and > I personally would be in favor of that happening after the > 8.0-release, FWIW. I will separate those changes out and work some more on them on another branch. I would really like to get the WARNS changes in first though. Thanks for all the comments, Uli From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 13 20:50:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0A171065679 for ; Tue, 13 Oct 2009 20:50:46 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 841BF8FC0C for ; Tue, 13 Oct 2009 20:50:46 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,553,1249250400"; d="scan'208";a="15787305" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 13 Oct 2009 22:50:44 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id E97171B0751; Tue, 13 Oct 2009 22:50:44 +0200 (CEST) Date: Tue, 13 Oct 2009 22:50:44 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Mikolaj Golub Message-ID: In-Reply-To: <86d44vqs9l.fsf@kopusha.onet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: crashtar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 20:50:47 -0000 Mikolaj Golub schrieb am 2009-10-10: > On Sat, 10 Oct 2009 12:34:05 +0200 (CEST) Alexander Best wrote: > AB> thanks. this is a cool script and very useful indeed. only thing > you might > AB> want to do is check for root privileges at the beginning to > avoid nasty error > AB> messages like. > AB> awk: can't open file /var/crash/info.0 > AB> source line number 12 > In some cases you might not need root privileges. E.g. on some > servers I don't > have root but SA gives me read access to crashdumps. In this case if > the > script had a check for root privileges I would not be able to use it. > Actually as for me the message looks informative enough, it says that > we have > some problems with accessing crash dump files, so permissions should > be > checked. alright then. :) again: great script. would be great to have this in the ports dir in the near future. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 00:50:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 792A21065670 for ; Wed, 14 Oct 2009 00:50:14 +0000 (UTC) (envelope-from motoom@xs4all.nl) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 16A388FC12 for ; Wed, 14 Oct 2009 00:50:13 +0000 (UTC) Received: from pasta.gandhi.xs4all.nl (gandhi.xs4all.nl [83.161.213.238]) (authenticated bits=0) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9E0cPtq056323; Wed, 14 Oct 2009 02:38:25 +0200 (CEST) (envelope-from motoom@xs4all.nl) From: Michiel Overtoom To: freebsd-hackers@freebsd.org Date: Wed, 14 Oct 2009 02:38:07 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910140238.07174.motoom@xs4all.nl> X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Wed, 14 Oct 2009 01:38:06 +0000 Subject: Re: sysinstall colours X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 00:50:14 -0000 On Saturday 10 October 2009 01:59:32 Randi Harper wrote: > All the problems with sysinstall, and your idea is to > change the color? [...] Fancy colors seems to me like a wrong focus of attention too... but maybe it would be nice to be able to run sysinstall in monochrome mode, for maximum contrast? Is this possible already? Just plain gray text on black background, and inverse for the selection bar, would be useful for those that have trouble reading yellow text on a lightgray background. Anyway, it's great to see that sysinstall gets some attention and useful fixes. What sometimes bothers me a bit while using sysinstall is the long sequence of Yes/No questions at a certain moment ('do you want NFS server? do you want NFS client? do you want anonymous FTP? do you want bridging? etc...). A more logical user interface seems a list of configurable options with their current settings, where you can 'point and click' with a selection bar to toggle Yes/No. Greetings, -- "The ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing." - Vinod Valloppillil http://www.catb.org/~esr/halloween/halloween4.html From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 04:35:23 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32823106566C for ; Wed, 14 Oct 2009 04:35:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D2E348FC12 for ; Wed, 14 Oct 2009 04:35:22 +0000 (UTC) Received: (qmail 4419 invoked by uid 399); 14 Oct 2009 04:35:21 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Oct 2009 04:35:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD55506.4000507@FreeBSD.org> Date: Tue, 13 Oct 2009 21:35:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Doug Barton , hackers@freebsd.org References: <20091011145021.GG36937@acme.spoerlein.net> <4AD3C09B.70801@FreeBSD.org> <20091013070417.GK36937@acme.spoerlein.net> In-Reply-To: <20091013070417.GK36937@acme.spoerlein.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 04:35:23 -0000 Ulrich Spörlein wrote: > The "default" would be the setting inherited by, eg, > src/bin/Makefile.inc. This already has a WARNS=6, are you saying that > debugging stuff under bin/ has been made more difficult by that change? It certainly can be, yes. Although admittedly I don't spend a lot of time debugging stuff under /bin. > Why do we want bin/ to be WARNS-clean and not care about usr.bin/? Red herring. I'd like everything to be as warns-clean as possible, I just disagree that this change will do anything to improve it. > One of the strengths of BSD in general that I have come to love is its > higher consistency compared to most other systems. With WARNS=6 under > bin/ and WARNS=2 under sbin/ this consistency is violated. The thing that you're glossing over is that most of the stuff in /bin is our code, and a lot of the stuff in /usr/[s]bin is contrib code. Thus they actually ARE different. Then of course there is the whole "Foolish consistency ...." issue. >>> There's also a lot of >>> work done by the DragonflyBSD folks which I intend to port peu a peu. >> Can you elaborate on this? What work are you planning to port over, >> and how does it depend on this default WARNS level issue? > > See > http://gitweb.dragonflybsd.org/dragonfly.git?a=search&h=HEAD&st=commit&s=WARNS6 > > It depends in no way on the included WARNS level, but "the big switch" > needs to be done anyway, so why not upfront? I disagree with your assertion that "the big switch needs to be done anyway." My personal preference would be to see first how many things will need overrides (WARNS != 6) before deciding whether it's worth setting a default. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 12:13:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49D3D106566B for ; Wed, 14 Oct 2009 12:13:21 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id C04178FC17 for ; Wed, 14 Oct 2009 12:13:20 +0000 (UTC) Received: from park.js.berklix.net (p549A7D74.dip.t-dialin.net [84.154.125.116]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n9EBd987029310; Wed, 14 Oct 2009 11:39:10 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n9EBd2v8011020; Wed, 14 Oct 2009 13:39:02 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n9EBh0Dw058809; Wed, 14 Oct 2009 13:43:05 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200910141143.n9EBh0Dw058809@fire.js.berklix.net> to: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 14 Oct 2009 02:38:07 +0200." <200910140238.07174.motoom@xs4all.nl> Date: Wed, 14 Oct 2009 13:43:00 +0200 Sender: jhs@berklix.com Cc: Michiel Overtoom Subject: Re: sysinstall colours X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 12:13:21 -0000 > What sometimes bothers me a bit while using sysinstall is the long sequence of > Yes/No questions at a certain moment ('do you want NFS server? do you want > NFS client? do you want anonymous FTP? do you want bridging? etc...). A > more logical user interface seems a list of configurable options with their > current settings, where you can 'point and click' with a selection bar to > toggle Yes/No. Would be nice. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 17:12:33 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16041065676; Wed, 14 Oct 2009 17:12:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BFC338FC19; Wed, 14 Oct 2009 17:12:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07422; Wed, 14 Oct 2009 20:12:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AD6067E.2010503@icyb.net.ua> Date: Wed, 14 Oct 2009 20:12:30 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org, freebsd-hackers@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 17:12:33 -0000 Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 I actually got around to implementing it (in initial/basic form): http://people.freebsd.org/~avg/heci.tgz Other drivers are: [Linux] http://www.openamt.org/ [OpenSolaris] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ An example of what functionality this driver could provide: http://article.gmane.org/gmane.linux.drivers.sensors/20398 This actually was my primary motivation for looking into this driver. Your hardware may be supported by this driver if pciconf -lv has something like the following: none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) HECI Controller' class = simple comms Here's how successful attachment of this driver looks on my system: heci0: mem 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x03: heci0: status = 0x00 heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 The driver has many functional and programming shortcomings, but I still would like to ask for its review and testing. Please read the following warnings and notices: 1. right now the driver is provided only as a module. 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it with; please see hecireg.h for a list of potentially supported IDs and add your ID to heci_probe(). 3. heciio.h does not get installed into /usr/include, so for time being you need to take an extra step to make it available to code that wishes to communicate to heci. 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so don't expect every OpenAMT program to work with it (but it does reliably work for me for the QST thing). Now more details about the code: 1. the code contains some style violations like overly long lines, probably others; but I still would like to hear your comments on its style. 2. there are some bad design decisions like using the same mutex+condvar pair for signaling different events (reception of data from ME, emptying of user buffer); but I still would like to hear your comments about improving the design. 3. only a single connection is allowed for a host client 4. only a single connection is allowed to a ME client (if the client can support more). 5. quite an arbitrary timeout is used in all places where we wait for simething to happen. 6. no power management supported. 7. only messages of size less than 512 bytes are supported. 8. only complete messages are supported, multi-part messages are not. 9. userland is expected to read or write the whole message in one go. 10. poll/select functionality is not tested. 11. non-blocking reads/writes are not supported. 12. some (probably important) properties and statuses of ME clients are not interpreted. 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. 14. probably many more... I think that ultimately, if complete feature support is needed, it would be easier to port the driver from either OpenSolaris or Linux than to add all the features to the presented driver. This is because documentation/description for many features is severely lacking in public access. I guess that Intel developers that worked on the OpenAMT driver had much more detailed specifications to work with. But reverse-engineering some parts of OpenAMT code is very hard. You can see for yourself, if not for the hacker who decompiled a Windows DLL, there would be no way of obtaining even GUID of QST client from public sources. Thank you very much in advance for any feedback, comments, ideas! P.S. BTW, can/may I drop "alternatively GPL" wording from License block of the files I borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? Some additional info. The files contain only some data structure/constants definitions. I guess those are not copyrightable at all? I added a bunch of comments to those file describing the constants and structs. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 21:25:41 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D8E106568D; Wed, 14 Oct 2009 21:25:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8908FC0C; Wed, 14 Oct 2009 21:25:40 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-199-198.ard.bellsouth.net [72.154.199.198]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9ELPc59026929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 17:25:38 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Content-Type: text/plain Organization: FreeBSD Date: Wed, 14 Oct 2009 16:25:32 -0500 Message-Id: <1255555532.95374.147.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:25:41 -0000 On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz Your getting a WITNESS warning from malloc() while holding a lock at like 941 of heci.c mec = (struct me_client *)malloc(sizeof(*mec), M_HECI, M_NOWAIT | M_ZERO); fixes it. It also locked up the machine when I tried to kldunload, but haven't identified a root cause of that. robert. > Other drivers are: > [Linux] http://www.openamt.org/ > [OpenSolaris] > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ > > An example of what functionality this driver could provide: > http://article.gmane.org/gmane.linux.drivers.sensors/20398 > This actually was my primary motivation for looking into this driver. > > Your hardware may be supported by this driver if pciconf -lv has something like > the following: > none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '(Bearlake) HECI Controller' > class = simple comms > > Here's how successful attachment of this driver looks on my system: > heci0: mem > 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x03: > heci0: status = 0x00 > heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 > > The driver has many functional and programming shortcomings, but I still would > like to ask for its review and testing. > Please read the following warnings and notices: > 1. right now the driver is provided only as a module. > 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it > with; please see hecireg.h for a list of potentially supported IDs and add your ID > to heci_probe(). > 3. heciio.h does not get installed into /usr/include, so for time being you need > to take an extra step to make it available to code that wishes to communicate to heci. > 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so > don't expect every OpenAMT program to work with it (but it does reliably work for > me for the QST thing). > > Now more details about the code: > 1. the code contains some style violations like overly long lines, probably > others; but I still would like to hear your comments on its style. > 2. there are some bad design decisions like using the same mutex+condvar pair for > signaling different events (reception of data from ME, emptying of user buffer); > but I still would like to hear your comments about improving the design. > 3. only a single connection is allowed for a host client > 4. only a single connection is allowed to a ME client (if the client can support > more). > 5. quite an arbitrary timeout is used in all places where we wait for simething to > happen. > 6. no power management supported. > 7. only messages of size less than 512 bytes are supported. > 8. only complete messages are supported, multi-part messages are not. > 9. userland is expected to read or write the whole message in one go. > 10. poll/select functionality is not tested. > 11. non-blocking reads/writes are not supported. > 12. some (probably important) properties and statuses of ME clients are not > interpreted. > 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. > 14. probably many more... > > I think that ultimately, if complete feature support is needed, it would be easier > to port the driver from either OpenSolaris or Linux than to add all the features > to the presented driver. This is because documentation/description for many > features is severely lacking in public access. I guess that Intel developers that > worked on the OpenAMT driver had much more detailed specifications to work with. > But reverse-engineering some parts of OpenAMT code is very hard. > You can see for yourself, if not for the hacker who decompiled a Windows DLL, > there would be no way of obtaining even GUID of QST client from public sources. > > Thank you very much in advance for any feedback, comments, ideas! > > P.S. > BTW, can/may I drop "alternatively GPL" wording from License block of the files I > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? > Some additional info. The files contain only some data structure/constants > definitions. I guess those are not copyrightable at all? I added a bunch of > comments to those file describing the constants and structs. > -- Robert Noland FreeBSD From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 22:46:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0779C1065670 for ; Wed, 14 Oct 2009 22:46:22 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5898FC13 for ; Wed, 14 Oct 2009 22:46:21 +0000 (UTC) Received: by fxm22 with SMTP id 22so353550fxm.36 for ; Wed, 14 Oct 2009 15:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CVLsc62Kou1DBdImRiclWx1/iFncp9BsZtqRXVL68HA=; b=d9U525H/YxEfjkhGXOM5rHpCl5m9CqIJuOULUvRLyxgJgWjFuBjLNu/T1sXd/PGhAV OidgW605Uli/aTzCmHm4tDyeJXOcBXTanUV/GhvN2SOi0U4tC9ptMbKPvTtfCf5h3h4b Euy5DTIo6AXX0IljR02/GqCjx1rWSOGLfeugE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dMofhw3v9DYeiJ+4m6S5Osrf+q6n3j/I6UdJCNW461RPXIBhXDrsAC5F3ODEuhYLt1 vHklfqOcIoPEmBtet7ZiNcQ4KuuDdmglny1zPMJL+H2lChJi4OK9Z3dfNwG3djN4/yg4 SMZosWsSxlFKeD7m3glmorTpp9t7DE1tE5SZA= MIME-Version: 1.0 Received: by 10.239.170.24 with SMTP id q24mr715173hbe.2.1255560380463; Wed, 14 Oct 2009 15:46:20 -0700 (PDT) In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Date: Wed, 14 Oct 2009 19:46:20 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 22:46:22 -0000 On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon wrote: > BTW, can/may I drop "alternatively GPL" wording from License block of the files I > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? If Intel is the copyright owner then you can not change the license without their permission. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 14 23:36:09 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8559D10656AB; Wed, 14 Oct 2009 23:36:09 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 49B6F8FC21; Wed, 14 Oct 2009 23:36:08 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-199-198.ard.bellsouth.net [72.154.199.198]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9ENa4Ji027991 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 19:36:07 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Content-Type: text/plain Organization: FreeBSD Date: Wed, 14 Oct 2009 16:35:29 -0500 Message-Id: <1255556129.95374.160.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 23:36:09 -0000 On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz > > Other drivers are: > [Linux] http://www.openamt.org/ > [OpenSolaris] > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ > > An example of what functionality this driver could provide: > http://article.gmane.org/gmane.linux.drivers.sensors/20398 > This actually was my primary motivation for looking into this driver. Could you also post the client code in some form more readily accessible than trying to cut/paste from the web page? robert. > Your hardware may be supported by this driver if pciconf -lv has something like > the following: > none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '(Bearlake) HECI Controller' > class = simple comms > > Here's how successful attachment of this driver looks on my system: > heci0: mem > 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x03: > heci0: status = 0x00 > heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 > > The driver has many functional and programming shortcomings, but I still would > like to ask for its review and testing. > Please read the following warnings and notices: > 1. right now the driver is provided only as a module. > 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it > with; please see hecireg.h for a list of potentially supported IDs and add your ID > to heci_probe(). > 3. heciio.h does not get installed into /usr/include, so for time being you need > to take an extra step to make it available to code that wishes to communicate to heci. > 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so > don't expect every OpenAMT program to work with it (but it does reliably work for > me for the QST thing). > > Now more details about the code: > 1. the code contains some style violations like overly long lines, probably > others; but I still would like to hear your comments on its style. > 2. there are some bad design decisions like using the same mutex+condvar pair for > signaling different events (reception of data from ME, emptying of user buffer); > but I still would like to hear your comments about improving the design. > 3. only a single connection is allowed for a host client > 4. only a single connection is allowed to a ME client (if the client can support > more). > 5. quite an arbitrary timeout is used in all places where we wait for simething to > happen. > 6. no power management supported. > 7. only messages of size less than 512 bytes are supported. > 8. only complete messages are supported, multi-part messages are not. > 9. userland is expected to read or write the whole message in one go. > 10. poll/select functionality is not tested. > 11. non-blocking reads/writes are not supported. > 12. some (probably important) properties and statuses of ME clients are not > interpreted. > 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. > 14. probably many more... > > I think that ultimately, if complete feature support is needed, it would be easier > to port the driver from either OpenSolaris or Linux than to add all the features > to the presented driver. This is because documentation/description for many > features is severely lacking in public access. I guess that Intel developers that > worked on the OpenAMT driver had much more detailed specifications to work with. > But reverse-engineering some parts of OpenAMT code is very hard. > You can see for yourself, if not for the hacker who decompiled a Windows DLL, > there would be no way of obtaining even GUID of QST client from public sources. > > Thank you very much in advance for any feedback, comments, ideas! > > P.S. > BTW, can/may I drop "alternatively GPL" wording from License block of the files I > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? > Some additional info. The files contain only some data structure/constants > definitions. I guess those are not copyrightable at all? I added a bunch of > comments to those file describing the constants and structs. > -- Robert Noland FreeBSD From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 05:23:54 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679611065670; Thu, 15 Oct 2009 05:23:54 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 378728FC28; Thu, 15 Oct 2009 05:23:52 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA15955; Thu, 15 Oct 2009 08:23:50 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MyIoX-0002WK-7n; Thu, 15 Oct 2009 08:23:49 +0300 Message-ID: <4AD6B1D5.3010003@icyb.net.ua> Date: Thu, 15 Oct 2009 08:23:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Robert Noland References: <4AD6067E.2010503@icyb.net.ua> <1255555532.95374.147.camel@balrog.2hip.net> In-Reply-To: <1255555532.95374.147.camel@balrog.2hip.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 05:23:54 -0000 on 15/10/2009 00:25 Robert Noland said the following: > On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz > > Your getting a WITNESS warning from malloc() while holding a lock at > like 941 of heci.c > > mec = (struct me_client *)malloc(sizeof(*mec), M_HECI, > M_NOWAIT | M_ZERO); > > fixes it. Shame on me! I have to admit that tested/used this module only on stable/7 (amd64) and without WITNESS/INVARIANTS. Thank you for catching this. I guess I should also add a check for malloc returning NULL. > It also locked up the machine when I tried to kldunload, but > haven't identified a root cause of that. Haven't seen it here. I will try to investigate. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 05:26:31 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A9D71065693; Thu, 15 Oct 2009 05:26:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1D008FC1C; Thu, 15 Oct 2009 05:26:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA16013; Thu, 15 Oct 2009 08:26:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MyIr6-0002Wa-3k; Thu, 15 Oct 2009 08:26:28 +0300 Message-ID: <4AD6B274.5050906@icyb.net.ua> Date: Thu, 15 Oct 2009 08:26:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Robert Noland References: <4AD6067E.2010503@icyb.net.ua> <1255556129.95374.160.camel@balrog.2hip.net> In-Reply-To: <1255556129.95374.160.camel@balrog.2hip.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 05:26:31 -0000 on 15/10/2009 00:35 Robert Noland said the following: > On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz >> >> Other drivers are: >> [Linux] http://www.openamt.org/ >> [OpenSolaris] >> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ >> >> An example of what functionality this driver could provide: >> http://article.gmane.org/gmane.linux.drivers.sensors/20398 >> This actually was my primary motivation for looking into this driver. > > Could you also post the client code in some form more readily accessible > than trying to cut/paste from the web page? > > robert. Sure: http://people.freebsd.org/~avg/heci-qst.c Sorry for not doing this from the very start. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 10:25:41 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C176B106566B for ; Thu, 15 Oct 2009 10:25:41 +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 830388FC1C for ; Thu, 15 Oct 2009 10:25:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 946386D41B; Thu, 15 Oct 2009 10:25:40 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 6267E84503; Thu, 15 Oct 2009 12:25:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon References: <4AD6067E.2010503@icyb.net.ua> Date: Thu, 15 Oct 2009 12:25:40 +0200 In-Reply-To: <4AD6067E.2010503@icyb.net.ua> (Andriy Gapon's message of "Wed, 14 Oct 2009 20:12:30 +0300") Message-ID: <86iqehx8bf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:25:41 -0000 Andriy Gapon writes: > BTW, can / may I drop "alternatively GPL" wording from License block > of the files I borrowed from Intel? I.e. can a dual BSD+GPL licensed > file be turned into BSD-only? No. Why would you want to? > Some additional info. The files contain only some data structure / > constants definitions. I guess those are not copyrightable at all? That's debatable. It is probably safe to assume that they aren't *if* they only describe the interface to another piece of software or to the hardware, but if they represent internal data structures used by the Linux driver, they are definitely copyrightable. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 14:17:04 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616831065679; Thu, 15 Oct 2009 14:17:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 261258FC12; Thu, 15 Oct 2009 14:17:04 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-199-198.ard.bellsouth.net [72.154.199.198]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9FEH0IV032165 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Oct 2009 10:17:01 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Andriy Gapon In-Reply-To: <4AD6B1D5.3010003@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> <1255555532.95374.147.camel@balrog.2hip.net> <4AD6B1D5.3010003@icyb.net.ua> Content-Type: text/plain Organization: FreeBSD Date: Thu, 15 Oct 2009 09:16:54 -0500 Message-Id: <1255616214.2356.872.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 14:17:04 -0000 On Thu, 2009-10-15 at 08:23 +0300, Andriy Gapon wrote: > on 15/10/2009 00:25 Robert Noland said the following: > > On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: > >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > >> > >> I actually got around to implementing it (in initial/basic form): > >> http://people.freebsd.org/~avg/heci.tgz > > > > Your getting a WITNESS warning from malloc() while holding a lock at > > like 941 of heci.c > > > > mec = (struct me_client *)malloc(sizeof(*mec), M_HECI, > > M_NOWAIT | M_ZERO); > > > > fixes it. > > Shame on me! > I have to admit that tested/used this module only on stable/7 (amd64) and > without WITNESS/INVARIANTS. > Thank you for catching this. > I guess I should also add a check for malloc returning NULL. Yes, with M_NOWAIT you should. Here is the dmesg output. heci0: mem 0xd0526100-0xd052610f irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x02: heci0: status = 0x00 heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 heci0: found ME client at address 0x03: heci0: status = 0x00 heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 heci0: found ME client at address 0x06: heci0: status = 0x00 heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x22: heci0: status = 0x00 heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 heci0: found ME client at address 0x23: heci0: status = 0x00 heci0: protocol_name(guid) = 9D9105BD-C8C6-41CA-AC28-84738E2CE9FD heci0: found ME client at address 0x24: heci0: status = 0x00 heci0: protocol_name(guid) = DC506909-7ADB-4A0D-B109-4E25E38C382C heci0: found ME client at address 0x25: heci0: status = 0x00 heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 heci0: found ME client at address 0x26: heci0: status = 0x00 heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C heci0: found ME client at address 0x27: heci0: status = 0x00 heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB robert. > > It also locked up the machine when I tried to kldunload, but > > haven't identified a root cause of that. > > Haven't seen it here. > I will try to investigate. > -- Robert Noland FreeBSD From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 15:01:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46A5F106568F; Thu, 15 Oct 2009 15:01:51 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-vw0-f181.google.com (mail-vw0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id D6D508FC21; Thu, 15 Oct 2009 15:01:50 +0000 (UTC) Received: by vws11 with SMTP id 11so496806vws.28 for ; Thu, 15 Oct 2009 08:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DT5CeRZdkDrkXXh7S84YHZnKh7D/CZgrDuR7Dl6lxNE=; b=mN97//tepsVrAI44FbgvdQlkuaC/BdoUb2/jkp1ZnfSm/cl2k8Qr8iAt8N2nk++jDO uy15d+VuO9SL7lkJ3MfCpacrNXPpaunT7FgYKYKtKU+e7A2sxLaBV846HSIgzKa6qFAo UhrLzEIbuukf4zBEE5PmxlJNKHtG8S41+YQBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ItsJdRFBGv5FtTpP7PrLi7lXAnnlwzh3DWc5q4XA6vTqe57TrulLd2jfbcVobYdppP 8IdH/POnlRHWTYCTfsPv9v8/QWjIDbTH20D3MqOwF5p5lZOyWBOyuBrU7tXWc9NfwySN pWLzSbN5OucHJXRURHiRaShkQWzUM3CXC/xw0= MIME-Version: 1.0 Received: by 10.239.144.92 with SMTP id n28mr12356hba.181.1255618908917; Thu, 15 Oct 2009 08:01:48 -0700 (PDT) In-Reply-To: <20091014203428.7d84bf96@bhuda.mired.org> References: <4AD6067E.2010503@icyb.net.ua> <20091014203428.7d84bf96@bhuda.mired.org> Date: Thu, 15 Oct 2009 12:01:48 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: Mike Meyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 15:01:51 -0000 On Wed, Oct 14, 2009 at 9:34 PM, Mike Meyer wrote: > On Wed, 14 Oct 2009 19:46:20 -0300 > "Carlos A. M. dos Santos" wrote: > >> On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon wrote: >> >> > BTW, can/may I drop "alternatively GPL" wording from License block of = the files I >> > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned i= nto BSD-only? >> >> If Intel is the copyright owner then you can not change the license >> without their permission. > > True. But he *has* their permission. They list the requirements for > use and redistribution in the license block in question: > > =A0* Redistribution and use in source and binary forms, with or without > =A0* modification, are permitted provided that the following conditions > =A0* are met: > =A0* 1. Redistributions of source code must retain the above copyright > =A0* =A0 =A0notice, this list of conditions, and the following disclaimer= , > =A0* =A0 =A0without modification. > =A0* 2. Redistributions in binary form must reproduce at minimum a discla= imer > =A0* =A0 =A0substantially similar to the "NO WARRANTY" disclaimer below > =A0* =A0 =A0("Disclaimer") and any redistribution must be conditioned upo= n > =A0* =A0 =A0including a substantially similar Disclaimer requirement for = further > =A0* =A0 =A0binary redistribution. > =A0* 3. Neither the names of the above-listed copyright holders nor the n= ames > =A0* =A0 =A0of any contributors may be used to endorse or promote product= s derived > =A0* =A0 =A0from this software without specific prior written permission. > > I don't see anything there about retaining the ability to choose an > alternative license. The paragraph in question says that people can > *choose* to distribute it under the GPLv2, not that it *is* being > distributed under the GPLv2. Conversely, I don't see anything there explicitly *allowing* somebody to remove that paragraph so I'd keep it unless I had express clearance from Intel. Making assumptions can be dangerous, especially when dealing with large corporations. That's the main lesson I've learned after several years dealing with such matters. I don't want to make this discussion longer than necessary, so I stop here. --=20 My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 13:58:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D2821065692 for ; Thu, 15 Oct 2009 13:58:15 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 082D78FC25 for ; Thu, 15 Oct 2009 13:58:14 +0000 (UTC) Received: by yxe1 with SMTP id 1so909002yxe.3 for ; Thu, 15 Oct 2009 06:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ouyefnY4631xAIgFwuxN/S/7boJeFENwe1Cc8GtwAoc=; b=EteVPyTVn3LQfRj8WBoYBVGSRJxBWFi9XqotkDXMwrXGq9j9uRoETKwBgAgs+vQAZr JND9FohlcFSs9rD6al4QGGD7RDtMu7DjEYtWitc8PEz/7/ZbrB5smGE4/D43pbHOULZx PRjjiTXjr+r7zYUcVgkcAODUB5UBYFJYhrWQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pQACkjBaxk+lBtPFoA6n/IqkRrYJ//EaAww028mKfmqGancEpymBE1bOprbRw5J1wi T7uRzuvrHkF2s/jf6zSw3PI0Sp8r045aN+/+ea1HLnKVM0CKxM+W6pGBWE/WRH/MQaBi fI8aHqpwc+zUjJiLgLD5pjZtCFs9sJZhYhpR4= MIME-Version: 1.0 Received: by 10.239.139.207 with SMTP id u15mr7399hbu.95.1255615090029; Thu, 15 Oct 2009 06:58:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 14:58:09 +0100 Message-ID: From: krad To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Thu, 15 Oct 2009 15:35:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: zfs root X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 13:58:15 -0000 i got no response on questions, anybody able to answer here? ---------- Forwarded message ---------- From: krad Date: 2009/10/3 Subject: zfs root To: questions@freebsd.org Hi, I have a quick question about freebsd on zfs root. I have built a few test systems all work fine. I have one question though. Does the loader replay any information when it accesses the pool? Basically im interested in how or what is done on reboot after the kernel panic or power loss. Are there any safe gaurds with regard to the zpool integrity? From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 21:16:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E101065676 for ; Thu, 15 Oct 2009 21:16:30 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 082C78FC08 for ; Thu, 15 Oct 2009 21:16:29 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n9FLGT92019976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Oct 2009 17:16:29 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n9FLGT92019976 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1255641389; bh=v7cF/ES5g7OmcESpMHwLERv/ZqC9ikTENYgNHewaP/Y=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=IA1xTU8wRh0KKQ8HDjOhiSj26XTZ82eBJpVzu32UZqLXV0+zSVLXfPls34PeqtKwV 5xHQWrFQXonHi09u9QZmRXchRODmWWeXRE8mKUaoTVhzK5A8VrfOYGokYTArB70zP1 tEIK9ocDEZMTH5fiEEyTdw64C853SvKOwJ9pgu9A= Message-ID: <4AD79126.8020104@cs.duke.edu> Date: Thu, 15 Oct 2009 17:16:22 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: namei (via firmware_get(9)) from taskq in 7.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 21:16:30 -0000 Hi, I'm trying to re-initialize a NIC which uses firmware(9) after a hardware fault. As part of the process, I need to re-load the firmware using firmware_get(). If the firmware kld is not resident, then the machine will panic like this: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff805b05d4 stack pointer = 0x10:0xffffff8000080460 frame pointer = 0x10:0xffffff8000080510 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 21 (swi5: +) [thread pid 21 tid 100021 ] Stopped at namei+0x174: movq 0x20(%rbx),%rax db> bt Tracing pid 21 tid 100021 td 0xffffff00013c3ae0 namei() at namei+0x174 vn_open_cred() at vn_open_cred+0x3a4 linker_load_module() at linker_load_module+0x1f2 linker_reference_module() at linker_reference_module+0xae firmware_get() at firmware_get+0x136 mxge_load_firmware() at mxge_load_firmware+0x2d mxge_watchdog_task() at mxge_watchdog_task+0x2f6 taskqueue_run() at taskqueue_run+0x9d ithread_loop() at ithread_loop+0x17d fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe Looking at it in gdb, it seems like the problem is that namei is trying to use ndp->ni_cnd.cn_thread->td_proc->p_fd->fd_cdir which is null in this context. Can somebody tell me what kernel context it is safe to call firmware_get() (and hence namei) from? Is there a safe way to do it from a taskq? FWIW, this seems to work fine (even from a callout context) in 8 and higher. It is only 7 and earlier where I'm having this problem. Thanks, Drew From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 15 23:46:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3D241065676 for ; Thu, 15 Oct 2009 23:46:35 +0000 (UTC) (envelope-from decado@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 82ECB8FC1C for ; Thu, 15 Oct 2009 23:46:35 +0000 (UTC) Received: by ewy18 with SMTP id 18so1356064ewy.43 for ; Thu, 15 Oct 2009 16:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=aaQx0uOFJR2MCFGN8FoHrH5hjDW+Q7ljuBFSWfHc7Es=; b=wZlrc8jFv426Sqbx2PPa9BN0D3tNhOKLfoOhFHQhGHzpcmdsp5/q6csOEKIAyWFiPR 9lzds4bo1G1umykoisARUW2Zs0nGnOwkXr3hQxhreI1ZbnpmNROtYMv082MMrW49GXQU 18FvmgPMNixDbVSRAdBGeHCz8DtK9nZkdsqrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ioHbBjXe24en+1W6S6g9LaUs7MPfvOJVMdFl/rm7LlN2dfYFx06bRLbAuZTJE8mFg0 fa+VmS49Cz3L63S3IK6Jlskpze5IxD/yr/yUl3bnTG5RV9Tw7ozd4TItn8+quNuzqsMc z0djjf96kQwio3L4DL7wDEARHI1dWH+5OAcGo= Received: by 10.216.85.137 with SMTP id u9mr355576wee.214.1255650394430; Thu, 15 Oct 2009 16:46:34 -0700 (PDT) Received: from ?192.168.1.200? (ppp118-209-107-207.lns20.mel4.internode.on.net [118.209.107.207]) by mx.google.com with ESMTPS id i35sm1210995gve.13.2009.10.15.16.46.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 16:46:33 -0700 (PDT) Message-ID: <4AD7C232.3020609@gmail.com> Date: Fri, 16 Oct 2009 10:45:38 +1000 From: "Andrew D. Boyd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <3a142e750910100150g7459e037u7b84b4b4bbc2bf8@mail.gmail.com> <20091011142923.GT71731@hoeg.nl> In-Reply-To: <20091011142923.GT71731@hoeg.nl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: sysinstall colours X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 23:46:36 -0000 Ed Schouten wrote: > * Paul B Mahol wrote: >> This have nothing to do with ncurses, colors you like simple can not >> be displayed in current syscons(4) and making support for 256 colors >> or even true bit color in sysinstall(so that it looks amazing in >> konsole) is waste of time. > > Yes. As of recently, our terminal emulator gained 256 color support, but > this gets smashed down to 8 colors, simply because Syscons cannot handle > more than 16 foreground and 8 background colors. > > This is how colors are converted: > > http://80386.nl/pub/xterm-256.png > http://80386.nl/pub/teken-256.png > My God that is hideous. Save us Ed! Three cheers for your recent console work. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 16 00:07:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB088106566B for ; Fri, 16 Oct 2009 00:07:33 +0000 (UTC) (envelope-from decado@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5C98FC13 for ; Fri, 16 Oct 2009 00:07:32 +0000 (UTC) Received: by ewy18 with SMTP id 18so1367293ewy.43 for ; Thu, 15 Oct 2009 17:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=iMUa6F2NpZr0rFltqWMRWczbETR5pXbwEQeEhzJsWfA=; b=HeWhVZ3Ms2ls/fpv3pgJrsbNpd47bL/nuEpyvLMl+EPAGA3Xj3pRLrw9xuk3JThuyT vy/jBWhV/20rHtfVbzpSGCYsI6WTrgf5x2/4OBWc5fWcbWBaairGFM8PbVSYVT5qBsKu ipLHuZlFTQJAiZugbUVr2hTHguPCp1XcNK7is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Zovjd6rjO3lHuhaPQ3+bUawL//W7BRnjQEriAv8cW/jxUk8t+6H6CIlQ2Myyeuaw6w S8Lyt5gXIrx4Xnw0yi02ei+wYnWQ/gr5dTTyGzJ9MNvvSiIewSaw6Uf1iU9fulWEvd9+ ponPlU7GzJftEZIzcnbKFPhb0xPMjDzaFUZtM= Received: by 10.216.88.8 with SMTP id z8mr389498wee.109.1255649724209; Thu, 15 Oct 2009 16:35:24 -0700 (PDT) Received: from ?192.168.1.200? (ppp118-209-107-207.lns20.mel4.internode.on.net [118.209.107.207]) by mx.google.com with ESMTPS id i6sm1190251gve.17.2009.10.15.16.35.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 16:35:22 -0700 (PDT) Message-ID: <4AD7BF94.908@gmail.com> Date: Fri, 16 Oct 2009 10:34:28 +1000 From: "Andrew D. Boyd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <86d44vqs9l.fsf@kopusha.onet> In-Reply-To: <86d44vqs9l.fsf@kopusha.onet> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: crashtar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 00:07:33 -0000 Mikolaj Golub wrote: > On Sat, 10 Oct 2009 12:34:05 +0200 (CEST) Alexander Best wrote: > > AB> thanks. this is a cool script and very useful indeed. only thing you might > AB> want to do is check for root privileges at the beginning to avoid nasty error > AB> messages like. > > AB> awk: can't open file /var/crash/info.0 > AB> source line number 12 > > In some cases you might not need root privileges. E.g. on some servers I don't > have root but SA gives me read access to crashdumps. In this case if the > script had a check for root privileges I would not be able to use it. > > Actually as for me the message looks informative enough, it says that we have > some problems with accessing crash dump files, so permissions should be > checked. > Instead of checking for root you could check if the file is readable: if [ -r FILE ] and then print an error message. Although the awk error message is sufficient some people might find this helpful. Regards, Andrew From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 16 13:15:17 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BAD106566C for ; Fri, 16 Oct 2009 13:15:17 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id A2F008FC15 for ; Fri, 16 Oct 2009 13:15:16 +0000 (UTC) Received: from elmar.spoerlein.net (e180130196.adsl.alicedsl.de [85.180.130.196]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9GDF4t8011190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Oct 2009 15:15:05 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: from elmar.spoerlein.net (localhost [127.0.0.1]) by elmar.spoerlein.net (8.14.3/8.14.3) with ESMTP id n9GDF4UV069866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 15:15:04 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by elmar.spoerlein.net (8.14.3/8.14.3/Submit) id n9GDF4uJ069865; Fri, 16 Oct 2009 15:15:04 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 16 Oct 2009 15:15:04 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20091016131504.GA5222@elmar.spoerlein.net> Mail-Followup-To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , hackers@freebsd.org References: <20091011145021.GG36937@acme.spoerlein.net> <861vl8sxxb.fsf@ds4.des.no> <20091012155421.GJ36937@acme.spoerlein.net> <86zl7wpnzh.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86zl7wpnzh.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org Subject: Re: RFC: Big Makefile patch for WARNS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:15:17 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, 12.10.2009 at 18:37:38 +0200, Dag-Erling Smørgrav wrote: > Ulrich Spörlein writes: > > Is there some easy way to do cross-compiles (like make universe) in just > > one of the subdirs? That would help tremendously. > > % cd /usr/src > % make toolchain TARGET=powerpc > % make buildenv TARGET=powerpc > %% cd usr.sbin/rwhod > %% make > > ('make buildenv' starts a subshell) Excellent, I now smashed together the following expect script, which can be used to compile a single subdir with these toolchains. It requires that you build all toolchains once, upfront. It's a total hack, but hey it works for me, example usage would be: $ cd /usr/src $ universe-build -t (builds toolchain for all targets, needs to be done every once in a while) $ universe-build games/grdc WARNS=6 sparc64 amd64 i386 (build grdc with WARNS=6 for 3 archs specified, using the buildenv target above) Pardon my weak tcl/expect-fu Regards, Uli --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=universe-build #!/usr/local/bin/expect # Does the following for variable subdirs and a given set of target archs, # exits upon first failure. # % cd /usr/src # % make toolchain TARGET=powerpc # % make buildenv TARGET=powerpc # %% cd usr.sbin/rwhod # %% make set timeout -1 set toolchain 0 proc usage {argv0} { send_user "usage: $argv0 -t \[target1 target2 ...\]\n" send_user " $argv0 subdir \[make-args\] \[target1 target2 ...\]\n" exit } while {[llength $argv]>0} { set flag [lindex $argv 0] switch -- $flag \ "-t" { set toolchain 1 set argv [lrange $argv 1 end] set argc [expr ($argc - 1)] } default { break } } if {$toolchain!=1} { if {$argc<1} { usage $argv0 exit 1 } set subdir [lindex $argv 0] set argv [lrange $argv 1 end] set argc [expr ($argc - 1)] # if something is present, use it as make args if {$argc>=1} { set margs [lindex $argv 0] set argv [lrange $argv 1 end] set argc [expr ($argc - 1)] } else { set margs {} } } # if there is still something, use it as target list, # else default to everything if {$argc>=1} { set targets [lrange $argv 0 end] } else { set input [open "|make universe -V TARGETS" r] set targets [split [string trimright [read $input]] " "] close $input } if {$toolchain==1} { foreach target $targets { spawn /bin/sh expect "$ " send "env MAKEOBJDIRPREFIX=/usr/obj/$target make toolchain __MAKE_CONF=/dev/null TARGET=$target\n" expect "$ " send "exit \$?\n" expect eof } puts "\n" exit } foreach target $targets { spawn /bin/sh set sid($target) $spawn_id expect "$ " send "env MAKEOBJDIRPREFIX=/usr/obj/$target make buildenv __MAKE_CONF=/dev/null TARGET=$target\n" expect "$ " send "make -C $subdir clean; make -C $subdir $margs\n" expect "$ " # Stupid buildenv is doing sh || true, so we cannot propagate by doing exit $rc :( # grab echo output instead send "echo rc=\$?\n" expect -re "echo rc=..\r" expect -re "rc=(.*)\n" # TODO: save rc per target, don't exit below but print rcs for all archs on exit set rc $expect_out(1,string) send "exit \$?\n" expect "$ " send "exit \$?\n" expect eof if {$rc!=0} { puts "" exit $rc } ## if we expect eof, the wait below will not return, wtf? ## XXX sid($target) wont work here?? #catch {close -i $spawn_id} ## wait returns PID, TYPE, CODE, grab code #set rc [lindex [wait sid($target)] 3] } --7JfCtLOvnd9MIVvH--