From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 02:13:09 2010 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 793691065742 for ; Sun, 14 Nov 2010 02:13:09 +0000 (UTC) (envelope-from freebsd-hackers@chrisbowman.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9418FC16 for ; Sun, 14 Nov 2010 02:13:08 +0000 (UTC) Received: by wyb36 with SMTP id 36so1348347wyb.13 for ; Sat, 13 Nov 2010 18:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.172.9 with SMTP id s9mr3695789wel.56.1289698971508; Sat, 13 Nov 2010 17:42:51 -0800 (PST) Received: by 10.216.22.137 with HTTP; Sat, 13 Nov 2010 17:42:51 -0800 (PST) X-Originating-IP: [66.87.0.205] Date: Sat, 13 Nov 2010 17:42:51 -0800 Message-ID: From: Christopher Bowman To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ugen claiming pcie device 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, 14 Nov 2010 02:13:09 -0000 I have a Xilinx PCIe card installed in my machine and it appears that ugen0 is claiming it. Why would a PCIe device even be offered to ugen? The message I get on boot up is: ugen0 on uhub3 Any way I can prevent this so my on kld driver can attach? Regards Christopher From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 02:47:56 2010 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 15249106564A for ; Sun, 14 Nov 2010 02:47:56 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id CD3EC8FC0C for ; Sun, 14 Nov 2010 02:47:55 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id oAE2ls1S058795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Nov 2010 20:47:55 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id oAE2lsoi079000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Nov 2010 20:47:54 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id oAE2lsQJ078999; Sat, 13 Nov 2010 20:47:54 -0600 (CST) (envelope-from dan) Date: Sat, 13 Nov 2010 20:47:53 -0600 From: Dan Nelson To: Christopher Bowman Message-ID: <20101114024753.GE57869@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.4 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Sat, 13 Nov 2010 20:47:55 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: ugen claiming pcie device 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, 14 Nov 2010 02:47:56 -0000 In the last episode (Nov 13), Christopher Bowman said: > I have a Xilinx PCIe card installed in my machine and it appears that > ugen0 is claiming it. Why would a PCIe device even be offered to ugen? > > The message I get on boot up is: > ugen0 on uhub3 > Any way I can prevent this so my on kld driver can attach? > Regards If it's hanging off uhub3, it's a usb device :) Google says that is the Xilinx "USB platform cable" device. The ugen device attaches to any usb device that no other driver has claimed. Maybe the Xilinx card provides a virtual usb controller and device that you control the card with? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 03:12:27 2010 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 54447106564A for ; Sun, 14 Nov 2010 03:12:27 +0000 (UTC) (envelope-from freebsd-hackers@chrisbowman.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id E6ADB8FC0A for ; Sun, 14 Nov 2010 03:12:26 +0000 (UTC) Received: by wwb29 with SMTP id 29so128179wwb.1 for ; Sat, 13 Nov 2010 19:12:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.166.68 with SMTP id f46mr5322870wel.26.1289704345435; Sat, 13 Nov 2010 19:12:25 -0800 (PST) Received: by 10.216.22.137 with HTTP; Sat, 13 Nov 2010 19:12:25 -0800 (PST) X-Originating-IP: [70.143.67.30] In-Reply-To: <20101114024753.GE57869@dan.emsphone.com> References: <20101114024753.GE57869@dan.emsphone.com> Date: Sat, 13 Nov 2010 19:12:25 -0800 Message-ID: From: Christopher Bowman To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: ugen claiming pcie device 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, 14 Nov 2010 03:12:27 -0000 Dan, I am smacking my forehead now! Of course, I have a pcie board in there, and I am programming it from another box, but I forgot about the Xilinx programmer attached to the machine for when I am running windows. The programmer is, of course, USB based. Thanks Christopher On Sat, Nov 13, 2010 at 6:47 PM, Dan Nelson wrote: > In the last episode (Nov 13), Christopher Bowman said: > > I have a Xilinx PCIe card installed in my machine and it appears that > > ugen0 is claiming it. Why would a PCIe device even be offered to ugen? > > > > The message I get on boot up is: > > ugen0 on uhub3 > > Any way I can prevent this so my on kld driver can attach? > > Regards > > If it's hanging off uhub3, it's a usb device :) Google says that is the > Xilinx "USB platform cable" device. The ugen device attaches to any usb > device that no other driver has claimed. Maybe the Xilinx card provides a > virtual usb controller and device that you control the card with? > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 03:40:22 2010 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 D5F00106566B; Sun, 14 Nov 2010 03:40:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4272F8FC1C; Sun, 14 Nov 2010 03:40:21 +0000 (UTC) Received: by wwb29 with SMTP id 29so138749wwb.1 for ; Sat, 13 Nov 2010 19:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tcMYEDsRNYVwodpQanCbtYTN63VrtQyry5fnVtFTQ+w=; b=m1MJYfgrViTgw0aWK19btU/OQ+xcC+OI0/0PZdNxl04tK7qgRsrEQvi5ws1cHphEfa BUUzAzUgZf1q9PBfDGteCnC4YnnrKAhkhwlsRgOJujpKo7AtHHYTmmJAuqmE3eacCNmH hiQ7NSERcyaIpoz5NOkNHfcup/ZzGyaZwSeaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=k7lGigg/sbGI4NPFPPDM6FXlmydbADqhgvYH3CG3lw6IRH5LvqwIAoadTOncph3BEL ddep4XbcbTr9C/YIX6JYU1KpnrUq6K9xyBrlafzpzbqt31znAqNtUAkmC7SNcUOcMzPx XqvfTg7AdLou2je18mBU7P3wt7h9rEDaEe6vg= MIME-Version: 1.0 Received: by 10.216.142.131 with SMTP id i3mr5340577wej.5.1289706020496; Sat, 13 Nov 2010 19:40:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Sat, 13 Nov 2010 19:40:20 -0800 (PST) Date: Sun, 14 Nov 2010 11:40:20 +0800 X-Google-Sender-Auth: FFePrc8HCv2HcLXNbwOJAoaJMGU Message-ID: From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , freebsd-embedded@freebsd.org Subject: The path is now set for "busybox", FreeBSD style 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, 14 Nov 2010 03:40:22 -0000 Hi everyone, I've committed the below changes to -HEAD. You can now create and build your own busybox style binary system, completely cross-compiled within the existing Make framework. It isn't as impressive as it sounds though - a lot of the framework is already there from just building crunchgen'ed rescue/sysinstall binaries. There's a few things which should be done. Specifically, being able to build an alternative set of libraries before building the crunchgen target. The base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc but you may not want your crunch'ed image to have them. To do this right now, you have to disable these features in the main build. That may be OK for some. But just to stress it - I've got a couple of access point images at home running a crunchgen'ed environment under MIPS and besides the obvious binary bloat, it works perfectly well. Besides a cut-down startup framework, the image cross-builds entirely from the base FreeBSD source tree. Let me know if you'd like to give it a shot and I'll put my "bsdbox" Makefile scripts online to try. Adrian On 5 October 2010 10:36, Adrian Chadd wrote: > Hi, > > I've broken out the crunchgen logic from src/rescue/rescue into a > share/mk file - that way it can be reused in other areas. > > The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff > > This bsd.crunchgen.mk file is generic enough to use in my > busybox-style thing as well as for src/rescue/rescue/. > > Comments, feedback, etc welcome! > > > Adrian > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 13:09:19 2010 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 A45401065670; Sun, 14 Nov 2010 13:09:19 +0000 (UTC) (envelope-from g.veniamin@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 34DF88FC0C; Sun, 14 Nov 2010 13:09:17 +0000 (UTC) Received: by eyb7 with SMTP id 7so2562932eyb.13 for ; Sun, 14 Nov 2010 05:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=mMD4rOnT2lyCSFKPLB2RX1ezsSjaEZ62jahU2zL5lVc=; b=UBpDwYeuIlCAZ0W4AfNCcefPC+QvvZczYwCOi9NnLFsKtOPm7kpzitBqvG3WUk7aPx x5eiJSIY37UglLf4yV0RoPKKevPVdkAp3Ehbc4WO65FCUGbjQ4Ow38CKfY+tisOzIWoK G25h3758hC7iINHGUe0r19C7K9Q1BCtx3I7o4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=wBVhnmpiRS5ZRI9orJsf4iXcnimt0uhIcVI1mBQtmXQASaBPzqn+TnBdYsDJ5/jVhk XzRN/x+KETQDBEPvH7T1zZpIbxW9QgYCL970xa8GkjuQB/xTauWgcfpI7Mz4gWeqvuG3 RNzTCpbWxO7COCmLsMvP6Rx6AUzOV7ACT2kwM= Received: by 10.213.13.15 with SMTP id z15mr2312135ebz.30.1289740156563; Sun, 14 Nov 2010 05:09:16 -0800 (PST) Received: from zlobook.local (zlonet.ru [94.78.205.21]) by mx.google.com with ESMTPS id v51sm5463551eeh.22.2010.11.14.05.09.11 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 05:09:14 -0800 (PST) Message-ID: <4CDFDF76.3080102@googlemail.com> Date: Sun, 14 Nov 2010 20:09:10 +0700 From: Veniamin Gvozdikov User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky , jkim@FreeBSD.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <4CDD7922.1060105@googlemail.com> <201011122131.57554.hselasky@c2i.net> <4CDE8738.1040406@googlemail.com> <201011131345.43364.hselasky@c2i.net> In-Reply-To: <201011131345.43364.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="------------040602000703070109000602" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: MacBookPro7,1 and FreeBSD 8.1 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, 14 Nov 2010 13:09:19 -0000 This is a multi-part message in MIME format. --------------040602000703070109000602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. I think that I can broke my laptop %) I same found information about MacBook in the files: sys/dev/asmc/asmc.c sys/dev/asmc/asmcvar.h sys/dev/usb/input/atp.c I attached acpi dumps from this is how to http://www.projectosx.com/forum/index.php?showtopic=359 > On Saturday 13 November 2010 13:40:24 Veniamin Gvozdikov wrote: >> Hello. >> I fund a few lines about the macbook but I have issue. >> >> if (strncmp(sysenv, "MacBook5,1", 10) == 0 || >> strncmp(sysenv, "MacBookPro5,5", 13) == 0 || >> strncmp(sysenv, "Macmini3,1", 10) == 0) >> strncmp(sysenv, "Macmini3,1", 10) == 0 || >> strncmp(sysenv, "iMac9,1", 7) == 0) >> >> I see for macbookpro5,5 value 13, where is can I found value for 7,1? > 13 is the length of the string exluding the terminating zero. > > --HPS > >> thank you! >> >>> This might be because your model is not listed in a quirk-table: >>> >>> grep -ri macbook /usr/src/sys/amd64 >>> >>> /usr/src/sys/amd64/amd64/machdep.c >>> >>> --HPS --------------040602000703070109000602-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 13:55:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7BF931065672; Sun, 14 Nov 2010 13:55:59 +0000 (UTC) Date: Sun, 14 Nov 2010 13:55:59 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101114135559.GA40535@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: i386 specific manual pages 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, 14 Nov 2010 13:55:59 -0000 hi there, could we please have the following manual pages lib/libc/i386/sys/i386_get_ioperm.2 lib/libc/i386/sys/i386_get_ldt.2 lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?) lib/libc/i386/sys/i386_vm86.2 installed into /usr/share/man/man{2,3}/i386? they can be accessed via sysarch(2) and are explicitly being referenced by its manual page. that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=amd64. cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 14:27:45 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7245A1065673; Sun, 14 Nov 2010 14:27:45 +0000 (UTC) Date: Sun, 14 Nov 2010 14:27:45 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101114142745.GA44253@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline Subject: WITH_GPIO and obsolete files 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, 14 Nov 2010 14:27:45 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not specified in src.conf. also i just noticed that src.conf needs to be regenerated, because it's missing the WITH_GPIO description. cheers. alex -- a13x --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="OptionalObsoleteFiles.inc.diff" diff --git a/tools/build/mk/OptionalObsoleteFiles.inc b/tools/build/mk/OptionalObsoleteFiles.inc index 4ce9968..d9b4e35 100644 --- a/tools/build/mk/OptionalObsoleteFiles.inc +++ b/tools/build/mk/OptionalObsoleteFiles.inc @@ -808,6 +808,11 @@ OLD_FILES+=usr/lib32/libgpib_p.a .endif .endif +.if ${MK_GPIO} == no +OLD_FILES+=usr/sbin/gpioctl +OLD_FILES+=usr/share/man/man8/gpioctl.8.gz +.endif + .if ${MK_GSSAPI} == no OLD_FILES+=usr/lib/libgssapi.a OLD_FILES+=usr/lib/libgssapi.so --LZvS9be/3tNcYl/X-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 15:17:45 2010 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 DB5A1106566B; Sun, 14 Nov 2010 15:17:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3CEBC8FC1F; Sun, 14 Nov 2010 15:17:44 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAEFHc8K003595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Nov 2010 17:17:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAEFHcql047814; Sun, 14 Nov 2010 17:17:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAEFHcij047813; Sun, 14 Nov 2010 17:17:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Nov 2010 17:17:38 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20101114151738.GR2392@deviant.kiev.zoral.com.ua> References: <20101114135559.GA40535@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2taX4z4jgVuBuSce" Content-Disposition: inline In-Reply-To: <20101114135559.GA40535@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: i386 specific manual pages 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, 14 Nov 2010 15:17:45 -0000 --2taX4z4jgVuBuSce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 14, 2010 at 01:55:59PM +0000, Alexander Best wrote: > hi there, >=20 > could we please have the following manual pages >=20 > lib/libc/i386/sys/i386_get_ioperm.2 > lib/libc/i386/sys/i386_get_ldt.2 > lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?) > lib/libc/i386/sys/i386_vm86.2 >=20 > installed into /usr/share/man/man{2,3}/i386? they can be accessed via > sysarch(2) and are explicitly being referenced by its manual page. >=20 > that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=3D= amd64. Just a note: all of them except vm86 can be reasonably implemented on amd64, as well are supported under ia32 emulation on amd64. I am not sure that suggestion to do the work make sence, since they functions looks unused even on i386. --2taX4z4jgVuBuSce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzf/ZIACgkQC3+MBN1Mb4iJ9QCcDsn6fbEqqZAtP+wRLboY7YKc J2UAnjfbyJPn6Ch53+C3UlxleVVFM8p3 =F8B/ -----END PGP SIGNATURE----- --2taX4z4jgVuBuSce-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 15:39:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 54878106567A; Sun, 14 Nov 2010 15:39:52 +0000 (UTC) Date: Sun, 14 Nov 2010 15:39:52 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20101114153952.GA52828@freebsd.org> References: <20101114135559.GA40535@freebsd.org> <20101114151738.GR2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101114151738.GR2392@deviant.kiev.zoral.com.ua> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 specific manual pages 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, 14 Nov 2010 15:39:52 -0000 On Sun Nov 14 10, Kostik Belousov wrote: > On Sun, Nov 14, 2010 at 01:55:59PM +0000, Alexander Best wrote: > > hi there, > > > > could we please have the following manual pages > > > > lib/libc/i386/sys/i386_get_ioperm.2 > > lib/libc/i386/sys/i386_get_ldt.2 > > lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?) > > lib/libc/i386/sys/i386_vm86.2 > > > > installed into /usr/share/man/man{2,3}/i386? they can be accessed via > > sysarch(2) and are explicitly being referenced by its manual page. > > > > that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=amd64. > > Just a note: all of them except vm86 can be reasonably implemented on > amd64, as well are supported under ia32 emulation on amd64. I am not > sure that suggestion to do the work make sence, since they functions > looks unused even on i386. i'm afraid we don't agree on that issue. i need to set io permissions in order to write to the parallel port and don't want to open /dev/io for security reasons. right now i don't know any way of doing this under amd64 except by using sysarch(2). it might be possible to implement this natively under amd64, but that is not the point. sysarch(2) is available *now* and i should be able to get information about the architecture-dependent functions i can use with sysarch(2). if a native silution for amd64 pops up in the future that's great, but there's no point in installing the sysarch(2) manual and referencing the i386 architecture-dependent functions in it without providing necessary information to use those functions. thats like buying a car and the guy is telling you "it has lots of cool features". when you ask him however "what are those features" he replies: "well. be sure it has a lot of features, however i can't tell you what they are". ;) cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 17:56:23 2010 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 125EB1065695; Sun, 14 Nov 2010 17:56:23 +0000 (UTC) (envelope-from jhein@gossamer.timing.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mx1.freebsd.org (Postfix) with ESMTP id CF0B58FC08; Sun, 14 Nov 2010 17:56:22 +0000 (UTC) Received: from gossamer.timing.com ([206.168.13.144]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MSciy-1OsUEZ1nm8-00RrxR; Sun, 14 Nov 2010 12:43:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19680.8138.582316.245120@gossamer.timing.com> Date: Sun, 14 Nov 2010 10:43:38 -0700 From: John Hein To: Adrian Chadd In-Reply-To: References: X-Mailer: VM 8.0.12 under 22.3.1 (i386-redhat-linux-gnu) X-Provags-ID: V02:K0:KWdt4qXSYYaHeYMvN0pjr3m7dKXDF7vueTe2JPHG6W3 EJnY+InP3N0smu+BSQodDMYgY1QqwdgWUzAkjwaMfe6d8WFtEA //IOig+XQfK3T81SOP990JDOZkDBEmT2vmJcJbD9BH8u6ImeQC 0G1ZVTgwyNvDLcnQrk3F2JrDShnMFMTGwFabHW0v0RIV5tG/yq lr+Bj4IC5yX0SWrlPNf4g== Cc: freebsd-hackers@freebsd.org, freebsd-current , freebsd-embedded@freebsd.org Subject: Re: The path is now set for "busybox", FreeBSD style 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, 14 Nov 2010 17:56:23 -0000 Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > I've committed the below changes to -HEAD. You can now create and build your > own busybox style binary system, completely cross-compiled within the > existing Make framework. It isn't as impressive as it sounds though - a lot > of the framework is already there from just building crunchgen'ed > rescue/sysinstall binaries. > > There's a few things which should be done. Specifically, being able to build > an alternative set of libraries before building the crunchgen target. The > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc > but you may not want your crunch'ed image to have them. To do this right > now, you have to disable these features in the main build. That may be OK > for some. > > But just to stress it - I've got a couple of access point images at home > running a crunchgen'ed environment under MIPS and besides the obvious binary > bloat, it works perfectly well. Besides a cut-down startup framework, the > image cross-builds entirely from the base FreeBSD source tree. > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > Makefile scripts online to try. That's great. I assume it be not be hard for someone to take your scripts as a starting point and create a sysutils/bsdbox akin to sysutils/busybox? From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 20:22:56 2010 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 1BFF0106566C for ; Sun, 14 Nov 2010 20:22:56 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id BA1118FC23 for ; Sun, 14 Nov 2010 20:22:55 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp2.one.com (Postfix) with ESMTPA id CA5B6B4BB2842; Sun, 14 Nov 2010 20:22:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2088-73844678; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: Date: Sun, 14 Nov 2010 21:22:53 +0100 Message-Id: <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> To: Giorgos Keramidas X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= , FreeBSD Hackers Subject: Re: Deterministic builds? 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, 14 Nov 2010 20:22:56 -0000 --Apple-Mail-2088-73844678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas: >>=20 >> Since the SVN rev. is recorded, I think a timestamp is redundant. Any >> ideas where I can disable the timestamps in the source? >=20 > The timestamp is not 'redundant'. It records _when_ you compiled the > sources of the kernel, which in itself is a useful bit of information. I'm curious as to why this might be useful? Would the mtime of the file = not be be sufficient? I can only think of debugging purposes, but apart = from the timestamp, two kernels with the same rev. would be bitwise = identical, so I think the rev. number is more useful. Is the timestamp = not just a remnant from the CVS days? If it is useful, why not brand all binaries with a rev. number and a = timestamp? Erik= --Apple-Mail-2088-73844678-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 20:32:09 2010 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 E2321106566C for ; Sun, 14 Nov 2010 20:32:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99B628FC12 for ; Sun, 14 Nov 2010 20:32:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:20d4:5ad4:8ef9:2ce4] (unknown [IPv6:2001:7b8:3a7:0:20d4:5ad4:8ef9:2ce4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ACFDC5C43; Sun, 14 Nov 2010 21:32:08 +0100 (CET) Message-ID: <4CE04750.8060802@FreeBSD.org> Date: Sun, 14 Nov 2010 21:32:16 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13pre) Gecko/20101113 Lanikai/3.1.7pre MIME-Version: 1.0 To: Erik Cederstrand References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> In-Reply-To: <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Giorgos Keramidas , =?ISO-8859-1?Q?Sp=F6rlein?= , FreeBSD Hackers , =?ISO-8859-1?Q?Ulrich_?= Subject: Re: Deterministic builds? 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, 14 Nov 2010 20:32:10 -0000 On 2010-11-14 21:22, Erik Cederstrand wrote: > I'm curious as to why this might be useful? Would the mtime of the > file not be be sufficient? I can only think of debugging purposes, but > apart from the timestamp, two kernels with the same rev. would be > bitwise identical, This does not have to be the case. For example, if you have have local modifications, or use different settings in make.conf or src.conf. Similarly, the host on which something is built can be interesting metadata, because not all hosts are equal. > If it is useful, why not brand all binaries with a rev. number and a timestamp? There are compilers that automatically brand every binary with a "built on" timestamp. If you want to 'compare' such binaries, you simply need a tool that disregards the timestamps. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 20:57:28 2010 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 6824B1065672 for ; Sun, 14 Nov 2010 20:57:28 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id F062A8FC1B for ; Sun, 14 Nov 2010 20:57:27 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id 313D11BC00A32; Sun, 14 Nov 2010 20:57:26 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2090-75917089; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <4CE04750.8060802@FreeBSD.org> Date: Sun, 14 Nov 2010 21:57:25 +0100 Message-Id: <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Giorgos Keramidas , =?iso-8859-1?Q?Sp=F6rlein?= , FreeBSD Hackers Subject: Re: Deterministic builds? 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, 14 Nov 2010 20:57:28 -0000 --Apple-Mail-2090-75917089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: > On 2010-11-14 21:22, Erik Cederstrand wrote: >> I'm curious as to why this might be useful? Would the mtime of the >> file not be be sufficient? I can only think of debugging purposes, = but >> apart from the timestamp, two kernels with the same rev. would be >> bitwise identical, >=20 > This does not have to be the case. For example, if you have have = local > modifications, or use different settings in make.conf or src.conf. In this case the timestamp + rev. is not sufficient to reproduce the = kernel anyway. You'd need to store externally the non-standard contents = of conf files, local diffs etc. on all your non-standard builds. You = could do all sorts of fun stuff, even fool the rev. number or timestamp = if you wanted. I'm just saying that for the standard user on a standard GENERIC kernel = (and world for that matter) - the revision number should be sufficient = for e.g. filing a PR. If you need the timestamp, there's the mtime. Erik= --Apple-Mail-2090-75917089-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 21:13:38 2010 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 06F81106566C; Sun, 14 Nov 2010 21:13:38 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 414B18FC19; Sun, 14 Nov 2010 21:13:37 +0000 (UTC) Received: from localhost (acme.spoerlein.net [188.72.220.29]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oAELDYGF012290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Nov 2010 22:13:34 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289769214; bh=4m/QvX4SrzyghDlUxOicvvGoA5XM0GtR6iYad0kHdPM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=i50gOw1RbOrdKfnDi+PL+uGJXWvshuMij8TjPrsR3oqtVd3tL46+5HGj8RZAWPfOX dIXkclPYq/1RT6BPnDXZUJKBw96/YhSM1rhJUr+D7+MrQMnTprZISqdtcfTVNQfCEG DWT4SpHiAH2H1zSMcHx6mw/vz0I7tf9gjHicr72Q= Date: Sun, 14 Nov 2010 22:13:34 +0100 From: =?utf-8?B?U3DDtnJsZWlu?= To: Erik Cederstrand Message-ID: <20101114211334.GG64243@acme.spoerlein.net> Mail-Followup-To: Erik Cederstrand , Dimitry Andric , Giorgos Keramidas , FreeBSD Hackers References: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Giorgos Keramidas , FreeBSD Hackers , Dimitry Andric Subject: Re: Deterministic builds? 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, 14 Nov 2010 21:13:38 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote: >=20 > Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: >=20 > > On 2010-11-14 21:22, Erik Cederstrand wrote: > >> I'm curious as to why this might be useful? Would the mtime of the > >> file not be be sufficient? I can only think of debugging purposes, but > >> apart from the timestamp, two kernels with the same rev. would be > >> bitwise identical, > >=20 > > This does not have to be the case. For example, if you have have local > > modifications, or use different settings in make.conf or src.conf. >=20 > In this case the timestamp + rev. is not sufficient to reproduce the kern= el anyway. You'd need to store externally the non-standard contents of conf= files, local diffs etc. on all your non-standard builds. You could do all = sorts of fun stuff, even fool the rev. number or timestamp if you wanted. >=20 > I'm just saying that for the standard user on a standard GENERIC kernel (= and world for that matter) - the revision number should be sufficient for e= =2Eg. filing a PR. If you need the timestamp, there's the mtime. It might not be very easy, going from revision to timestamp. It is still very useful to know the rough timeframe when a kernel was built, as that might give you the "age" of the source tree. This is of course not a very good mapping, and the reason we have both the revision number in there, but also something a human understands. If this timestamp must be fixed, my vote would be on using the timestamp of the svn revision the build was using as a source. But it should be made clear, that this is then no longer the built timestamp, but the source repo timestamp. Uli --ew6BAiZeqk4r7MaW Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIPCQYJKoZIhvcNAQcCoIIO+jCCDvYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DHUwggUwMIIDGKADAgECAgMInfMwDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTAwNTA4MjEyNjUwWhcNMTIwNTA3MjEyNjUwWjA8MRgwFgYDVQQDFA9VbHJpY2ggU3D2cmxl aW4xIDAeBgkqhkiG9w0BCQEWEXVxc0BzcG9lcmxlaW4ubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAueVoTQDswlZczHBpS954Fl+D3Lzv/iYroev/X5062gfN3A8IsFcM Jpc/BErc7prdFzPoDjlprvMyA60MRT1I9YYqgjFnxH7tUV95Z42XgcVvtpL6u5A8O0029Ob/ RTXFuvXywFGfVKdHsoDimkUmviqXveJxjlHqhNDLiN1/lwIpyTZ63s+wTn/jrxVznwUHK+mG Clp7KbGh4n0X9zK/hFmSfLazjsg94HDT7D8SgoWAKaddEgq0qrfUTNK/g6wqAY3egNyrxbMT ie5GqL1IA89+xeQqNxKi/WX4XGLvUGA038ptFqtjTH/0twWM8dGB2cbehgYeCK4t29Zif2Kk PwIDAQABo4H9MIH6MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAcBgNVHREEFTATgRF1cXNAc3BvZXJsZWluLm5ldDANBgkqhkiG 9w0BAQUFAAOCAgEAyyl4LvYaEocSOvH45evNrAyksPI+kKpMCjA+OtqE8IY+XgMsErL/Wkml HfOA/UxJJ7rzB5ZQIMF3mNGzAl8f7fGBCvHiUzFMxBB1utDQMjphlIsRQEHfED2GCIyuPp2H oNvhDah6w+OYHmDPLUXdvkClZpvM00WfVNnOBIg/vGUMalbYyEzIi6QonaTVdJvetbP1zfHc YJltcfpgsWe4I9wUiGiVRaWB74mN+/bEViLJoxmQ/l9P1n8T2O/JEf2oGd6v6GLppYoNLj25 vtEFTAkeSUdfwiEAfg38GE40yrmFIQOGHLodnzWLrkBWjtqqYwe5Vqb/m0QZNYStHHSkPyXK HLiZ61Y53sOFihNQg4pW4gY8oTCdLHSX/QJ8C/V3WK/6dKKYgcDbVAUvWWcMJMRvtx9CsstW XqiHAIoYJcwFwYKirkr2KZpixBysQP6+XF1SbP5/KH2mfNY1FghClHIpriu30UpmhTXij0AW opq80MXb2rjSMEEuJJ8goGsr+oHvdVLJNpNJU73AC38Gho8hwuYX5gGonoemnw7FSc2vw1tR aVpCfgC4ii29DQMeiUiLIrDNYok/nK2gKJwP1qd+3Izfw2YpiUVPe1DWA4kBREfJx+E/Wsdz nnCz5yZK+k1BRupapzLJLBjC16USCH4TpLXGZoB2bWF3Hfh236Qwggc9MIIFJaADAgECAgEA MA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTAzMDMzMDEyMjk0OVoXDTMzMDMy OTEyMjk0OVoweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDOIsDiRn3sNigHUJbyoDNAjEvxO2Y/MeVrAjbb1nz28YiPTnc2BUGV+QnwEs9GhnNgt25+ 6MBYZK7NsK1FFwxj+mcK6NbSvz7nmMTwTPrgA7s1XWwh3p4g2brNZjI3cvr3CPXHzVjJjucO Xuo+/hyhFAoVbIaEW2RmKnqpS1N59Yiie+4vCmErjbJ+TValE+zq2pKerERBHlhgZQVm+MBE vcuU90J+C/dlaJhRBfDzBZEEHRsXguzIV7vDa3qI8bByzCVbIJHsFgISjzLpFxhI0McFLgIw QrglnAVrP6o6p+tTSPfo0rYHmNwbxjR/f8kcgnoFWCsIW/M4oqsXXWbJmNeeEIui0t10mvdx DHJg381vmDOdljR2PiR6krAOlR5v5qBFOEeq10HtSrcS9tcbg4oPLtgJtlnXqgT/0pN9aC7d i0urWLovjeqVp6DDVIml+9uLUSKdssO+Eb4skYaLlnitINOKLxo/xtBRZYchsRkBZX9FHIf1 fNBBTE8pmCH9Mx91DARR+hl329QUHO6Bwx31mLdpBpEi3QBQzIExrBIHezjaaFvmK9R+yV+t 6OtyTPMB5Usgv5qmV8qRAAGLoXUhN7VjDWc+Rk9wIGfOxdZZ2wLg8NLLzbpit5BB6N0g5Cm8 ZClCyCLceJr/Q+yYGwlRS1pawnHxxMtzqeWhCwIDAQABo4IBzjCCAcowHQYDVR0OBBYEFBa1 MhvUx/Pg5o7zvdKwOu6yORjRMIGjBgNVHSMEgZswgZiAFBa1MhvUx/Pg5o7zvdKwOu6yORjR oX2kezB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZ4IBADAPBgNVHRMBAf8EBTADAQH/MDIGA1UdHwQrMCkwJ6Al oCOGIWh0dHBzOi8vd3d3LmNhY2VydC5vcmcvcmV2b2tlLmNybDAwBglghkgBhvhCAQQEIxYh aHR0cHM6Ly93d3cuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMDQGCWCGSAGG+EIBCAQnFiVodHRw Oi8vd3d3LmNhY2VydC5vcmcvaW5kZXgucGhwP2lkPTEwMFYGCWCGSAGG+EIBDQRJFkdUbyBn ZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzANBgkqhkiG9w0BAQQFAAOCAgEAKMfunIICulyAEso1Ch2Bb4lqmczy aA9/p+GNWJU+vfIGw5BarLVg9plDAaOIcJydYp2kh69nWA0wNjvmrUjTy3QChnE+4isDaPE0 YkBGO1PqKPSs+2aVU4pNXf072WDXynlpO7FlkqbGgYJcnM3rTQGKpd8RVaoVyh83wIKYcGHb anyWo44uVD5PIamQ79yCv9zoRa1NkHMIPJRlsASZdn/ivMJqFaqXBDck2B6UTm0OUb7WxI/K lm33Q9/oMGUnO3u7Q0NjxEP3suxozOEZjiL7mOF7Wj4BNzuLCLCi85VOGsubzZqx27Jw8C1K 29iw429FSDMS//48MipU98T3ivCII8JH/mR6ccDRHqZjsAd+pC/TAY/cnyu2xgipD5NIJfwS /Z9C3PPEPvZXsNfdadEGdzQKS9LKoP8cxozJFr7EzDI3aHNfCPtR90lTNgUKlQJM8nkaEPbY OnWc8x3xog1wZ4Ybsxb1L+Wk63mG+T0LwnMLpZmsb/xnuOUvC6YYJI170Ug1KRhArJNg4ZaG ULR6WdiPIQufz4KRxju/a9wHkbmXViOqtmyUxkgGPOTOTqrk9i8J3FNvLvx06zpjmcKmrIm8 p7JEoA2KEONs8iTL+pufcEcu3hSL1LIgCZaiZPEkHNyhNZwVstS8VS59BvWcDlX0WtaT2nat JXNMxUMxggJcMIICWAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCJ3zMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTE0MjExMzM0 WjAjBgkqhkiG9w0BCQQxFgQUBd3DnjFxy9jucr7mxNsqET7JrzcwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAlfr1cw9Homd0xf5Qc0XMmky7WCYe ThdX6F/0ZZ3GpAqGKJFR1dmMhmHqm9dMY6W3IjiW1DouPMj5GLUxenwahCaQhXglj48vo1KO Dr05OMNEH0hQC5FLE2TJiS8G9FYTDNyT4SAwBE2IqWwsAgda15Vspk2B6429EL4nX6/mPkvs XoY7IsxbANFby3u+fjjOhhSYPNYrpZx7G5xvz40/A1BjH/jU4NlaHr0irseNagWO02eDwnq6 UVR/irA2ltJyIgkFIriWgB8ae2lx37xkjIulTl2I2clpmQlENckfk6nzIhRMnl2LK9pDscWa bFZY6xlHiA2zRtChwKPeJa6dlA== --ew6BAiZeqk4r7MaW-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 21:42:14 2010 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 4C457106566C for ; Sun, 14 Nov 2010 21:42:14 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 98AEE8FC1A for ; Sun, 14 Nov 2010 21:42:13 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oAELffhv015252 Received: from gkeramidas-glaptop.linux.gr (217-162-216-74.dclient.hispeed.ch [217.162.216.74]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oAELffhv015252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Nov 2010 23:41:49 +0200 From: keramida@freebsd.org (Giorgos Keramidas) To: Erik Cederstrand References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> Date: Sun, 14 Nov 2010 22:41:30 +0100 In-Reply-To: <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> (Erik Cederstrand's message of "Sun, 14 Nov 2010 21:22:53 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= , FreeBSD Hackers Subject: Re: Deterministic builds? 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, 14 Nov 2010 21:42:14 -0000 --=-=-= Content-Type: text/plain On Sun, 14 Nov 2010 21:22:53 +0100, Erik Cederstrand wrote: >Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas: >>> Since the SVN rev. is recorded, I think a timestamp is redundant. Any >>> ideas where I can disable the timestamps in the source? >> >> The timestamp is not 'redundant'. It records _when_ you compiled the >> sources of the kernel, which in itself is a useful bit of information. > > I'm curious as to why this might be useful? Would the mtime of the file > not be be sufficient? I can only think of debugging purposes, but apart > from the timestamp, two kernels with the same rev. would be bitwise > identical, so I think the rev. number is more useful. Is the timestamp > not just a remnant from the CVS days? The timestamp is a remnant from much older days, but it's still a bit useful if you build several kernels from 'almost' the same source tree. For example, think of two kernels who are built from the same svn revision but they are built from two different patched kernel source trees. They will both have a version string that says "svn 12345+" but their "+" will refer to different patch states. When a kernel developer is trying various iterations of this own local patch, having the timestamp may actually be useful to differentiate between a working and a non-working patch state. I *like* the idea of 100% repeatable kernel builds and I'd even go as far as suggesting it is nice to turn on by *default*, but let's think about a way to _include_ the timestamp e.g. with an src.conf option for those cases when it's really useful. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzgV4oACgkQ1g+UGjGGA7ZC4QCePYJocjrmvVku0PghnhsJs+S7 GR0AoL8Th2lI08/Vw1tB0PcNigessqJE =OGtg -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 22:31:26 2010 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 AC701106564A; Sun, 14 Nov 2010 22:31:26 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 757F28FC14; Sun, 14 Nov 2010 22:31:26 +0000 (UTC) Received: from [24.87.55.58] (helo=[192.168.10.184]) by launchpad.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PHkr8-0005Ct-A5; Sun, 14 Nov 2010 14:15:27 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <20101114142745.GA44253@freebsd.org> Date: Sun, 14 Nov 2010 14:15:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <301FA51F-9308-415D-9142-5AC9656A8CF3@bluezbox.com> References: <20101114142745.GA44253@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1082) Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2010-11-14, at 6:27 AM, Alexander Best wrote: > hi there, > > this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not specified > in src.conf. > > also i just noticed that src.conf needs to be regenerated, because it's missing the > WITH_GPIO description. Thanks Alexander, I commited this patch and regenerated src.conf.5 manpage. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-hackers@freebsd.org Subject: Re: WITH_GPIO and obsolete files 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, 14 Nov 2010 22:31:26 -0000 On 2010-11-14, at 6:27 AM, Alexander Best wrote: > hi there, >=20 > this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not = specified > in src.conf. >=20 > also i just noticed that src.conf needs to be regenerated, because = it's missing the > WITH_GPIO description. Thanks Alexander, I commited this patch and regenerated src.conf.5 = manpage. --=20 gonzo From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 22:55:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B96EF1065672; Sun, 14 Nov 2010 22:55:07 +0000 (UTC) Date: Sun, 14 Nov 2010 22:55:07 +0000 From: Alexander Best To: Oleksandr Tymoshenko Message-ID: <20101114225507.GA21308@freebsd.org> References: <20101114142745.GA44253@freebsd.org> <301FA51F-9308-415D-9142-5AC9656A8CF3@bluezbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <301FA51F-9308-415D-9142-5AC9656A8CF3@bluezbox.com> Cc: freebsd-hackers@freebsd.org Subject: Re: WITH_GPIO and obsolete files 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, 14 Nov 2010 22:55:07 -0000 On Sun Nov 14 10, Oleksandr Tymoshenko wrote: > > On 2010-11-14, at 6:27 AM, Alexander Best wrote: > > > hi there, > > > > this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not specified > > in src.conf. > > > > also i just noticed that src.conf needs to be regenerated, because it's missing the > > WITH_GPIO description. > Thanks Alexander, I commited this patch and regenerated src.conf.5 manpage. thanks. :) > > > -- > gonzo > > -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 14 23:25:03 2010 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 2555C106564A for ; Sun, 14 Nov 2010 23:25:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A5F968FC0A for ; Sun, 14 Nov 2010 23:25:02 +0000 (UTC) Received: by wwi14 with SMTP id 14so364881wwi.31 for ; Sun, 14 Nov 2010 15:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=vjzQBdvQUdVSkRDRrR2b/fWRUA6fpquyBPg6861pOKY=; b=wLqhvuqZTkEVghwG4sqN6e6kePy+77eKUyUBbTHYjrbAhQ53KLt1P6wM7hfYsaaExc RWMIZ/WYEdr1ZQBxA6+GQSDRWuRrobOq/YjiDljZD1Y/29hBEEXGZZV8GK4ybZauvVED juw/h/oU37RnF6t2epq38n4aPNMKi77lQWrkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RtuR7ExtZQ/3OJIK7YIpL7DsuH6Gqy2/k29gL6+YLu5QPBg90+w/NSGgVuHMWoncBz mcqFaBnmWw9FG5OYwqgQ5ssFhTWq5yIYunxJwb1hiV2ZAg0ig0rptygYOLbt8sW8n8vR 1FlUmdOWf5bS2o3JnHxO+jZ+4ygFiUvQEqcVQ= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr6592009wep.30.1289777101459; Sun, 14 Nov 2010 15:25:01 -0800 (PST) Received: by 10.216.198.27 with HTTP; Sun, 14 Nov 2010 15:25:01 -0800 (PST) Date: Sun, 14 Nov 2010 15:25:01 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016364c7576f8d0d404950ba1ae Subject: [PATCH] More explicit return codes for sigismember(3) 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, 14 Nov 2010 23:25:03 -0000 --0016364c7576f8d0d404950ba1ae Content-Type: text/plain; charset=ISO-8859-1 Hi, I found this change kicking around my tree from a while back. It brings the manpage for sigismember(3) more in line with the POSIX definition [1] in the RETURN CODES section by explicitly noting that sigismember(3) returns 0 if a signal is valid and not a part of the set passed in. If someone could review and commit the change, it would be much appreciated. Thanks! -Garrett [1] http://www.opengroup.org/onlinepubs/009695399/functions/sigismember.html (SUS Issue 6 -- but the wording for the manpage is the same in SUS Issue 7). --0016364c7576f8d0d404950ba1ae Content-Type: application/octet-stream; name="more-explicit-sigismember-return-codes.diff" Content-Disposition: attachment; filename="more-explicit-sigismember-return-codes.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggijv1x10 SW5kZXg6IGxpYi9saWJjL2dlbi9zaWdzZXRvcHMuMwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBsaWIvbGliYy9n ZW4vc2lnc2V0b3BzLjMJKHJldmlzaW9uIDIxNTMxMCkKKysrIGxpYi9saWJjL2dlbi9zaWdzZXRv cHMuMwkod29ya2luZyBjb3B5KQpAQCAtOTIsOCArOTIsMTEgQEAKIFRoZQogLkZuIHNpZ2lzbWVt YmVyCiBmdW5jdGlvbiByZXR1cm5zIDEKLWlmIHRoZSBzaWduYWwgaXMgYSBtZW1iZXIgb2YgdGhl IHNldCwKLTAgb3RoZXJ3aXNlLgoraWYgdGhlIHNpZ25hbCBpcyBhIG1lbWJlciBvZiB0aGUgc2V0 LCBvciAwIGlmIGl0IGlzIG5vdC4KK090aGVyd2lzZSwgaXQgcmV0dXJucyBcLTEgYW5kIHRoZSBn bG9iYWwgdmFyaWFibGUKKy5WYSBlcnJubworaXMgc2V0IHRvIGluZGljYXRlIHRoZSByZWFzb24u CisuQmwKIFRoZSBvdGhlciBmdW5jdGlvbnMgcmV0dXJuIDAgdXBvbiBzdWNjZXNzLgogQSBcLTEg cmV0dXJuIHZhbHVlCiBpbmRpY2F0ZXMgYW4gZXJyb3Igb2NjdXJyZWQgYW5kIHRoZSBnbG9iYWwg dmFyaWFibGUK --0016364c7576f8d0d404950ba1ae-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 05:14:17 2010 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 3B935106564A for ; Mon, 15 Nov 2010 05:14:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C399D8FC16 for ; Mon, 15 Nov 2010 05:14:16 +0000 (UTC) Received: by wyb36 with SMTP id 36so2161832wyb.13 for ; Sun, 14 Nov 2010 21:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6nxBZYiUlGkIgX4qAWHQIksl1R35uz8NBZkbrmzKNSg=; b=sFYdfnjX5y/s8V104DxtK+BSUKbRQtydGbF8LPao7nW+TqQr+uiOjhN2u63Zi2VKE4 xy4e0VjK/YGQ1R+nYEVAW+ezZ9420AZ3ia0mpUWsvSTvsCnwVAP1LwFof9AaFlJXO+AK 6wxAKjkVht6uk5qdlfZP7J2qn8IpXxT/sbolM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Rc/BDiOXoM4cBNANIN71Ud6aAVXVCUto7LcQhHBJ3OofiW2yAXHZsqnjbP5mCHOsI5 JzVkwHdDHtFVDNDEt4SAXiv6JNpHdhYJ9yBcs4zUHJxMCY7PntWPY7XG7RTRWgy1A0gC VW+nPIMMIKCYFA+E6LXiV9vGXff51JMbPBUgc= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr5356803wee.45.1289798055626; Sun, 14 Nov 2010 21:14:15 -0800 (PST) Received: by 10.216.198.27 with HTTP; Sun, 14 Nov 2010 21:14:15 -0800 (PST) Date: Sun, 14 Nov 2010 21:14:15 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=001636eefd2af0072f0495108274 Subject: [PATCH] Fix lib/libpam's include of sys/time.h 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, 15 Nov 2010 05:14:17 -0000 --001636eefd2af0072f0495108274 Content-Type: text/plain; charset=ISO-8859-1 libpam uses sys/time.h to pick up ctime, but it's actually defined in time.h according to POSIX and the ctime manpage. If someone could help review and commit this patch, it would be much appreciated. This is part of a much larger change to fix namespace pollution with time.h in sys/time.h. Thanks, -Garrett --001636eefd2af0072f0495108274 Content-Type: text/x-patch; charset=US-ASCII; name="lib-libpam-use-time-dot-h.patch" Content-Disposition: attachment; filename="lib-libpam-use-time-dot-h.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggiwezv30 SW5kZXg6IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fdW5peC9wYW1fdW5peC5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fdW5peC9wYW1fdW5peC5jCShyZXZpc2lvbiAyMTUz MzMpCisrKyBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3VuaXgvcGFtX3VuaXguYwkod29ya2luZyBj b3B5KQpAQCAtMzksNyArMzksNiBAQAogCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVk ZSA8c3lzL3NvY2tldC5oPgotI2luY2x1ZGUgPHN5cy90aW1lLmg+CiAjaW5jbHVkZSA8bmV0aW5l dC9pbi5oPgogI2luY2x1ZGUgPGFycGEvaW5ldC5oPgogCkBAIC01MCw2ICs0OSw3IEBACiAjaW5j bHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzeXNsb2cuaD4K KyNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKICNpbmNsdWRlIDxsaWJ1 dGlsLmg+Cg== --001636eefd2af0072f0495108274-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 05:55:14 2010 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 8DEAB1065670 for ; Mon, 15 Nov 2010 05:55:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCC58FC16 for ; Mon, 15 Nov 2010 05:55:13 +0000 (UTC) Received: by wyb36 with SMTP id 36so2184020wyb.13 for ; Sun, 14 Nov 2010 21:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=peQMW/OYpFMA0njPGWfN5XJU4TyH4d0aupC8xVDjBhk=; b=W2ajH9gGXlcjAFfYqV8y36p70XTdmxhO0vbAC1O2oCZFIJVAJmfZVVM2Pfp06tqTOe 4Dg/ddQhWg69MEw671adQ8wetJGk4N/9EFsPGoGFXL0MkAhbDyDpsAKq4FE38XRsDWWv W920M8sfrk3/RUIRzINk4LXT6fR5m3CcBGIrs= 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 :content-type; b=jVk0dWILt/MLWwM+dFgFJKQd1EimYj37CTN2aAybDyPgpR1YKXRNE/QHTnurudnSd5 mc58b8N76TXqcMiCFigvUH9VUkvcGlvy1d7F2SsoZJpTdQWAZS1EcsM/h7Z3Hiq6Z5N3 SWCo/zBKMfPROzsw9PPeqpYeIAu1oMqEkucGM= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr5388602wee.45.1289800512782; Sun, 14 Nov 2010 21:55:12 -0800 (PST) Received: by 10.216.198.27 with HTTP; Sun, 14 Nov 2010 21:55:12 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Nov 2010 21:55:12 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=001636eefd2a6543a0049511152a Subject: Re: [PATCH] Fix lib/libpam's include of sys/time.h 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, 15 Nov 2010 05:55:14 -0000 --001636eefd2a6543a0049511152a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Nov 14, 2010 at 9:14 PM, Garrett Cooper wrote: > =A0 =A0libpam uses sys/time.h to pick up ctime, but it's actually defined > in time.h according to POSIX and the ctime manpage. > =A0 =A0If someone could help review and commit this patch, it would be > much appreciated. This is part of a much larger change to fix > namespace pollution with time.h in sys/time.h. Sorry... missed the gettimeofday requirement in the lib. The library fully compiles with this patch (where sys/time.h isn't removed). This is POSIX compliant. Thanks, -Garrett --001636eefd2a6543a0049511152a Content-Type: text/x-patch; charset=US-ASCII; name="lib-libpam-use-time-dot-h.patch" Content-Disposition: attachment; filename="lib-libpam-use-time-dot-h.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggixwadn1 SW5kZXg6IC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fdW5peC9wYW1fdW5peC5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fdW5peC9wYW1fdW5p eC5jCShyZXZpc2lvbiAyMTUzMzMpCisrKyAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFt X3VuaXgvcGFtX3VuaXguYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2luY2x1 ZGUgPHN0cmluZy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3lzbG9nLmg+Cisj aW5jbHVkZSA8dGltZS5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAjaW5jbHVkZSA8bGlidXRp bC5oPgo= --001636eefd2a6543a0049511152a-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 11:56:36 2010 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 3C5C71065696; Mon, 15 Nov 2010 11:56:36 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id C0DE08FC1D; Mon, 15 Nov 2010 11:56:35 +0000 (UTC) Received: from [192.168.0.22] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp1.one.com (Postfix) with ESMTP id 47A3F1BC01BC2; Mon, 15 Nov 2010 11:56:31 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2127-129861126; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: Date: Mon, 15 Nov 2010 12:56:29 +0100 Message-Id: <5C879D3B-B8B8-4F58-B644-D43DCB674DA5@cederstrand.dk> References: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> <20101114211334.GG64243@acme.spoerlein.net> To: Tom Evans X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Giorgos Keramidas , FreeBSD Hackers , Dimitry Andric Subject: Re: Deterministic builds? 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, 15 Nov 2010 11:56:36 -0000 --Apple-Mail-2127-129861126 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 15/11/2010 kl. 12.40 skrev Tom Evans: > The important things for us are that given a binary, you should be > able to easily reproduce the source environment that the binary was > produced from, and any two binaries produced from the same sources > should be identical. I'm leaning towards not even recording the svn rev. within the binary. A = commit only changing comments or style(9) would not change the bits of = the binary, but the differing revision number would. A solution could be = to have an external file, e.g. /etc/kernel-buildinfo and = /etc/world-buildinfo, containing the output of "svn stat", "svn diff", = src.conf, make.conf, SRCDIR and OBJDIR locations, the full = buildworld/kernel command and whatever else could affect the build = outcome. Erik= --Apple-Mail-2127-129861126-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 12:04:36 2010 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 F2BEF10656AB; Mon, 15 Nov 2010 12:04:35 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE708FC0C; Mon, 15 Nov 2010 12:04:35 +0000 (UTC) Received: by qyk2 with SMTP id 2so1843199qyk.13 for ; Mon, 15 Nov 2010 04:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5AgCvup/++ImmdJEinyJTy4Rs2jiP+r3QJ7JUK9mwN8=; b=BJGW5ig2pyX3wbQXgLvxkG9OsnPl/phX4Ls6zaTJHEY/Rj7n7sRA/ZCVEk8G4tEP71 /pXIw+WYKFLrEmE2wRgVm+Nry13QWsCmcEUYGZy0vVT/8lkG2WM+c47nPJ661GHR5Yah wxkYhSoiclXQZWT7gpUTFqDZGoSh19jORzD40= 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:content-transfer-encoding; b=YNlaYy1aaniN4xKCxWu5bpfNDVEJwcPHav1Wusv3xzOqY2OUAmdQekQRMuMSR+f3cA aeEIrMO5a+tzAtmp0AzMbc5uPRdRzt8okiyvD17pa9fEqVFVshWpJpSys+T7K33JS0AY OMujaPo/CcyXZ09xmwKW8Oc5HcdzM4WWY22M4= MIME-Version: 1.0 Received: by 10.229.232.205 with SMTP id jv13mr4992180qcb.68.1289821206947; Mon, 15 Nov 2010 03:40:06 -0800 (PST) Received: by 10.229.182.18 with HTTP; Mon, 15 Nov 2010 03:40:06 -0800 (PST) In-Reply-To: <20101114211334.GG64243@acme.spoerlein.net> References: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> <20101114211334.GG64243@acme.spoerlein.net> Date: Mon, 15 Nov 2010 11:40:06 +0000 Message-ID: From: Tom Evans To: Erik Cederstrand , Dimitry Andric , Giorgos Keramidas , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Deterministic builds? 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, 15 Nov 2010 12:04:36 -0000 On Sun, Nov 14, 2010 at 9:13 PM, Sp=C3=B6rlein wrote: > On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote: >> >> Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: >> >> > On 2010-11-14 21:22, Erik Cederstrand wrote: >> >> I'm curious as to why this might be useful? Would the mtime of the >> >> file not be be sufficient? I can only think of debugging purposes, bu= t >> >> apart from the timestamp, two kernels with the same rev. would be >> >> bitwise identical, >> > >> > This does not have to be the case. =C2=A0For example, if you have have= local >> > modifications, or use different settings in make.conf or src.conf. >> >> In this case the timestamp + rev. is not sufficient to reproduce the ker= nel anyway. You'd need to store externally the non-standard contents of con= f files, local diffs etc. on all your non-standard builds. You could do all= sorts of fun stuff, even fool the rev. number or timestamp if you wanted. >> >> I'm just saying that for the standard user on a standard GENERIC kernel = (and world for that matter) - the revision number should be sufficient for = e.g. filing a PR. If you need the timestamp, there's the mtime. > > It might not be very easy, going from revision to timestamp. It is still > very useful to know the rough timeframe when a kernel was built, as that > might give you the "age" of the source tree. This is of course not a > very good mapping, and the reason we have both the revision number in > there, but also something a human understands. > > If this timestamp must be fixed, my vote would be on using the timestamp > of the svn revision the build was using as a source. But it should be > made clear, that this is then no longer the built timestamp, but the > source repo timestamp. > > Uli > Timestamp of the revision is better than timestamp of the build - it is more than possible that someone could forget to update their sources, and rebuild their kernel and world, giving a recent build timestamp to some code that is actually quite old. This may not be possible with the kernel, but at $JOB we wanted our build system to produce binaries that we could precisely reproduce the source for, so our binaries contain both the revision numbers of the various libraries etc, but also contain any differences that the source files had (we literally add the output of "svn diff" to an object file generated by the Makefile). There are probably nicer ways of doing this with the elf file format, but I don't know them :) The important things for us are that given a binary, you should be able to easily reproduce the source environment that the binary was produced from, and any two binaries produced from the same sources should be identical. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 12:04:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3FD1210656AA; Mon, 15 Nov 2010 12:04:48 +0000 (UTC) Date: Mon, 15 Nov 2010 12:04:48 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20101115120448.GA32034@freebsd.org> References: <20101114135559.GA40535@freebsd.org> <20101114151738.GR2392@deviant.kiev.zoral.com.ua> <20101114153952.GA52828@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101114153952.GA52828@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 specific manual pages 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, 15 Nov 2010 12:04:48 -0000 On Sun Nov 14 10, Alexander Best wrote: > On Sun Nov 14 10, Kostik Belousov wrote: > > On Sun, Nov 14, 2010 at 01:55:59PM +0000, Alexander Best wrote: > > > hi there, > > > > > > could we please have the following manual pages > > > > > > lib/libc/i386/sys/i386_get_ioperm.2 > > > lib/libc/i386/sys/i386_get_ldt.2 > > > lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?) > > > lib/libc/i386/sys/i386_vm86.2 > > > > > > installed into /usr/share/man/man{2,3}/i386? they can be accessed via > > > sysarch(2) and are explicitly being referenced by its manual page. > > > > > > that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=amd64. > > > > Just a note: all of them except vm86 can be reasonably implemented on > > amd64, as well are supported under ia32 emulation on amd64. I am not > > sure that suggestion to do the work make sence, since they functions > > looks unused even on i386. another possibility would be to add something like "WITH_MAN_ARCH", which will install all arch dependant manual pages, no matter what the current arch is. this would come in handy for people running let's say amd64, but also working on other arch dependant code. cheers. alex > > i'm afraid we don't agree on that issue. i need to set io permissions in order > to write to the parallel port and don't want to open /dev/io for security > reasons. right now i don't know any way of doing this under amd64 except by > using sysarch(2). it might be possible to implement this natively under amd64, > but that is not the point. sysarch(2) is available *now* and i should be able > to get information about the architecture-dependent functions i can use with > sysarch(2). > > if a native silution for amd64 pops up in the future that's great, but there's > no point in installing the sysarch(2) manual and referencing the i386 > architecture-dependent functions in it without providing necessary information > to use those functions. > > thats like buying a car and the guy is telling you "it has lots of cool > features". when you ask him however "what are those features" he replies: > "well. be sure it has a lot of features, however i can't tell you what they > are". ;) > > cheers. > alex > > -- > a13x -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 12:50:45 2010 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 82E99106577C for ; Mon, 15 Nov 2010 12:50:45 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D2D948FC1D for ; Mon, 15 Nov 2010 12:50:44 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oAFCoQFm031452 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oAFCoQFm031452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Nov 2010 14:50:32 +0200 From: keramida@freebsd.org (Giorgos Keramidas) To: Erik Cederstrand References: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> <20101114211334.GG64243@acme.spoerlein.net> <5C879D3B-B8B8-4F58-B644-D43DCB674DA5@cederstrand.dk> Date: Mon, 15 Nov 2010 13:50:21 +0100 In-Reply-To: <5C879D3B-B8B8-4F58-B644-D43DCB674DA5@cederstrand.dk> (Erik Cederstrand's message of "Mon, 15 Nov 2010 12:56:29 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: Tom Evans , FreeBSD Hackers , Dimitry Andric Subject: Re: Deterministic builds? 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, 15 Nov 2010 12:50:45 -0000 --=-=-= Content-Type: text/plain On Mon, 15 Nov 2010 12:56:29 +0100, Erik Cederstrand wrote: >Den 15/11/2010 kl. 12.40 skrev Tom Evans: >> The important things for us are that given a binary, you should be >> able to easily reproduce the source environment that the binary was >> produced from, and any two binaries produced from the same sources >> should be identical. > > I'm leaning towards not even recording the svn rev. within the binary. A > commit only changing comments or style(9) would not change the bits of > the binary, but the differing revision number would. A solution could be > to have an external file, e.g. /etc/kernel-buildinfo and > /etc/world-buildinfo, containing the output of "svn stat", "svn diff", > src.conf, make.conf, SRCDIR and OBJDIR locations, the full > buildworld/kernel command and whatever else could affect the build > outcome. A few other things that may affect the binaries produced are: * Runtime shell environment (CFLAGS etc.) * make -j JOBS count * the value of -frandom-seed=STRING (see NetBSD's build.sh script and `3.9 Options for Debugging Your Program or GCC' in the gcc.info docs) If we are to record all these in the resulting binary snapshot of build output, then it may be possible to fully reproduce the *exact* set of binaries from a given source tree, but 'perfect' may be the enemy of the good-enough solution. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzhLI0ACgkQ1g+UGjGGA7YisQCeNSDkhDwxprXLQHuj2uaCkTtK /a0An3PJKeYBac4+vm+pRinbBA4dLoqc =dLZJ -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 13:48:55 2010 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 A443A1065698 for ; Mon, 15 Nov 2010 13:48:55 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from pikmeer.webweaving.org (pikmeer.webweaving.org [213.207.101.183]) by mx1.freebsd.org (Postfix) with ESMTP id 281A28FC1A for ; Mon, 15 Nov 2010 13:48:54 +0000 (UTC) Received: from neep.dmi.dev.local (ge2-0.rt2.rbsov.bbc.co.uk [212.58.239.38]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.4/8.14.4) with ESMTP id oAFDcETO004019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Nov 2010 13:38:14 GMT (envelope-from dirkx@webweaving.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dirk-Willem van Gulik In-Reply-To: Date: Mon, 15 Nov 2010 13:48:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (pikmeer.webweaving.org [213.207.101.183]); Mon, 15 Nov 2010 13:38:14 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, freebsd-current , freebsd-embedded@freebsd.org Subject: Re: The path is now set for "busybox", FreeBSD style 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, 15 Nov 2010 13:48:55 -0000 On 14 Nov 2010, at 03:40, Adrian Chadd wrote: > I've committed the below changes to -HEAD. You can now create and = build your > own busybox style binary system, completely cross-compiled within the > existing Make framework. It isn't as impressive as it sounds though - = a lot > of the framework is already there from just building crunchgen'ed > rescue/sysinstall binaries. Wonderful ! > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > Makefile scripts online to try. Yes please, Dw.= From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 17:05:44 2010 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 CCC1B1065670 for ; Mon, 15 Nov 2010 17:05:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2D18FC15 for ; Mon, 15 Nov 2010 17:05:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1A1E046B49; Mon, 15 Nov 2010 12:05:44 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 87F5E8A009; Mon, 15 Nov 2010 12:05:38 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 15 Nov 2010 11:25:42 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101112184000.GS11110@cel.leo> In-Reply-To: <20101112184000.GS11110@cel.leo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011151125.42697.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 15 Nov 2010 12:05:38 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Paul LeoNerd Evans Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 17:05:45 -0000 On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote: > I'm trying to build a high-level language wrapper around kqueue/kevent, > specifically, a Perl wrapper. > > (In fact I am trying to fix this bug: > http://rt.cpan.org/Public/Bug/Display.html?id=61481 > ) > > My plan is to use the void *udata field of a kevent watcher to store a > pointer to some user-provided Perl data structure (an SV*), to associate > with the event. Typically this could be a code reference for an event > callback or similar, but the exact nature doesn't matter. It's a pointer > to a reference-counted data structure. SvREFCNT_dec(sv) is the function > used to decrement the reference counter. > > To account for the fact that the kernel stores a pointer here, I'm > artificially increasing the reference count on the object, so that it > still remains alive even if the rest of the Perl code drops it, to rely > on getting it back out of the kernel in an individual kevent. At some > point when the kernel has finished looking after the event, this count > needs to be decreased again, so the structure can be freed. > > I am having trouble trying to work out how to do this, or rather, when. > I have the following problems: > > * If the event was registered using EV_ONESHOT, when it gets fired the > flags that come back in the event stucture do not include EV_ONESHOT. > > * Some events can only happen once, such as watching for EVFILT_PROC > NOTE_EXIT events. > > * The kernel can silently drop watches, such as when the process calls > close() on a filehandl with an EVFILT_READ or EVFILT_WRITE watch. > > * There doesn't seem to be a way to query that pointer back out of the > kernel, in case the user code wants to EV_DELETE the watch. > > These problems all mean that I never quite know when I ought to call > SvREFCNT_dec() on that pointer. > > My current best-attack plan looks like the following: > > a) Store a structure in the void *udata that contains the actual SV* > pointer and a flag to remember if the event had been installed as > EV_ONESHOT (or remember if it was one of the event types that is > oneshot anyway) > > b) Store an entire mapping in userland from filter+identity to pointer, > so that if userland wants to EV_DELETE the watch early, it has the > pointer to be able to drop it. > > I can't think of a solution to the close() problem at all, though. > > Part a of my solution seems OK (though I'd wonder why the flags back > from the kernel don't contain EV_ONESHOT), but part b confuses me. I had > thought the point of kqueue/kevent is the O(1) nature of it, which is > among why the kernel is storing that void *udata pointer in the first > place. If I have to store a mapping from every filter+identity back to > my data pointer, why does the kernel store one at all? I could just > ignore the udata field and use my mapping for my own purposes. > > Have I missed something here, then? I was hoping there'd be a nice way > for kernel to give me back those pointers so I can just decrement a > refcount on it, and have it reclaimed. I think the assumption is that userland actually maintains a reference on the specified object (e.g. a file descriptor) and will know to drop the associated data when the file descriptor is closed. That is, think of the kevent as a member of an eventable object rather than a separate object that has a reference to the eventable object. When the eventable object's reference count drops to zero in userland, then the kevent should be deleted, either via EV_DELETE, or implicitly (e.g. by closing the associated file descriptor). I think in your case you should not give the kevent a reference to your object, but instead remove the associated event for a given object when an object's refcount drops to zero. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 17:53:59 2010 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 831E3106564A for ; Mon, 15 Nov 2010 17:53:59 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5FE8FC0C for ; Mon, 15 Nov 2010 17:53:58 +0000 (UTC) Received: by eyb7 with SMTP id 7so3085281eyb.13 for ; Mon, 15 Nov 2010 09:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=u+flXdrWe/U4Y6f18qnVeviGCwNN1Exkgc8eYVbr1j0=; b=UyB0yQ2fw5Xz7bbhHP6k55bp5N0ny+oFCANm9QMWYOGNMe0Oknruk3zk77eyeacZ3P pBnxL+LWD6+7yD+dFZiyFs+FKRev8xXbYwYURH5ud421ebA+Tnv/IoGRXUgtKERjXu1S uDAcxmAyJEYz7KkYgXQpHZ7mTfSiNbghNDpdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ieUf98M4LS4DPPzcjXgXsKhxJ+/6VIblEFDXAQoA3/LnXXaTWEUdxvnb/0udqtL1nO c6PzYARRt/cGHSeWSqRpmB20Lq0dgPA4qU3Tv+llfiRv890sX9OZZrgxjesVDnl6sXIz qyLXuaa9IgEUTj67NxrW7m09PYmojiQApSkQo= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr6233647wel.30.1289843637817; Mon, 15 Nov 2010 09:53:57 -0800 (PST) Received: by 10.216.198.27 with HTTP; Mon, 15 Nov 2010 09:53:57 -0800 (PST) Date: Mon, 15 Nov 2010 09:53:57 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Phantom sysctl 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, 15 Nov 2010 17:53:59 -0000 According to SYSCTL_INT(9): The SYSCTL kernel interfaces allow code to statically declare sysctl(8) MIB entries, which will be initialized when the kernel module containing the declaration is initialized. When the module is unloaded, the sysctl will be automatically destroyed. The sysctl should be reaped when the module is unloaded. My dumb test kernel module [1] doesn't seem to do that though (please note that the OID test_int_sysctl is created, and not reaped... FWIW it's kind of bizarre that test_int_sysctl is created in the first place, given what I've seen when SYSCTL_* gets executed): toaster# kldload ./test_int_sysctl.ko toaster# sysctl -a | grep test test_int_sysctl: 0 vfs.nfs_common.realign_test: 0 debug.test_int_sysctl: 0 toaster# sysctl test_int_sysctl sysctl: unknown oid 'test_int_sysctl' toaster# kldunload ./test_int_sysctl.ko toaster# sysctl -a | grep test test_int_sysctl: 0 vfs.nfs_common.realign_test: 0 toaster# sysctl test_int_sysctl sysctl: unknown oid 'test_int_sysctl' I've seen this behavior on 8.1-RELEASE (custom kernel, vanilla sources), and CURRENT r215254. I'm compiling the kernel with SYSCTL_DEBUG (and added some missing error checking in the kern_sysctl.c code) to see if I can track down the resource issue, but in the meantime if someone more knowledgeable has some suggestions for what to do / where I should look, I'm all ears. Thanks! -Garrett 1. http://pastebin.com/n7d9bH8U From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 18:10:24 2010 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 8A0771065672 for ; Mon, 15 Nov 2010 18:10:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE748FC15 for ; Mon, 15 Nov 2010 18:10:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1EFE046B06; Mon, 15 Nov 2010 13:10:24 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50C2A8A027; Mon, 15 Nov 2010 13:10:23 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 15 Nov 2010 13:09:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011151309.23068.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 15 Nov 2010 13:10:23 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Garrett Cooper Subject: Re: Phantom sysctl 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, 15 Nov 2010 18:10:24 -0000 On Monday, November 15, 2010 12:53:57 pm Garrett Cooper wrote: > According to SYSCTL_INT(9): > > The SYSCTL kernel interfaces allow code to statically declare sysctl(8) > MIB entries, which will be initialized when the kernel module containing > the declaration is initialized. When the module is unloaded, the sysctl > will be automatically destroyed. > > The sysctl should be reaped when the module is unloaded. My dumb > test kernel module [1] doesn't seem to do that though (please note > that the OID test_int_sysctl is created, and not reaped... FWIW it's > kind of bizarre that test_int_sysctl is created in the first place, > given what I've seen when SYSCTL_* gets executed): I believe I have seen this work properly before. Look for 'sysctl' in sys/kern/kern_linker.c to see the sysctl hooks invoked on kldload and kldunload to manage these sysctls. You will probably want to start your debugging in the unload hook as it sounds like the node is not being fully deregistered. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 18:12:14 2010 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 CBCC7106566B for ; Mon, 15 Nov 2010 18:12:14 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id 73DD28FC15 for ; Mon, 15 Nov 2010 18:12:14 +0000 (UTC) Received: by cel.leonerd.org.uk (Postfix, from userid 1000) id 0B2A240A9; Mon, 15 Nov 2010 18:12:12 +0000 (GMT) Date: Mon, 15 Nov 2010 18:12:11 +0000 From: Paul LeoNerd Evans To: John Baldwin Message-ID: <20101115181211.GV11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ii7PBTTHr1LoMMv3" Content-Disposition: inline In-Reply-To: <201011151125.42697.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 18:12:15 -0000 --Ii7PBTTHr1LoMMv3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote: > I think the assumption is that userland actually maintains a reference on= the=20 > specified object (e.g. a file descriptor) and will know to drop the assoc= iated=20 > data when the file descriptor is closed. That is, think of the kevent as= a=20 > member of an eventable object rather than a separate object that has a=20 > reference to the eventable object. When the eventable object's reference= =20 > count drops to zero in userland, then the kevent should be deleted, eithe= r via=20 > EV_DELETE, or implicitly (e.g. by closing the associated file descriptor). Ah. Well, that could be considered a bit more awkward for the use case I wanted to apply. The idea was that the udata would refer effectively to a closure, to invoke when the event happens. The idea being you can just add an event watcher by, say: $ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub { print STDERR "The child process $pid has now exited\n"; } ); So, the kernel's udata pointer effectively holds the only reference to this anonymous closure. It's much more flexible this way, especially for oneshot events like that. The beauty is also that the kevents() loop can simply know that the udata is always a code reference so just has to invoke it to do whatever the original caller wanted to do. Keep in mind my use-case here; I'm not trying to be one specific application, it's a general-purpose kevent-wrapping library. > I think in your case you should not give the kevent a reference to your= =20 > object, but instead remove the associated event for a given object when a= n=20 > object's refcount drops to zero. Well that's certainly doable in longrunning watches, but I don't think it sounds very convenient for a oneshot event; see the above example for justification. Also it again begs my question, worth repeating here: On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote: > I had > thought the point of kqueue/kevent is the O(1) nature of it, which is > among why the kernel is storing that void *udata pointer in the first > place. If I have to store a mapping from every filter+identity back to > my data pointer, why does the kernel store one at all? I could just > ignore the udata field and use my mapping for my own purposes. If you're saying that in my not-so-rare use case, I don't want to be using udata, and instead keeping my own mapping, why does the kernel provide this udata field at all? --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Ii7PBTTHr1LoMMv3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM4Xf7vLS2TC8cBo0RAiWdAJ4xbkjLKNitZgV8rT+4353OFQk08gCg44pu Upnxi26cqde1GFthTj4KiGo= =KwOH -----END PGP SIGNATURE----- --Ii7PBTTHr1LoMMv3-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 18:24:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 242B71065670; Mon, 15 Nov 2010 18:24:09 +0000 (UTC) Date: Mon, 15 Nov 2010 18:24:09 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101115182409.GA97839@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline Subject: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzip 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, 15 Nov 2010 18:24:09 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, any thoughts on this patch? it changes the semantics of gzip so that it is consistent with the semantics of bzip2, xz and for more important GNU gzip. cheers. alex -- a13x --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gzip.c.diff" diff --git a/usr.bin/gzip/gzip.1 b/usr.bin/gzip/gzip.1 index 848a4b3..8eab82c 100644 --- a/usr.bin/gzip/gzip.1 +++ b/usr.bin/gzip/gzip.1 @@ -25,7 +25,7 @@ .\" SUCH DAMAGE. .\" .\" $FreeBSD$ -.Dd April 27, 2010 +.Dd November 15, 2010 .Dt GZIP 1 .Os .Sh NAME @@ -127,9 +127,9 @@ stream, leaving files intact. This option selects decompression rather than compression. .It Fl f , -force This option turns on force mode. -This allows files with multiple links, overwriting of pre-existing -files, reading from or writing to a terminal, and when combined -with the +This allows files with multiple links, symbolic links to regular files, +overwriting of pre-existing files, reading from or writing to a terminal, +and when combined with the .Fl c option, allowing non-compressed data to pass through unchanged. .It Fl h , -help diff --git a/usr.bin/gzip/gzip.c b/usr.bin/gzip/gzip.c index d86e84b..15fcf95 100644 --- a/usr.bin/gzip/gzip.c +++ b/usr.bin/gzip/gzip.c @@ -1781,7 +1781,7 @@ handle_pathname(char *path) } retry: - if (stat(path, &sb) != 0) { + if (fflag && stat(path, &sb) != 0 || fflag == 0 && lstat(path, &sb) != 0) { /* lets try .gz if we're decompressing */ if (dflag && s == NULL && errno == ENOENT) { len = strlen(path); --tThc/1wpZn/ma/RB-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 18:33:25 2010 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 C5AC7106564A; Mon, 15 Nov 2010 18:33:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-8.mx.aerioconnect.net [216.240.47.68]) by mx1.freebsd.org (Postfix) with ESMTP id A4E648FC08; Mon, 15 Nov 2010 18:33:25 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAFIXOcT019146; Mon, 15 Nov 2010 10:33:24 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7719C2D601A; Mon, 15 Nov 2010 10:33:23 -0800 (PST) Message-ID: <4CE17CF5.6050107@freebsd.org> Date: Mon, 15 Nov 2010 10:33:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul LeoNerd Evans References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> In-Reply-To: <20101115181211.GV11110@cel.leo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 18:33:25 -0000 On 11/15/10 10:12 AM, Paul LeoNerd Evans wrote: > On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote: >> I think the assumption is that userland actually maintains a reference on the >> specified object (e.g. a file descriptor) and will know to drop the associated >> data when the file descriptor is closed. That is, think of the kevent as a >> member of an eventable object rather than a separate object that has a >> reference to the eventable object. When the eventable object's reference >> count drops to zero in userland, then the kevent should be deleted, either via >> EV_DELETE, or implicitly (e.g. by closing the associated file descriptor). > Ah. Well, that could be considered a bit more awkward for the use case I > wanted to apply. The idea was that the udata would refer effectively > to a closure, to invoke when the event happens. The idea being you can > just add an event watcher by, say: > > $ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub { > print STDERR "The child process $pid has now exited\n"; > } ); > > So, the kernel's udata pointer effectively holds the only reference to > this anonymous closure. It's much more flexible this way, especially for > oneshot events like that. > > The beauty is also that the kevents() loop can simply know that the > udata is always a code reference so just has to invoke it to do whatever > the original caller wanted to do. > > Keep in mind my use-case here; I'm not trying to be one specific > application, it's a general-purpose kevent-wrapping library. > >> I think in your case you should not give the kevent a reference to your >> object, but instead remove the associated event for a given object when an >> object's refcount drops to zero. > Well that's certainly doable in longrunning watches, but I don't think > it sounds very convenient for a oneshot event; see the above example for > justification. > > Also it again begs my question, worth repeating here: > > On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote: >> I had >> thought the point of kqueue/kevent is the O(1) nature of it, which is >> among why the kernel is storing that void *udata pointer in the first >> place. If I have to store a mapping from every filter+identity back to >> my data pointer, why does the kernel store one at all? I could just >> ignore the udata field and use my mapping for my own purposes. > If you're saying that in my not-so-rare use case, I don't want to be > using udata, and instead keeping my own mapping, why does the kernel > provide this udata field at all? it was provided for pretty much what you are using it for, so that the userland caller could easily associate the returning event with some private information about the event. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 18:38:09 2010 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 C19491065672 for ; Mon, 15 Nov 2010 18:38:09 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7422E8FC16 for ; Mon, 15 Nov 2010 18:38:09 +0000 (UTC) Received: by cel.leonerd.org.uk (Postfix, from userid 1000) id 81A1740A9; Mon, 15 Nov 2010 18:38:08 +0000 (GMT) Date: Mon, 15 Nov 2010 18:38:08 +0000 From: Paul LeoNerd Evans To: Julian Elischer Message-ID: <20101115183807.GW11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oRUqH22/eHvpdsWk" Content-Disposition: inline In-Reply-To: <4CE17CF5.6050107@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 18:38:09 -0000 --oRUqH22/eHvpdsWk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote: > it was provided for pretty much what you are using it for, so that > the userland caller could > easily associate the returning event with some private information > about the event. This was indeed the impression I got. With reference to my original questions regarding its use, perhaps you could suggest some way to actually use this API then, in order to solve my problem? Unless there's some subtle detail or trick I have misunderstood, it doesn't appear to be easily possible in this manner. How would you suggest I manage these pointers and data structures? --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --oRUqH22/eHvpdsWk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM4X4PvLS2TC8cBo0RAigYAKD/LAL95kSQfzoRc0yECjkL9XkFSQCfeUkK I2ubutgoBcn5d46hXq9cSs0= =C9QV -----END PGP SIGNATURE----- --oRUqH22/eHvpdsWk-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 19:11:34 2010 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 EED46106564A for ; Mon, 15 Nov 2010 19:11:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B11598FC20 for ; Mon, 15 Nov 2010 19:11:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3E80E46B5B; Mon, 15 Nov 2010 14:11:33 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 402F38A009; Mon, 15 Nov 2010 14:11:32 -0500 (EST) From: John Baldwin To: Paul LeoNerd Evans Date: Mon, 15 Nov 2010 14:10:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> In-Reply-To: <20101115181211.GV11110@cel.leo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011151410.46130.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 15 Nov 2010 14:11:32 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 19:11:34 -0000 On Monday, November 15, 2010 1:12:11 pm Paul LeoNerd Evans wrote: > On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote: > > I think the assumption is that userland actually maintains a reference on the > > specified object (e.g. a file descriptor) and will know to drop the associated > > data when the file descriptor is closed. That is, think of the kevent as a > > member of an eventable object rather than a separate object that has a > > reference to the eventable object. When the eventable object's reference > > count drops to zero in userland, then the kevent should be deleted, either via > > EV_DELETE, or implicitly (e.g. by closing the associated file descriptor). > > Ah. Well, that could be considered a bit more awkward for the use case I > wanted to apply. The idea was that the udata would refer effectively > to a closure, to invoke when the event happens. The idea being you can > just add an event watcher by, say: > > $ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub { > print STDERR "The child process $pid has now exited\n"; > } ); > > So, the kernel's udata pointer effectively holds the only reference to > this anonymous closure. It's much more flexible this way, especially for > oneshot events like that. > > The beauty is also that the kevents() loop can simply know that the > udata is always a code reference so just has to invoke it to do whatever > the original caller wanted to do. > > Keep in mind my use-case here; I'm not trying to be one specific > application, it's a general-purpose kevent-wrapping library. So is GCD (Apple's libdispatch). It also implements closures on top of kevent. However, the way it works is that it doesn't expose kevent() directly, instead it uses kevent to implement asynchronous I/O on a socket for example, and since it is logically managing the life cycle of a socket, it knows when the socket is closed and cleans up then. > > I think in your case you should not give the kevent a reference to your > > object, but instead remove the associated event for a given object when an > > object's refcount drops to zero. > > Well that's certainly doable in longrunning watches, but I don't think > it sounds very convenient for a oneshot event; see the above example for > justification. For the above case, if you know an event is one shot, you should either use EV_ONESHOT, or use a wrapper around the closure that clears the event after the closure runs (or possibly before the closure runs?) > Also it again begs my question, worth repeating here: > > On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote: > > I had > > thought the point of kqueue/kevent is the O(1) nature of it, which is > > among why the kernel is storing that void *udata pointer in the first > > place. If I have to store a mapping from every filter+identity back to > > my data pointer, why does the kernel store one at all? I could just > > ignore the udata field and use my mapping for my own purposes. > > If you're saying that in my not-so-rare use case, I don't want to be > using udata, and instead keeping my own mapping, why does the kernel > provide this udata field at all? Your use case is rare. Almost all consumers of kevent() that I've seen use kevent() as one part of a system that maintain the lifecycle of objects. Those objects are only accessed within the system, so the system knows when an object is closed and can release the resources at the same time. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 19:24:45 2010 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 A58AB1065672; Mon, 15 Nov 2010 19:24:45 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id 479928FC27; Mon, 15 Nov 2010 19:24:45 +0000 (UTC) Received: by cel.leonerd.org.uk (Postfix, from userid 1000) id 0FFF340AA; Mon, 15 Nov 2010 19:24:43 +0000 (GMT) Date: Mon, 15 Nov 2010 19:24:43 +0000 From: Paul LeoNerd Evans To: John Baldwin Message-ID: <20101115192443.GX11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <201011151410.46130.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VLyqDKa+9yql3vk0" Content-Disposition: inline In-Reply-To: <201011151410.46130.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 19:24:45 -0000 --VLyqDKa+9yql3vk0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 02:10:45PM -0500, John Baldwin wrote: > On Monday, November 15, 2010 1:12:11 pm Paul LeoNerd Evans wrote: > > On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote: > > > I think the assumption is that userland actually maintains a referenc= e on the=20 > > > specified object (e.g. a file descriptor) and will know to drop the a= ssociated=20 > > > data when the file descriptor is closed. That is, think of the keven= t as a=20 > > > member of an eventable object rather than a separate object that has = a=20 > > > reference to the eventable object. When the eventable object's refer= ence=20 > > > count drops to zero in userland, then the kevent should be deleted, e= ither via=20 > > > EV_DELETE, or implicitly (e.g. by closing the associated file descrip= tor). > >=20 > > Ah. Well, that could be considered a bit more awkward for the use case I > > wanted to apply. The idea was that the udata would refer effectively > > to a closure, to invoke when the event happens. The idea being you can > > just add an event watcher by, say: > >=20 > > $ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub { > > print STDERR "The child process $pid has now exited\n"; > > } ); > >=20 > > So, the kernel's udata pointer effectively holds the only reference to > > this anonymous closure. It's much more flexible this way, especially for > > oneshot events like that. > >=20 > > The beauty is also that the kevents() loop can simply know that the > > udata is always a code reference so just has to invoke it to do whatever > > the original caller wanted to do. > >=20 > > Keep in mind my use-case here; I'm not trying to be one specific > > application, it's a general-purpose kevent-wrapping library. >=20 > So is GCD (Apple's libdispatch). It also implements closures on top of > kevent. However, the way it works is that it doesn't expose kevent() > directly, instead it uses kevent to implement asynchronous I/O on a=20 > socket for example, and since it is logically managing the life cycle > of a socket, it knows when the socket is closed and cleans up then. Well, the principle item of work here is a direct API reimplementation in IO::KQueue on CPAN. I'm trying to simply expose the API of storing an arbitrary Perl scalar in the udata field. It -could- be a closure, but of course it doesn't have to. Maybe the using code wants to keep a HASH ref of some pseudo-structure, or whatever... > For the above case, if you know an event is one shot, you should either > use EV_ONESHOT, or use a wrapper around the closure that clears the event > after the closure runs (or possibly before the closure runs?) I don't see how passing EV_ONESHOT at all helps here. If it's oneshot by nature (child process exit), it'll be oneshot whatever happens. I've already observed that the EV_ONESHOT flag does not get re-emitted by the kernel anyway, so I'd have to track that one separately somehow. > Your use case is rare. Almost all consumers of kevent() that I've seen > use kevent() as one part of a system that maintain the lifecycle of objec= ts. > Those objects are only accessed within the system, so the system knows wh= en > an object is closed and can release the resources at the same time. OK. I'm prepared to accept this. It may be that nobody's really tried to provide a simple kqueue/kevent API wrapping for a high-level language, that could nicely take advantage of memory management in the language, rather than at the low C level of explicit malloc+free. Could we perhaps address the second part of my question for a moment? If there really isn't a general solution here, could my EV_FREEWATCH flag be added? It's a single extra flag to export in the API .h file, completely backward-compatible. Surely quite simple to implement in the kernel too, because it already knows how to free() its own internal structures anyway; so just before it does that when it deletes an event for whatever reason, it could just fire that event back up to userland to say "I've dropped this, and here have your pointer back". Userland catches it, SvRECFNT_dec()s or whatever, problem solved. Is that an API extension anyone would consider accepting? I for one would use it. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --VLyqDKa+9yql3vk0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM4Yj7vLS2TC8cBo0RAoI0AKCvJS0Kd/f/+NEcRm39wbLJEA7J3wCbBLjm dJVDke7vE7mOeDH9LH0znYk= =8T/B -----END PGP SIGNATURE----- --VLyqDKa+9yql3vk0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 19:37:23 2010 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 2C89C1065674 for ; Mon, 15 Nov 2010 19:37:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-9.mx.aerioconnect.net [216.240.47.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB818FC1B for ; Mon, 15 Nov 2010 19:37:22 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAFJbM5v022445; Mon, 15 Nov 2010 11:37:22 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id BAD852D6019; Mon, 15 Nov 2010 11:37:21 -0800 (PST) Message-ID: <4CE18BF3.4080301@freebsd.org> Date: Mon, 15 Nov 2010 11:37:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul LeoNerd Evans References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo> In-Reply-To: <20101115183807.GW11110@cel.leo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 19:37:23 -0000 On 11/15/10 10:38 AM, Paul LeoNerd Evans wrote: > On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote: >> it was provided for pretty much what you are using it for, so that >> the userland caller could >> easily associate the returning event with some private information >> about the event. > This was indeed the impression I got. With reference to my original > questions regarding its use, perhaps you could suggest some way to > actually use this API then, in order to solve my problem? > > Unless there's some subtle detail or trick I have misunderstood, it > doesn't appear to be easily possible in this manner. > > How would you suggest I manage these pointers and data structures? > I don't think it was thought of in the context of reference counted items. you could use an ever increasing number that you hash on a hash table. if the kernel returns a number that is out of date you won't find it and you can ignore it. If the kernel returns a number you are currently tracking. then you use the item associated with that entry. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 20:04:06 2010 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 5B2F31065675 for ; Mon, 15 Nov 2010 20:04:06 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED928FC12 for ; Mon, 15 Nov 2010 20:04:05 +0000 (UTC) Received: by iwn39 with SMTP id 39so7140451iwn.13 for ; Mon, 15 Nov 2010 12:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=h8WrFI91YtjKIUoHKvIrD0fxmWmm5C59GIaYsXud1dw=; b=SkMnRIQLkkkQJhrsWeMkc204or+7ZF6Cl8JbFFQyGdqPQOmJPQEZ+ypYhKFeLgBK5S NTQTTLgmW6WEjprp2xIV/77eml+oTC0TyzkrDbqLgePhaTrDY6CpNt7PRtPKR6OJcI8/ RdVpBEUfqmPsLggn5MqtW7tXHH0d9UPX5AoYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dkAZ/zHLo3G7FX+4vFkKFU/pVjy+EA7bC4j4keuFs7NoPYl/F1TZJIvVvBFhhLr5ol IbznwRQymcAfLMaIM7NMl9XJfkks7azMlMu/2iuJMIhaI8bnwOK300VIgT3e3jDJqBnT qmPa/fpMCUbBMKSYZ1XAAczBCSzh7NClLdtao= MIME-Version: 1.0 Received: by 10.231.156.139 with SMTP id x11mr4941951ibw.22.1289850016358; Mon, 15 Nov 2010 11:40:16 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Mon, 15 Nov 2010 11:40:16 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Nov 2010 11:40:16 -0800 X-Google-Sender-Auth: SkqCyk-c3rgdlaWjCo1ff5sxjqc Message-ID: From: mdf@FreeBSD.org To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Phantom sysctl 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, 15 Nov 2010 20:04:06 -0000 On Mon, Nov 15, 2010 at 9:53 AM, Garrett Cooper wrote: > =A0 =A0According to SYSCTL_INT(9): > > =A0 =A0 The SYSCTL kernel interfaces allow code to statically declare sys= ctl(8) > =A0 =A0 MIB entries, which will be initialized when the kernel module con= taining > =A0 =A0 the declaration is initialized. =A0When the module is unloaded, t= he sysctl > =A0 =A0 will be automatically destroyed. > > =A0 =A0The sysctl should be reaped when the module is unloaded. My dumb > test kernel module [1] doesn't seem to do that though (please note > that the OID test_int_sysctl is created, and not reaped... FWIW it's > kind of bizarre that test_int_sysctl is created in the first place, > given what I've seen when SYSCTL_* gets executed): > > toaster# kldload ./test_int_sysctl.ko > toaster# sysctl -a | grep test > test_int_sysctl: 0 > vfs.nfs_common.realign_test: 0 > debug.test_int_sysctl: 0 > toaster# sysctl test_int_sysctl > sysctl: unknown oid 'test_int_sysctl' > toaster# kldunload ./test_int_sysctl.ko > toaster# sysctl -a | grep test > test_int_sysctl: 0 > vfs.nfs_common.realign_test: 0 debug.test_int_sysctl did disappear, and that was the sysctl in the module: SYSCTL_INT(_debug, OID_AUTO, test_int_sysctl, CTLFLAG_RW, &_sysctl, 0, "Test sysctl OID"); I am not sure where the other test_int_sysctl appeared from, but the results of "sysctl test_int_sysctl" didn't change from before kldunload to after. Thanks, matthew > toaster# sysctl test_int_sysctl > sysctl: unknown oid 'test_int_sysctl' > > =A0 =A0I've seen this behavior on 8.1-RELEASE (custom kernel, vanilla > sources), and CURRENT r215254. > =A0 =A0I'm compiling the kernel with SYSCTL_DEBUG (and added some missing > error checking in the kern_sysctl.c code) to see if I can track down > the resource issue, but in the meantime if someone more knowledgeable > has some suggestions for what to do / where I should look, I'm all > ears. > Thanks! > -Garrett > > 1. http://pastebin.com/n7d9bH8U > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 20:14:47 2010 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 BEE15106564A; Mon, 15 Nov 2010 20:14:47 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id 75EEA8FC0C; Mon, 15 Nov 2010 20:14:47 +0000 (UTC) Received: by cel.leonerd.org.uk (Postfix, from userid 1000) id 7AA8C40A9; Mon, 15 Nov 2010 20:14:46 +0000 (GMT) Date: Mon, 15 Nov 2010 20:14:46 +0000 From: Paul LeoNerd Evans To: Julian Elischer Message-ID: <20101115201445.GY11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo> <4CE18BF3.4080301@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0gFD7xD8qWl5Ra4" Content-Disposition: inline In-Reply-To: <4CE18BF3.4080301@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 20:14:47 -0000 --y0gFD7xD8qWl5Ra4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 11:37:23AM -0800, Julian Elischer wrote: > I don't think it was thought of in the context of reference counted items. This problem has nothing to do with reference counting, and all to do with resource ownership. Consider in the totally C-based world, no refcounts, just malloc() and free(). You malloc() some event structure, put it in the udata field to the kernel, then return to the main run loop. You've dropped every reference to this malloc()ed memory, because hey, kernel has it. Later, event fires, kernel gives you back that pointer. Great. Lets use it. Was it a PROC|EXIT event? Lets free() the data. Was it an event that had been registered as EV_ONESHOT? Oops. We can't remember because kernel didn't tell us. Want to EV_DELETE it now? Can't, lost the pointer, can't ask kernel for it back. Want to close() the filehandle associated? Can't, because kernel has pointer that it'll drop. In all these cases we'll memory leak the malloc()ed data. The only solution here is to keep another copy somewhere up in userland. This copy has to be associated with the original filter specification, so that on EV_DELETE we know the pointer so can free() it. But, as I said, if we're going to keep that mapping, why does the kernel even give us this udata ability in the first place? We might as well not bother and use the mapping all the time. Maybe this just is what people do? That was the thrust of my first question - _is_ this what people do? I'm not experienced enough with kqueue to know what is best practice here, and the documentation gives no guidance. Can someone advise me? --- Totally separate to that, if nobody has really thought of a solution to this before, what are anyone's thoughts on my suggestion of the EV_FREEWATCH flag? Get the kernel always to tell userland that it has dropped a watch, and return the pointer back, so userland can do whatever it wants by way of resource reclaimation. > you could use an ever increasing number that you hash on a hash table. > if the kernel returns a number that is out of date you won't find it > and you > can ignore it. If the kernel returns a number you are currently tracking. > then you use the item associated with that entry. I'm really not sure I understand where this is going, or how it helps me... --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --y0gFD7xD8qWl5Ra4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM4ZS1vLS2TC8cBo0RAjNsAKC4z14t0dAjdGv+soid67Z0A036iwCbB9bJ sBzFKjy4sf/nZ5uGmnQnPqU= =dwSI -----END PGP SIGNATURE----- --y0gFD7xD8qWl5Ra4-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 20:51:57 2010 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 53674106566C for ; Mon, 15 Nov 2010 20:51:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-10.mx.aerioconnect.net [216.240.47.70]) by mx1.freebsd.org (Postfix) with ESMTP id 331F18FC1A for ; Mon, 15 Nov 2010 20:51:56 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAFKpuB2027808; Mon, 15 Nov 2010 12:51:56 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id A9BBB2D6012; Mon, 15 Nov 2010 12:51:55 -0800 (PST) Message-ID: <4CE19D6D.7000201@freebsd.org> Date: Mon, 15 Nov 2010 12:51:57 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul LeoNerd Evans References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo> <4CE18BF3.4080301@freebsd.org> <20101115201445.GY11110@cel.leo> In-Reply-To: <20101115201445.GY11110@cel.leo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 20:51:57 -0000 On 11/15/10 12:14 PM, Paul LeoNerd Evans wrote: > On Mon, Nov 15, 2010 at 11:37:23AM -0800, Julian Elischer wrote: >> I don't think it was thought of in the context of reference counted items. > This problem has nothing to do with reference counting, and all to do > with resource ownership. > > Consider in the totally C-based world, no refcounts, just malloc() and > free(). You malloc() some event structure, put it in the udata field to > the kernel, then return to the main run loop. You've dropped every > reference to this malloc()ed memory, because hey, kernel has it. Later, > event fires, kernel gives you back that pointer. Great. Lets use it. Was > it a PROC|EXIT event? Lets free() the data. > > Was it an event that had been registered as EV_ONESHOT? Oops. We can't > remember because kernel didn't tell us. > > Want to EV_DELETE it now? Can't, lost the pointer, can't ask kernel for > it back. > > Want to close() the filehandle associated? Can't, because kernel has > pointer that it'll drop. > > In all these cases we'll memory leak the malloc()ed data. > > The only solution here is to keep another copy somewhere up in userland. > This copy has to be associated with the original filter specification, > so that on EV_DELETE we know the pointer so can free() it. But, as I > said, if we're going to keep that mapping, why does the kernel even give > us this udata ability in the first place? We might as well not bother > and use the mapping all the time. > > Maybe this just is what people do? That was the thrust of my first > question - _is_ this what people do? I'm not experienced enough with > kqueue to know what is best practice here, and the documentation gives > no guidance. Can someone advise me? > > --- > > Totally separate to that, if nobody has really thought of a solution to > this before, what are anyone's thoughts on my suggestion of the > EV_FREEWATCH flag? Get the kernel always to tell userland that it has > dropped a watch, and return the pointer back, so userland can do > whatever it wants by way of resource reclaimation. > > > >> you could use an ever increasing number that you hash on a hash table. >> if the kernel returns a number that is out of date you won't find it >> and you >> can ignore it. If the kernel returns a number you are currently tracking. >> then you use the item associated with that entry. > I'm really not sure I understand where this is going, or how it helps "keep more information associated with each kevent and use the user cookie to match them" this is what it was for. it's a tool, not an answer. Given this tool you should be able to get what you want. how you do it is your job. It's not the kernel's job to keep application specific data for you.. but it gives you a way to do it yourself and keep track of it trivially. It's expected that for every event the user gives to the kernel, he has some matching information about that event in userland. > me... > From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 20:54:05 2010 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 CE8391065670; Mon, 15 Nov 2010 20:54:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id AFFD28FC0A; Mon, 15 Nov 2010 20:54:04 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 78372A69B77; Tue, 16 Nov 2010 04:54:00 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id j6+OqFTutihs; Tue, 16 Nov 2010 04:53:53 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8F1E5A69B6B; Tue, 16 Nov 2010 04:53:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=KFmKX11Gh1hxEg/j9SzBya5fK7OuBVhgKNYlDDtix7be8DCv6AFlvvW1hQv2/UQHF iJYEeGN7kCrGFwsWM6wjg== Message-ID: <4CE19DDD.3070105@delphij.net> Date: Mon, 15 Nov 2010 12:53:49 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Alexander Best References: <20101115182409.GA97839@freebsd.org> In-Reply-To: <20101115182409.GA97839@freebsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzip X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 20:54:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 11/15/10 10:24, Alexander Best wrote: > hi there, > > any thoughts on this patch? it changes the semantics of gzip so that it is > consistent with the semantics of bzip2, xz and for more important GNU gzip. Could you please elaborate more about the GNU gzip behavior? By the way I also found some difference between BSD gzip and GNU gzip: touch foo ln -s foo.nonexistent foo.gz gzip foo gzip: could not create output: foo.gz: File exists /usr/local/bin/gzip foo gzip: foo.gz already exists; do you wish to overwrite (y or n)? ^C (case 1) echo | /usr/local/bin/gzip foo gzip: foo.gz already exists; not overwritten gzip -f foo gzip: could not create output: foo.gz: File exists /usr/local/bin/gzip -f foo (succeeded; case 2). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM4Z3cAAoJEATO+BI/yjfBLGoIAKcvx+bH6L0pJqLSv34bii6G 1FwXmPQqeIs+B5K8wNMmWblWLidJc2xkXxFCdJKsoZmgS6Hcakg6r1CzZ7tkjMAP CqYMG3cgkCiqZpgZ8QY3E3tmdxMqYk3EyII+TUv2xSNvUp8A7TPvC2vwS1eD3GzO OACbH/ULSJ30iMXi/A6nPkvEWesuExGplfpzzfJ0yCySKj/3HyXV87HxVw46LFYj XsG3F7WWUkVrIzCFGLgaN0ULRZlz30Fq4ODnm4sAnUJQx0hzHGUDmYkgLxqh50t5 AN81GC06I6XZttqIaM1FNm5Dp27Vh6uVfYd21lJ+g5ee5kXM6Fd03jSJOqZJiro= =QEEo -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 21:22:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F25CB106566B; Mon, 15 Nov 2010 21:22:38 +0000 (UTC) Date: Mon, 15 Nov 2010 21:22:38 +0000 From: Alexander Best To: d@delphij.net Message-ID: <20101115212238.GA28376@freebsd.org> References: <20101115182409.GA97839@freebsd.org> <4CE19DDD.3070105@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE19DDD.3070105@delphij.net> Cc: freebsd-hackers@freebsd.org Subject: Re: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzip 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, 15 Nov 2010 21:22:39 -0000 On Mon Nov 15 10, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > On 11/15/10 10:24, Alexander Best wrote: > > hi there, > > > > any thoughts on this patch? it changes the semantics of gzip so that it is > > consistent with the semantics of bzip2, xz and for more important GNU gzip. > > Could you please elaborate more about the GNU gzip behavior? sure! ***START LINUX*** otaku% gzip --version gzip 1.4 Copyright (C) 2007 Free Software Foundation, Inc. Copyright (C) 1993 Jean-loup Gailly. This is free software. You may redistribute copies of it under the terms of the GNU General Public License . There is NO WARRANTY, to the extent permitted by law. Written by Jean-loup Gailly. otaku% echo "AAAAA" > FILE1 otaku% ln -s FILE1 FILE2 otaku% gzip FILE2 gzip: FILE2: Too many links otaku% gzip --force FILE2 otaku% file FILE2.gz FILE2.gz: gzip compressed data, was "FILE2", from Unix, last modified: Mon Nov 15 21:09:03 2010 ***END LINUX*** ***START BSD*** otaku% gzip --version FreeBSD gzip 20100407 otaku% echo "AAAAA" > FILE1 otaku% ln -s FILE1 FILE2 otaku% gzip FILE2 otaku% file FILE2.gz FILE2.gz: gzip compressed data, was "FILE2", from Unix, last modified: Mon Nov 15 22:12:21 2010 **END BSD*** ***START BSD WITH PATCH*** otaku% gzip --version FreeBSD gzip 20100407 otaku% echo "AAAAA" > FILE1 otaku% ln -s FILE1 FILE2 otaku% gzip FILE2 gzip: FILE2 is not a regular file otaku% gzip --force FILE2 otaku% file FILE2.gz FILE2.gz: gzip compressed data, was "FILE2", from Unix, last modified: Mon Nov 15 22:17:11 2010 **END BSD WITH PATCH*** > > By the way I also found some difference between BSD gzip and GNU gzip: > > touch foo > ln -s foo.nonexistent foo.gz > > gzip foo > gzip: could not create output: foo.gz: File exists > > /usr/local/bin/gzip foo > gzip: foo.gz already exists; do you wish to overwrite (y or n)? ^C > (case 1) > > echo | /usr/local/bin/gzip foo > gzip: foo.gz already exists; not overwritten > > gzip -f foo > gzip: could not create output: foo.gz: File exists > > /usr/local/bin/gzip -f foo > (succeeded; case 2). > > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (FreeBSD) > > iQEcBAEBCAAGBQJM4Z3cAAoJEATO+BI/yjfBLGoIAKcvx+bH6L0pJqLSv34bii6G > 1FwXmPQqeIs+B5K8wNMmWblWLidJc2xkXxFCdJKsoZmgS6Hcakg6r1CzZ7tkjMAP > CqYMG3cgkCiqZpgZ8QY3E3tmdxMqYk3EyII+TUv2xSNvUp8A7TPvC2vwS1eD3GzO > OACbH/ULSJ30iMXi/A6nPkvEWesuExGplfpzzfJ0yCySKj/3HyXV87HxVw46LFYj > XsG3F7WWUkVrIzCFGLgaN0ULRZlz30Fq4ODnm4sAnUJQx0hzHGUDmYkgLxqh50t5 > AN81GC06I6XZttqIaM1FNm5Dp27Vh6uVfYd21lJ+g5ee5kXM6Fd03jSJOqZJiro= > =QEEo > -----END PGP SIGNATURE----- -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 21:29:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9328D106566B; Mon, 15 Nov 2010 21:29:59 +0000 (UTC) Date: Mon, 15 Nov 2010 21:29:59 +0000 From: Alexander Best To: d@delphij.nety Message-ID: <20101115212959.GA30608@freebsd.org> References: <20101115182409.GA97839@freebsd.org> <4CE19DDD.3070105@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE19DDD.3070105@delphij.net> Cc: freebsd-hackers@freebsd.org Subject: Re: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzipy 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, 15 Nov 2010 21:29:59 -0000 On Mon Nov 15 10, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > On 11/15/10 10:24, Alexander Best wrote: > > hi there, > > > > any thoughts on this patch? it changes the semantics of gzip so that it is > > consistent with the semantics of bzip2, xz and for more important GNU gzip. > > Could you please elaborate more about the GNU gzip behavior? > > By the way I also found some difference between BSD gzip and GNU gzip: > > touch foo > ln -s foo.nonexistent foo.gz > > gzip foo > gzip: could not create output: foo.gz: File exists > > /usr/local/bin/gzip foo > gzip: foo.gz already exists; do you wish to overwrite (y or n)? ^C > (case 1) ^^ confirmed! > > echo | /usr/local/bin/gzip foo > gzip: foo.gz already exists; not overwritten ^^ this is only the GNU output. however bsd gzip seems to behave the same > > gzip -f foo > gzip: could not create output: foo.gz: File exists > > /usr/local/bin/gzip -f foo > (succeeded; case 2). ^^ confirmed! it appears the designers of BSD gzip did not take symbolic links into account. cheers. alex > > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (FreeBSD) > > iQEcBAEBCAAGBQJM4Z3cAAoJEATO+BI/yjfBLGoIAKcvx+bH6L0pJqLSv34bii6G > 1FwXmPQqeIs+B5K8wNMmWblWLidJc2xkXxFCdJKsoZmgS6Hcakg6r1CzZ7tkjMAP > CqYMG3cgkCiqZpgZ8QY3E3tmdxMqYk3EyII+TUv2xSNvUp8A7TPvC2vwS1eD3GzO > OACbH/ULSJ30iMXi/A6nPkvEWesuExGplfpzzfJ0yCySKj/3HyXV87HxVw46LFYj > XsG3F7WWUkVrIzCFGLgaN0ULRZlz30Fq4ODnm4sAnUJQx0hzHGUDmYkgLxqh50t5 > AN81GC06I6XZttqIaM1FNm5Dp27Vh6uVfYd21lJ+g5ee5kXM6Fd03jSJOqZJiro= > =QEEo > -----END PGP SIGNATURE----- -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 21:32:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5F7B11065673; Mon, 15 Nov 2010 21:32:34 +0000 (UTC) Date: Mon, 15 Nov 2010 21:32:34 +0000 From: Alexander Best To: d@delphij.net Message-ID: <20101115213234.GA32320@freebsd.org> References: <20101115182409.GA97839@freebsd.org> <4CE19DDD.3070105@delphij.net> <20101115212959.GA30608@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101115212959.GA30608@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: changing gzip's symlink handling to be consistent with bzip2, xz and GNU gzip 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, 15 Nov 2010 21:32:35 -0000 On Mon Nov 15 10, Alexander Best wrote: > On Mon Nov 15 10, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Hi, > > > > On 11/15/10 10:24, Alexander Best wrote: > > > hi there, > > > > > > any thoughts on this patch? it changes the semantics of gzip so that it is > > > consistent with the semantics of bzip2, xz and for more important GNU gzip. > > > > Could you please elaborate more about the GNU gzip behavior? > > > > By the way I also found some difference between BSD gzip and GNU gzip: > > > > touch foo > > ln -s foo.nonexistent foo.gz > > > > gzip foo > > gzip: could not create output: foo.gz: File exists > > > > /usr/local/bin/gzip foo > > gzip: foo.gz already exists; do you wish to overwrite (y or n)? ^C > > (case 1) > > ^^ confirmed! > > > > echo | /usr/local/bin/gzip foo > > gzip: foo.gz already exists; not overwritten > > ^^ this is only the GNU output. however bsd gzip seems to behave the same > > > > gzip -f foo > > gzip: could not create output: foo.gz: File exists > > > > /usr/local/bin/gzip -f foo > > (succeeded; case 2). > > ^^ confirmed! > > it appears the designers of BSD gzip did not take symbolic links into account. > sorry i messed up the subject line and your mail address in my previous message. i've fixed it in this one. cheers. alex > cheers. > alex > > > > > > > Cheers, > > - -- > > Xin LI http://www.delphij.net/ > > FreeBSD - The Power to Serve! Live free or die > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.16 (FreeBSD) > > > > iQEcBAEBCAAGBQJM4Z3cAAoJEATO+BI/yjfBLGoIAKcvx+bH6L0pJqLSv34bii6G > > 1FwXmPQqeIs+B5K8wNMmWblWLidJc2xkXxFCdJKsoZmgS6Hcakg6r1CzZ7tkjMAP > > CqYMG3cgkCiqZpgZ8QY3E3tmdxMqYk3EyII+TUv2xSNvUp8A7TPvC2vwS1eD3GzO > > OACbH/ULSJ30iMXi/A6nPkvEWesuExGplfpzzfJ0yCySKj/3HyXV87HxVw46LFYj > > XsG3F7WWUkVrIzCFGLgaN0ULRZlz30Fq4ODnm4sAnUJQx0hzHGUDmYkgLxqh50t5 > > AN81GC06I6XZttqIaM1FNm5Dp27Vh6uVfYd21lJ+g5ee5kXM6Fd03jSJOqZJiro= > > =QEEo > > -----END PGP SIGNATURE----- > > -- > a13x -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 22:20:08 2010 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 75EE010656A7 for ; Mon, 15 Nov 2010 22:20:08 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id E18778FC27 for ; Mon, 15 Nov 2010 22:20:07 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAFM8JEM039518 for ; Mon, 15 Nov 2010 23:08:19 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAFM8HAs039515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Nov 2010 23:08:17 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Mon, 15 Nov 2010 23:08:14 +0100 (CET) From: Joerg Pulz To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mailhost.frm2.tum.de [129.187.179.12]); Mon, 15 Nov 2010 23:08:17 +0100 (CET) Subject: [CFT+RFC] patch to buildworld with heimdal from ports 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, 15 Nov 2010 22:20:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, after the security/heimdal port was updated to the current heimdal release and i added one missing function from base it is now possible to completely buildworld src/ using the port for all Kerberos5/GSSAPI enabled parts. The patches for src/ are here: ftp://ftp.frm2.tum.de/pub/jpulz/FreeBSD/patches/CURRENT_use_kerberos_port.patch ftp://ftp.frm2.tum.de/pub/jpulz/FreeBSD/patches/8-STABLE_use_kerberos_port.patch ftp://ftp.frm2.tum.de/pub/jpulz/FreeBSD/patches/8.1-RELENG_use_kerberos_port.patch Here are the necessary steps - - install security/heimdal - - download the patch - - cd /usr/src && patch -p0 < patchfile - - add WITH_KERBEROS_PORT=1 to /etc/src.conf - - add HEIMDAL_HOME= (usually /usr/local) to /etc/make.conf - - make buildworld as usual To get a clean system you should add WITHOUT_KERBEROS=1 to /etc/src.conf otherwise you will still build and install the base Kerberos5/GSSAPI implementation. If you decide to add this to /etc/src.conf, don't forget to run 'make delete-old delete-old-libs' to get rid of all the old stuff. If you try this on 8-STABLE or 8.1-RELENG there will still be leftovers but as soon as tools/build/mk/OptionalObsoleteFiles.inc gets MFC'd it should at least on 8-STABLE no longer be a problem. There is one drawback. As the port installs no 32bit libraries on amd64 or powerpc64 there is no chance to build and install the following 32bit compat libraries: librpcsec_gss, pam_krb5, pam_ksu. The 32bit libssh will be build and installed but without Kerberos5/GSSAPI support. You should rebuild all ports which make use of the base Kerberos5/GSSAPI libraries. See ports/152029 and ports/152071 for additional ports related patches. I use all this stuff on several machines right now and didn't found any problem, it rather solved the problems i had with the broken stuff in base, especially OpenLDAP with Cyrus-Sasl or Cyrus-Imapd and so on. So everyone, please test and comment as i would really like to see this functionality in base to provide people with an easy to use solution to work around the old and partially broken Kerberos5/GSSAPI stuff in base. Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM4a9RSPOsGF+KA+MRAgnFAJ9s26Insh0AJkxCBgSsEALrMuN5nQCgyxYL fUNRYFwA+t+ozBF2U74uYhY= =aKfM -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 23:22:49 2010 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 79371106567A; Mon, 15 Nov 2010 23:22:49 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [81.187.167.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7678FC15; Mon, 15 Nov 2010 23:22:48 +0000 (UTC) Received: by cel.leonerd.org.uk (Postfix, from userid 1000) id D800F40AA; Mon, 15 Nov 2010 23:22:47 +0000 (GMT) Date: Mon, 15 Nov 2010 23:22:47 +0000 From: Paul LeoNerd Evans To: Julian Elischer Message-ID: <20101115232247.GZ11110@cel.leo> References: <20101112184000.GS11110@cel.leo> <201011151125.42697.jhb@freebsd.org> <20101115181211.GV11110@cel.leo> <4CE17CF5.6050107@freebsd.org> <20101115183807.GW11110@cel.leo> <4CE18BF3.4080301@freebsd.org> <20101115201445.GY11110@cel.leo> <4CE19D6D.7000201@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IQJU2WPwyEuShvbf" Content-Disposition: inline In-Reply-To: <4CE19D6D.7000201@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent 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, 15 Nov 2010 23:22:49 -0000 --IQJU2WPwyEuShvbf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 12:51:57PM -0800, Julian Elischer wrote: > "keep more information associated with each kevent and use the user > cookie to > match them" this is what it was for. > it's a tool, not an answer. Given this tool you should be able to > get what you want. > how you do it is your job. OK. Then I am not seeing it. I would love to seen an example, if you or anyone else could provide me one, on how I am supposed to use this feature. That would be great... but please read below first. > It's not the kernel's job to keep application specific data for > you.. but it gives you a way > to do it yourself and keep track of it trivially. > It's expected that for every event the user gives to the kernel, he > has some matching > information about that event in userland. Sure. The information I keep in userland is in the structure at the end of that udata pointer. Since you claim it to be so trivial then, I would like to ask you to explain it. It should be quite a simple task: --- Demonstrate me a program that, on receipt of -any- event out of the kqueue file descriptor, can print the word "FREE\n" when the kernel has now dropped its side of the watcher, for this event. Specifically, it has to print "FREE\n" in any of the following four conditions: 1. After a final event, such as EVFILT_PROC,NOTE_EXIT 2. After any event that had been registered with EV_ONESHOT 3. After the user has called EV_SET(..., EV_DELETE,...) on it 4. After calling close(fd) on a filehandle that has been registered under EVFILT_READ or EVFILT_WRITE --- I am claiming that such a program cannot be written, using the current kqueue interface, and simply allowing the user code to call EV_SET however they like and put their own pointers in it. If I read your assertion of triviallity correctly, then you are claiming that such a program is indeed possible. I would therefore invite you to demonstrate for me such a program. If perhaps this does indeed prove to be impossible, I would like instead you to demonstate a program having all the above properties, but allowing you to arbitrarily wrap the kqueue API; store extra data in my structures, or hook extra information around EV_SET calls. I have already demonstrated -a- way to solve this, by storing data in the event udata structure to answer 2, and storing a full mapping from ident+filter to udata pointer, to answer 3. I declare 1 trivial by inspection of the results in the returned kevent. I declare 4 to be impossible short of such hackery as LD_PRELOAD around the actual close() libc function. In short, I claim that a solution to all parts 1-4 is impossible. It is possible to solve 1-3 only, by storing a full mapping from ident+filter to udata pointer, in userland. But then by doing that why bother giving the pointer to the kernel in the first place? There comes a further complication for a wrapping library that tries to provide a generic interface around kqueue, for problem 1 however. Right now, the following function could be said to implement problem 1: int is_final(struct kevent *ev) { switch(ev->filter) { case EVFILT_READ: case EVFILT_WRITE: return ev->flags & EV_EOF; case EVFILT_VNODE: return ev->fflags & (NOTE_DELETE|NOTE_REVOKE); /* I'm only guessing on this one from reading the docs, I'm not * 100% sure */ case EVFILT_PROC: return ev->fflags & NOTE_EXIT; default: return 0; } } And in fact even this code isn't perfect, because the kqueue(2) manpage does also point out that EV_EOF on a pipe/fifo isn't final, because you can EV_CLEAR to reset the EOF condition and wait again. So maybe this code ought to read: case EVFILT_READ: case EVFILT_WRITE: { struct stat st; fstat(ev->ident, &st); return (ev->flags & EV_EOF) && !(S_ISFIFO(st.st_mode)); } And so now we suddenly have to make an fstat() call -every- time we receive an event on a read/write filter? OK well clearly not, we'd in fact do that once at EV_ADD time, and store whether it's a FIFO in our extended udata structure, so as to know if EV_EOF is final. But then we're having to use that udata structure to store data internal to the purposes of this kqueue interface, and not the overall user data. Are you still now going to claim to me this is trivial? Please compare this solution to: if(ev->flags & EV_FREEWATCH) free(ev->udata); I would call that solution "trivial". And I claim it fairly easy to implement.=20 --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --IQJU2WPwyEuShvbf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM4cDHvLS2TC8cBo0RAm2RAKC9GjeqdbDfAjUgzrSc9BGKT5GGEwCgrbF5 Juhh08LLq6z2kpV82XYf5xc= =RsrW -----END PGP SIGNATURE----- --IQJU2WPwyEuShvbf-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 01:17:12 2010 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 6DD22106566C for ; Tue, 16 Nov 2010 01:17:12 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 555A48FC18 for ; Tue, 16 Nov 2010 01:17:12 +0000 (UTC) Received: from supra.b1c1l1.com (unknown [IPv6:2607:fc48:12:2:225:4bff:fecf:472e]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id EC0BE5C34; Mon, 15 Nov 2010 17:17:11 -0800 (PST) Message-ID: <4CE1DB90.3000502@b1c1l1.com> Date: Mon, 15 Nov 2010 17:17:04 -0800 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20101002 Lightning/1.0b3pre Thunderbird/3.1.4 MIME-Version: 1.0 To: Joerg Pulz References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCAD3B4894700CB8002576647" Cc: freebsd-hackers@freebsd.org Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 01:17:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCAD3B4894700CB8002576647 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/15/2010 02:08 PM, Joerg Pulz wrote: > Hi, >=20 > after the security/heimdal port was updated to the current heimdal > release and i added one missing function from base it is now possible t= o > completely buildworld src/ using the port for all Kerberos5/GSSAPI > enabled parts. Hi Joerg, I don't think that having the base system depend on a port is the right solution to resolving the libgssapi compatibility problems in base. Did you ever come across the old PR kern/147454 that I submitted in June? In it I included a src patch that replaced the base system's libgssapi with upstream Heimdal's, which resolved all libgssapi compatibility problems. That patch is now stale, but either way I haven't been able to draw enough attention to the issue to have it fixed.= --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enigCAD3B4894700CB8002576647 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM4duVAAoJEDQaOGXZe8jk4DEP/Rk1vwGgnyDSU7rQll116TQ6 NPcHh2+NnBfGpHDlglHXFmGNlgmPWTmvEvpOMjuxTjg5co9rHOHhe+3rZ2doXPWn P9/gK+iYgI06DhoBNwwG4DYocfihWte9+ymSIldoocOaIH/RztHXcrRNzzDw9GJJ wRAF6F3D1mLiv6uxYXKeCI971N6E7B3w3wPgz4UfqyYcwu7lAzcUNXXUuZ0nFdxl BEQ5su0XTvQamZT/IPxfDgGZ9GhsCUPakU1/ibIXLdsAkHVnl5iyWrD6gTpNH8N7 c4gz9VBaAfx1MUR9S8Ga1adQTp//JLz9K7JrObVtsjHbcyYVUfw4vTS5trNey234 1PUQXQC+N9ZTCuqdFjHrkUODtTYRq7d5BlyEtK+4jyTVJ3f/3Hx/3B8IDvtpdaev 4WOPqVzjsG/J96MJiFDgGhb5/quuYX75hovkLfGxYcUln+g0RUNgXvYpAnF8FzSi UwxoYkbokYMkQSd11VgfLxbaRhMbNbKaLrYXwO3L4SrqglwsHEgRa9wWqQCtTcHK 3dy105Ja7nUhALuaaKFqfdw/2HVTNYLfgnu6SoihKO2gB2aSfk1k2fDe67Rv5jmC WWk6UrG85qZOeTRIG4q62qhNMFmYPrDj5890ulOPJ3YsPjKSYl7OoiAQsWo6XwxV DOkdsK3PFnhed1SeVyUL =vsRE -----END PGP SIGNATURE----- --------------enigCAD3B4894700CB8002576647-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 02:51:17 2010 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 AEF84106566B for ; Tue, 16 Nov 2010 02:51:17 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 46F128FC0A for ; Tue, 16 Nov 2010 02:51:16 +0000 (UTC) Received: by wwd20 with SMTP id 20so211809wwd.31 for ; Mon, 15 Nov 2010 18:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:in-reply-to:references:x-mailer; bh=cLVqJ7FO3tSisKIZKW6QC4FdEehFtXd7xdI5CeWr0BE=; b=irLkBz2lSZlN1BCcXe5BRZZm2S8xhywnbQHsCFVtZwUv7tCrJ/EDSpplA89uy7+8++ qn35NYpVOOual1jjVFcRN2zklBXJFSn8V5jwju2rkaw1Xrl6VF8w/8Rz7W7JPJPTXgk8 bMdcQSE5/22Rri1Y/KXQkJQaBre893LY2Vg5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:in-reply-to:references:x-mailer; b=lg5RiSp7MoGjtBV3XGm/5CXGM0pwOjPoap6A5+Pl9dpThqfMJ0rG0uiS2OFf9A+8pD ejFIAgO7InmlT3Q5dYKIAHDUvWUS9j8a6Cjn4Inc/CN6KULAu0AmCCwJgqohjGn5Jc1r v4hUTqKgvHwdVyMu5iVBgMPlT5HJ1/kA5I/7c= Received: by 10.227.151.148 with SMTP id c20mr6954331wbw.15.1289874322386; Mon, 15 Nov 2010 18:25:22 -0800 (PST) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id i19sm432179wbe.17.2010.11.15.18.25.19 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Nov 2010 18:25:21 -0800 (PST) Message-ID: <20101116.022422.921.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@FreeBSD.org Date: Tue, 16 Nov 2010 03:24:22 +0100 In-Reply-To: <4CA4C63F.4070503@icyb.net.ua> References: <4CA4C63F.4070503@icyb.net.ua> X-Mailer: POP Peeper (3.7.0.0) Cc: Subject: Unhappy with cross-worlding 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, 16 Nov 2010 02:51:17 -0000 So, I have Core 2 Duo, runing as i386. I decided to go for amd64 (it's name, is so deceiving, that I've just recently, accidentaly figured out, that it can be used, with intel CPUs, too) :P 8.1 cross build i386 -> amd64 has failed World completes successfully, but kernel fails: mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq - I/usr/obj/amd64/usr/src/sys/GENERIC /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:43:36: error: machine/../linux/linux.h: No such file or directory /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:44:42: error: machine/../linux/linux_proto.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error Then, I've snapped and took an USB stick and did a binary 8.1 amd64 install on it. Booted from it and kernel compiled flawlessly PS: Core 2 Duo - 8.1 GENERIC Kernel build time: 10:30 --> i386 08:30 --> amd64 Yes, without caching! PORTS: ------ >From i386, when created USB amd64, I wanted to compile some ports(i386 -> amd64), for that USB stick, on my own. Especially because of port's patches ... DESTIR has been set, as usual, but TARGET, was a no go! Looking into documentation, only /usr/src, supports TARGET, used for cross world compilation. Also, after throwing an eye into /usr/ports/Mk ..., I've concluded that ports, simply can't be cross world compiled, as they don't support it. This 2 problems should be fixed. Domagoj From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 03:34:38 2010 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 ED0EA106566B for ; Tue, 16 Nov 2010 03:34:38 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81FC58FC08 for ; Tue, 16 Nov 2010 03:34:38 +0000 (UTC) Received: by wyb36 with SMTP id 36so251462wyb.13 for ; Mon, 15 Nov 2010 19:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D6RescAEBfg1rboXpK5OglROtS4jqeg6nuYoY0i0LLQ=; b=vQTuciNjT4MNNjjTgT/9Rdw5yReMUutzSHi8t3EX/O42BDFJj0ZsfZdA3rnRDOLb81 G71oQ7Tf1raxENGtnFPf9ZVyuYiZQmMCiTJww1uutXWXv0/WzRNwmKK+slgTGY4boPnv KkgHtILYoDR5GXpPBdGs09f9jNrvG/5tyJlkY= 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=wZ3k9ZbZhSd7kkiFs4OSqq5k5mZ1733SRq2yfVM1dtOXzuWOq+HJaztp1dGUvax25v 1KjnAqR/oR9vvqUyTARmDY6yfHoILCJUPy31AxsRCgiHyrQYW3kkzebXFM3Rn5rKXSG8 GYtZPKC4oQ5FYFp1trmqbAnCkEY9O+86kgRb8= MIME-Version: 1.0 Received: by 10.216.171.75 with SMTP id q53mr5805875wel.74.1289876978790; Mon, 15 Nov 2010 19:09:38 -0800 (PST) Received: by 10.216.12.80 with HTTP; Mon, 15 Nov 2010 19:09:38 -0800 (PST) In-Reply-To: <4CE1DB90.3000502@b1c1l1.com> References: <4CE1DB90.3000502@b1c1l1.com> Date: Mon, 15 Nov 2010 21:09:38 -0600 Message-ID: From: Brandon Gooch To: Benjamin Lee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Joerg Pulz Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 03:34:39 -0000 On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: > On 11/15/2010 02:08 PM, Joerg Pulz wrote: >> Hi, >> >> after the security/heimdal port was updated to the current heimdal >> release and i added one missing function from base it is now possible to >> completely buildworld src/ using the port for all Kerberos5/GSSAPI >> enabled parts. > > Hi Joerg, > > I don't think that having the base system depend on a port is the right > solution to resolving the libgssapi compatibility problems in base. > > Did you ever come across the old PR kern/147454 that I submitted in > June? =A0In it I included a src patch that replaced the base system's > libgssapi with upstream Heimdal's, which resolved all libgssapi > compatibility problems. =A0That patch is now stale, but either way I > haven't been able to draw enough attention to the issue to have it fixed. I guess we're waiting on someone to review the patch and commit it? Hopefully someone can get this in soon, before 8.2 is released. Is there something wrong with your patch? -Brandon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 03:35:09 2010 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 619DC106566C for ; Tue, 16 Nov 2010 03:35:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E92DF8FC16 for ; Tue, 16 Nov 2010 03:35:08 +0000 (UTC) Received: by mail-wy0-f182.google.com with SMTP id 36so251462wyb.13 for ; Mon, 15 Nov 2010 19:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=yWtvstZvNaRQVKIv+VaP+rw0xF2/1wc0rq1RvrNpRrk=; b=uwtCOOMzCdWAzRVFA+C/NMcwB0VYEDz0+CemH93Ro5MjKrG8iMhCrk/mjYZiY1hgFc OqmlyXcT+HB6qV1ZoyxOjgDaz0MWlIDQcqdi0Z05Sjb+bFPj7GwQWbgX5dmgLK8uw2zc fLD/JePgmOawYfdMQ4gdZK9rwjZQKud5MxP70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Rde9mOnrzUM9Bk2Ox4/kzS+Vl4lpdxechkqyNRT2PHv89NC3/BL28sYxPy3MVwKqfj aODzKqkhMbE8HjYGEgRxuBHH3G/zdxm4CcokHEWj1p+ymXzWf0jqtNiV+etMcu/GJg1V 9l3bqGtVbmWK09T5PStB5gbAHGdfLyqQMV3os= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr8049373web.45.1289878508339; Mon, 15 Nov 2010 19:35:08 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Mon, 15 Nov 2010 19:35:08 -0800 (PST) In-Reply-To: <20101116.022422.921.1@DEV> References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> Date: Mon, 15 Nov 2010 19:35:08 -0800 X-Google-Sender-Auth: WJj8ZMOTVYrhN8Msqh0u06eBFAU Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 03:35:09 -0000 On Mon, Nov 15, 2010 at 6:24 PM, wrote: > So, I have Core 2 Duo, runing as i386. > I decided to go for amd64 (it's name, is so deceiving, that I've just > recently, accidentaly figured out, that it can be used, with intel CPUs, > too) :P > > 8.1 cross build i386 -> amd64 has failed > World completes successfully, but kernel fails: > > =A0 =A0mkdep -f .depend -a =A0 -nostdinc -D_KERNEL -DKLD_MODULE > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq - > =A0 =A0I/usr/obj/amd64/usr/src/sys/GENERIC > /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c > =A0 =A0/usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:43= :36: > error: machine/../linux/linux.h: No such file or directory > =A0 =A0/usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:44= :42: > error: machine/../linux/linux_proto.h: No such file or directory > =A0 =A0mkdep: compile failed > =A0 =A0*** Error code 1 > =A0 =A01 error > =A0 =A0*** Error code 2 > =A0 =A01 error > =A0 =A0*** Error code 2 > =A0 =A01 error > =A0 =A0*** Error code 2 > =A0 =A02 errors > =A0 =A0*** Error code 2 > =A0 =A01 error > =A0 =A0*** Error code 2 > =A0 =A01 error > > Then, I've snapped and took an USB stick and did a binary 8.1 amd64 insta= ll > on it. > Booted from it and kernel compiled flawlessly > > PS: > Core 2 Duo - 8.1 GENERIC > =A0 =A0Kernel build time: > =A0 =A010:30 --> i386 > =A0 =A008:30 --> amd64 > > =A0 =A0Yes, without caching! > > > PORTS: > ------ > >From i386, when created USB amd64, I wanted to compile some ports(i386 -= > > amd64), for that USB stick, on my own. > Especially because of port's patches ... > > DESTIR has been set, as usual, but TARGET, was a no go! > Looking into documentation, only /usr/src, supports TARGET, used for cros= s > world compilation. > Also, after throwing an eye into /usr/ports/Mk ..., I've concluded that > ports, simply can't be cross world compiled, as they don't support it. > > This 2 problems should be fixed. The best way to work with this is to create a chroot, set the appropriate variables (OSVERSION, UNAME_m, UNAME_r, etc), mount the /usr/ports via nullfs (if you dare) and then call chroot to access the chroot and build to your heart's content. There's an entry in the handbook somewhere that better describes how to do it from scratch, but my search skills are failing me and I don't have the full docs tree checked out. But yes, building amd64 on i386 probably won't work too well :)... HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 03:36:30 2010 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 B80A1106564A for ; Tue, 16 Nov 2010 03:36:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0488FC16 for ; Tue, 16 Nov 2010 03:36:29 +0000 (UTC) Received: by wwd20 with SMTP id 20so245561wwd.31 for ; Mon, 15 Nov 2010 19:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=q9/O1Suq1XhJnD1g+cQI2fK1Igowdynx0nr8WAePZtk=; b=TU3pfDbSYrXArn4xxqqad98u4yFLc8tEExGq95LUEwsVC85sSRjiqjTv70LNhN8OmW ERdSsqFy9DuGzFd8qoQFEfL9IKs3RnydTJ6DKJuxSYhp2vU8ApG3ZG16/9Y0dqDOUS7j eAaJvRtbEvsQYyMtrLuEKWjnpeNV9ravfNsYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=M/EenYRkrzuN4JGFm9YvHxlQEHj9UtlKRY3aj1AXmcHtBmZUOuldnUv5VPaoblU6qz af7YtkZ5NE6oINAz44mP4EhtzOju4e2SkVHkWje4bQSTX9CUR5hT39hletGXY5l3jKQB Goif917fDY3Z+dvFqVVEzEa2iH+KaD5Kl2zWM= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr8050441web.45.1289878588935; Mon, 15 Nov 2010 19:36:28 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Mon, 15 Nov 2010 19:36:28 -0800 (PST) In-Reply-To: References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> Date: Mon, 15 Nov 2010 19:36:28 -0800 X-Google-Sender-Auth: iUp_CiUAL8sy-TkT5N2TqNpnm3A Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 03:36:30 -0000 On Mon, Nov 15, 2010 at 7:35 PM, Garrett Cooper wrote= : > On Mon, Nov 15, 2010 at 6:24 PM, =A0 wrote: >> So, I have Core 2 Duo, runing as i386. >> I decided to go for amd64 (it's name, is so deceiving, that I've just >> recently, accidentaly figured out, that it can be used, with intel CPUs, >> too) :P >> >> 8.1 cross build i386 -> amd64 has failed >> World completes successfully, but kernel fails: >> >> =A0 =A0mkdep -f .depend -a =A0 -nostdinc -D_KERNEL -DKLD_MODULE >> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq - >> =A0 =A0I/usr/obj/amd64/usr/src/sys/GENERIC >> /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c >> =A0 =A0/usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:4= 3:36: >> error: machine/../linux/linux.h: No such file or directory >> =A0 =A0/usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:4= 4:42: >> error: machine/../linux/linux_proto.h: No such file or directory >> =A0 =A0mkdep: compile failed >> =A0 =A0*** Error code 1 >> =A0 =A01 error >> =A0 =A0*** Error code 2 >> =A0 =A01 error >> =A0 =A0*** Error code 2 >> =A0 =A01 error >> =A0 =A0*** Error code 2 >> =A0 =A02 errors >> =A0 =A0*** Error code 2 >> =A0 =A01 error >> =A0 =A0*** Error code 2 >> =A0 =A01 error >> >> Then, I've snapped and took an USB stick and did a binary 8.1 amd64 inst= all >> on it. >> Booted from it and kernel compiled flawlessly >> >> PS: >> Core 2 Duo - 8.1 GENERIC >> =A0 =A0Kernel build time: >> =A0 =A010:30 --> i386 >> =A0 =A008:30 --> amd64 >> >> =A0 =A0Yes, without caching! >> >> >> PORTS: >> ------ >> >From i386, when created USB amd64, I wanted to compile some ports(i386 = -> >> amd64), for that USB stick, on my own. >> Especially because of port's patches ... >> >> DESTIR has been set, as usual, but TARGET, was a no go! >> Looking into documentation, only /usr/src, supports TARGET, used for cro= ss >> world compilation. >> Also, after throwing an eye into /usr/ports/Mk ..., I've concluded that >> ports, simply can't be cross world compiled, as they don't support it. >> >> This 2 problems should be fixed. > > =A0 =A0The best way to work with this is to create a chroot, set the > appropriate variables (OSVERSION, UNAME_m, UNAME_r, etc), mount the > /usr/ports via nullfs (if you dare) and then call chroot to access the > chroot and build to your heart's content. There's an entry in the > handbook somewhere that better describes how to do it from scratch, > but my search skills are failing me and I don't have the full docs > tree checked out. > =A0 =A0But yes, building amd64 on i386 probably won't work too well :)... Clarification: well, when applied to the above method. I don't know how well cross-building amd64 works on 8-stable... Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 03:37:18 2010 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 9B71110656A4 for ; Tue, 16 Nov 2010 03:37:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0AF8FC1F for ; Tue, 16 Nov 2010 03:37:17 +0000 (UTC) Received: by wyb36 with SMTP id 36so253359wyb.13 for ; Mon, 15 Nov 2010 19:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=i4NfO/hIJ1UlQLmatewt9ziAylcTnhGqyV62t7HmhbM=; b=WJinIFpuyXoQcPiNc672kQzMwEH/gCe9pOLNQdZsuokZ96qg8up4Uj4FYRFq4adTTy +cSia78hWbpr1SXm5IbzCM4YtalRwmUnjr8vCWJ2ivoL76MUBoNLzOiEQKypi1sus5w6 7W4ZdfzLvGBlkf6XWh2odB+cIPnX7NU4OC05k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D9WpnHKGCFwsVqojJyCtjabbtcj/OueDhFXunZw4prWiePO0KylNgyRWyjuwA1ojsW p4F4UmnNKCkSnbP8EHNblkCICT1gUx7EhtSOvUVYs1bXN/hjqYfgg0sgnslo2/+RLRuw GEQ7o97WSpjEjQLdZKkCeACg6gvI5SzaGh/9g= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr8139616wep.30.1289878636916; Mon, 15 Nov 2010 19:37:16 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Mon, 15 Nov 2010 19:37:16 -0800 (PST) In-Reply-To: References: <4CE1DB90.3000502@b1c1l1.com> Date: Mon, 15 Nov 2010 19:37:16 -0800 X-Google-Sender-Auth: ss5w6ip18Fv20YGrfbH0PjLwrM4 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Lee , freebsd-hackers@freebsd.org, Joerg Pulz Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 03:37:18 -0000 On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch wrote: > On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>> Hi, >>> >>> after the security/heimdal port was updated to the current heimdal >>> release and i added one missing function from base it is now possible t= o >>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>> enabled parts. >> >> Hi Joerg, >> >> I don't think that having the base system depend on a port is the right >> solution to resolving the libgssapi compatibility problems in base. >> >> Did you ever come across the old PR kern/147454 that I submitted in >> June? =A0In it I included a src patch that replaced the base system's >> libgssapi with upstream Heimdal's, which resolved all libgssapi >> compatibility problems. =A0That patch is now stale, but either way I >> haven't been able to draw enough attention to the issue to have it fixed= . > > I guess we're waiting on someone to review the patch and commit it? > Hopefully someone can get this in soon, before 8.2 is released. > > Is there something wrong with your patch? Not according to another person that commented on the patch (and it sounds like the experience is positive, not negative). Who's the maintainer of the component? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 04:54:42 2010 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 EDF56106566B for ; Tue, 16 Nov 2010 04:54:41 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 580138FC13 for ; Tue, 16 Nov 2010 04:54:41 +0000 (UTC) Received: by wyb36 with SMTP id 36so305851wyb.13 for ; Mon, 15 Nov 2010 20:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=78qWvaZoN1ZJJdjXjczXmMIRZSwF2l0Gjh+NGNNQrxM=; b=P6zWm1crP34W2vYisRIlq29MBbWVUkJlc7RmQFiXFr8I6Y/amujW4z0iX1nz5f0tr9 yoFwY+mA+K2sLzu6UqSDuzF4cMgTeWRW8St2lgL47NDCmPQtCQEsOLXsck+5WTrWO5+q YxHqy2pyCHToFlegqM4ALozqT+315elhDNBgE= 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=OuUeT/AF76zjqFqqQow7gmLW0B+YnBqTvBsAcj482mAI7lLcO+jtFfAjPd7eC96WMT Ik4aai97N31l1FrYO7QioBRlszaEBMg1TcNrlIfASkHyHZtcwe7VNkkeWr16OZhX3o+2 tf/m9B0DdhL3veec5Xxv83qu89XbWjyYB7Xmw= MIME-Version: 1.0 Received: by 10.216.231.227 with SMTP id l77mr7125748weq.104.1289883280101; Mon, 15 Nov 2010 20:54:40 -0800 (PST) Received: by 10.216.12.80 with HTTP; Mon, 15 Nov 2010 20:54:40 -0800 (PST) In-Reply-To: References: <4CE1DB90.3000502@b1c1l1.com> Date: Mon, 15 Nov 2010 22:54:40 -0600 Message-ID: From: Brandon Gooch To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Lee , freebsd-hackers@freebsd.org, Joerg Pulz Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 04:54:42 -0000 On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper wrote= : > On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch > wrote: >> On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >>> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>>> Hi, >>>> >>>> after the security/heimdal port was updated to the current heimdal >>>> release and i added one missing function from base it is now possible = to >>>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>>> enabled parts. >>> >>> Hi Joerg, >>> >>> I don't think that having the base system depend on a port is the right >>> solution to resolving the libgssapi compatibility problems in base. >>> >>> Did you ever come across the old PR kern/147454 that I submitted in >>> June? =A0In it I included a src patch that replaced the base system's >>> libgssapi with upstream Heimdal's, which resolved all libgssapi >>> compatibility problems. =A0That patch is now stale, but either way I >>> haven't been able to draw enough attention to the issue to have it fixe= d. >> >> I guess we're waiting on someone to review the patch and commit it? >> Hopefully someone can get this in soon, before 8.2 is released. >> >> Is there something wrong with your patch? > > Not according to another person that commented on the patch (and it > sounds like the experience is positive, not negative). Who's the > maintainer of the component? Garrett, where would one look for such an important detail? Source file somewhere? Joerg, how about taking over what's in base? Seems to me like you know what's going on, and you're maintaining the port :) BTW, I'm only beginning to dive into Kerberos on FreeBSD, so I'm not bringing to this discussion much wisdom :/ But I would like all of the pieces to work! -Brandon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 06:15:31 2010 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 1AFC9106566C; Tue, 16 Nov 2010 06:15:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-20.mx.aerioconnect.net [216.240.47.80]) by mx1.freebsd.org (Postfix) with ESMTP id EEE4F8FC14; Tue, 16 Nov 2010 06:15:30 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAG6FTY6022240; Mon, 15 Nov 2010 22:15:29 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 8FEBB2D6011; Mon, 15 Nov 2010 22:15:28 -0800 (PST) Message-ID: <4CE22182.7090008@freebsd.org> Date: Mon, 15 Nov 2010 22:15:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: rank1seeker@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 06:15:31 -0000 On 11/15/10 7:35 PM, Garrett Cooper wrote: > On Mon, Nov 15, 2010 at 6:24 PM, wrote: >> So, I have Core 2 Duo, runing as i386. >> I decided to go for amd64 (it's name, is so deceiving, that I've just >> recently, accidentaly figured out, that it can be used, with intel CPUs, >> too) :P >> >> 8.1 cross build i386 -> amd64 has failed >> World completes successfully, but kernel fails: >> >> mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE >> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq - >> I/usr/obj/amd64/usr/src/sys/GENERIC >> /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c >> /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:43:36: >> error: machine/../linux/linux.h: No such file or directory >> /usr/src/sys/modules/amr/amr_linux/../../../dev/amr/amr_linux.c:44:42: >> error: machine/../linux/linux_proto.h: No such file or directory >> mkdep: compile failed >> *** Error code 1 >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 2 errors >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error >> >> Then, I've snapped and took an USB stick and did a binary 8.1 amd64 install >> on it. >> Booted from it and kernel compiled flawlessly >> >> PS: >> Core 2 Duo - 8.1 GENERIC >> Kernel build time: >> 10:30 --> i386 >> 08:30 --> amd64 >> >> Yes, without caching! >> >> >> PORTS: >> ------ >> > From i386, when created USB amd64, I wanted to compile some ports(i386 -> >> amd64), for that USB stick, on my own. >> Especially because of port's patches ... >> >> DESTIR has been set, as usual, but TARGET, was a no go! >> Looking into documentation, only /usr/src, supports TARGET, used for cross >> world compilation. >> Also, after throwing an eye into /usr/ports/Mk ..., I've concluded that >> ports, simply can't be cross world compiled, as they don't support it. >> >> This 2 problems should be fixed. > The best way to work with this is to create a chroot, set the > appropriate variables (OSVERSION, UNAME_m, UNAME_r, etc), mount the > /usr/ports via nullfs (if you dare) and then call chroot to access the > chroot and build to your heart's content. There's an entry in the > handbook somewhere that better describes how to do it from scratch, > but my search skills are failing me and I don't have the full docs > tree checked out. > But yes, building amd64 on i386 probably won't work too well :)... It's supposed to but hasn't for years. > HTH, > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 08:01:49 2010 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 08B951065744 for ; Tue, 16 Nov 2010 08:01:49 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8F99E8FC13 for ; Tue, 16 Nov 2010 08:01:48 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAG80eB7050254; Tue, 16 Nov 2010 09:01:41 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAG81dE6050286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 09:01:39 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Tue, 16 Nov 2010 09:01:36 +0100 (CET) From: Joerg Pulz To: Benjamin Lee In-Reply-To: <4CE1DB90.3000502@b1c1l1.com> Message-ID: References: <4CE1DB90.3000502@b1c1l1.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mailhost.frm2.tum.de [129.187.179.12]); Tue, 16 Nov 2010 09:01:39 +0100 (CET) Cc: freebsd-hackers@freebsd.org Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 08:01:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 15 Nov 2010, Benjamin Lee wrote: > On 11/15/2010 02:08 PM, Joerg Pulz wrote: >> Hi, >> >> after the security/heimdal port was updated to the current heimdal >> release and i added one missing function from base it is now possible to >> completely buildworld src/ using the port for all Kerberos5/GSSAPI >> enabled parts. > > Hi Joerg, > > I don't think that having the base system depend on a port is the right > solution to resolving the libgssapi compatibility problems in base. > > Did you ever come across the old PR kern/147454 that I submitted in > June? In it I included a src patch that replaced the base system's > libgssapi with upstream Heimdal's, which resolved all libgssapi > compatibility problems. That patch is now stale, but either way I > haven't been able to draw enough attention to the issue to have it fixed. Hi Benjamin, the patch is not being meant to change the default. So default world builds will still use what we have in base now. It's just an additional option. There are already other places in base where one can link against stuff from ports. E.g. you can build base heimdal with OpenLDAP hdb backend support (see src/kerberos5/Makefile.inc) or you can build base sendmail with SASL and OpenLDAP support (see /etc/make.conf for SASL instructions) or you can build base bind with IDN and XML support (see src/usr.sbin/named/Makefile or in src.conf(5) the WITH_BIND_IDN and WITH_BIND_XML option). So it's not really uncommon to build base and link/use stuff from ports. I think as long as base is self hosting and you're not required to have somthing from ports installed just to be able to actually build world successful, everything is fine. I'm aware of kern/147454 and it will probably of use for my ongoing work in this area. Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM4jpjSPOsGF+KA+MRAiffAKCRJazCvg/feEJgUhkc8ieDz+6mDACfTyYh kreX9tEcoBq57VWr0i3XxBU= =y7Vb -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 08:49:28 2010 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 AEECA1065670 for ; Tue, 16 Nov 2010 08:49:28 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 537DD8FC28 for ; Tue, 16 Nov 2010 08:49:27 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAG8nN5D052480; Tue, 16 Nov 2010 09:49:23 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) (authenticated bits=0) by mailhost.frm2.tum.de (8.14.4/8.14.4) with ESMTP id oAG8nMQC052477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 09:49:22 +0100 (CET) (envelope-from Joerg.Pulz@frm2.tum.de) Date: Tue, 16 Nov 2010 09:49:20 +0100 (CET) From: Joerg Pulz To: Brandon Gooch In-Reply-To: Message-ID: References: <4CE1DB90.3000502@b1c1l1.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3469798045-1678378151-1289895727=:1682" Content-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mailhost.frm2.tum.de [129.187.179.12]); Tue, 16 Nov 2010 09:49:22 +0100 (CET) Cc: Benjamin Lee , freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 08:49:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3469798045-1678378151-1289895727=:1682 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Mon, 15 Nov 2010, Brandon Gooch wrote: > On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper wrote: >> On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch >> wrote: >>> On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >>>> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>>>> Hi, >>>>> >>>>> after the security/heimdal port was updated to the current heimdal >>>>> release and i added one missing function from base it is now possible to >>>>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>>>> enabled parts. >>>> >>>> Hi Joerg, >>>> >>>> I don't think that having the base system depend on a port is the right >>>> solution to resolving the libgssapi compatibility problems in base. >>>> >>>> Did you ever come across the old PR kern/147454 that I submitted in >>>> June?  In it I included a src patch that replaced the base system's >>>> libgssapi with upstream Heimdal's, which resolved all libgssapi >>>> compatibility problems.  That patch is now stale, but either way I >>>> haven't been able to draw enough attention to the issue to have it fixed. >>> >>> I guess we're waiting on someone to review the patch and commit it? >>> Hopefully someone can get this in soon, before 8.2 is released. >>> >>> Is there something wrong with your patch? >> >> Not according to another person that commented on the patch (and it >> sounds like the experience is positive, not negative). Who's the >> maintainer of the component? > > Garrett, where would one look for such an important detail? Source > file somewhere? > > Joerg, how about taking over what's in base? Seems to me like you know > what's going on, and you're maintaining the port :) > > BTW, I'm only beginning to dive into Kerberos on FreeBSD, so I'm not > bringing to this discussion much wisdom :/ But I would like all of the > pieces to work! Hi Brandon, i already started to work on updating base heimdal to a recent version which is not the easiest task but i made some progreess. Be patient. Kind regards - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM4kWSSPOsGF+KA+MRAn3xAJ4ttm/cy+1ue0+G/Ca0+82fXWpf6wCePS4D Fm+7ZkvEu34lWhByynZKOGM= =PWDZ -----END PGP SIGNATURE----- --3469798045-1678378151-1289895727=:1682-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 09:39:15 2010 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 B9B7F106566B; Tue, 16 Nov 2010 09:39:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 751688FC19; Tue, 16 Nov 2010 09:39:15 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6D8311FFC34; Tue, 16 Nov 2010 09:39:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 42E438452D; Tue, 16 Nov 2010 10:39:14 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Julian Elischer References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> <4CE22182.7090008@freebsd.org> Date: Tue, 16 Nov 2010 10:39:14 +0100 In-Reply-To: <4CE22182.7090008@freebsd.org> (Julian Elischer's message of "Mon, 15 Nov 2010 22:15:30 -0800") Message-ID: <86sjz18v5p.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 09:39:15 -0000 Julian Elischer writes: > Garrett Cooper > > But yes, building amd64 on i386 probably won't work too well :)... > It's supposed to but hasn't for years. Umm, what do you mean? You can cross-build world and kernel with TARGET=3Damd64 (this is what the tinderbox and 'make universe' do), then install the kernel, reboot into single-user mode, and install world. Some things won't work properly until you've built and installed world a second time, but nothing important AFAIK. You may have to copy /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 before you reboot - it used to be necessary, but ISTR someone hacked around it to make it easier to run 32-bit chroots on amd64. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 09:40:21 2010 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 D2F6D1065695; Tue, 16 Nov 2010 09:40:21 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 340348FC13; Tue, 16 Nov 2010 09:40:20 +0000 (UTC) Received: by fxm19 with SMTP id 19so281631fxm.13 for ; Tue, 16 Nov 2010 01:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=rSWl5lRuto2RQFlA2kiaMoJIp2NQFk2+pq0hqQg9MR8=; b=Kz+zjvpobeX1iq1BbNqQmLalZ2/M3UOB5lf4vQXi8dONZj8Q2frV7CKrB2YzLQdyg9 dVkGAT2Nww/jQycqqg9dO2xVbJAJ2b7aHVNlX4ICz/NGl6qwjwFDIarLNe4LBi0NBkcP ePL8UjkuOrzr69g6x2OONGiQsVgW9Qx9HWMA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=CiTGhR0n/ZXLR8eYODTBsVAkpCtXm4VkgDRFgqWA/7nLEluzo/WwIWPX91oovRwca6 F3UglLs6anSNjoko4vUmzFqp6tZO8ELzzRc4dbzoQSAEw3oVo3y39z2eUKBt/dXl7y8/ p8e5/net6keaZ8tg8kCjtukWzAbipkIJLf5Mg= Received: by 10.223.114.202 with SMTP id f10mr5707983faq.67.1289900420034; Tue, 16 Nov 2010 01:40:20 -0800 (PST) Received: from ernst.jennejohn.org (p578E2EC2.dip.t-dialin.net [87.142.46.194]) by mx.google.com with ESMTPS id z25sm1190931fam.18.2010.11.16.01.40.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 01:40:19 -0800 (PST) Date: Tue, 16 Nov 2010 10:40:17 +0100 From: Gary Jennejohn To: Brandon Gooch Message-ID: <20101116104017.559537c4@ernst.jennejohn.org> In-Reply-To: References: <4CE1DB90.3000502@b1c1l1.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Benjamin Lee , freebsd-hackers@freebsd.org, Joerg Pulz , Garrett Cooper Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 09:40:21 -0000 On Mon, 15 Nov 2010 22:54:40 -0600 Brandon Gooch wrote: > On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper wrote: > > Not according to another person that commented on the patch (and it > > sounds like the experience is positive, not negative). Who's the > > maintainer of the component? > > Garrett, where would one look for such an important detail? Source > file somewhere? > libgssapi doesn't have an official maintainer. Usually the committers who touch it the most are deemed responsible. Seems that dfr@ and uqs@ fit the bill. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 13:17:10 2010 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 3DACE106564A; Tue, 16 Nov 2010 13:17:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id C25588FC18; Tue, 16 Nov 2010 13:17:09 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 645946F60051; Tue, 16 Nov 2010 16:01:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289912505; bh=ev8ClHZXhuBwFeAuzm9BDWumLFFAYZCx0jN99WMp9Bg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=KarWMsBJD9dq7Qus9oX/3+V2UGLF0DG4ZE9A6ykDKm64revoCONWEEsedQnvoqRTI Q4iTezh9urIhxnNUmtcs2ZTRd1zcrvdOdSFXEFR+TEdTe4V5xRZgerX7XjADHNEh/d BfS1BWCUC5uGj5M/kOOKJQ6fddFT6ZSyTlzTcU+U= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id E5B311280A6; Tue, 16 Nov 2010 16:01:44 +0300 (MSK) Message-ID: <4CE280B7.1070502@yandex.ru> Date: Tue, 16 Nov 2010 16:01:43 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Adrian Chadd References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060308000204010909070501" Cc: Bruce Cran , freebsd-hackers@freebsd.org, freebsd-current Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 13:17:10 -0000 This is a multi-part message in MIME format. --------------060308000204010909070501 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit On 08.11.2010 15:31, Adrian Chadd wrote: >> I've broken out the crunchgen logic from src/rescue/rescue into a >> share/mk file - that way it can be reused in other areas. >> >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> >> >> This bsd.crunchgen.mk file is generic enough to use in my >> busybox-style thing as well as for src/rescue/rescue/. >> >> Comments, feedback, etc welcome! It seems this broke usage of livefs from sysinstall. sysinstall does check for /rescue/ldconfig and can not find it there. I think attached patch can fix this issue (not tested). -- WBR, Andrey V. Elsukov --------------060308000204010909070501 Content-Type: text/plain; name="sysinstall_rescue.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysinstall_rescue.diff" Index: head/usr.sbin/sysinstall/install.c =================================================================== --- head/usr.sbin/sysinstall/install.c (revision 215396) +++ head/usr.sbin/sysinstall/install.c (working copy) @@ -342,7 +342,7 @@ installFixitUSB(dialogMenuItem *self) !DEVICE_INIT(mediaDevice)) { msgConfirm("No USB devices found!"); return (DITEM_FAILURE); - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { msgConfirm("Unable to find a FreeBSD live filesystem."); return (DITEM_FAILURE); } @@ -375,7 +375,7 @@ installFixitCDROM(dialogMenuItem *self) mediaClose(); if (need_eject && msgYesNo("Unable to mount the disc. Do you want to try again?") != 0) return DITEM_FAILURE; - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { mediaClose(); if (need_eject && msgYesNo("Unable to find a FreeBSD live filesystem. Do you want to try again?") != 0) @@ -565,7 +565,7 @@ fixit_livefs_common(dialogMenuItem *self) /* Generate a new ld.so.hints */ if (!file_readable("/var/run/ld.so.hints")) { Mkdir("/var/run"); - if (vsystem("/mnt2/rescue/ldconfig -s /mnt2/lib " + if (vsystem("/mnt2/rescue/rescue ldconfig -s /mnt2/lib " "/mnt2/usr/lib")) { msgConfirm("Warning: ldconfig could not create the " "ld.so hints file.\nDynamic executables from the " --------------060308000204010909070501-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 13:29:37 2010 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 4194E106564A; Tue, 16 Nov 2010 13:29:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 116888FC08; Tue, 16 Nov 2010 13:29:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BE32046B39; Tue, 16 Nov 2010 08:29:36 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5751D8A01D; Tue, 16 Nov 2010 08:29:35 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Nov 2010 08:29:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4CE280B7.1070502@yandex.ru> In-Reply-To: <4CE280B7.1070502@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011160829.13511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 08:29:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 13:29:37 -0000 On Tuesday, November 16, 2010 8:01:43 am Andrey V. Elsukov wrote: > On 08.11.2010 15:31, Adrian Chadd wrote: > >> I've broken out the crunchgen logic from src/rescue/rescue into a > >> share/mk file - that way it can be reused in other areas. > >> > >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< > >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> > >> > >> This bsd.crunchgen.mk file is generic enough to use in my > >> busybox-style thing as well as for src/rescue/rescue/. > >> > >> Comments, feedback, etc welcome! > > It seems this broke usage of livefs from sysinstall. > sysinstall does check for /rescue/ldconfig and can not find it there. > I think attached patch can fix this issue (not tested). Err, are there no longer hard links to all of the frontends for a given crunch? If so, that is a problem as it will make rescue much harder to use. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 13:45:15 2010 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 8F0E1106564A; Tue, 16 Nov 2010 13:45:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 3306F8FC1C; Tue, 16 Nov 2010 13:45:15 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 7070D2210815; Tue, 16 Nov 2010 16:45:13 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289915113; bh=hTm+LU+UaOMNGcaeRYMsGlaNwRAV7OXIq0bCOysf++A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=IZvI2xuZZ/rrKUso9jAtbDk3uurz3M3elKRMQmpBLzAsoNYkIgl+B7UR9E4elD7IU RGhwEzgw/czkackM/LDFX+OmMJOKeB5EkeEp7sRqgqiocrDsihDx9m/Z4/eRPALSq4 xRfCzN8YgmO3QVTpiffd4hBjYVe3xKIp3kq01Kcs= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id E9E2F415805A; Tue, 16 Nov 2010 16:45:12 +0300 (MSK) Message-ID: <4CE28AE4.70101@yandex.ru> Date: Tue, 16 Nov 2010 16:45:08 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4CE280B7.1070502@yandex.ru> <201011160829.13511.jhb@freebsd.org> In-Reply-To: <201011160829.13511.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA27E854D4E700BE54394D527" Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 13:45:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA27E854D4E700BE54394D527 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.11.2010 16:29, John Baldwin wrote: > Err, are there no longer hard links to all of the frontends for a given= =20 > crunch? If so, that is a problem as it will make rescue much harder to= use. Yes, probably this patch is not needed and it should be fixed somewhere i= n makefiles. But currently rescue does not have any hardlinks: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNA= P/cdrom/livefs/rescue/ And what is was before: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNA= P/cdrom/livefs/rescue/ --=20 WBR, Andrey V. Elsukov --------------enigA27E854D4E700BE54394D527 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM4oroAAoJEAHF6gQQyKF6L5IIAMBnnOFJhRRR2QbbAA2c4acK zxwCLhFJ7MTFcoYdwX9HHAJnaEILssMzI8sF6p/Yqa1bvm6Jrl6hPBQAllJU/Qlx Fj3xGrf+tjJMEmlaPQxalCkF6IWmiVmBB4+/aYLb0J66vAHywZJPsIqdx3BfQHrq 2Gxy7YjxUhnW86b9rOb9UOJPalqK8eEojb7HYzWaeW0haJhjzXGcjTdSD0oh6Rvk VAqr82kMvhjUV0MzYDtxY7fYQaJB04wa+jZWSVQmVMH2MPOFbzK35py38o8aQ27y bL83MVVboVAHDGGjGnD1QmlbVas1T4Hzw+lqJUgduOSjtACP4cQveZZXcms1CqI= =lt5u -----END PGP SIGNATURE----- --------------enigA27E854D4E700BE54394D527-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 13:55:55 2010 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 03D551065693 for ; Tue, 16 Nov 2010 13:55:55 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 396708FC25 for ; Tue, 16 Nov 2010 13:55:54 +0000 (UTC) Received: by fxm19 with SMTP id 19so461368fxm.13 for ; Tue, 16 Nov 2010 05:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:in-reply-to:references:x-mailer; bh=BT6u4WohccbAeAs8B9YoG2VOoYjt0vxDwCRS0yt9bFc=; b=x7RjizDPa6UL1pBYS29A1Ppv6fPmKq/DOim1qYu0B7T9iHFMRAeA301HxLHKE2oapW /l19UdQa0H9W2Xj11OPLYqhqulNFaWZ3vx16P+uPibicV/yhiF+ksgmCVkRdIItDVxhM BGu2euQGZLhE8JTklCILQ+ZBTYJJvcOYmHwuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:in-reply-to:references:x-mailer; b=u5Bgc9cILkZOrLxfGAze5GMadvbelvyX1amDWmT4L+eurgGMJji2tqSqEmgOJ170hG 1kxMl2bGh8GcgWxvWfp6H9sBv+QKq1+NGN9Znj7ztrlOwaeZgH9bsXoR+wPpwHcyaBcc pOmeJlURBeznF8TgEHY1jKGXc9LRvvC1dyb2U= Received: by 10.223.100.12 with SMTP id w12mr1613098fan.136.1289915753440; Tue, 16 Nov 2010 05:55:53 -0800 (PST) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id k21sm1281546faa.1.2010.11.16.05.55.50 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 05:55:52 -0800 (PST) Message-ID: <20101116.135453.625.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org, "Julian Elischer" , "Garrett Cooper" , "Dag-Erling Smorgrav" Date: Tue, 16 Nov 2010 14:54:53 +0100 In-Reply-To: <86sjz18v5p.fsf@ds4.des.no> References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> <4CE22182.7090008@freebsd.org> <86sjz18v5p.fsf@ds4.des.no> X-Mailer: POP Peeper (3.7.0.0) Cc: Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 13:55:55 -0000 Additionally ... After I've created, bootable binary USB amd64 on i386, I wanted do a freebsd-update, on memstick, via '-b' flag, to avoid doing it later. Conclusion: Don't use '-b' at all, as it fetches updates for LOCAL running OS (i386) >From running 8.1 i386, I did a binary 8.1 am64 install into /memstick Then I ran: (to avoid running it after boot) freebsd-update -b /memstick fetch freebsd-update -b /memstick install It is really retarded, but it fetched for local i386 and with them patched amd64 in /memstick This cross-worlding is a total mess! Nothing works. Domagoj From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 14:20:57 2010 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 32849106564A; Tue, 16 Nov 2010 14:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02F118FC0C; Tue, 16 Nov 2010 14:20:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 97A5F46B35; Tue, 16 Nov 2010 09:20:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A74C78A009; Tue, 16 Nov 2010 09:20:55 -0500 (EST) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 16 Nov 2010 09:12:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> In-Reply-To: <4CE28AE4.70101@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011160912.27693.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 09:20:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 14:20:57 -0000 On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: > On 16.11.2010 16:29, John Baldwin wrote: > > Err, are there no longer hard links to all of the frontends for a given > > crunch? If so, that is a problem as it will make rescue much harder to use. > > Yes, probably this patch is not needed and it should be fixed somewhere in > makefiles. But currently rescue does not have any hardlinks: > http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ > > And what is was before: > http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ That definitely needs to be fixed. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 14:36:51 2010 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 11334106564A; Tue, 16 Nov 2010 14:36:51 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C258F8FC18; Tue, 16 Nov 2010 14:36:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so896420iwn.13 for ; Tue, 16 Nov 2010 06:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SKQtBg3lutdJqo8ghwHWZ+s3+OA87TACIHekUo4GS+U=; b=Ya3GAQb3mT7Fwyf4D//5hofeyj/5TunYIEbZ/EcaomilbTf8Ow4GCed09ZdlZLjXmj AKVqDw1tskmwYQnFKmm2l7eV2CNV9cC1LGO4lSbmoCzIh66vbMgoh3I5u1ZA3aM3NZZY ZT6Qo1oraENEKQ8OkZtVDVaktwospTJcLatdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=bCafUh+EnbS09phKIwmWge0fv5a13fs7fPlBEHaqn0qFcaB5lVjtyUwmiuPVTpxxft RRVsZRD1SnvtGn4jdS4wmdni+j6acj6K4EGQj7njprrFAjfi6qhSRi3qCsa1wZK4HZbv 2UaL0p/pUpx2MY4r8nwRQjV2dO6X44c1Qm3fg= MIME-Version: 1.0 Received: by 10.231.11.3 with SMTP id r3mr5384267ibr.53.1289918210138; Tue, 16 Nov 2010 06:36:50 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.180.164 with HTTP; Tue, 16 Nov 2010 06:36:50 -0800 (PST) Date: Tue, 16 Nov 2010 15:36:50 +0100 X-Google-Sender-Auth: SWoPm0mX8ZuNsKQ4RVjq9_bna9A Message-ID: From: Baptiste Daroussin To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] sync libedit with netbsd 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, 16 Nov 2010 14:36:51 -0000 Hi all, Here is a new version of the patch, this time it only upgrades libedit without installing the readline compatibility headers (as I have been suggested for a first step) Their should be no regression with this patch. If it gets committed I'll send the FreeBSD's enhancement to upstream so that we can keep sources in sync. http://people.freebsd.org/~bapt/libedit-netbsd-sync.patch regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 14:38:11 2010 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 280CA106564A for ; Tue, 16 Nov 2010 14:38: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 D39AA8FC1A for ; Tue, 16 Nov 2010 14:38:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PIMfh-0003NU-Os for freebsd-hackers@freebsd.org; Tue, 16 Nov 2010 15:38:09 +0100 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 ; Tue, 16 Nov 2010 15:38:09 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2010 15:38:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 16 Nov 2010 15:37:59 +0100 Lines: 6 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 X-Enigmail-Version: 1.1.2 Subject: Network socket concurrency (userland) 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, 16 Nov 2010 14:38:11 -0000 Are there any standard-defined guarantees for TCP network sockets used by multiple threads to do IO on them? Specifically, will multiple write() or send() calls on the same socket execute serially (i.e. not interfere with each other) and blocking (until completion) even for large buffer sizes? What about read() / recv()? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 15:38:33 2010 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 B7B78106566B for ; Tue, 16 Nov 2010 15:38:33 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF578FC08 for ; Tue, 16 Nov 2010 15:38:33 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 0F771667A1 for ; Tue, 16 Nov 2010 16:18:56 +0100 (CET) Received: by britannica.bec.de (Postfix, from userid 1000) id B13B7116D6D; Tue, 16 Nov 2010 16:19:03 +0100 (CET) Date: Tue, 16 Nov 2010 16:19:03 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20101116151903.GA2361@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Network socket concurrency (userland) 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, 16 Nov 2010 15:38:33 -0000 On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote: > Are there any standard-defined guarantees for TCP network sockets > used by multiple threads to do IO on them? System calls are atomic relative to each other. They may be partially executed from the perspective of a remote system, e.g. due to segmentation, but one system call will finish before the next call of the same category is started. > Specifically, will multiple write() or send() calls on the same > socket execute serially (i.e. not interfere with each other) and > blocking (until completion) even for large buffer sizes? What about > read() / recv()? All write operations are serialised against each other, just like all read operations are serialised against. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 15:51:15 2010 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 828B9106566C for ; Tue, 16 Nov 2010 15:51:15 +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 37DE88FC13 for ; Tue, 16 Nov 2010 15:51:14 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PINoO-0000uv-RC for freebsd-hackers@freebsd.org; Tue, 16 Nov 2010 16:51:12 +0100 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 ; Tue, 16 Nov 2010 16:51:12 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2010 16:51:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 16 Nov 2010 16:51:04 +0100 Lines: 24 Message-ID: References: <20101116151903.GA2361@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20101116151903.GA2361@britannica.bec.de> X-Enigmail-Version: 1.1.2 Subject: Re: Network socket concurrency (userland) 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, 16 Nov 2010 15:51:15 -0000 On 11/16/10 16:19, Joerg Sonnenberger wrote: > On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote: >> Are there any standard-defined guarantees for TCP network sockets >> used by multiple threads to do IO on them? > > System calls are atomic relative to each other. They may be partially > executed from the perspective of a remote system, e.g. due to > segmentation, but one system call will finish before the next call of > the same category is started. It seems to me that with a multithreaded kernel and multithreaded userland that cannot really be guaranteed in general (and really should not be guaranteed for performance reasons), but maybe it's true for e.g. sockets if they are protected by a mutex or two within the kernel? >> Specifically, will multiple write() or send() calls on the same >> socket execute serially (i.e. not interfere with each other) and >> blocking (until completion) even for large buffer sizes? What about >> read() / recv()? > > All write operations are serialised against each other, just like all > read operations are serialised against. To what degree is such serialization standardized (by POSIX?)? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 16:33:50 2010 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 59A6F106566B for ; Tue, 16 Nov 2010 16:33:50 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id C17558FC0A for ; Tue, 16 Nov 2010 16:33:49 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 3A1F96669E for ; Tue, 16 Nov 2010 17:33:48 +0100 (CET) Received: by britannica.bec.de (Postfix, from userid 1000) id EBE5E116D6D; Tue, 16 Nov 2010 17:33:54 +0100 (CET) Date: Tue, 16 Nov 2010 17:33:54 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20101116163354.GA4720@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20101116151903.GA2361@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Network socket concurrency (userland) 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, 16 Nov 2010 16:33:50 -0000 On Tue, Nov 16, 2010 at 04:51:04PM +0100, Ivan Voras wrote: > On 11/16/10 16:19, Joerg Sonnenberger wrote: > >On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote: > >>Are there any standard-defined guarantees for TCP network sockets > >>used by multiple threads to do IO on them? > > > >System calls are atomic relative to each other. They may be partially > >executed from the perspective of a remote system, e.g. due to > >segmentation, but one system call will finish before the next call of > >the same category is started. > > It seems to me that with a multithreaded kernel and multithreaded > userland that cannot really be guaranteed in general (and really > should not be guaranteed for performance reasons), but maybe it's > true for e.g. sockets if they are protected by a mutex or two within > the kernel? Of course it can be guaranteed. There are a few tricky bits like writing to a file with O_APPEND, but for sockets it is essentially all about taking a mutex before changes the socket buffer. > >>Specifically, will multiple write() or send() calls on the same > >>socket execute serially (i.e. not interfere with each other) and > >>blocking (until completion) even for large buffer sizes? What about > >>read() / recv()? > > > >All write operations are serialised against each other, just like all > >read operations are serialised against. > > To what degree is such serialization standardized (by POSIX?)? It is written somewhere, I forget where and can't find it right now :) Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 17:38:36 2010 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 8CCFC106564A for ; Tue, 16 Nov 2010 17:38:36 +0000 (UTC) (envelope-from nvidican@m2.vidican.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 526D78FC1F for ; Tue, 16 Nov 2010 17:38:36 +0000 (UTC) Received: by gyg13 with SMTP id 13so528358gyg.13 for ; Tue, 16 Nov 2010 09:38:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.178.13 with SMTP id e13mr6786571wem.25.1289927331142; Tue, 16 Nov 2010 09:08:51 -0800 (PST) Sender: nvidican@m2.vidican.com Received: by 10.216.234.217 with HTTP; Tue, 16 Nov 2010 09:08:51 -0800 (PST) X-Originating-IP: [136.1.1.105] Date: Tue, 16 Nov 2010 12:08:51 -0500 X-Google-Sender-Auth: xtjDScnuu9raE531iOTEgV7lnoQ Message-ID: From: Nathan Vidican To: hackers@freebsd.org X-Mailman-Approved-At: Tue, 16 Nov 2010 17:42:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Software interrupts; where to start 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, 16 Nov 2010 17:38:36 -0000 Hey All, So I'm about as new as it gets to kernel/device level programming, but far from new to application programming/coding in general. I've recently created some components which communicate via serial port to a host computer (server). These components are used to control a bunch of inter-connected devices for home automation; lighting/dimming packs, HVAC, security, etc - via simple commands relayed from the serial port of the server. The server runs a local instance of memcached, instantiating and copying a local fixed array and polling the memcached server comparing the values against an array there, when the values do not match the (different) value is written out the serial port and updated in the local array slot as appropriate. Multiple other sources update the memcached array via the network and that's essentially how the whole system works, (ie: user presses a button on a web-based app, and that app in turn changes the dimmer value associated as a specific slot in the memcached copy of the array). This solution works, but introduced nearly 100% CPU usage as the polling was done in a constant loop, after having added a 20 milli-second delay to the loop it's dropped the CPU usage to nearly 25% - but this still seems very wasteful to me and I can't help but wonder if there is a just plain better way to do this. What I would like to do, is replace the above scenario with one wherein the program writing to the serial port is always connected and running, but not polling; ideally having some sort of interupt or signal triggered from within memcached when a value is altered. Sort of a 're-sync' request asserting that the program sending data out the serial port should 'loop once'. I'd like to continue with the use of memcached as it provides a simple way for multiple systems to query the values in the array as well, (ie: some devices need not change the data, but only view it; given the latency requirements memcached operates ideally). This trigger should be asynchronous in that it should be fired and forgotten by memcached (by nature of the hardware designed, no error-checking nor receipt would be needed). I'm just not sure where to start? Could someone send me the right RTFM link to start from, or perhaps suggest a better way to look at solving this problem? Ideally any example code to look at with a simple signal or interrupt type of handler would be great. What I'm leaning towards is modifying memcached daemon to send a signal or trigger an interrupt of some sort to tell the other program communicating with the device to re-poll once. It would also be nice to have a way to trigger from other programs too. The device communicating via serial port is essentially a protocol translator to a modified RS422 serial bus, the eventual goal of using a local UART with some modified hardware and changing the device driver to support the communications differences directly in the kernel would be best scenario, so any suggestions leaning towards having the sending program be integrated within the kernel in some way would be even better. I'm not looking for a handout here, just a better understanding of where to start; so any suggestions or referrals to RTFM or source examples would be greatly appreciated. Thanks. -- Nathan Vidican nathan@vidican.com From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 17:52:58 2010 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 1C734106564A; Tue, 16 Nov 2010 17:52:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 874788FC18; Tue, 16 Nov 2010 17:52:57 +0000 (UTC) Received: by gwj20 with SMTP id 20so536408gwj.13 for ; Tue, 16 Nov 2010 09:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=gGzOmkDQAnN2sQIWAGWjI7Pee+mUT8fPdzenvyQLD4U=; b=P+25Ke1qyZKpQ5zPbQySLXSk88WG7fDa23eXA9Lav8txCd8wg52dV2yNTutG3vGr40 FDaQguS/KdPpNfqAJhB0Sug/CXhwphJljz0L57ZrBlxaGyeGfCL/skc2nuMFPjMhxRJE jtP5+JYRM1zFaFR0D6/7hEhC9CRHiYAz9DOf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=phjCIAccAAFcJ8dw4tATy8QeA2vg3D6aSLSI9HLmmAxC2FjHkHFFYCpuQgzsjFJZXb qANuCIVipE58GdRtfyxmdeulBIAoy5GNN8b/SW5hQunVybudPMDe50RAB41h+WHrdp3A YE1EM1mZHmzHI5ni14LU/BwQff214IfvA2Tds= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr7512660wee.45.1289929976116; Tue, 16 Nov 2010 09:52:56 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 09:52:56 -0800 (PST) In-Reply-To: <201011160912.27693.jhb@freebsd.org> References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Tue, 16 Nov 2010 09:52:56 -0800 X-Google-Sender-Auth: NRgn383jEBK6pv3JGpWOucqoQ_Q Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=001636eefd2a02f74904952f3a30 Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 17:52:58 -0000 --001636eefd2a02f74904952f3a30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: > On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >> On 16.11.2010 16:29, John Baldwin wrote: >> > Err, are there no longer hard links to all of the frontends for a give= n >> > crunch? =A0If so, that is a problem as it will make rescue much harder= to use. >> >> Yes, probably this patch is not needed and it should be fixed somewhere = in >> makefiles. But currently rescue does not have any hardlinks: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSN= AP/cdrom/livefs/rescue/ >> >> And what is was before: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSN= AP/cdrom/livefs/rescue/ > > That definitely needs to be fixed. The .mk file wasn't being installed. Could someone please test this patch for validity and commit it? More importantly, why didn't the above build process, or tinderbox fail properly with this change? Thanks, -Garrett --001636eefd2a02f74904952f3a30 Content-Type: text/x-patch; charset=US-ASCII; name="fix-crunchgen.patch" Content-Disposition: attachment; filename="fix-crunchgen.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggl2yoqx0 SW5kZXg6IHNoYXJlL21rL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21rL01ha2VmaWxl CShyZXZpc2lvbiAyMTUzMzMpCisrKyBzaGFyZS9tay9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpA QCAtMyw3ICszLDggQEAKIAogRklMRVM9CWJzZC5SRUFETUUKIEZJTEVTKz0JYnNkLmFyY2guaW5j Lm1rCi1GSUxFUys9CWJzZC5jb21wYXQubWsgYnNkLmNwdS5tayBic2QuZGVwLm1rIGJzZC5kb2Mu bWsgYnNkLmR0cmFjZS5taworRklMRVMrPQlic2QuY29tcGF0Lm1rIGJzZC5jcnVuY2hnZW4ubWsg YnNkLmNwdS5taworRklMRVMrPQlic2QuZGVwLm1rIGJzZC5kb2MubWsgYnNkLmR0cmFjZS5tawog RklMRVMrPQlic2QuZW5kaWFuLm1rCiBGSUxFUys9CWJzZC5maWxlcy5tayBic2QuaW5jcy5tayBi c2QuaW5mby5tayBic2QuaW5pdC5tawogRklMRVMrPQlic2Qua21vZC5tawo= --001636eefd2a02f74904952f3a30-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 18:05:03 2010 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 43D49106566B; Tue, 16 Nov 2010 18:05:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42EF98FC24; Tue, 16 Nov 2010 18:05:01 +0000 (UTC) Received: by ewy3 with SMTP id 3so488360ewy.13 for ; Tue, 16 Nov 2010 10:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dYKXwu4MmTrYL/HeXhk6vnq9wIoCZ8f2jWNfH4VwGEQ=; b=hdM4h+SWGO+gu3aeT3cr56rSbq4qHfkbLBqCciZvvmj3AcW0wBp49+a3EQpVjbKHrz FJbA/D1HK2+wGgxI2fa7aLKlA+PqQfi4SK5P9Xkfmbx6viWokhE/pAo2t6kvm1d7Wt3k jPX0h42revKJ7P1JXpWWXXGkSCWrWeSE3e3qY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BID756Oswrvhp5wuyKMimT1U2Vis7NBAZtn1FG5OTevfCwRdwKep43uIZ8SZVUGxgr zSeuMjyqWUPba33HB9T8DJ/8RzN4mnOT2XLJurupTc7WWH6c/dzjXvfB5GMLIHFIbNtz ZpAS6FmkiI43u/FMcLAiQzZVfXT3bomz0g8hk= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr650331web.45.1289930698964; Tue, 16 Nov 2010 10:04:58 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 10:04:58 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Tue, 16 Nov 2010 10:04:58 -0800 X-Google-Sender-Auth: vzdiBGHsrwYxIV4RYGtDyb46xuU Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=0016364c7a13191b8204952f65dc Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 18:05:03 -0000 --0016364c7a13191b8204952f65dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wrote= : > On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>> On 16.11.2010 16:29, John Baldwin wrote: >>> > Err, are there no longer hard links to all of the frontends for a giv= en >>> > crunch? =A0If so, that is a problem as it will make rescue much harde= r to use. >>> >>> Yes, probably this patch is not needed and it should be fixed somewhere= in >>> makefiles. But currently rescue does not have any hardlinks: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPS= NAP/cdrom/livefs/rescue/ >>> >>> And what is was before: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPS= NAP/cdrom/livefs/rescue/ >> >> That definitely needs to be fixed. > > =A0 =A0The .mk file wasn't being installed. Could someone please test > this patch for validity and commit it? > =A0 =A0More importantly, why didn't the above build process, or tinderbox > fail properly with this change? Ouch. I can definitely still see the other problem: # make install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script The second attached patch (not a superset of the first) what unbreaks it: # make -C rescue/rescue/ install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script /rescue/cat -> /rescue/rescue /rescue/chflags -> /rescue/rescue /rescue/chio -> /rescue/rescue /rescue/chmod -> /rescue/rescue /rescue/cp -> /rescue/rescue /rescue/date -> /rescue/rescue /rescue/dd -> /rescue/rescue /rescue/df -> /rescue/rescue /rescue/echo -> /rescue/rescue /rescue/ed -> /rescue/rescue /rescue/red -> /rescue/rescue /rescue/expr -> /rescue/rescue /rescue/getfacl -> /rescue/rescue /rescue/hostname -> /rescue/rescue /rescue/kenv -> /rescue/rescue /rescue/kill -> /rescue/rescue /rescue/ln -> /rescue/rescue /rescue/link -> /rescue/rescue /rescue/ls -> /rescue/rescue /rescue/mkdir -> /rescue/rescue /rescue/mv -> /rescue/rescue /rescue/pkill -> /rescue/rescue /rescue/pgrep -> /rescue/rescue /rescue/ps -> /rescue/rescue /rescue/pwd -> /rescue/rescue /rescue/realpath -> /rescue/rescue /rescue/rm -> /rescue/rescue /rescue/unlink -> /rescue/rescue /rescue/rmdir -> /rescue/rescue /rescue/setfacl -> /rescue/rescue /rescue/sh -> /rescue/rescue /rescue/stty -> /rescue/rescue /rescue/sync -> /rescue/rescue /rescue/test -> /rescue/rescue /rescue/[ -> /rescue/rescue /rescue/csh -> /rescue/rescue /rescue/tcsh -> /rescue/rescue /rescue/atacontrol -> /rescue/rescue /rescue/badsect -> /rescue/rescue /rescue/camcontrol -> /rescue/rescue /rescue/ccdconfig -> /rescue/rescue /rescue/clri -> /rescue/rescue /rescue/devfs -> /rescue/rescue /rescue/dmesg -> /rescue/rescue /rescue/dump -> /rescue/rescue /rescue/rdump -> /rescue/rescue /rescue/dumpfs -> /rescue/rescue /rescue/dumpon -> /rescue/rescue /rescue/fsck -> /rescue/rescue /rescue/fsck_ffs -> /rescue/rescue /rescue/fsck_4.2bsd -> /rescue/rescue /rescue/fsck_ufs -> /rescue/rescue /rescue/fsck_msdosfs -> /rescue/rescue /rescue/fsdb -> /rescue/rescue /rescue/fsirand -> /rescue/rescue /rescue/gbde -> /rescue/rescue /rescue/geom -> /rescue/rescue /rescue/glabel -> /rescue/rescue /rescue/gpart -> /rescue/rescue /rescue/ifconfig -> /rescue/rescue /rescue/init -> /rescue/rescue /rescue/kldconfig -> /rescue/rescue /rescue/kldload -> /rescue/rescue /rescue/kldstat -> /rescue/rescue /rescue/kldunload -> /rescue/rescue /rescue/ldconfig -> /rescue/rescue /rescue/md5 -> /rescue/rescue /rescue/mdconfig -> /rescue/rescue /rescue/mdmfs -> /rescue/rescue /rescue/mknod -> /rescue/rescue /rescue/mount -> /rescue/rescue /rescue/mount_cd9660 -> /rescue/rescue /rescue/mount_msdosfs -> /rescue/rescue /rescue/mount_nfs -> /rescue/rescue /rescue/mount_ntfs -> /rescue/rescue /rescue/mount_nullfs -> /rescue/rescue /rescue/mount_udf -> /rescue/rescue /rescue/mount_unionfs -> /rescue/rescue /rescue/newfs -> /rescue/rescue /rescue/newfs_msdos -> /rescue/rescue /rescue/nos-tun -> /rescue/rescue /rescue/ping -> /rescue/rescue /rescue/reboot -> /rescue/rescue /rescue/fastboot -> /rescue/rescue /rescue/halt -> /rescue/rescue /rescue/fasthalt -> /rescue/rescue /rescue/restore -> /rescue/rescue /rescue/rrestore -> /rescue/rescue /rescue/rcorder -> /rescue/rescue /rescue/route -> /rescue/rescue /rescue/routed -> /rescue/rescue /rescue/rtquery -> /rescue/rescue /rescue/rtsol -> /rescue/rescue /rescue/savecore -> /rescue/rescue /rescue/spppcontrol -> /rescue/rescue /rescue/swapon -> /rescue/rescue /rescue/sysctl -> /rescue/rescue /rescue/tunefs -> /rescue/rescue /rescue/umount -> /rescue/rescue /rescue/bsdlabel -> /rescue/rescue /rescue/disklabel -> /rescue/rescue /rescue/fdisk -> /rescue/rescue /rescue/dhclient -> /rescue/rescue /rescue/head -> /rescue/rescue /rescue/mt -> /rescue/rescue /rescue/sed -> /rescue/rescue /rescue/tail -> /rescue/rescue /rescue/tee -> /rescue/rescue /rescue/gzip -> /rescue/rescue /rescue/gunzip -> /rescue/rescue /rescue/gzcat -> /rescue/rescue /rescue/zcat -> /rescue/rescue /rescue/bzip2 -> /rescue/rescue /rescue/bunzip2 -> /rescue/rescue /rescue/bzcat -> /rescue/rescue /rescue/xz -> /rescue/rescue /rescue/unxz -> /rescue/rescue /rescue/lzma -> /rescue/rescue /rescue/unlzma -> /rescue/rescue /rescue/xzcat -> /rescue/rescue /rescue/lzcat -> /rescue/rescue /rescue/tar -> /rescue/rescue /rescue/vi -> /rescue/rescue /rescue/ex -> /rescue/rescue /rescue/id -> /rescue/rescue /rescue/groups -> /rescue/rescue /rescue/whoami -> /rescue/rescue /rescue/chroot -> /rescue/rescue /rescue/chown -> /rescue/rescue /rescue/chgrp -> /rescue/rescue So it looks like something tunable needs to be added to the .mk file to deal with hardlinks as this basically reenables functionality that Adrian disabled. Thanks, -Garrett --0016364c7a13191b8204952f65dc Content-Type: text/x-patch; charset=US-ASCII; name="fix-crunchgen-hardlinking.patch" Content-Disposition: attachment; filename="fix-crunchgen-hardlinking.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggl3c4zt1 SW5kZXg6IHNoYXJlL21rL2JzZC5jcnVuY2hnZW4ubWsKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWsv YnNkLmNydW5jaGdlbi5tawkocmV2aXNpb24gMjE1MzMzKQorKysgc2hhcmUvbWsvYnNkLmNydW5j aGdlbi5tawkod29ya2luZyBjb3B5KQpAQCAtNTEsMTkgKzUxLDE2IEBACiAuZWxzZQogJChPVVRQ VVRTKTogJCguQ1VSRElSKS8uLi8uLi8kKEQpLyQoUCkvTWFrZWZpbGUKIC5lbmRpZgotIyBEaXNh YmxlIGJ1aWxkaW5nIGxpbmtzIGZvciBic2Rib3ggLSB3aGF0ZXZlciBpcyBpbnN0YWxsaW5nIHRo ZSBiaW5hcmllcyBpbnRvCi0jIHRoZSBlbWJlZGRlZCBzeXN0ZW0gc2hvdWxkIChmb3Igbm93KSBk byB0aGUgbGlua2luZyB0aGVyZS4gVGhpcyBtYXkgY2hhbmdlCi0jIGluIHRoZSBmdXR1cmUuIC1h ZHJpYW4KLSMuaWZuZGVmIENSVU5DSF9TVVBQUkVTU19MSU5LXyR7UH0KLSNMSU5LUys9ICQoQklO RElSKS8kKFBST0cpICQoQklORElSKS8kKFApCi0jLmVuZGlmCi0jLmZvciBBIGluICQoQ1JVTkNI X0FMSUFTXyQoUCkpCi0jLmlmbmRlZiBDUlVOQ0hfU1VQUFJFU1NfTElOS18ke0F9Ci0jTElOS1Mr PSAkKEJJTkRJUikvJChQUk9HKSAkKEJJTkRJUikvJChBKQotIy5lbmRpZgotIy5lbmRmb3IKKy5p Zm5kZWYgQ1JVTkNIX1NVUFBSRVNTX0xJTktfJHtQfQorTElOS1MrPSAkKEJJTkRJUikvJChQUk9H KSAkKEJJTkRJUikvJChQKQorLmVuZGlmCisuZm9yIEEgaW4gJChDUlVOQ0hfQUxJQVNfJChQKSkK Ky5pZm5kZWYgQ1JVTkNIX1NVUFBSRVNTX0xJTktfJHtBfQorTElOS1MrPSAkKEJJTkRJUikvJChQ Uk9HKSAkKEJJTkRJUikvJChBKQorLmVuZGlmCiAuZW5kZm9yCiAuZW5kZm9yCisuZW5kZm9yCiAK IGFsbDogJChQUk9HKQogZXhlOiAkKFBST0cpCg== --0016364c7a13191b8204952f65dc-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 18:20:10 2010 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 74D181065696 for ; Tue, 16 Nov 2010 18:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2BC28FC1B for ; Tue, 16 Nov 2010 18:20:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E6A746B5C; Tue, 16 Nov 2010 13:20:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 30BB78A01D; Tue, 16 Nov 2010 13:20:01 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 16 Nov 2010 13:19:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201011161319.58787.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 13:20:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Nathan Vidican Subject: Re: Software interrupts; where to start 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, 16 Nov 2010 18:20:10 -0000 On Tuesday, November 16, 2010 12:08:51 pm Nathan Vidican wrote: > What I would like to do, is replace the above scenario with one wherein the > program writing to the serial port is always connected and running, but not > polling; ideally having some sort of interupt or signal triggered from > within memcached when a value is altered. Sort of a 're-sync' request > asserting that the program sending data out the serial port should 'loop > once'. I'd like to continue with the use of memcached as it provides a > simple way for multiple systems to query the values in the array as well, > (ie: some devices need not change the data, but only view it; given the > latency requirements memcached operates ideally). This trigger should be > asynchronous in that it should be fired and forgotten by memcached (by > nature of the hardware designed, no error-checking nor receipt would be > needed). > > I'm just not sure where to start? Could someone send me the right RTFM link > to start from, or perhaps suggest a better way to look at solving this > problem? Ideally any example code to look at with a simple signal or > interrupt type of handler would be great. What I'm leaning towards is > modifying memcached daemon to send a signal or trigger an interrupt of some > sort to tell the other program communicating with the device to re-poll > once. It would also be nice to have a way to trigger from other programs > too. A simple solution would be to create a pipe shared between memcached and the process that writes to the serial port. memcached would write a dummy byte to the pipe each time it updates the values. Your app could either use select/poll/kqueue or a blocking read on the pipe to sleep until memcached does an update. That requires modify memcached though. I'm not familiar enough with memcached to know if it already has some sort of signalling facility already that you could use directly. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 20:10:29 2010 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 A2A611065672; Tue, 16 Nov 2010 20:10:29 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7318FC14; Tue, 16 Nov 2010 20:10:28 +0000 (UTC) Received: by gxk9 with SMTP id 9so678098gxk.13 for ; Tue, 16 Nov 2010 12:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Dg9/UaQ0ZJR49M58x9RofQ4IlS4ca5YIZXwrZizAcWw=; b=QlOHr53TdpK/UEHaV1sB+i9S6XhVGt4phwwrYY+eTh8afXzenWIYfNAZUfI+q9pDG4 Pn0snhfb6RTyvD8c4/2s0eGt2a9QdHjEkp+zOQCzjf2jWDALbYw12x3oDI7lukhszQk7 ZR4CamJT982NbvpiQaWme0CE21ISvTeKq7GEU= 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=nw2IoGuALinMsk5q5x/ukRNGRiwHxQ0y9u27As/5uyncxcq/v50si4nAJBH1Evuke8 oL2otGjhTyLcpxYzTVYlkkdlurxdynLbWxILP2hgggehpQVlPidRfXFDoGe2/cSO4PQR F4hbRz1IgXj3zNKLWhgUYolmbELBr6CJaKTis= MIME-Version: 1.0 Received: by 10.216.93.9 with SMTP id k9mr6710672wef.89.1289938170985; Tue, 16 Nov 2010 12:09:30 -0800 (PST) Received: by 10.216.12.80 with HTTP; Tue, 16 Nov 2010 12:09:29 -0800 (PST) In-Reply-To: References: <4CE1DB90.3000502@b1c1l1.com> Date: Tue, 16 Nov 2010 14:09:29 -0600 Message-ID: From: Brandon Gooch To: Joerg Pulz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Lee , freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: [CFT+RFC] patch to buildworld with heimdal from ports 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, 16 Nov 2010 20:10:29 -0000 On Tue, Nov 16, 2010 at 2:49 AM, Joerg Pulz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Content-ID: > > On Mon, 15 Nov 2010, Brandon Gooch wrote: > >> On Mon, Nov 15, 2010 at 9:37 PM, Garrett Cooper >> wrote: >>> >>> On Mon, Nov 15, 2010 at 7:09 PM, Brandon Gooch >>> wrote: >>>> >>>> On Mon, Nov 15, 2010 at 7:17 PM, Benjamin Lee wrote: >>>>> >>>>> On 11/15/2010 02:08 PM, Joerg Pulz wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> after the security/heimdal port was updated to the current heimdal >>>>>> release and i added one missing function from base it is now possibl= e >>>>>> to >>>>>> completely buildworld src/ using the port for all Kerberos5/GSSAPI >>>>>> enabled parts. >>>>> >>>>> Hi Joerg, >>>>> >>>>> I don't think that having the base system depend on a port is the rig= ht >>>>> solution to resolving the libgssapi compatibility problems in base. >>>>> >>>>> Did you ever come across the old PR kern/147454 that I submitted in >>>>> June? =A0In it I included a src patch that replaced the base system's >>>>> libgssapi with upstream Heimdal's, which resolved all libgssapi >>>>> compatibility problems. =A0That patch is now stale, but either way I >>>>> haven't been able to draw enough attention to the issue to have it >>>>> fixed. >>>> >>>> I guess we're waiting on someone to review the patch and commit it? >>>> Hopefully someone can get this in soon, before 8.2 is released. >>>> >>>> Is there something wrong with your patch? >>> >>> Not according to another person that commented on the patch (and it >>> sounds like the experience is positive, not negative). Who's the >>> maintainer of the component? >> >> Garrett, where would one look for such an important detail? Source >> file somewhere? >> >> Joerg, how about taking over what's in base? Seems to me like you know >> what's going on, and you're maintaining the port :) >> >> BTW, I'm only beginning to dive into Kerberos on FreeBSD, so I'm not >> bringing to this discussion much wisdom :/ But I would like all of the >> pieces to work! > > Hi Brandon, > > i already started to work on updating base heimdal to a recent version wh= ich > is not the easiest task but i made some progreess. > Be patient. > > Kind regards Thanks Joerg! Patience is indeed a virtue, though I suppose I'm not too virtuous! ;) I'm sure you're work is going to make a lot of people happy! -Brandon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 20:40:03 2010 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 3FD661065809; Tue, 16 Nov 2010 20:40:03 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E9BC08FC26; Tue, 16 Nov 2010 20:40:02 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 436F1E71F5; Tue, 16 Nov 2010 20:40:02 +0000 (GMT) Received: from unknown (client-86-27-19-226.glfd.adsl.virginmedia.com [86.27.19.226]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Tue, 16 Nov 2010 20:40:01 +0000 (GMT) Date: Tue, 16 Nov 2010 20:40:00 +0000 From: Bruce Cran To: Alexander Best Message-ID: <20101116204000.00005aea@unknown> In-Reply-To: <20101022100309.GA16446@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dag-Erling, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, Alexander Motin , =?ISO-8859-1?Q?v?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 20:40:03 -0000 On Fri, 22 Oct 2010 10:03:09 +0000 Alexander Best wrote: > so how about olivers patch? it will only apply to ata devices so it's > garanteed not to break any other CAM devices (i'm thinking about the > aac controller issue). you could revert your previous shutdown work > and plug olivers patch into CAM. you might want to replace the > combination of flush/standby immediate with sleep. One problem with the code that's been committed is that the shutdown event handler doesn't get run during a suspend operation so an emergency unload still gets done when running "acpiconf -s3". -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 20:58:28 2010 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 A570B106566B for ; Tue, 16 Nov 2010 20:58:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1248FC15 for ; Tue, 16 Nov 2010 20:58:28 +0000 (UTC) Received: by ywa8 with SMTP id 8so730436ywa.13 for ; Tue, 16 Nov 2010 12:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=WO+hH2q1vQ/isxMSVywI3wLqPx5vrv8FmME7JLDdB7c=; b=fE7Lsdqku91ASCXTW/8BaX9gNbT2iLTTSC36lZu1HBRJ+4Ck2oNFiHo4UYjWCgu3Y7 X6cs0h5RwmDCsbMq2gdKOpTx7IybRLhFN8R0AcHwtSr3/YZDIKKq26Fluu81ZYsFUwAj CueOdOjRTcNnePDY/Ylaa7R1GWEqP5b2a91Fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=SCSmouk8VCRe1E267KwwgIaPeGlgDDF/1drvfPDJoSXUgoweDhQHqZBKh8O+ofYJiJ VPKV9gtAEFUyPckod7rWfTe/wf3g0DHAXzW6Wxy+648Z3RRGkEErERfzDSbyWLCNyNGd 3iUFgu+6BClA6D3YUhy2/9AbP3+frzET0vmqk= Received: by 10.150.157.20 with SMTP id f20mr12520445ybe.374.1289941107574; Tue, 16 Nov 2010 12:58:27 -0800 (PST) Received: from mark-laptop-bsd.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id p20sm207601ybe.5.2010.11.16.12.58.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 12:58:26 -0800 (PST) Date: Tue, 16 Nov 2010 15:57:45 -0500 From: Mark Johnston To: freebsd-hackers@freebsd.org Message-ID: <20101116205745.GA1365@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [call for testing] userland debug symbols 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, 16 Nov 2010 20:58:28 -0000 Hello all, I've been sitting on my changes for a while, but I think they're ready for testing at this point. They are described here: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033474.html Some minor changes from my last patch: - Changed gdb's default debug-file-directory to /usr/lib/debug. I have no problem changing this again, but this seems like a good place. - Removed hard-coded paths to strip(1) and objcopy(1) from stripbin.sh. I explicitly added /usr/bin/ to PATH. The patch is available here: www.student.cs.uwaterloo.ca/~m6johnst/patch/symbdir.patch Would anybody be willing to test this? Of particular interest is non-i386/amd64 architectures and cross-compiles. Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 22:17:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DE8701065670; Tue, 16 Nov 2010 22:17:25 +0000 (UTC) Date: Tue, 16 Nov 2010 22:17:25 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20101116221725.GA49789@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101116204000.00005aea@unknown> Cc: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , Alexander Motin , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 22:17:26 -0000 On Tue Nov 16 10, Bruce Cran wrote: > On Fri, 22 Oct 2010 10:03:09 +0000 > Alexander Best wrote: > > > so how about olivers patch? it will only apply to ata devices so it's > > garanteed not to break any other CAM devices (i'm thinking about the > > aac controller issue). you could revert your previous shutdown work > > and plug olivers patch into CAM. you might want to replace the > > combination of flush/standby immediate with sleep. > > One problem with the code that's been committed is that the shutdown > event handler doesn't get run during a suspend operation so an > emergency unload still gets done when running "acpiconf -s3". unfortunately i don't think a can help you on that one. acpi never worked for me! even 'acpiconf -s1' will hopelessly crash my system. :( cheers. alex > > -- > Bruce Cran -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 22:19:06 2010 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 86942106566B; Tue, 16 Nov 2010 22:19:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93E038FC1B; Tue, 16 Nov 2010 22:19:05 +0000 (UTC) Received: by wyb35 with SMTP id 35so404212wyb.13 for ; Tue, 16 Nov 2010 14:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rOFBbTuxnWVzfOftmlbfnyGT7hp18rmVRlPxXG5z55k=; b=bevQ/h60xMvnyZanJjyklwScfmVOnBve2A1fFFoWWJJIq0DUmuC2aJCjMgPSEsMzZH UnMFbfKbujzp+BDpkRhTLAbVa8NQunzZJezx7WsOHYee3glCcPIhMNJBFgjRuUHiPGq5 Xj6oXMszxrbMa1Hi30ohDxiXih63p28c9X8Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=H2M4odKKt7rXZGV+6LPh2En8SsCMV5LB87XYhRRRWxWoXARfHFsC3W1HbTV+ZuYqGN u57PsyoHxVYlchEUpblpM6KH9sML3xzISjQWR5dlS2AfNJxCLHZpoiMNiSpsVxBRUw1Z jkQth5GPT2XLoA833na22BWqTQCgkWq6zhbfs= MIME-Version: 1.0 Received: by 10.216.46.19 with SMTP id q19mr650148web.0.1289945944342; Tue, 16 Nov 2010 14:19:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 14:19:04 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Wed, 17 Nov 2010 06:19:04 +0800 X-Google-Sender-Auth: uiFfRJjXQAW4V5XYeqP1Z5v_KTc Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-hackers@freebsd.org, "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 22:19:06 -0000 Oops, I can't believe I committed the wrong version of this damned thing. I'll go and commit that particular un-braindamage. in a sec. Sorry everyone. Adrian On 17 November 2010 02:04, Garrett Cooper wrote: > On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wro= te: >> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>> On 16.11.2010 16:29, John Baldwin wrote: >>>> > Err, are there no longer hard links to all of the frontends for a gi= ven >>>> > crunch? =A0If so, that is a problem as it will make rescue much hard= er to use. >>>> >>>> Yes, probably this patch is not needed and it should be fixed somewher= e in >>>> makefiles. But currently rescue does not have any hardlinks: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JP= SNAP/cdrom/livefs/rescue/ >>>> >>>> And what is was before: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JP= SNAP/cdrom/livefs/rescue/ >>> >>> That definitely needs to be fixed. >> >> =A0 =A0The .mk file wasn't being installed. Could someone please test >> this patch for validity and commit it? >> =A0 =A0More importantly, why didn't the above build process, or tinderbo= x >> fail properly with this change? > > Ouch. I can definitely still see the other problem: > > # make install > install -s -o root -g wheel -m 555 =A0 rescue /rescue > install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot > install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient-= script > > The second attached patch (not a superset of the first) what unbreaks it: > > # make -C rescue/rescue/ install > install -s -o root -g wheel -m 555 =A0 rescue /rescue > install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot > install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient-= script > /rescue/cat -> /rescue/rescue > /rescue/chflags -> /rescue/rescue > /rescue/chio -> /rescue/rescue > /rescue/chmod -> /rescue/rescue > /rescue/cp -> /rescue/rescue > /rescue/date -> /rescue/rescue > /rescue/dd -> /rescue/rescue > /rescue/df -> /rescue/rescue > /rescue/echo -> /rescue/rescue > /rescue/ed -> /rescue/rescue > /rescue/red -> /rescue/rescue > /rescue/expr -> /rescue/rescue > /rescue/getfacl -> /rescue/rescue > /rescue/hostname -> /rescue/rescue > /rescue/kenv -> /rescue/rescue > /rescue/kill -> /rescue/rescue > /rescue/ln -> /rescue/rescue > /rescue/link -> /rescue/rescue > /rescue/ls -> /rescue/rescue > /rescue/mkdir -> /rescue/rescue > /rescue/mv -> /rescue/rescue > /rescue/pkill -> /rescue/rescue > /rescue/pgrep -> /rescue/rescue > /rescue/ps -> /rescue/rescue > /rescue/pwd -> /rescue/rescue > /rescue/realpath -> /rescue/rescue > /rescue/rm -> /rescue/rescue > /rescue/unlink -> /rescue/rescue > /rescue/rmdir -> /rescue/rescue > /rescue/setfacl -> /rescue/rescue > /rescue/sh -> /rescue/rescue > /rescue/stty -> /rescue/rescue > /rescue/sync -> /rescue/rescue > /rescue/test -> /rescue/rescue > /rescue/[ -> /rescue/rescue > /rescue/csh -> /rescue/rescue > /rescue/tcsh -> /rescue/rescue > /rescue/atacontrol -> /rescue/rescue > /rescue/badsect -> /rescue/rescue > /rescue/camcontrol -> /rescue/rescue > /rescue/ccdconfig -> /rescue/rescue > /rescue/clri -> /rescue/rescue > /rescue/devfs -> /rescue/rescue > /rescue/dmesg -> /rescue/rescue > /rescue/dump -> /rescue/rescue > /rescue/rdump -> /rescue/rescue > /rescue/dumpfs -> /rescue/rescue > /rescue/dumpon -> /rescue/rescue > /rescue/fsck -> /rescue/rescue > /rescue/fsck_ffs -> /rescue/rescue > /rescue/fsck_4.2bsd -> /rescue/rescue > /rescue/fsck_ufs -> /rescue/rescue > /rescue/fsck_msdosfs -> /rescue/rescue > /rescue/fsdb -> /rescue/rescue > /rescue/fsirand -> /rescue/rescue > /rescue/gbde -> /rescue/rescue > /rescue/geom -> /rescue/rescue > /rescue/glabel -> /rescue/rescue > /rescue/gpart -> /rescue/rescue > /rescue/ifconfig -> /rescue/rescue > /rescue/init -> /rescue/rescue > /rescue/kldconfig -> /rescue/rescue > /rescue/kldload -> /rescue/rescue > /rescue/kldstat -> /rescue/rescue > /rescue/kldunload -> /rescue/rescue > /rescue/ldconfig -> /rescue/rescue > /rescue/md5 -> /rescue/rescue > /rescue/mdconfig -> /rescue/rescue > /rescue/mdmfs -> /rescue/rescue > /rescue/mknod -> /rescue/rescue > /rescue/mount -> /rescue/rescue > /rescue/mount_cd9660 -> /rescue/rescue > /rescue/mount_msdosfs -> /rescue/rescue > /rescue/mount_nfs -> /rescue/rescue > /rescue/mount_ntfs -> /rescue/rescue > /rescue/mount_nullfs -> /rescue/rescue > /rescue/mount_udf -> /rescue/rescue > /rescue/mount_unionfs -> /rescue/rescue > /rescue/newfs -> /rescue/rescue > /rescue/newfs_msdos -> /rescue/rescue > /rescue/nos-tun -> /rescue/rescue > /rescue/ping -> /rescue/rescue > /rescue/reboot -> /rescue/rescue > /rescue/fastboot -> /rescue/rescue > /rescue/halt -> /rescue/rescue > /rescue/fasthalt -> /rescue/rescue > /rescue/restore -> /rescue/rescue > /rescue/rrestore -> /rescue/rescue > /rescue/rcorder -> /rescue/rescue > /rescue/route -> /rescue/rescue > /rescue/routed -> /rescue/rescue > /rescue/rtquery -> /rescue/rescue > /rescue/rtsol -> /rescue/rescue > /rescue/savecore -> /rescue/rescue > /rescue/spppcontrol -> /rescue/rescue > /rescue/swapon -> /rescue/rescue > /rescue/sysctl -> /rescue/rescue > /rescue/tunefs -> /rescue/rescue > /rescue/umount -> /rescue/rescue > /rescue/bsdlabel -> /rescue/rescue > /rescue/disklabel -> /rescue/rescue > /rescue/fdisk -> /rescue/rescue > /rescue/dhclient -> /rescue/rescue > /rescue/head -> /rescue/rescue > /rescue/mt -> /rescue/rescue > /rescue/sed -> /rescue/rescue > /rescue/tail -> /rescue/rescue > /rescue/tee -> /rescue/rescue > /rescue/gzip -> /rescue/rescue > /rescue/gunzip -> /rescue/rescue > /rescue/gzcat -> /rescue/rescue > /rescue/zcat -> /rescue/rescue > /rescue/bzip2 -> /rescue/rescue > /rescue/bunzip2 -> /rescue/rescue > /rescue/bzcat -> /rescue/rescue > /rescue/xz -> /rescue/rescue > /rescue/unxz -> /rescue/rescue > /rescue/lzma -> /rescue/rescue > /rescue/unlzma -> /rescue/rescue > /rescue/xzcat -> /rescue/rescue > /rescue/lzcat -> /rescue/rescue > /rescue/tar -> /rescue/rescue > /rescue/vi -> /rescue/rescue > /rescue/ex -> /rescue/rescue > /rescue/id -> /rescue/rescue > /rescue/groups -> /rescue/rescue > /rescue/whoami -> /rescue/rescue > /rescue/chroot -> /rescue/rescue > /rescue/chown -> /rescue/rescue > /rescue/chgrp -> /rescue/rescue > > So it looks like something tunable needs to be added to the .mk file > to deal with hardlinks as this basically reenables functionality that > Adrian disabled. > > Thanks, > -Garrett > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 22:23:58 2010 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 C54AD106564A; Tue, 16 Nov 2010 22:23:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id D1A5B8FC18; Tue, 16 Nov 2010 22:23:57 +0000 (UTC) Received: by wwb28 with SMTP id 28so154520wwb.1 for ; Tue, 16 Nov 2010 14:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PE8ie1nQIiOjYWzM8pS82w9qRpfZCDIpFPHTWuV4/NY=; b=qzZHNIhlpivw8SEXxlBBLKharIh/COVGxpzwsdBbmLW4LREcQNuCnlXcnNQc1By5i8 qesLQQPMTLfZtV1OS/lxzPgQBl37k126mevXHe6eeYonPR9AAoHMc+OfnXqL5WV2J/3C +2N5/57XrH9PmxMov8YzlbuftZxRaLw3FN5Bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gUwHl808c1dAZgnTjvjsJ99h4AkoQddUzMivoY46pHbKiJuUaL1m68XmDo3HIwID3+ rZ5+1N8IL38/IPJesldPHNN/yklPm0GpuSxihre4GVLQXedK8KH2swzr4YHwaZoh8mLi 9XB01F3vru74iyp0AmIzVo4UlJzOZ3zclhl10= MIME-Version: 1.0 Received: by 10.216.5.21 with SMTP id 21mr830194wek.20.1289946235708; Tue, 16 Nov 2010 14:23:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 14:23:55 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Wed, 17 Nov 2010 06:23:55 +0800 X-Google-Sender-Auth: UARpsTmeTUvB-FS9RwA_tikQAkA Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-hackers@freebsd.org, "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file 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, 16 Nov 2010 22:23:59 -0000 I've just committed: * stuff to re-enable the link production * installing bsd.crunchgen.mk Thanks, Adrian On 17 November 2010 06:19, Adrian Chadd wrote: > Oops, I can't believe I committed the wrong version of this damned thing. > > I'll go and commit that particular un-braindamage. in a sec. > > Sorry everyone. > > > > Adrian > > On 17 November 2010 02:04, Garrett Cooper wrote: >> On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wr= ote: >>> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>>> On 16.11.2010 16:29, John Baldwin wrote: >>>>> > Err, are there no longer hard links to all of the frontends for a g= iven >>>>> > crunch? =A0If so, that is a problem as it will make rescue much har= der to use. >>>>> >>>>> Yes, probably this patch is not needed and it should be fixed somewhe= re in >>>>> makefiles. But currently rescue does not have any hardlinks: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-J= PSNAP/cdrom/livefs/rescue/ >>>>> >>>>> And what is was before: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-J= PSNAP/cdrom/livefs/rescue/ >>>> >>>> That definitely needs to be fixed. >>> >>> =A0 =A0The .mk file wasn't being installed. Could someone please test >>> this patch for validity and commit it? >>> =A0 =A0More importantly, why didn't the above build process, or tinderb= ox >>> fail properly with this change? >> >> Ouch. I can definitely still see the other problem: >> >> # make install >> install -s -o root -g wheel -m 555 =A0 rescue /rescue >> install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot >> install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient= -script >> >> The second attached patch (not a superset of the first) what unbreaks it= : >> >> # make -C rescue/rescue/ install >> install -s -o root -g wheel -m 555 =A0 rescue /rescue >> install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot >> install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient= -script >> /rescue/cat -> /rescue/rescue >> /rescue/chflags -> /rescue/rescue >> /rescue/chio -> /rescue/rescue >> /rescue/chmod -> /rescue/rescue >> /rescue/cp -> /rescue/rescue >> /rescue/date -> /rescue/rescue >> /rescue/dd -> /rescue/rescue >> /rescue/df -> /rescue/rescue >> /rescue/echo -> /rescue/rescue >> /rescue/ed -> /rescue/rescue >> /rescue/red -> /rescue/rescue >> /rescue/expr -> /rescue/rescue >> /rescue/getfacl -> /rescue/rescue >> /rescue/hostname -> /rescue/rescue >> /rescue/kenv -> /rescue/rescue >> /rescue/kill -> /rescue/rescue >> /rescue/ln -> /rescue/rescue >> /rescue/link -> /rescue/rescue >> /rescue/ls -> /rescue/rescue >> /rescue/mkdir -> /rescue/rescue >> /rescue/mv -> /rescue/rescue >> /rescue/pkill -> /rescue/rescue >> /rescue/pgrep -> /rescue/rescue >> /rescue/ps -> /rescue/rescue >> /rescue/pwd -> /rescue/rescue >> /rescue/realpath -> /rescue/rescue >> /rescue/rm -> /rescue/rescue >> /rescue/unlink -> /rescue/rescue >> /rescue/rmdir -> /rescue/rescue >> /rescue/setfacl -> /rescue/rescue >> /rescue/sh -> /rescue/rescue >> /rescue/stty -> /rescue/rescue >> /rescue/sync -> /rescue/rescue >> /rescue/test -> /rescue/rescue >> /rescue/[ -> /rescue/rescue >> /rescue/csh -> /rescue/rescue >> /rescue/tcsh -> /rescue/rescue >> /rescue/atacontrol -> /rescue/rescue >> /rescue/badsect -> /rescue/rescue >> /rescue/camcontrol -> /rescue/rescue >> /rescue/ccdconfig -> /rescue/rescue >> /rescue/clri -> /rescue/rescue >> /rescue/devfs -> /rescue/rescue >> /rescue/dmesg -> /rescue/rescue >> /rescue/dump -> /rescue/rescue >> /rescue/rdump -> /rescue/rescue >> /rescue/dumpfs -> /rescue/rescue >> /rescue/dumpon -> /rescue/rescue >> /rescue/fsck -> /rescue/rescue >> /rescue/fsck_ffs -> /rescue/rescue >> /rescue/fsck_4.2bsd -> /rescue/rescue >> /rescue/fsck_ufs -> /rescue/rescue >> /rescue/fsck_msdosfs -> /rescue/rescue >> /rescue/fsdb -> /rescue/rescue >> /rescue/fsirand -> /rescue/rescue >> /rescue/gbde -> /rescue/rescue >> /rescue/geom -> /rescue/rescue >> /rescue/glabel -> /rescue/rescue >> /rescue/gpart -> /rescue/rescue >> /rescue/ifconfig -> /rescue/rescue >> /rescue/init -> /rescue/rescue >> /rescue/kldconfig -> /rescue/rescue >> /rescue/kldload -> /rescue/rescue >> /rescue/kldstat -> /rescue/rescue >> /rescue/kldunload -> /rescue/rescue >> /rescue/ldconfig -> /rescue/rescue >> /rescue/md5 -> /rescue/rescue >> /rescue/mdconfig -> /rescue/rescue >> /rescue/mdmfs -> /rescue/rescue >> /rescue/mknod -> /rescue/rescue >> /rescue/mount -> /rescue/rescue >> /rescue/mount_cd9660 -> /rescue/rescue >> /rescue/mount_msdosfs -> /rescue/rescue >> /rescue/mount_nfs -> /rescue/rescue >> /rescue/mount_ntfs -> /rescue/rescue >> /rescue/mount_nullfs -> /rescue/rescue >> /rescue/mount_udf -> /rescue/rescue >> /rescue/mount_unionfs -> /rescue/rescue >> /rescue/newfs -> /rescue/rescue >> /rescue/newfs_msdos -> /rescue/rescue >> /rescue/nos-tun -> /rescue/rescue >> /rescue/ping -> /rescue/rescue >> /rescue/reboot -> /rescue/rescue >> /rescue/fastboot -> /rescue/rescue >> /rescue/halt -> /rescue/rescue >> /rescue/fasthalt -> /rescue/rescue >> /rescue/restore -> /rescue/rescue >> /rescue/rrestore -> /rescue/rescue >> /rescue/rcorder -> /rescue/rescue >> /rescue/route -> /rescue/rescue >> /rescue/routed -> /rescue/rescue >> /rescue/rtquery -> /rescue/rescue >> /rescue/rtsol -> /rescue/rescue >> /rescue/savecore -> /rescue/rescue >> /rescue/spppcontrol -> /rescue/rescue >> /rescue/swapon -> /rescue/rescue >> /rescue/sysctl -> /rescue/rescue >> /rescue/tunefs -> /rescue/rescue >> /rescue/umount -> /rescue/rescue >> /rescue/bsdlabel -> /rescue/rescue >> /rescue/disklabel -> /rescue/rescue >> /rescue/fdisk -> /rescue/rescue >> /rescue/dhclient -> /rescue/rescue >> /rescue/head -> /rescue/rescue >> /rescue/mt -> /rescue/rescue >> /rescue/sed -> /rescue/rescue >> /rescue/tail -> /rescue/rescue >> /rescue/tee -> /rescue/rescue >> /rescue/gzip -> /rescue/rescue >> /rescue/gunzip -> /rescue/rescue >> /rescue/gzcat -> /rescue/rescue >> /rescue/zcat -> /rescue/rescue >> /rescue/bzip2 -> /rescue/rescue >> /rescue/bunzip2 -> /rescue/rescue >> /rescue/bzcat -> /rescue/rescue >> /rescue/xz -> /rescue/rescue >> /rescue/unxz -> /rescue/rescue >> /rescue/lzma -> /rescue/rescue >> /rescue/unlzma -> /rescue/rescue >> /rescue/xzcat -> /rescue/rescue >> /rescue/lzcat -> /rescue/rescue >> /rescue/tar -> /rescue/rescue >> /rescue/vi -> /rescue/rescue >> /rescue/ex -> /rescue/rescue >> /rescue/id -> /rescue/rescue >> /rescue/groups -> /rescue/rescue >> /rescue/whoami -> /rescue/rescue >> /rescue/chroot -> /rescue/rescue >> /rescue/chown -> /rescue/rescue >> /rescue/chgrp -> /rescue/rescue >> >> So it looks like something tunable needs to be added to the .mk file >> to deal with hardlinks as this basically reenables functionality that >> Adrian disabled. >> >> Thanks, >> -Garrett >> > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:16:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7B4021065693; Tue, 16 Nov 2010 23:16:50 +0000 (UTC) Date: Tue, 16 Nov 2010 23:16:50 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101116231650.GA58652@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: sched_autogroup_enabled 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, 16 Nov 2010 23:16:50 -0000 hi everybody, i just read up on the very popular linux 200 line sched patch that everyone's talking about right now [1]. especially the videos posted on the seond page of [1] are very impressive. did somebody dive into the patch and see if SCHED_ULE could benefit from it? cheers. alex [1] http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:23:53 2010 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 D2A411065674; Tue, 16 Nov 2010 23:23:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 302428FC28; Tue, 16 Nov 2010 23:23:52 +0000 (UTC) Received: by ewy3 with SMTP id 3so792393ewy.13 for ; Tue, 16 Nov 2010 15:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=k2jGH1Q7e3/GVc30qnzMF1CfnVd9hzgVTyYY3Eg+6Uc=; b=Z3L/KRBtDySjJDYVXyLf/5on75ggqoSfy1J9xSg1GHiHqlcu1ZCQdKVbYRPSw3n2KU +cbjRtKuXC3tesma6k780ylyjYf5GyByk/PAZaORC/kohVhO/1zQA+GHValbMYzu46A5 4DQREOYOF4VSGxz7s7uJimNlMGia8Ttv6jocg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LfnPN/rJAGu+eRWh5BsNiQfhtRuhpZWGFB6xiOL+EFJitJmeXEj+8Cc1hGfcJNkVBq qLTWQcXrXhZGFCa/J9TVMfevwDU3/tjI9ulzF2gu9hZiLyi5qtlrYLUCToEHT7nk7xtx V31gLcpztjB2CF9Fm6IZF1lFNEIdxEHsIoa+s= Received: by 10.204.122.65 with SMTP id k1mr8241628bkr.151.1289949831988; Tue, 16 Nov 2010 15:23:51 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm879570bki.1.2010.11.16.15.23.49 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 15:23:50 -0800 (PST) Sender: Alexander Motin Message-ID: <4CE3125E.1000307@FreeBSD.org> Date: Wed, 17 Nov 2010 01:23:10 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> In-Reply-To: <20101116221725.GA49789@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgra?=, =?ISO-8859-1?Q?v?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 23:23:53 -0000 Alexander Best wrote: > On Tue Nov 16 10, Bruce Cran wrote: >> On Fri, 22 Oct 2010 10:03:09 +0000 >> Alexander Best wrote: >> >>> so how about olivers patch? it will only apply to ata devices so it's >>> garanteed not to break any other CAM devices (i'm thinking about the >>> aac controller issue). you could revert your previous shutdown work >>> and plug olivers patch into CAM. you might want to replace the >>> combination of flush/standby immediate with sleep. >> One problem with the code that's been committed is that the shutdown >> event handler doesn't get run during a suspend operation so an >> emergency unload still gets done when running "acpiconf -s3". > > unfortunately i don't think a can help you on that one. acpi never worked for > me! even 'acpiconf -s1' will hopelessly crash my system. :( It is not necessary to have fully working suspend to work on this. Bounce mode should be enough. If bounce is also not working for you - it definitely should be the first thing to fix. >From the other side ATM I see no good approach to this, as soon as CAM devices are not present on NewBus to handle suspend events. Unless SIM drivers will expose those events to CAM in some way. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:50:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E565A1065672; Tue, 16 Nov 2010 23:50:51 +0000 (UTC) Date: Tue, 16 Nov 2010 23:50:51 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101116235051.GA62744@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE3125E.1000307@FreeBSD.org> Cc: Bruce Cran , Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 23:50:52 -0000 On Wed Nov 17 10, Alexander Motin wrote: > Alexander Best wrote: > > On Tue Nov 16 10, Bruce Cran wrote: > >> On Fri, 22 Oct 2010 10:03:09 +0000 > >> Alexander Best wrote: > >> > >>> so how about olivers patch? it will only apply to ata devices so it's > >>> garanteed not to break any other CAM devices (i'm thinking about the > >>> aac controller issue). you could revert your previous shutdown work > >>> and plug olivers patch into CAM. you might want to replace the > >>> combination of flush/standby immediate with sleep. > >> One problem with the code that's been committed is that the shutdown > >> event handler doesn't get run during a suspend operation so an > >> emergency unload still gets done when running "acpiconf -s3". > > > > unfortunately i don't think a can help you on that one. acpi never worked for > > me! even 'acpiconf -s1' will hopelessly crash my system. :( > > It is not necessary to have fully working suspend to work on this. > Bounce mode should be enough. If bounce is also not working for you - it > definitely should be the first thing to fix. bounce mode? sorry i'm lost. > > >From the other side ATM I see no good approach to this, as soon as CAM > devices are not present on NewBus to handle suspend events. Unless SIM > drivers will expose those events to CAM in some way. > > -- > Alexander Motin -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:52:06 2010 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 28D5F106566C; Tue, 16 Nov 2010 23:52:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D86118FC08; Tue, 16 Nov 2010 23:52:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C1E3C1FFC38; Tue, 16 Nov 2010 23:52:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 9CE6B844A3; Wed, 17 Nov 2010 00:52:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: rank1seeker@gmail.com References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> <4CE22182.7090008@freebsd.org> <86sjz18v5p.fsf@ds4.des.no> <20101116.135453.625.1@DEV> Date: Wed, 17 Nov 2010 00:52:04 +0100 In-Reply-To: <20101116.135453.625.1@DEV> (rank1seeker@gmail.com's message of "Tue, 16 Nov 2010 14:54:53 +0100") Message-ID: <86fwv0968r.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: Unhappy with cross-worlding 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, 16 Nov 2010 23:52:06 -0000 rank1seeker@gmail.com writes: > After I've created, bootable binary USB amd64 on i386, I wanted do a=20 > freebsd-update, on memstick, via '-b' flag, to avoid doing it later. > > Conclusion: > Don't use '-b' at all, as it fetches updates for LOCAL running OS > (i386) Well, yes. That's what it's for. It was never meant for cross- upgrades. You can fool it by setting the correct UNAME_* envars, though, if you know what you're doing, but that's not how it's intended to be used. > This cross-worlding is a total mess! > Nothing works. Nothing that you've tried works because everything you tried was wrong. You can't just make something up and expect it to work because you want it to work. Read the documentation and use the proper tool for the proper job. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:54:21 2010 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 DE658106564A; Tue, 16 Nov 2010 23:54:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC008FC15; Tue, 16 Nov 2010 23:54:20 +0000 (UTC) Received: by wwb28 with SMTP id 28so239008wwb.1 for ; Tue, 16 Nov 2010 15:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=CAsh87QnSh0xlN9xH1lYvZk8LW196wdT3vkMkiB2w/s=; b=a5WdI9zxK66bAw4lVt1pZeVwIUZdvYXH6ib4SSOR4htTdGN7y+1ToWL8ACNnoxBSAz XvLK/F9vyRtAKNQgk9Dv7cwgMIk5hVcE4vWhOv1gTOqD8j7u4PjmVm0tbBRAzSzbTo3M Urgkb/YQWF8o++laweWQALdHlHNJrepDvp4MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uZjHHcGYRsFzSwHgYSOIiMvC0ILdfJ72TxNXaDAzV3M26anKj/awEKpNYpTXxnMSVn uNKVG8Qau9gRxOoVfgJ/JX+Niq+5Igy0ucUqBtGNYWAGAcW8w9gwOKUECmswjnkXjTQT Eac5PKnV2+1NgO47JJsUCV62Kz5A/uNNoJB7k= MIME-Version: 1.0 Received: by 10.216.35.139 with SMTP id u11mr1114440wea.15.1289951659768; Tue, 16 Nov 2010 15:54:19 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 15:54:19 -0800 (PST) In-Reply-To: <20101116235051.GA62744@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> Date: Tue, 16 Nov 2010 15:54:19 -0800 X-Google-Sender-Auth: P1PYF8XhcejpE7OyYN1EBj5O1ps Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, Alexander Motin , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 23:54:22 -0000 On Tue, Nov 16, 2010 at 3:50 PM, Alexander Best wrote: > On Wed Nov 17 10, Alexander Motin wrote: >> Alexander Best wrote: >> > On Tue Nov 16 10, Bruce Cran wrote: >> >> On Fri, 22 Oct 2010 10:03:09 +0000 >> >> Alexander Best wrote: >> >> >> >>> so how about olivers patch? it will only apply to ata devices so it's >> >>> garanteed not to break any other CAM devices (i'm thinking about the >> >>> aac controller issue). you could revert your previous shutdown work >> >>> and plug olivers patch into CAM. you might want to replace the >> >>> combination of flush/standby immediate with sleep. >> >> One problem with the code that's been committed is that the shutdown >> >> event handler doesn't get run during a suspend operation so an >> >> emergency unload still gets done when running "acpiconf -s3". >> > >> > unfortunately i don't think a can help you on that one. acpi never worked for >> > me! even 'acpiconf -s1' will hopelessly crash my system. :( >> >> It is not necessary to have fully working suspend to work on this. >> Bounce mode should be enough. If bounce is also not working for you - it >> definitely should be the first thing to fix. > > bounce mode? sorry i'm lost. $ sysctl debug.acpi.suspend_bounce debug.acpi.suspend_bounce: 0 From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 23:55:58 2010 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 DE0B2106566B; Tue, 16 Nov 2010 23:55:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2118E8FC08; Tue, 16 Nov 2010 23:55:56 +0000 (UTC) Received: by bwz2 with SMTP id 2so865431bwz.13 for ; Tue, 16 Nov 2010 15:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=NRA9dOO3F13JIvx1nKPHR9eFDhyY10KShSd0FKntHkY=; b=wHBLrv6nK4Le/Ve/rTveGR/r3no+wvdoL//qvFSWaSg6vynwrbV8JlWG9WxtqxoOLr Qrq3jimKGfHZIh6ySy3w0ADjSb7gSHLQUQ+eMZTy7AcGiCNjAI6A2JXAH2W+USVs8I4s MAeePbPE58wHtB+2rj+9ykM+E2kWJC822SlBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=xeRHJ+Xe5pa2MDcydCNygXwprsaq4xls33zgho+OXVXRAhdLz9TUelM4wmp9rw6VCb z8XL6nbiuwCdC8pebxJGYGIAis9x+1ENEX9kOddLVh/dhG6fi1RO9rvQGa724v7JwBDV SC4chlvMTh1rwvzzQba9BBMJse6JOoD+6Se4Y= Received: by 10.204.112.10 with SMTP id u10mr8104079bkp.146.1289951755707; Tue, 16 Nov 2010 15:55:55 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g8sm889932bkg.11.2010.11.16.15.55.53 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 15:55:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4CE319E3.4040705@FreeBSD.org> Date: Wed, 17 Nov 2010 01:55:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> In-Reply-To: <20101116235051.GA62744@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgra?=, =?ISO-8859-1?Q?v?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 16 Nov 2010 23:55:58 -0000 Alexander Best wrote: > On Wed Nov 17 10, Alexander Motin wrote: >> Alexander Best wrote: >>> On Tue Nov 16 10, Bruce Cran wrote: >>>> On Fri, 22 Oct 2010 10:03:09 +0000 >>>> Alexander Best wrote: >>>> >>>>> so how about olivers patch? it will only apply to ata devices so it's >>>>> garanteed not to break any other CAM devices (i'm thinking about the >>>>> aac controller issue). you could revert your previous shutdown work >>>>> and plug olivers patch into CAM. you might want to replace the >>>>> combination of flush/standby immediate with sleep. >>>> One problem with the code that's been committed is that the shutdown >>>> event handler doesn't get run during a suspend operation so an >>>> emergency unload still gets done when running "acpiconf -s3". >>> unfortunately i don't think a can help you on that one. acpi never worked for >>> me! even 'acpiconf -s1' will hopelessly crash my system. :( >> It is not necessary to have fully working suspend to work on this. >> Bounce mode should be enough. If bounce is also not working for you - it >> definitely should be the first thing to fix. > > bounce mode? sorry i'm lost. sysctl debug.acpi.suspend_bounce=1 It will make system to wake up back immediately after suspending all devices, instead of transition to requested S-state. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 17 01:09:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E0D101065672; Wed, 17 Nov 2010 01:09:16 +0000 (UTC) Date: Wed, 17 Nov 2010 01:09:16 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101117010916.GA73392@freebsd.org> References: <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> <4CE319E3.4040705@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE319E3.4040705@FreeBSD.org> Cc: Bruce Cran , Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 17 Nov 2010 01:09:17 -0000 On Wed Nov 17 10, Alexander Motin wrote: > Alexander Best wrote: > > On Wed Nov 17 10, Alexander Motin wrote: > >> Alexander Best wrote: > >>> On Tue Nov 16 10, Bruce Cran wrote: > >>>> On Fri, 22 Oct 2010 10:03:09 +0000 > >>>> Alexander Best wrote: > >>>> > >>>>> so how about olivers patch? it will only apply to ata devices so it's > >>>>> garanteed not to break any other CAM devices (i'm thinking about the > >>>>> aac controller issue). you could revert your previous shutdown work > >>>>> and plug olivers patch into CAM. you might want to replace the > >>>>> combination of flush/standby immediate with sleep. > >>>> One problem with the code that's been committed is that the shutdown > >>>> event handler doesn't get run during a suspend operation so an > >>>> emergency unload still gets done when running "acpiconf -s3". > >>> unfortunately i don't think a can help you on that one. acpi never worked for > >>> me! even 'acpiconf -s1' will hopelessly crash my system. :( > >> It is not necessary to have fully working suspend to work on this. > >> Bounce mode should be enough. If bounce is also not working for you - it > >> definitely should be the first thing to fix. > > > > bounce mode? sorry i'm lost. > > sysctl debug.acpi.suspend_bounce=1 > > It will make system to wake up back immediately after suspending all > devices, instead of transition to requested S-state. thanks. i'll investigate a little bit regarding this issue. under single user mode 'acpiconf -s 1' works with and without bounce mode set. under multi user mode however both modes fail. i've made sure kldstat reports the same modules loaded both under single and multi user mode so it seems no module (i suspected nvidia.ko or rtc.ko) is causing the acpi issue in multi user mode. maybe HAL is causing problems. i'll check that out. cheers. alex > > -- > Alexander Motin -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 17 03:07:11 2010 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 79F9D1065673; Wed, 17 Nov 2010 03:07:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AEACF8FC18; Wed, 17 Nov 2010 03:07:10 +0000 (UTC) Received: by wwd20 with SMTP id 20so1493126wwd.31 for ; Tue, 16 Nov 2010 19:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HOAX9yMStPrnvHc2fKb7Q3ZH5TwmPb9EXEblnBgPlss=; b=j6stnoYdkAVPxWD6LNBmNzt/V/AsaIPcZetLoxjItY4xORhBgDUOOgkcSe1VBTmL5/ RMISx8eUTIEL8cEnyHQoGoBUUoYVcaxLMcYpSRC/GtabOiR2VEfxXSwlzjSYm76UquDJ 6XTVh7u8E15vB9p0DwTvX9kWAA3NbmS1BAdHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=gYCPQAocktbZ4zBwLqkVO7jppVnKL7JxxqxFyNXiY+tcT5wEiH2PQ1blATJovvODe9 E/IB9OO3wF7AM992uB0NDmKKHKiCqFosToZD50G2IbziJ6x11j2tnEqgXpwt9j58ZOYG qaZg3bcA8sDcvVKXdzCucvtU5wXlcJP5/uAH8= MIME-Version: 1.0 Received: by 10.216.142.131 with SMTP id i3mr1132874wej.5.1289963229083; Tue, 16 Nov 2010 19:07:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 19:07:09 -0800 (PST) In-Reply-To: <19680.8138.582316.245120@gossamer.timing.com> References: <19680.8138.582316.245120@gossamer.timing.com> Date: Wed, 17 Nov 2010 11:07:09 +0800 X-Google-Sender-Auth: NtB3hwy-bl4gpj2aXNFar1oUPss Message-ID: From: Adrian Chadd To: John Hein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current , freebsd-embedded@freebsd.org Subject: Re: The path is now set for "busybox", FreeBSD style 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, 17 Nov 2010 03:07:11 -0000 Nope. it's easy. That's why I've done it. Adrian On 15 November 2010 01:43, John Hein wrote: > Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > > I've committed the below changes to -HEAD. You can now create and build > your > > own busybox style binary system, completely cross-compiled within the > > existing Make framework. It isn't as impressive as it sounds though - a > lot > > of the framework is already there from just building crunchgen'ed > > rescue/sysinstall binaries. > > > > There's a few things which should be done. Specifically, being able to > build > > an alternative set of libraries before building the crunchgen target. > The > > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, > etc > > but you may not want your crunch'ed image to have them. To do this right > > now, you have to disable these features in the main build. That may be > OK > > for some. > > > > But just to stress it - I've got a couple of access point images at home > > running a crunchgen'ed environment under MIPS and besides the obvious > binary > > bloat, it works perfectly well. Besides a cut-down startup framework, > the > > image cross-builds entirely from the base FreeBSD source tree. > > > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > > Makefile scripts online to try. > > That's great. > I assume it be not be hard for someone to take your scripts as a > starting point and create a sysutils/bsdbox akin to sysutils/busybox? > From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 17 07:02:26 2010 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 D1DA21065673 for ; Wed, 17 Nov 2010 07:02:26 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9448FC12 for ; Wed, 17 Nov 2010 07:02:25 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAH72N0I006843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2010 18:02:24 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id oAH72Mrc063022; Wed, 17 Nov 2010 18:02:22 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id oAH72MCS063021; Wed, 17 Nov 2010 18:02:22 +1100 (EST) (envelope-from peter) Date: Wed, 17 Nov 2010 18:02:22 +1100 From: Peter Jeremy To: rank1seeker@gmail.com Message-ID: <20101117070222.GA62380@server.vk2pj.dyndns.org> References: <4CA4C63F.4070503@icyb.net.ua> <20101116.022422.921.1@DEV> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20101116.022422.921.1@DEV> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Unhappy with cross-worlding 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, 17 Nov 2010 07:02:26 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Nov-16 03:24:22 +0100, rank1seeker@gmail.com wrote: >I decided to go for amd64 (it's name, is so deceiving, that I've just=20 >recently, accidentaly figured out, that it can be used, with intel CPUs,= =20 >too) :P Well, FreeBSD had support for the amd64 before Intel licensed the architecture from AMD and renamed it. By the time Intel had called it EM64T, the FreeBSD Project decided it was too late to rename its port. That said, this has caused a degree of confusion over the years. --=20 Peter Jeremy --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzjff4ACgkQ/opHv/APuIfLgQCfegS7zHQVzZBYCPbdSXr+ViPd SDkAoLYAOd9h4xOZ/9WW5YkYmppGrS+K =4Ift -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 17 15:37:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7ED101065674; Wed, 17 Nov 2010 15:37:00 +0000 (UTC) Date: Wed, 17 Nov 2010 15:37:00 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101117153700.GA86165@freebsd.org> References: <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> <4CE319E3.4040705@FreeBSD.org> <20101117010916.GA73392@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101117010916.GA73392@freebsd.org> Cc: Bruce Cran , Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 17 Nov 2010 15:37:00 -0000 On Wed Nov 17 10, Alexander Best wrote: > On Wed Nov 17 10, Alexander Motin wrote: > > Alexander Best wrote: > > > On Wed Nov 17 10, Alexander Motin wrote: > > >> Alexander Best wrote: > > >>> On Tue Nov 16 10, Bruce Cran wrote: > > >>>> On Fri, 22 Oct 2010 10:03:09 +0000 > > >>>> Alexander Best wrote: > > >>>> > > >>>>> so how about olivers patch? it will only apply to ata devices so it's > > >>>>> garanteed not to break any other CAM devices (i'm thinking about the > > >>>>> aac controller issue). you could revert your previous shutdown work > > >>>>> and plug olivers patch into CAM. you might want to replace the > > >>>>> combination of flush/standby immediate with sleep. > > >>>> One problem with the code that's been committed is that the shutdown > > >>>> event handler doesn't get run during a suspend operation so an > > >>>> emergency unload still gets done when running "acpiconf -s3". > > >>> unfortunately i don't think a can help you on that one. acpi never worked for > > >>> me! even 'acpiconf -s1' will hopelessly crash my system. :( > > >> It is not necessary to have fully working suspend to work on this. > > >> Bounce mode should be enough. If bounce is also not working for you - it > > >> definitely should be the first thing to fix. > > > > > > bounce mode? sorry i'm lost. > > > > sysctl debug.acpi.suspend_bounce=1 > > > > It will make system to wake up back immediately after suspending all > > devices, instead of transition to requested S-state. > > thanks. i'll investigate a little bit regarding this issue. under single user > mode 'acpiconf -s 1' works with and without bounce mode set. > > under multi user mode however both modes fail. i've made sure kldstat reports > the same modules loaded both under single and multi user mode so it seems no > module (i suspected nvidia.ko or rtc.ko) is causing the acpi issue in multi > user mode. maybe HAL is causing problems. i'll check that out. alexander leidinger informd me that the cause for this might be the fact that the kernel modules might be loaded in single user mode, but they're not being accessed. since i read somewhere that snd_hda might be causing problems with acpi i stopped the musicpd daemon and unloaded snd_hda ans sound. doing 'acpiconf -s1' didn't stall the system (i set debug.acpi.suspend_bounce=1) and my system came backup again. so snd_hda/sound are defanetly causing problems for acpi. however they are not the only modules causing problems. after the system came back the following message was printed repeatedlyy to the console: swap_pager: indefinite wait buffer ... although my usb keyboard was working i couldn't perform certain actions: 1) switching to a differnt tty worked, but i couldn't log in (input was simply ignored) 2) i could enter chars on ttyv0, but ctrl+alt+del didn't do anything so i had to do a hard reset. cheers. alex > > cheers. > alex > > > > > -- > > Alexander Motin > > -- > a13x -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 17 16:23:14 2010 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 C542A10656A8 for ; Wed, 17 Nov 2010 16:23:14 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 917AC8FC0C for ; Wed, 17 Nov 2010 16:23:14 +0000 (UTC) Received: by iwn39 with SMTP id 39so2432594iwn.13 for ; Wed, 17 Nov 2010 08:23:13 -0800 (PST) Received: by 10.231.10.200 with SMTP id q8mr6598261ibq.144.1290009604585; Wed, 17 Nov 2010 08:00:04 -0800 (PST) Received: from tech304 (supranet-tech.secure-on.net [66.170.8.18]) by mx.google.com with ESMTPS id gy41sm2349240ibb.23.2010.11.17.08.00.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Nov 2010 08:00:03 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> <4CE319E3.4040705@FreeBSD.org> <20101117010916.GA73392@freebsd.org> <20101117153700.GA86165@freebsd.org> Date: Wed, 17 Nov 2010 10:00:02 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20101117153700.GA86165@freebsd.org> User-Agent: Opera Mail/11.00 (FreeBSD) Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 17 Nov 2010 16:23:14 -0000 On Wed, 17 Nov 2010 09:37:00 -0600, Alexander Best wrote: > 1) switching to a differnt tty worked, but i couldn't log in (input was > simply > ignored) I don't mean to derail this thread if this is completely unrelated, but we've been having issues with FreeBSD 8.0 and 8.1 dying on our ESX 4.0 cluster. The usual result is that the machine stops responding to all network activity and at the console you can switch ttys but it doesn't accept any input. We can't find any absolute hard evidence yet, but we think it might have to do with the preferred path changing to the SAN and FreeBSD freaking out. Could this possibly be boiling down to the same core issue? Regards, Mark From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 18 18:58:37 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5E6261065695; Thu, 18 Nov 2010 18:58:37 +0000 (UTC) Date: Thu, 18 Nov 2010 18:58:37 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101118185837.GA44549@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline Subject: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc 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, 18 Nov 2010 18:58:37 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline this change has been discussed on developers@. cheers. alex -- a13x --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ObsoleteFiles.inc.diff" diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc index e358ed9..106c10e 100644 --- a/ObsoleteFiles.inc +++ b/ObsoleteFiles.inc @@ -13,6 +13,12 @@ # # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. # +# Before you commit changes to this file please check, if any entries in +# tools/build/mk/OptionalObsoleteFiles.inc can be removed. The following +# command was proposed by Dmitry Morozovsky: +# ( grep '+=' /usr/src/ObsoleteFiles.inc | sort -u ; \ +# grep '+=' /usr/src/tools/build/mk/OptionalObsoleteFiles.inc | sort -u) | \ +# sort | uniq -d # 20101112: vgonel(9) has gone to private API a while ago OLD_FILES+=usr/share/man/man9/vgonel.9.gz @@ -1634,7 +1640,7 @@ OLD_DIRS+=usr/include/c++/3.4 OLD_FILES+=usr/sbin/zfs OLD_FILES+=usr/sbin/zpool # 20070423: rc.bluetooth (examples) removed -OLD_FILES+=usr/share/examples/netgraph/bluetooth/rc.bluetooth +OLD_FILES+=usr/share/examples/netgraph/bluetooth/rc.bluetooth # 20070421: worm.4 removed OLD_FILES+=usr/share/man/man4/worm.4.gz # 20070417: trunk(4) renamed to lagg(4) --6c2NcOVqGQ03X4Wi-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 18 20:51:53 2010 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 9ACB51065679 for ; Thu, 18 Nov 2010 20:51:53 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56C6D8FC15 for ; Thu, 18 Nov 2010 20:51:53 +0000 (UTC) Received: by iwn39 with SMTP id 39so4125351iwn.13 for ; Thu, 18 Nov 2010 12:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Eq5CKXXkrMNBWbiLLsTHCOPGDcG6qWyc3T3fpM6wIk0=; b=Oh7ppN9SeyjdoiabyDLpVhS+fv0N1+aE0nQV/IffO/kAZFVCMhPC7oUfAkLvBZlkjq Lh/xfr0Vms1N/JJIpUpHtPtc8h32S30ddYZLnYnURycuVeU0AEnWbnckgp/g0hPtEYXc sl2yeKRI/m8rBt4pEOAObNht5gUzKANTfaRz4= 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=njVnmueiXbBJkn+99S+rHi/78VRJeh3MiD1r0NFa3T6z2z5gnK06WippvsBSZwfajR 10aF2jVfg36rkxDQt0y0bHHiLvH73tmBshQXE2chsZ+yiCRxbL0MS50FF6QJ8FhIY27O R8gv0iDc6BK8nCt6VJDdm/JU491uYZYlBM9/E= MIME-Version: 1.0 Received: by 10.231.15.75 with SMTP id j11mr1297377iba.45.1290113512612; Thu, 18 Nov 2010 12:51:52 -0800 (PST) Received: by 10.231.34.135 with HTTP; Thu, 18 Nov 2010 12:51:52 -0800 (PST) In-Reply-To: <20101116231650.GA58652@freebsd.org> References: <20101116231650.GA58652@freebsd.org> Date: Thu, 18 Nov 2010 21:51:52 +0100 Message-ID: From: Harald Servat To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: sched_autogroup_enabled 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, 18 Nov 2010 20:51:53 -0000 Alexander (& rest of the list), -performance has a thread about this topic. If you're interested, you can take a look there. Here's the URL http://lists.freebsd.org/pipermail/freebsd-performance/2010-November/004067.html Regards. 2010/11/17 Alexander Best > hi everybody, > > i just read up on the very popular linux 200 line sched patch that > everyone's > talking about right now [1]. > > especially the videos posted on the seond page of [1] are very impressive. > did > somebody dive into the patch and see if SCHED_ULE could benefit from it? > > cheers. > alex > > [1] > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > -- > a13x > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 18 21:24:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 12C9C10656A6; Thu, 18 Nov 2010 21:24:51 +0000 (UTC) Date: Thu, 18 Nov 2010 21:24:51 +0000 From: Alexander Best To: Harald Servat Message-ID: <20101118212451.GA77462@freebsd.org> References: <20101116231650.GA58652@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: sched_autogroup_enabled 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, 18 Nov 2010 21:24:51 -0000 On Thu Nov 18 10, Harald Servat wrote: > Alexander (& rest of the list), > > -performance has a thread about this topic. If you're interested, you can > take a look there. Here's the URL thanks for the hint. :) > > http://lists.freebsd.org/pipermail/freebsd-performance/2010-November/004067.html > > Regards. > > 2010/11/17 Alexander Best > > > hi everybody, > > > > i just read up on the very popular linux 200 line sched patch that > > everyone's > > talking about right now [1]. > > > > especially the videos posted on the seond page of [1] are very impressive. > > did > > somebody dive into the patch and see if SCHED_ULE could benefit from it? > > > > cheers. > > alex > > > > [1] > > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > > > -- > > a13x > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > > > -- > _________________________________________________________________ > Fry: You can see how I lived before I met you. > Bender: You lived before you met me?! > Fry: Yeah, lots of people did. > Bender: Really?! -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 01:19:33 2010 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 B3940106566C for ; Fri, 19 Nov 2010 01:19:33 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 672B08FC17 for ; Fri, 19 Nov 2010 01:19:33 +0000 (UTC) Received: by qyk9 with SMTP id 9so156454qyk.13 for ; Thu, 18 Nov 2010 17:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=i/Tu+P2eUFMFVXKW2DyDCq6famBIg65saWxLQ8sj9D4=; b=omE/xtOGj64xZdVKJix9B1clw8phg1rvFZNK2n3YojEWXHvFGEdGMPpXaWWT5Fj96m MacSfGCD06AgSTUfkKjpGTIWtqfovNoHTLULFW82dUodWaMrhTn8pJQD/78OIJzwWw+Q YSQSNajaFuqacxvihAQyrxiX/EKpDKCX7C4/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=Ua+WuiiFCgjJu/Heaem1orm5ZZJ4uKAi46ilbf9KT48etNJ1lK07/kIZ6e5duKxj9F nAtWs10QeHQDC3VXv2AcHE9Xuk6HDhwFyn0xaBSAxcHKoFrl+EL3wKkXneOuT8qI1NjN V1K1YWPKjVkO2Snga6VdsPxfo98yBKnOVPNU4= Received: by 10.224.182.137 with SMTP id cc9mr1135969qab.320.1290129572469; Thu, 18 Nov 2010 17:19:32 -0800 (PST) Received: from localhost ([208.53.142.42]) by mx.google.com with ESMTPS id x9sm623540qco.34.2010.11.18.17.19.30 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 17:19:32 -0800 (PST) From: Anonymous To: Alexander Best References: <20101118185837.GA44549@freebsd.org> Date: Fri, 19 Nov 2010 04:19:16 +0300 In-Reply-To: <20101118185837.GA44549@freebsd.org> (Alexander Best's message of "Thu, 18 Nov 2010 18:58:37 +0000") Message-ID: <86y68q3yaz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc 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, 19 Nov 2010 01:19:33 -0000 Alexander Best writes: > diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc > index e358ed9..106c10e 100644 > --- a/ObsoleteFiles.inc > +++ b/ObsoleteFiles.inc > @@ -13,6 +13,12 @@ > # > # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. > # > +# Before you commit changes to this file please check, if any entries in > +# tools/build/mk/OptionalObsoleteFiles.inc can be removed. The following > +# command was proposed by Dmitry Morozovsky: > +# ( grep '+=' /usr/src/ObsoleteFiles.inc | sort -u ; \ > +# grep '+=' /usr/src/tools/build/mk/OptionalObsoleteFiles.inc | sort -u) | \ > +# sort | uniq -d An easier way to check duplicates that understands `.if ${TARGET_ARCH}...' $ make -V OLD_FILES -V OLD_LIBS -V OLD_DIRS \ -f Makefile.inc1 check-old \ | sed 'y/ /\n/' | sort | uniq -d And there are a number of false positives usr/include/c++/3.4/ext/demangle.h usr/include/rune.h usr/lib/libkse.so.1 usr/lib/libpcap.so.3 usr/lib/snmp_atm.so.3 usr/lib/snmp_mibII.so.3 usr/lib/snmp_netgraph.so.3 usr/lib/snmp_pf.so.3 usr/share/man/man3/exp10.3.gz usr/share/man/man3/exp10f.3.gz usr/share/man/man3/fgetrune.3.gz usr/share/man/man3/fpsetsticky.3.gz usr/share/man/man3/fputrune.3.gz usr/share/man/man3/fungetrune.3.gz usr/share/man/man3/gss_krb5_compat_des3_mic.3.gz usr/share/man/man3/gss_krb5_copy_ccache.3.gz usr/share/man/man3/mac_is_present_np.3.gz usr/share/man/man3/mbmb.3.gz usr/share/man/man3/mbrrune.3.gz usr/share/man/man3/mbrune.3.gz usr/share/man/man3/rune.3.gz usr/share/man/man3/setinvalidrune.3.gz usr/share/man/man3/setrunelocale.3.gz usr/share/man/man3/sgetrune.3.gz usr/share/man/man3/sputrune.3.gz From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 01:57:14 2010 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 82D97106564A; Fri, 19 Nov 2010 01:57:14 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E2A378FC17; Fri, 19 Nov 2010 01:57:13 +0000 (UTC) Received: by wwd20 with SMTP id 20so3971103wwd.31 for ; Thu, 18 Nov 2010 17:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=3Fzvx9NNM7MosTNqP6Tr1YNsxdk8rog3Uco+6wO4PwI=; b=kMGd0BJflif19XDb1n5gIl9TlBcBeA0xBmyqzeca2K1cffzvDyhWIY7qtPkRLoctH2 +LsU2p62MjezAIOrJNdjCW4VZozAEYsWzKsjy7wYyoh6YBf249ggmxCS0DZG047oR7rl KFu28bfLTVu2GESGgG+NugzaiXhnO7ZAqzqXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=e4Ic5AVjPiI+h96iJHT4yYmZIxfat6qI705pEeATXHpVb4mvnGnphcB+gKCJ6W8MAV 83W8OQVSoix/8zFqFlke5zkTmKCDgLjrmsKY6KaAtG2y2N17Re/hcmUPE1ChnpGQardM 8rB45LKX/G5WM0LiDzP6Ym+ADR1mD/lNpUWAw= Received: by 10.227.136.72 with SMTP id q8mr1552998wbt.52.1290131832643; Thu, 18 Nov 2010 17:57:12 -0800 (PST) Received: from localhost (khaki.feralhosting.com [91.121.141.21]) by mx.google.com with ESMTPS id i19sm721251wbe.11.2010.11.18.17.57.08 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 17:57:11 -0800 (PST) From: Anonymous To: Alexander Best References: <20101118185837.GA44549@freebsd.org> <86y68q3yaz.fsf@gmail.com> Date: Fri, 19 Nov 2010 04:57:02 +0300 In-Reply-To: <86y68q3yaz.fsf@gmail.com> (Anonymous's message of "Fri, 19 Nov 2010 04:19:16 +0300") Message-ID: <8662vu3wk1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc 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, 19 Nov 2010 01:57:14 -0000 Anonymous writes: > Alexander Best writes: > >> diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc >> index e358ed9..106c10e 100644 >> --- a/ObsoleteFiles.inc >> +++ b/ObsoleteFiles.inc >> @@ -13,6 +13,12 @@ >> # >> # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. >> # >> +# Before you commit changes to this file please check, if any entries in >> +# tools/build/mk/OptionalObsoleteFiles.inc can be removed. The following >> +# command was proposed by Dmitry Morozovsky: >> +# ( grep '+=' /usr/src/ObsoleteFiles.inc | sort -u ; \ >> +# grep '+=' /usr/src/tools/build/mk/OptionalObsoleteFiles.inc | sort -u) | \ >> +# sort | uniq -d > > An easier way to check duplicates that understands `.if ${TARGET_ARCH}...' > > $ make -V OLD_FILES -V OLD_LIBS -V OLD_DIRS \ > -f Makefile.inc1 check-old \ > | sed 'y/ /\n/' | sort | uniq -d Nevermind. It's more important to check OptionalObsoleteFiles.inc when files are re-introduced and thus removed from ObsoleteFiles.inc. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 11:15:56 2010 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 C4BB2106566B; Fri, 19 Nov 2010 11:15:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 829F18FC0C; Fri, 19 Nov 2010 11:15:56 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D6FADE60BE; Fri, 19 Nov 2010 11:15:55 +0000 (GMT) Received: from unknown (client-86-27-40-229.glfd.adsl.virginmedia.com [86.27.40.229]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 19 Nov 2010 11:15:54 +0000 (GMT) Date: Fri, 19 Nov 2010 11:15:57 +0000 From: Bruce Cran Message-ID: <20101119111557.00000a3a@unknown> In-Reply-To: <20101116204000.00005aea@unknown> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Coosemans , Oliver Fromme , Dag-Erling@FreeBSD.ORG, freebsd-hackers@freebsd.org, Alexander Motin , Tijl, Alexander Best Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 19 Nov 2010 11:15:56 -0000 On Tue, 16 Nov 2010 20:40:00 +0000 Bruce Cran wrote: > One problem with the code that's been committed is that the shutdown > event handler doesn't get run during a suspend operation so an > emergency unload still gets done when running "acpiconf -s3". Something else I noticed today: I've just got a new disk that supports NCQ and found the kern.cam.ada.ada_send_ordered sysctl that appears to enable/disable its use (?). But the shutdown handler that spins the disk down only gets initialized if ada_send_ordered is enabled. I was wondering what the reason for this is? -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 11:24:51 2010 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 BE7501065670; Fri, 19 Nov 2010 11:24:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E973B8FC0A; Fri, 19 Nov 2010 11:24:50 +0000 (UTC) Received: by fxm19 with SMTP id 19so2675690fxm.13 for ; Fri, 19 Nov 2010 03:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CUB27yrrN0uIpWenfeh3VWj8BfnCRhz3hV6nwzUofU0=; b=J42GDfuLLxneiTQx8IQosoePrY+Ex/qVvmQ6njI78CWqCTbj1WiTiaLm5YfMdBNuOO brgV3R9WtdKl7XnQphlO/CZ+0HK8PjFWLPUU/LxVWODnOei71C9E4ywYC/Vi553DuP2v ZB47p39uOumF7vRttP0OyahaJenPAFlN6rsNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=tAulpa9jZDaPpTbNvZCbXBKCwmny2Bh8fspb+w11S4yTcxlMH5baOC5WR/dRtmwyO2 ZCV00fnqufDXwfbe5dTPtb0D1Om8AtqA0xt93jgT9sC518GerSnjPwgqAaDDqAJ7jG9b EuJFT5gcFEFXxp1paDhqv3XOSLvJslLj28DiI= Received: by 10.223.74.143 with SMTP id u15mr678184faj.27.1290165889897; Fri, 19 Nov 2010 03:24:49 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e17sm476573fak.10.2010.11.19.03.24.47 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 03:24:48 -0800 (PST) Sender: Alexander Motin Message-ID: <4CE65E52.5040009@FreeBSD.org> Date: Fri, 19 Nov 2010 13:24:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Cran References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101119111557.00000a3a@unknown> In-Reply-To: <20101119111557.00000a3a@unknown> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, Dag-Erling@FreeBSD.ORG Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 19 Nov 2010 11:24:51 -0000 Bruce Cran wrote: > On Tue, 16 Nov 2010 20:40:00 +0000 > Bruce Cran wrote: > >> One problem with the code that's been committed is that the shutdown >> event handler doesn't get run during a suspend operation so an >> emergency unload still gets done when running "acpiconf -s3". > > Something else I noticed today: I've just got a new disk that supports > NCQ and found the kern.cam.ada.ada_send_ordered sysctl that appears to > enable/disable its use (?). ada_send_ordered controls periodical non-queued commands insertion to avoid possible infinite commands starvation and timeouts as result. NCQ can't be disabled now. > But the shutdown handler that spins > the disk down only gets initialized if ada_send_ordered is enabled. I > was wondering what the reason for this is? Interesting question. That code came as-is from "da" driver and I can't explain it. I have feeling that it's wrong. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 15:45:39 2010 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 357D1106566B for ; Fri, 19 Nov 2010 15:45:39 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mx1.freebsd.org (Postfix) with ESMTP id D80618FC1D for ; Fri, 19 Nov 2010 15:45:38 +0000 (UTC) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mx.arcor.de (Postfix) with ESMTP id 44F2F9C630 for ; Fri, 19 Nov 2010 16:12:25 +0100 (CET) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 40A3C15B897 for ; Fri, 19 Nov 2010 16:12:25 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-092-075-207-206.pools.arcor-ip.net [92.75.207.206]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 193EA264AA for ; Fri, 19 Nov 2010 16:12:25 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 193EA264AA Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.4/8.14.3) with ESMTP id oAJFCOkp039037 for ; Fri, 19 Nov 2010 16:12:24 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.4/8.14.4/Submit) id oAJFCOSa039036 for freebsd-hackers@freebsd.org; Fri, 19 Nov 2010 16:12:24 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Fri, 19 Nov 2010 15:12:24 +0000 (UTC) Message-ID: References: <1289506363.30235.113.camel@localhost.localdomain> <2CCA101F-22FA-4CE2-8F4C-117824CEA104@vicor.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-hackers@freebsd.org Subject: Re: Spinner Function for Shell Scripts 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, 19 Nov 2010 15:45:39 -0000 Devin Teske wrote: > >> So, just as the subject-line says, ... here's an efficient and robust > >> spinner function compatible with many shells. > >> DONE=$( /bin/sh -c 'read -t 0 DONE; echo $DONE' ) > > > > Is this expected to be portable to other operating systems? The dash > > shell, used as /bin/bash in Ubuntu, does not acept the "-t" argument > > to the read builtin command. Using /bin/bash solves the problem. > > I was shooting for bourne-shell, FreeBSD's /bin/sh is *not* a Bourne shell. > It's rather unfortunate that bourne-shell has what we need but is not > available on all operating systems since many OSes have started swapping > out bourne-shell for it's younger cousin. A traditional Bourne shell, such as Solaris's, does not implement read -t at all. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 15:56:54 2010 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 214D6106564A for ; Fri, 19 Nov 2010 15:56:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6E28D8FC19 for ; Fri, 19 Nov 2010 15:56:52 +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 RAA15017; Fri, 19 Nov 2010 17:39:53 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE69A49.4080801@freebsd.org> Date: Fri, 19 Nov 2010 17:39:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: new cpuid bits 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, 19 Nov 2010 15:56:54 -0000 Guys, I would like to add definitions for couple more useful CPUID bits, but I am greatly confused about how to name them. I failed to deduce the naming convention from the existing definitions and I am not sure how to make the names proper and descriptive. The bits in question are returned by CPUID.6 in EAX and ECX. CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is defined for both. Description/naming of the bits from the specifications: EAX[0]: Digital temperature sensor is supported if set EAX[1]: Intel Turbo Boost Technology Available EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. ECX[0]: Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT MSRs). AMD: EffFreq: effective frequency interface. How does the following look to you? I will appreciate suggestions/comments. Thanks! Index: sys/amd64/include/specialreg.h =================================================================== --- sys/amd64/include/specialreg.h (revision 215524) +++ sys/amd64/include/specialreg.h (working copy) @@ -136,6 +136,15 @@ #define CPUID2_AESNI 0x02000000 /* + * Important bits in the Thermal and Power Management flags + * CPUID.6 EAX and ECX. + */ +#define CPUTPM1_SENSOR 0x00000001 +#define CPUTPM1_TURBO 0x00000002 +#define CPUTPM1_ARAT 0x00000004 +#define CPUTPM2_EFFREQ 0x00000001 + +/* * Important bits in the AMD extended cpuid flags */ #define AMDID_SYSCALL 0x00000800 -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 16:21:25 2010 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 9FBDD1065674; Fri, 19 Nov 2010 16:21:25 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 439D58FC15; Fri, 19 Nov 2010 16:21:24 +0000 (UTC) Received: by yxh35 with SMTP id 35so2875488yxh.13 for ; Fri, 19 Nov 2010 08:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=8Z+yC0ilfTRbgWr3NYwWl3q4yI5+5G0JGhbvRhcpaqI=; b=q+O+qFq+/XuyqAL5DEN/ietfuZJ8tfm7IGUE+kX+e6eRidw/p5hn4UPF4cf1uOjaC3 pXQ4QgpUc+Hv62CGXLLvexwzO+Q3Q7hFZksmonzVJOaf17AsoTLyv2M5iNktBvmuFsPX i8P1gIgnW6qQ5Dvy2z5t2v9JjK0qPYtUS2KGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=bT0q4Kn568uWVnUJIPcDs7UreuFBKFEZdl8gkMOOLQTS8F1ax4opIS/SDq5FzvP9uV thIXp8iuM9KlEnTaCwq+KKDve2qg/cYXTe9T9HfwrMJG1Upjh01iGPg5/JUkALjZ9W4U jYj7dusKwE0AkX8ptyh2ROLgvZ5U5joMUksVI= Received: by 10.204.97.143 with SMTP id l15mr2261073bkn.127.1290183683115; Fri, 19 Nov 2010 08:21:23 -0800 (PST) Received: from ernst.jennejohn.org (p578E3432.dip.t-dialin.net [87.142.52.50]) by mx.google.com with ESMTPS id p34sm947484bkf.15.2010.11.19.08.21.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 08:21:22 -0800 (PST) Date: Fri, 19 Nov 2010 17:21:20 +0100 From: Gary Jennejohn To: Andriy Gapon Message-ID: <20101119172120.7fd14c9f@ernst.jennejohn.org> In-Reply-To: <4CE69A49.4080801@freebsd.org> References: <4CE69A49.4080801@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: new cpuid bits X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:21:25 -0000 On Fri, 19 Nov 2010 17:39:53 +0200 Andriy Gapon wrote: > > Guys, > > I would like to add definitions for couple more useful CPUID bits, but I am > greatly confused about how to name them. > I failed to deduce the naming convention from the existing definitions and I am > not sure how to make the names proper and descriptive. > > The bits in question are returned by CPUID.6 in EAX and ECX. > CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management > (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is > defined for both. > > Description/naming of the bits from the specifications: > EAX[0]: Digital temperature sensor is supported if set > EAX[1]: Intel Turbo Boost Technology Available > EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. > ECX[0]: > Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT > MSRs). > AMD: EffFreq: effective frequency interface. > > How does the following look to you? > I will appreciate suggestions/comments. > Thanks! > > Index: sys/amd64/include/specialreg.h > =================================================================== > --- sys/amd64/include/specialreg.h (revision 215524) > +++ sys/amd64/include/specialreg.h (working copy) > @@ -136,6 +136,15 @@ > #define CPUID2_AESNI 0x02000000 > > /* > + * Important bits in the Thermal and Power Management flags > + * CPUID.6 EAX and ECX. > + */ > +#define CPUTPM1_SENSOR 0x00000001 > +#define CPUTPM1_TURBO 0x00000002 > +#define CPUTPM1_ARAT 0x00000004 > +#define CPUTPM2_EFFREQ 0x00000001 > + > +/* > * Important bits in the AMD extended cpuid flags > */ > #define AMDID_SYSCALL 0x00000800 > Maybe add a comment in which register the bits are to be found, like in the text? -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 16:57:44 2010 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 248CD106564A; Fri, 19 Nov 2010 16:57:44 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0F87E8FC16; Fri, 19 Nov 2010 16:57:42 +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 SAA16273; Fri, 19 Nov 2010 18:57:41 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE6AC85.9040802@freebsd.org> Date: Fri, 19 Nov 2010 18:57:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Alexander Motin X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: statclock(n) 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, 19 Nov 2010 16:57:44 -0000 Alexander, I wonder if instead of calling statclock() multiple times (after an idle period) we couldn't call it just with an appropriate N parameter. So some stats like e.g. cp_time[] could do +=N instead of ++. Other stats ru_ixrss need to be updated only once. Similarly, N could be passed further down to sched_clock() and handled there too. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 17:45:46 2010 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 58DB91065670; Fri, 19 Nov 2010 17:45:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F00FC8FC15; Fri, 19 Nov 2010 17:45:45 +0000 (UTC) Received: by yxh35 with SMTP id 35so2956981yxh.13 for ; Fri, 19 Nov 2010 09:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=i0FLInjTMeSijdW3sbFjkW+7hjVJ6GLo6VEs5byay6Q=; b=oGZEFcW+d4Vgwh/RCQv1Y/TUTEq9t0jrWMll+GyME6jgLqttP8KWQ4iw9XRbs3pPWd +f3q/xxX+HeoZQyjOnnGp/XN+5b4RuxD1GVaUYSzxkuOjONfskcf87bg4kHR/3mWbVz8 lf5dEyNrECIzux2Lrzo36x2+1s18p1d3XW1ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=O6Es073H8CZD/Scv2reojXPnZ3h6O8H3Bf6onERB9LZmguRc2nKr/ywP1rA9kLvEPD 7LDUar1Q5n2arhU+H1gCUIXvJ89xuDAW6/nYSzxRL2XP5Y2RCbbPy2yVSjHvdL85oKzR xWlvsoHXf2+GSx3CyMw8E+cOvprAOhpMNmaiE= Received: by 10.223.81.78 with SMTP id w14mr1145108fak.5.1290188744353; Fri, 19 Nov 2010 09:45:44 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id z25sm602585fam.18.2010.11.19.09.45.42 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 09:45:43 -0800 (PST) Sender: Alexander Motin Message-ID: <4CE6B7C5.6040501@FreeBSD.org> Date: Fri, 19 Nov 2010 19:45:41 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4CE6AC85.9040802@freebsd.org> In-Reply-To: <4CE6AC85.9040802@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: statclock(n) 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, 19 Nov 2010 17:45:46 -0000 Hi. Andriy Gapon wrote: > I wonder if instead of calling statclock() multiple times (after an idle period) > we couldn't call it just with an appropriate N parameter. > So some stats like e.g. cp_time[] could do +=N instead of ++. > Other stats ru_ixrss need to be updated only once. > Similarly, N could be passed further down to sched_clock() and handled there too. I think yes. It is reasonable. Initially hardclock() was also called in a loop. It was just rewritten first because it is called more often (more times), goes to hardware to sync time, and any way required changes to work properly. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 19:28:11 2010 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 98EE0106566B for ; Fri, 19 Nov 2010 19:28:11 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7F31B8FC13 for ; Fri, 19 Nov 2010 19:28:11 +0000 (UTC) Received: from [192.168.134.187] (port=62223 helo=[192.168.1.111]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1PJWcy-0007nY-KD; Fri, 19 Nov 2010 11:28:10 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: Date: Fri, 19 Nov 2010 11:28:07 -0800 Message-Id: <2E23D040-6461-4938-88CE-328A091D7739@vicor.com> References: <1289506363.30235.113.camel@localhost.localdomain> <2CCA101F-22FA-4CE2-8F4C-117824CEA104@vicor.com> To: naddy@mips.inka.de (Christian Weisgerber) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: c61feb86be2d5867fe8e5dc7b9036f8f X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Spinner Function for Shell Scripts 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, 19 Nov 2010 19:28:11 -0000 On Nov 19, 2010, at 7:12 AM, Christian Weisgerber wrote: > Devin Teske wrote: >=20 >>>> So, just as the subject-line says, ... here's an efficient and = robust >>>> spinner function compatible with many shells. >>>> DONE=3D$( /bin/sh -c 'read -t 0 DONE; echo = $DONE' ) >>>=20 >>> Is this expected to be portable to other operating systems? The dash >>> shell, used as /bin/bash in Ubuntu, does not acept the "-t" argument >>> to the read builtin command. Using /bin/bash solves the problem. >>=20 >> I was shooting for bourne-shell, >=20 > FreeBSD's /bin/sh is *not* a Bourne shell. I see that now from the sh(1) manual (had been assuming it was true to = its roots from 4.4BSDLite -- ala FreeBSD-1.0). More akin to Korn shell = while maintaining POSIX.2 spec. >=20 >> It's rather unfortunate that bourne-shell has what we need but is not >> available on all operating systems since many OSes have started = swapping >> out bourne-shell for it's younger cousin. >=20 > A traditional Bourne shell, such as Solaris's, does not implement > read -t at all. Thanks! I guess that means that this code is specific to FreeBSD. I guess that = means I love FreeBSD even more than I did before. Unfortunately, that = means that if I want to implement this spinner on any other platform, = I'll have to resort to my previous impementations -- using backgrounding = and/or temporary files on-disk. >=20 > --=20 > Christian "naddy" Weisgerber = naddy@mips.inka.de >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 19 23:02:00 2010 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 920A01065672 for ; Fri, 19 Nov 2010 23:02:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5136A8FC16 for ; Fri, 19 Nov 2010 23:02:00 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 2995D13DF46 for ; Sat, 20 Nov 2010 01:42:34 +0300 (MSK) Date: Sat, 20 Nov 2010 01:42:29 +0300 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <19363551.20101120014229@serebryakov.spb.ru> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD (UNIXes?), UARTs, forced parity and "Custom" UART settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 23:02:00 -0000 Hello, Freebsd-hackers. When I implemented USB2COM driver, I found that there is NO flags in termios for forces parity. Here are flags to tunr parity on or off and make it odd or even, but no mention about forced (alway 1 -- odd -- or 0 -- even) parity, which is not dependend on data and acts as one more (inverted sometimes) stop bit. Virtually every UART has such mode (16x50-compatible UARTS hereis bit in LCR for it), but no flag in the (POSIX?) API! Did I miss something? How people communicate with equipment, which uses (and wants) forced parity? Some equipment uses this bit as address one... Another question -- does USB2COM driver need RS-485 mode (which is supported by hardware), and what is better way to turn it ons -- sysctl or ioctl? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 16:51:26 2010 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 42E63106564A for ; Sat, 20 Nov 2010 16:51:26 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B59E88FC14 for ; Sat, 20 Nov 2010 16:51:25 +0000 (UTC) Received: by bwz2 with SMTP id 2so5000025bwz.13 for ; Sat, 20 Nov 2010 08:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:user-agent:mime-version:content-type; bh=812C1Yo4kufTAMfqdXLtUbTE1zTRFid0VRPEKgf/x5k=; b=S0YEkoew7jruDzACEVI7V8j1BYoq9QK8qlwp06rscWCFv5cOjy06U/wL5HJ/EyNafh QcZinhSH1xdxWIZjTubr9bzVrMHveS4xMkE0qnoMOGkjuzI//9uOp6YMWSkYUwPup8WC 7g32C3oycQDy2tiqwfMK+tHUuql99jcmXCRsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; b=qkdY9S5pwTZUsRU7phXFzCzdRgvLViEkdSVuCWIxyYHl0HsSlcgf++vZZ9ghkvOf9a 0RMOXAKS5N8EiLAkI8TKJFOu3uprXeIrreySDMfpzEKlgsIdAlM6ulHlIA9TyBRAaDSP kAqesBoiwFCgRmnuT9uKbMgiA1nJBJiwNlzGQ= Received: by 10.204.120.67 with SMTP id c3mr3309409bkr.174.1290270132323; Sat, 20 Nov 2010 08:22:12 -0800 (PST) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id p22sm1445301bkp.9.2010.11.20.08.22.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 08:22:11 -0800 (PST) From: Mikolaj Golub To: freebsd-hackers@freebsd.org Date: Sat, 20 Nov 2010 18:22:06 +0200 Message-ID: <86pqu0nexd.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 16:51:26 -0000 Hi, Running something like below under VirtualBox (CURRENT, VIMAGE) echo "creating jail and iface" jail -c name="${JAIL}" vnet persist ifconfig "${EPAIR}" create ifconfig "${EPAIR}b" vnet "${JAIL}" sleep 1 echo "destroying jail and iface" # below is a race jail -r "${JAIL}" & ifconfig "${EPAIR}a" destroy wait I will frequently get a livelock (it might also crash, but that may be a different story) between these 3 threads in flowtable code: 1308 1183 1183 0 D+ flowclea 0xc101a314 ifconfig 1307 1183 1183 0 R+ jail 18 0 0 0 RL [flowcleaner] Thread 100075 at 0xc2685b40: proc (pid 1308): 0xc28e4aa0 name: ifconfig stack: 0xc8742000-0xc8743fff flags: 0x20804 pflags: 0 state: INHIBITED: {SLEEPING} wmesg: flowcleanwait wchan: 0xc101a314 priority: 138 container lock: sleepq chain (0xc0ebee0c) Tracing command ifconfig pid 1308 tid 100075 td 0xc2685b40 sched_switch(c2685b40,0,104,191,4b654535,...) at sched_switch+0x3d3 mi_switch(104,0,c0d299f4,1f3,0,...) at mi_switch+0x200 sleepq_switch(c2685b40,0,c0d299f4,268,c2685b40,...) at sleepq_switch+0x15f sleepq_wait(c101a314,0,c87439c0,1,0,...) at sleepq_wait+0x63 _cv_wait(c101a314,c101a31c,c87439f8,17,0,...) at _cv_wait+0x243 flowtable_flush(0,c1ef0000,c0d353e4,38e,40,...) at flowtable_flush+0x90 if_detach_internal(c8743a68,c0999d7d,c1ef0000,c1ef0000,c8743aa4,...) at if_detach_internal+0x43d if_detach(c1ef0000) at if_detach+0x10 ether_ifdetach(c1ef0000,1,c8743aa4,c099309e,c0d35665,...) at ether_ifdetach+0x3d epair_clone_destroy(c2963c40,c1ef0000,c0d359fd,105,c2963c70,...) at epair_clone_destroy+0x6b if_clone_destroyif(c2963c40,c1ef0000,c0d359fd,e0,c08cfc1d,...) at if_clone_destroyif+0x147 if_clone_destroy(c1fee8e0,19c,3,c2685b40,c0d52bad,...) at if_clone_destroy+0x147 ifioctl(c2564680,80206979,c1fee8e0,c2685b40,c08a6a31,...) at ifioctl+0x621 soo_ioctl(c1ff5d90,80206979,c1fee8e0,c1d83200,c2685b40,...) at soo_ioctl+0x427 kern_ioctl(c2685b40,3,80206979,c1fee8e0,743cec,...) at kern_ioctl+0x20d ioctl(c2685b40,c8743cec,c2685b40,c8743d28,c0d2a23d,...) at ioctl+0x134 syscallenter(c2685b40,c8743ce4,c8743ce4,0,c0eb0c40,...) at syscallenter+0x2c3 syscall(c8743d28) at syscall+0x4f Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281c73f3, esp = 0xbfbfe46c, ebp = 0xbfbfe488 --- Thread 100050 at 0xc20032d0: proc (pid 1307): 0xc267f7f8 name: jail stack: 0xc43fd000-0xc43fefff flags: 0x4 pflags: 0 state: RUNQ priority: 137 container lock: sched lock 0 (0xc0eb0c40) Tracing pid 1307 tid 100050 td 0xc20032d0 sched_switch(c20032d0,0,602,18c,4b69c645,...) at sched_switch+0x3d3 mi_switch(602,0,c0d25710,cd,0,...) at mi_switch+0x200 critical_exit(c0e6a98c,1,c0e6a98c,c43fea20,0,...) at critical_exit+0xa8 intr_event_handle(c1dbfe80,c43fea20,ff6b36c5,c20032d0,1,...) at intr_event_handle+0x115 intr_execute_handlers(c0e6a98c,c43fea20,c20032d0,c101a314,c43fea64,...) at intr_execute_handlers+ 0x49 atpic_handle_intr(1,c43fea20) at atpic_handle_intr+0x7c Xatpic_intr1() at Xatpic_intr1+0x22 --- interrupt, eip = 0xc0c30cfb, esp = 0xc43fea60, ebp = 0xc43fea64 --- spinlock_exit(c0eb0c40,4,c0d236ac,109,c091cf25,39248) at spinlock_exit+0x2b _mtx_unlock_spin_flags(c0eb0c40,0,c0d299f4,26a) at _mtx_unlock_spin_flags+0x12d sleepq_wait(c101a314,0,c43feadc,1,0,...) at sleepq_wait+0x85 _cv_wait(c101a314,c101a31c,c43feb14,17,0,...) at _cv_wait+0x243 flowtable_flush(0,c1ef0400,c0d353e4,38e,c1d42dc0,...) at flowtable_flush+0x90 if_detach_internal(8,c0d37941,117,0,c0d204c3,...) at if_detach_internal+0x43d if_vmove(c1ef0400,c1d720c0,117,115,0,...) at if_vmove+0x1b vnet_destroy(c1d5d260,c0d204c3,9c6,9b8,17,...) at vnet_destroy+0x163 prison_deref(c08b7d2b,c253c028,0,c0d204c3,2,...) at prison_deref+0x3a2 prison_remove_one(c0e20060,1,c0d204c3,83f,c0c3d6cf,...) at prison_remove_one+0x53 jail_remove(c20032d0,c43fecec,c20032d0,c43fed28,c0d2a23d,...) at jail_remove+0x266 syscallenter(c20032d0,c43fece4,c43fece4,0,c0eb0c40,...) at syscallenter+0x2c3 syscall(c43fed28) at syscall+0x4f Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (508, FreeBSD ELF32, jail_remove), eip = 0x280efa1b, esp = 0xbfbfebdc, ebp = 0xbfbfeca8 --- Thread 100037 at 0xc1fc6870: proc (pid 18): 0xc1fd47f8 name: flowcleaner stack: 0xc43c6000-0xc43c7fff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 160 container lock: sched lock 0 (0xc0eb0c40) Tracing pid 18 tid 100037 td 0xc1fc6870 sched_switch(c1fc6870,0,104,191,3d6a1775,...) at sched_switch+0x3d3 mi_switch(104,0,c0d299f4,1f3,0,...) at mi_switch+0x200 sleepq_switch(c1fc6870,0,c0d299f4,28b,c1fc6870,...) at sleepq_switch+0x15f sleepq_timedwait(c101a314,0,c43c7ca0,1,0,...) at sleepq_timedwait+0x6b _cv_timedwait(c101a314,c101a31c,7d0,620,c1fc6870,...) at _cv_timedwait+0x252 flowtable_cleaner(0,c43c7d28,c0d20004,33b,c1fd47f8,...) at flowtable_cleaner+0x255 fork_exit(c0990630,0,c43c7d28) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 In net/flowtable.c we have two functions: static void flowtable_cleaner(void) { ... while (1) { ... flowclean_cycles++; mtx_lock(&flowclean_lock); cv_broadcast(&flowclean_cv); cv_timedwait(&flowclean_cv, &flowclean_lock, flowclean_freq); mtx_unlock(&flowclean_lock); } } static void flowtable_flush(void *unused __unused) { uint64_t start; mtx_lock(&flowclean_lock); start = flowclean_cycles; while (start == flowclean_cycles) { cv_broadcast(&flowclean_cv); cv_wait(&flowclean_cv, &flowclean_lock); } mtx_unlock(&flowclean_lock); } It looks like when two threads enter flowtable_flush() simultaneously they start to wake up each other not giving to flowcleaner thread (which is in RUNQ) a chance to run (I suppose because it has higher priority number) and update flowclean_cycles counter. I added print in flowtable_flush() loop to check my assumption and got: flowtable_flush: start(C43FEB14): 23; flowclean_cycles: 23 flowtable_flush: start(C87439F8): 23; flowclean_cycles: 23 flowtable_flush: start(C43FEB14): 23; flowclean_cycles: 23 flowtable_flush: start(C87439F8): 23; flowclean_cycles: 23 flowtable_flush: start(C43FEB14): 23; flowclean_cycles: 23 flowtable_flush: start(C87439F8): 23; flowclean_cycles: 23 flowtable_flush: start(C43FEB14): 23; flowclean_cycles: 23 flowtable_flush: start(C87439F8): 23; flowclean_cycles: 23 ... So the question is who is guilty in this situation? ULE? flowtable? Or jail/epair, which should not allow simultaneous entering of flowtable_flush? -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 17:05:07 2010 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 A1A7C106566C for ; Sat, 20 Nov 2010 17:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 55BF28FC08 for ; Sat, 20 Nov 2010 17:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6DEED41C752; Sat, 20 Nov 2010 18:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id VNugTHepk1IG; Sat, 20 Nov 2010 18:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 936DE41C750; Sat, 20 Nov 2010 18:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 01AAC4448FA; Sat, 20 Nov 2010 17:03:13 +0000 (UTC) Date: Sat, 20 Nov 2010 17:03:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mikolaj Golub In-Reply-To: <86pqu0nexd.fsf@kopusha.home.net> Message-ID: <20101120165604.T24596@maildrop.int.zabbadoz.net> References: <86pqu0nexd.fsf@kopusha.home.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 17:05:07 -0000 On Sat, 20 Nov 2010, Mikolaj Golub wrote: Hi, > Running something like below under VirtualBox (CURRENT, VIMAGE) ... > So the question is who is guilty in this situation? ULE? flowtable? Or > jail/epair, which should not allow simultaneous entering of flowtable_flush? In general: you for running an experimental feature;-) Seriously, flowtable has a number of different problems: 1) you will leak neighbor entries still 2) I have patches for VIMAGE but if you are running VIMAGE you are advised not to run flowtable. 3) FLOWTABLE should go from GENERIC but that's a different story. I think net@ would have been a better initial place but since this seems to be a problem when interacting with VIMAGE freebsd-virtualization might be better. What you could try is: http://people.freebsd.org/~bz/20100216-10-ft-cv.diff /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 17:55:52 2010 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 DD182106566C for ; Sat, 20 Nov 2010 17:55:52 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63AC08FC0A for ; Sat, 20 Nov 2010 17:55:52 +0000 (UTC) Received: by bwz2 with SMTP id 2so5034272bwz.13 for ; Sat, 20 Nov 2010 09:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=Di2YfL1qUdF+Wi2iqa2KX0c29eEdpok+9al2PDhuSDI=; b=ldHgYvYYWqYhAIubfgPoChmWKmogB/hey/rMrD5B139Q4Q3V4zsBM96Fk+QTq9X6mA h6qWvl8pgtor9rsSh7Aa5BKmD2KO33pjYTzOZ1dSAqyeuXthQD9+EdIElig53RtTqAo9 TMOeL//e9V3Sx3+VXrEvujTtt6x2qtWUDUaZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=i7q8ELTtRpni178I0tSoHp77GPUf9FNEiv6Rhyj8cFGRV8NbjYBWfx0EPNQmliLFnP AR22s+SEFKqqWebjDbsC02KyH+WLEC1TsYREWxk0Weq7aDMbiVU1wp1EA2UOuDoAomou wuatJEazA+i9ziwA8nqo2b4ipc7ROS/nsBJ28= Received: by 10.204.120.67 with SMTP id c3mr3380165bkr.174.1290275749465; Sat, 20 Nov 2010 09:55:49 -0800 (PST) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id f21sm1479244bkf.12.2010.11.20.09.55.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 09:55:48 -0800 (PST) From: Mikolaj Golub To: "Bjoern A. Zeeb" References: <86pqu0nexd.fsf@kopusha.home.net> <20101120165604.T24596@maildrop.int.zabbadoz.net> X-Comment-To: Bjoern A. Zeeb Date: Sat, 20 Nov 2010 19:55:45 +0200 In-Reply-To: <20101120165604.T24596@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Sat, 20 Nov 2010 17:03:13 +0000 (UTC)") Message-ID: <86hbfbop5q.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 17:55:52 -0000 On Sat, 20 Nov 2010 17:03:13 +0000 (UTC) Bjoern A. Zeeb wrote: BAZ> On Sat, 20 Nov 2010, Mikolaj Golub wrote: BAZ> Hi, >> Running something like below under VirtualBox (CURRENT, VIMAGE) BAZ> ... >> So the question is who is guilty in this situation? ULE? flowtable? Or >> jail/epair, which should not allow simultaneous entering of flowtable_flush? BAZ> In general: you for running an experimental feature;-) I like experimenting :-) BAZ> What you could try is: BAZ> http://people.freebsd.org/~bz/20100216-10-ft-cv.diff I will. Thanks. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 19:09:43 2010 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 0DCB81065670 for ; Sat, 20 Nov 2010 19:09:43 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2668FC0A for ; Sat, 20 Nov 2010 19:09:42 +0000 (UTC) Received: by bwz2 with SMTP id 2so5072291bwz.13 for ; Sat, 20 Nov 2010 11:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=ZJHsQJResiOBa/6yOk3OxpRO11Msht2/d7K/2+ygkF8=; b=If8gSo59MPbIR4qAqPEy4ZDSmWMALUIAsjdADjY0MxudFM1/FQTWI4tbnOtHOemz7U XcjsXk1MvO0pryzWiWeHSb/VbXU53mRlupp3ZFxWF5oiRBHKceY7JQugHuyUVmx6gzwA ynW/uCwbdQsTd+399j53JA2DzWQn2oQqdE2Qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=tXU3b0L9fdBqoPeK2q8LlP5EbFyixwRIEMRbNskYgGWAajqC5kbNi3KqPAKnjueQ7Q nui2eHEh+hRycXBp1oxFNLfXSoRqBsTNK9MQK+7SaxAEQFezRA8qQGhmS+n550S46xAg /rSf1Gz4admradkVAKn+NE9W67qTbVznTc3Ws= Received: by 10.204.64.80 with SMTP id d16mr3546348bki.181.1290280180487; Sat, 20 Nov 2010 11:09:40 -0800 (PST) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id t10sm1507271bkj.4.2010.11.20.11.09.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 11:09:39 -0800 (PST) From: Mikolaj Golub To: "Bjoern A. Zeeb" References: <86pqu0nexd.fsf@kopusha.home.net> <20101120165604.T24596@maildrop.int.zabbadoz.net> X-Comment-To: Bjoern A. Zeeb Date: Sat, 20 Nov 2010 21:09:35 +0200 In-Reply-To: <20101120165604.T24596@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Sat, 20 Nov 2010 17:03:13 +0000 (UTC)") Message-ID: <868w0nolqo.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-hackers@freebsd.org Subject: Re: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 19:09:43 -0000 --=-=-= On Sat, 20 Nov 2010 17:03:13 +0000 (UTC) Bjoern A. Zeeb wrote: BAZ> I think net@ would have been a better initial place but since this BAZ> seems to be a problem when interacting with VIMAGE BAZ> freebsd-virtualization might be better. BAZ> What you could try is: BAZ> http://people.freebsd.org/~bz/20100216-10-ft-cv.diff Ah, I have recalled I had already saw this patch but did not understand what the problem was that it fixed, thus did not associated it with my case (actually, I thought you had committed all these patches to the tree long time ago and I was running the kernel with them already :-). BTW, the patch needs updating: in the current flow_full() wakes up flowcleaner too, and flowcleaner sleeps for flowclean_freq instead of 10*hz (see the attached patch). With the patch I can't reproduce the lock. Only the crash I mentioned in my first letter is observed: (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc04f2789 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056677760, dummy4=0xc8731860 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04f2b81 in db_command (last_cmdp=0xc0e79f7c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04f2cda in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04f4bfd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc09119be in kdb_trap (type=12, code=0, tf=0xc8731a94) at /usr/src/sys/kern/subr_kdb.c:546 #6 0xc0c3da8f in trap_fatal (frame=0xc8731a94, eva=3735929074) at /usr/src/sys/i386/i386/trap.c:970 #7 0xc0c3e0be in trap (frame=0xc8731a94) at /usr/src/sys/i386/i386/trap.c:361 #8 0xc0c272dc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #9 0xc0988415 in strncmp (s1=0xc1fee4e0 "epair20b", s2=0xdeadc0f2
, n=16) at /usr/src/sys/libkern/strncmp.c:44 #10 0xc09929d7 in ifunit_ref (name=0xc1fee4e0 "epair20b") at /usr/src/sys/net/if.c:1986 #11 0xc0996982 in ifioctl (so=0xc25649c0, cmd=3223349536, data=0xc1fee4e0 "epair20b", td=0xc286c000) at /usr/src/sys/net/if.c:2475 #12 0xc09307f7 in soo_ioctl (fp=0xc1ff5af0, cmd=3223349536, data=0xc1fee4e0, active_cred=0xc1d83e80, td=0xc286c000) at /usr/src/sys/kern/sys_socket.c:212 #13 0xc092a61d in kern_ioctl (td=0xc286c000, fd=3, com=3223349536, data=0xc1fee4e0 "epair20b") at file.h:254 #14 0xc092a7a4 in ioctl (td=0xc286c000, uap=0xc8731cec) at /usr/src/sys/kern/sys_generic.c:679 #15 0xc091f303 in syscallenter (td=0xc286c000, sa=0xc8731ce4) at /usr/src/sys/kern/subr_trap.c:318 #16 0xc0c3dd2f in syscall (frame=0xc8731d28) at /usr/src/sys/i386/i386/trap.c:1094 #17 0xc0c27371 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 10 #10 0xc09929d7 in ifunit_ref (name=0xc1fee4e0 "epair20b") at /usr/src/sys/net/if.c:1986 1986 if (strncmp(name, ifp->if_xname, IFNAMSIZ) == 0 && (kgdb) p ifp $1 = (struct ifnet *) 0xdeadc0de I might want to report it to freebsd-virtualization unless I find that this is a known issue. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=20101120-10-ft-cv.diff Index: sys/net/flowtable.c =================================================================== --- sys/net/flowtable.c (revision 215574) +++ sys/net/flowtable.c (working copy) @@ -195,7 +195,8 @@ STATIC_VNET_DEFINE(uma_zone_t, flow_ipv6_zone); #define V_flow_ipv6_zone VNET(flow_ipv6_zone) -static struct cv flowclean_cv; +static struct cv flowclean_f_cv; +static struct cv flowclean_c_cv; static struct mtx flowclean_lock; static uint32_t flowclean_cycles; static uint32_t flowclean_freq; @@ -951,7 +952,7 @@ flow_full(struct flowtable *ft) if ((ft->ft_flags & FL_HASH_ALL) == 0) ft->ft_udp_idle = ft->ft_fin_wait_idle = ft->ft_syn_idle = ft->ft_tcp_idle = 5; - cv_broadcast(&flowclean_cv); + cv_broadcast(&flowclean_c_cv); } else if (!full && ft->ft_full) { flowclean_freq = 20*hz; if ((ft->ft_flags & FL_HASH_ALL) == 0) @@ -1560,14 +1561,14 @@ flowtable_cleaner(void) } VNET_LIST_RUNLOCK(); - flowclean_cycles++; /* * The 10 second interval between cleaning checks * is arbitrary */ mtx_lock(&flowclean_lock); - cv_broadcast(&flowclean_cv); - cv_timedwait(&flowclean_cv, &flowclean_lock, flowclean_freq); + flowclean_cycles++; + cv_broadcast(&flowclean_f_cv); + cv_timedwait(&flowclean_c_cv, &flowclean_lock, 10*hz); mtx_unlock(&flowclean_lock); } } @@ -1580,8 +1581,8 @@ flowtable_flush(void *unused __unused) mtx_lock(&flowclean_lock); start = flowclean_cycles; while (start == flowclean_cycles) { - cv_broadcast(&flowclean_cv); - cv_wait(&flowclean_cv, &flowclean_lock); + cv_broadcast(&flowclean_c_cv); + cv_wait(&flowclean_f_cv, &flowclean_lock); } mtx_unlock(&flowclean_lock); } @@ -1613,7 +1614,8 @@ static void flowtable_init(const void *unused __unused) { - cv_init(&flowclean_cv, "flowcleanwait"); + cv_init(&flowclean_c_cv, "c_flowcleanwait"); + cv_init(&flowclean_f_cv, "f_flowcleanwait"); mtx_init(&flowclean_lock, "flowclean lock", NULL, MTX_DEF); EVENTHANDLER_REGISTER(ifnet_departure_event, flowtable_flush, NULL, EVENTHANDLER_PRI_ANY); --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 20:05:07 2010 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 81C6410656A6 for ; Sat, 20 Nov 2010 20:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B25F8FC14 for ; Sat, 20 Nov 2010 20:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 97D3A41C747; Sat, 20 Nov 2010 21:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Y1QP7mrID1pj; Sat, 20 Nov 2010 21:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E774141C713; Sat, 20 Nov 2010 21:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 20E8244490B; Sat, 20 Nov 2010 20:04:36 +0000 (UTC) Date: Sat, 20 Nov 2010 20:04:35 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mikolaj Golub In-Reply-To: <868w0nolqo.fsf@kopusha.home.net> Message-ID: <20101120200208.M24596@maildrop.int.zabbadoz.net> References: <86pqu0nexd.fsf@kopusha.home.net> <20101120165604.T24596@maildrop.int.zabbadoz.net> <868w0nolqo.fsf@kopusha.home.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 20:05:07 -0000 On Sat, 20 Nov 2010, Mikolaj Golub wrote: Hey, > On Sat, 20 Nov 2010 17:03:13 +0000 (UTC) Bjoern A. Zeeb wrote: > > BAZ> I think net@ would have been a better initial place but since this > BAZ> seems to be a problem when interacting with VIMAGE > BAZ> freebsd-virtualization might be better. > > BAZ> What you could try is: > BAZ> http://people.freebsd.org/~bz/20100216-10-ft-cv.diff > > Ah, I have recalled I had already saw this patch but did not understand what > the problem was that it fixed, thus did not associated it with my case > (actually, I thought you had committed all these patches to the tree long time > ago and I was running the kernel with them already :-). > > BTW, the patch needs updating: in the current flow_full() wakes up flowcleaner > too, and flowcleaner sleeps for flowclean_freq instead of 10*hz (see the > attached patch). For sure it does; as you can see form the date in the file name, that patch was from the beginning of the year. > With the patch I can't reproduce the lock. Only the crash I mentioned in my > first letter is observed: Hmm, I guess I should get the updated version comitted then. How do you reproduce the crash? Is it just another ifioctl race as from kern/146250? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 21:04:38 2010 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 703B11065674 for ; Sat, 20 Nov 2010 21:04:38 +0000 (UTC) (envelope-from sergio.g.delreal@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 080C28FC1A for ; Sat, 20 Nov 2010 21:04:37 +0000 (UTC) Received: by eyb7 with SMTP id 7so3332650eyb.13 for ; Sat, 20 Nov 2010 13:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=t0TO8nTXktSlLsodWAr1tT7i+RxspQ98xYPTI8jEvTo=; b=IuPDcyHkAAz4u0EX9sNUeQeWSu2x0eUcUHvMS4rm/c2c7/FDgroKNHzeEViZZZ161I 5St61Mnz+TQZcsXNG+bmuNo8QjOrzm/LVsEzabPcpEDbo2vPjG6TqYqJvFYpY1iiANlq ZtOe05zf56hzNsl1B510Jq3hPk3ndSGxMbg40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DlJAQDoclhIsf8Kt2VNbWqxs0sJ6uSJRkIXsJypcaYcAXsrX9oxM1aZqqcbB8qAKid GFxV9v0HSWfGQcALvJRMUnvZCFDCYEQzCfkfucea/MNKbsVful2wpeFcOJwsn55GTWCM Y9pMKjhEZWCgw/obkXz+cWq/lGtfhW/BRJMlI= MIME-Version: 1.0 Received: by 10.213.13.16 with SMTP id z16mr1154740ebz.14.1290285538550; Sat, 20 Nov 2010 12:38:58 -0800 (PST) Received: by 10.213.19.205 with HTTP; Sat, 20 Nov 2010 12:38:58 -0800 (PST) Date: Sat, 20 Nov 2010 15:38:58 -0500 Message-ID: From: =?ISO-8859-1?Q?Sergio_Andr=E9s_G=F3mez_del_Real?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Quick i386 question... 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: Sat, 20 Nov 2010 21:04:38 -0000 If received an interrupt while in protected-mode and paging enabled, is linear address from IDT stored at the idtr translated using the paging-hierarchy structures? I have looked at the interrupt/exception chapter in the corresponding Intel manual but can't find the answer. Maybe I overlooked. Thanks. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 21:22:56 2010 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 B032010656A9 for ; Sat, 20 Nov 2010 21:22:56 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3561B8FC15 for ; Sat, 20 Nov 2010 21:22:55 +0000 (UTC) Received: by bwz2 with SMTP id 2so5133140bwz.13 for ; Sat, 20 Nov 2010 13:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=No93VM1raPx+yLAxA5bq0kZJ+e94EWBrlKn7gf9yvPk=; b=sIt39lV+VL6RJYrxLU0FX906qf5UDmN3TgYXvZ2HtduXWUt+dutQVmki4gxcNmT9DD QN4R7LDDVyxFUe9Jtp59anDnf1ErkcQJPHCRqliiIbD8UORcPdqh1cfclBCLooTgkoK8 eBkPGe23hQKLyupSPmjvQ7eQez0jv2wAI5YBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=S3R9FpPUoKwOnivmsi8DQd8u/aQ2X9YiaN7CtU+t0jkfZT3Wz57k9ep6+WsO0os8lK CqjwuqO80wHn5/R9kv/jkfVTjx9fsg7iT9VosRwpU7skVRNyueQtePMkFZMoIX6nqHDx Sir9EyYe+BTfvWm9VOxzWMh6+gYEaRPEtjByY= Received: by 10.204.100.79 with SMTP id x15mr3611115bkn.10.1290288174936; Sat, 20 Nov 2010 13:22:54 -0800 (PST) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id p34sm1554340bkf.15.2010.11.20.13.22.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 13:22:53 -0800 (PST) From: Mikolaj Golub To: "Bjoern A. Zeeb" References: <86pqu0nexd.fsf@kopusha.home.net> <20101120165604.T24596@maildrop.int.zabbadoz.net> <868w0nolqo.fsf@kopusha.home.net> <20101120200208.M24596@maildrop.int.zabbadoz.net> X-Comment-To: Bjoern A. Zeeb Date: Sat, 20 Nov 2010 23:22:50 +0200 In-Reply-To: <20101120200208.M24596@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Sat, 20 Nov 2010 20:04:35 +0000 (UTC)") Message-ID: <864obbofkl.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-hackers@freebsd.org Subject: Re: flowtable_cleaner/flowtable_flush livelock 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: Sat, 20 Nov 2010 21:22:56 -0000 --=-=-= On Sat, 20 Nov 2010 20:04:35 +0000 (UTC) Bjoern A. Zeeb wrote: BAZ> How do you reproduce the crash? Is it just another ifioctl race as BAZ> from kern/146250? Using the same script I posted in my first mail, removing a jail and epair interface simultaneously: ifconfig epair0b vnet myjail jail -r myjail & ifconfig epair0a destroy For me it loooks like other thread is destroying interface improperly in that time. One time I saw crash in another thread: (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc04f2439 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056689728, dummy4=0xc2ba5984 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04f2831 in db_command (last_cmdp=0xc0e75cfc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04f298a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04f48ad in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc090face in kdb_trap (type=12, code=0, tf=0xc2ba5bf8) at /usr/src/sys/kern/subr_kdb.c:546 #6 0xc0c3d2bf in trap_fatal (frame=0xc2ba5bf8, eva=3735929066) at /usr/src/sys/i386/i386/trap.c:971 #7 0xc0c3d4f0 in trap_pfault (frame=0xc2ba5bf8, usermode=0, eva=3735929066) at /usr/src/sys/i386/i386/trap.c:893 #8 0xc0c3dca5 in trap (frame=0xc2ba5bf8) at /usr/src/sys/i386/i386/trap.c:568 #9 0xc0c24a9c in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #10 0xc09ad219 in vnet_destroy (vnet=0xc2f24240) at /usr/src/sys/net/vnet.c:284 #11 0xc08b5922 in prison_deref (pr=0xc3640800, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_jail.c:2506 #12 0xc08b5ab0 in prison_complete (context=0xc3640800, pending=1) at /usr/src/sys/kern/kern_jail.c:2433 #13 0xc091c87b in taskqueue_run_locked (queue=0xc2dd6d80) at /usr/src/sys/kern/subr_taskqueue.c:247 #14 0xc091cf17 in taskqueue_thread_loop (arg=0xc0ebb8e8) at /usr/src/sys/kern/subr_taskqueue.c:379 #15 0xc08af558 in fork_exit (callout=0xc091ceb0 , arg=0xc0ebb8e8, frame=0xc2ba5d28) at /usr/src/sys/kern/kern_fork.c:835 #16 0xc0c24b44 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) fr 10 #10 0xc09ad219 in vnet_destroy (vnet=0xc2f24240) at /usr/src/sys/net/vnet.c:284 284 TAILQ_FOREACH_SAFE(ifp, &V_ifnet, if_link, nifp) { (kgdb) list 279 VNET_LIST_WUNLOCK(); 280 281 CURVNET_SET_QUIET(vnet); 282 283 /* Return all inherited interfaces to their parent vnets. */ 284 TAILQ_FOREACH_SAFE(ifp, &V_ifnet, if_link, nifp) { 285 if (ifp->if_home_vnet != ifp->if_vnet) 286 if_vmove(ifp, ifp->if_home_vnet); 287 } 288 (kgdb) p ifp $1 = (struct ifnet *) 0xdeadc0de Doesn't this need some lock protection? I tried the attached patch, but still observed crashes in ifioctl I posted earlier. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=vnet.c.patch Index: sys/net/vnet.c =================================================================== --- sys/net/vnet.c (revision 215576) +++ sys/net/vnet.c (working copy) @@ -268,7 +268,7 @@ vnet_alloc(void) void vnet_destroy(struct vnet *vnet) { - struct ifnet *ifp, *nifp; + struct ifnet *ifp; SDT_PROBE2(vnet, functions, vnet_destroy, entry, __LINE__, vnet); KASSERT(vnet->vnet_sockcnt == 0, @@ -281,10 +281,20 @@ vnet_destroy(struct vnet *vnet) CURVNET_SET_QUIET(vnet); /* Return all inherited interfaces to their parent vnets. */ - TAILQ_FOREACH_SAFE(ifp, &V_ifnet, if_link, nifp) { - if (ifp->if_home_vnet != ifp->if_vnet) + do { + IFNET_RLOCK(); + TAILQ_FOREACH(ifp, &V_ifnet, if_link) { + if (ifp->if_home_vnet != ifp->if_vnet) { + if_ref(ifp); + break; + } + } + IFNET_RUNLOCK(); + if (ifp != NULL) { if_vmove(ifp, ifp->if_home_vnet); - } + if_rele(ifp); + } + } while (ifp != NULL); vnet_sysuninit(); CURVNET_RESTORE(); --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 20 21:58:04 2010 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 5A476106566B; Sat, 20 Nov 2010 21:58:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C09CD8FC13; Sat, 20 Nov 2010 21:58:03 +0000 (UTC) Received: by wyb35 with SMTP id 35so4941044wyb.13 for ; Sat, 20 Nov 2010 13:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=dqVSELevyqrM2GZCqiZ8zK/v0HjTkNUXo7Y6J7UARAY=; b=iMYNjC6NAgJ/t2kcrpd3MqxoSC520DXhKUCvJaxIC7IrgFbsyZbGByTtjOQOYojdyh tb3ADK4wQwTz05dXiecEtFDNAtiNaWyFmt5tquAXbn1P2R3g4V6ZpUEAAReVZNUqdSxQ HlAus0/FrCHvLcBefDFXtLyZQUP5rYhKeN2Gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=JC1njJML8nY4FB7hMw5rFgu9PDhQzG1uP0OsH2i75vsABhDVr1zQPtIekSK/4kZgPP WUEHwh29sZ1UJGzfvSpCOyNgxHquCUTSI0tReNGLsk5NjAWX/mti8dQexUJ1RLlwQ6uq RtiUrsb4Thg15U+DSrYPZ3wVh2DFJZfReucA0= MIME-Version: 1.0 Received: by 10.216.35.139 with SMTP id u11mr2877793wea.15.1290290282591; Sat, 20 Nov 2010 13:58:02 -0800 (PST) Received: by 10.216.198.27 with HTTP; Sat, 20 Nov 2010 13:58:02 -0800 (PST) Date: Sat, 20 Nov 2010 13:58:02 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Andriy Gapon Subject: Best way to determine if an IRQ is present 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: Sat, 20 Nov 2010 21:58:04 -0000 Trying to do a complete solution for kern/145385, Andriy has raised concerns about IRQ mapping to CPUs; while I've have put together more pieces of the puzzle, I'm a bit confused how I determine whether or not an IRQ is available for use. Sure, I could linear probe a series of IRQs, but that would probably be expensive, and different architectures treat IRQs differently, so building assumptions based on the fact that IRQ hierarchy is done in a particular order is probably not the best thing to do. I've poked around kern/kern_cpuset.c and kern/kern_intr.c a bit but I may have missed something important... Thanks, -Garrett