From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 01:53:46 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 DCC08106566C for ; Sun, 11 Jul 2010 01:53:46 +0000 (UTC) (envelope-from freebsd-hackers@chrisbowman.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 831028FC15 for ; Sun, 11 Jul 2010 01:53:46 +0000 (UTC) Received: by wwe15 with SMTP id 15so844950wwe.31 for ; Sat, 10 Jul 2010 18:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.28.155 with SMTP id m27mr2016974wbc.66.1278811666076; Sat, 10 Jul 2010 18:27:46 -0700 (PDT) Received: by 10.227.140.161 with HTTP; Sat, 10 Jul 2010 18:27:46 -0700 (PDT) X-Originating-IP: [216.27.181.118] Date: Sat, 10 Jul 2010 18:27:46 -0700 Message-ID: From: Christopher Bowman To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Missing files device_if.h and bus_if.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: Sun, 11 Jul 2010 01:53:46 -0000 line 523 of bus.h tries to include the following files: #include "device_if.h" #include "bus_if.h" however, I don't see them any where in my source tree. Are these missing or am I suppose to create them or are they built as part of the build process and if the latter then why didn't I get a copy when I built a custom kernel? Where do I get these files? Could someone please clue me in here? And since I am asking questions here, I see BUS_READ_IVAR used a couple of places but can't find it's definition. Where is it defined? Thanks Christopher From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 03:40:32 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 C83B8106566B for ; Sun, 11 Jul 2010 03:40:32 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 955E88FC17 for ; Sun, 11 Jul 2010 03:40:32 +0000 (UTC) Received: from [192.168.0.100] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o6B3eVuw072596 for ; Sat, 10 Jul 2010 20:40:31 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C393D36.1050905@feral.com> Date: Sat, 10 Jul 2010 20:40:38 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Sat, 10 Jul 2010 20:40:31 -0700 (PDT) Subject: Re: Missing files device_if.h and bus_if.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: Sun, 11 Jul 2010 03:40:32 -0000 config(8) creates them I believe > line 523 of bus.h > > tries to include the following files: > > #include "device_if.h" > #include "bus_if.h" > > however, I don't see them any where in my source tree. Are these > missing or am I suppose to create them or are they built as part of > the build process and if the latter then why didn't I get a copy when > I built a custom kernel? > > Where do I get these files? Could someone please clue me in here? > > And since I am asking questions here, I see BUS_READ_IVAR used a > couple of places but can't find it's definition. Where is it defined? > > Thanks > Christopher > _______________________________________________ > 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 Jul 11 03:58: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 284251065672 for ; Sun, 11 Jul 2010 03:58:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8867F8FC16 for ; Sun, 11 Jul 2010 03:58:35 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-157-65.lns6.adl6.internode.on.net [121.45.157.65]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6B3V165002994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Jul 2010 13:01:08 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sun, 11 Jul 2010 13:01:00 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Bowman X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Missing files device_if.h and bus_if.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: Sun, 11 Jul 2010 03:58:36 -0000 On 11/07/2010, at 10:57, Christopher Bowman wrote: > #include "device_if.h" > #include "bus_if.h" >=20 > however, I don't see them any where in my source tree. Are these > missing or am I suppose to create them or are they built as part of > the build process and if the latter then why didn't I get a copy when > I built a custom kernel? >=20 > Where do I get these files? Could someone please clue me in here? They are part of the newbus infrastructure and are generated on the fly. An awk script (makeobjops.awk) generates them from the corresponding .m = file in src/sys/kern. > And since I am asking questions here, I see BUS_READ_IVAR used a > couple of places but can't find it's definition. Where is it defined? It is defined in (the generated) bus_if.h -> static __inline int BUS_READ_IVAR(device_t _dev, device_t _child, int = _index, uintptr_t *_result) { kobjop_t _m; KOBJOPLOOKUP(((kobj_t)_dev)->ops,bus_read_ivar); return ((bus_read_ivar_t *) _m)(_dev, _child, _index, _result); } -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 11:54: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 E0D21106566B; Sun, 11 Jul 2010 11:54:19 +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 4B8FA8FC17; Sun, 11 Jul 2010 11:54:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA27168; Sun, 11 Jul 2010 14:54:15 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OXv6t-000DmG-EE; Sun, 11 Jul 2010 14:54:15 +0300 Message-ID: <4C39B0E6.3090400@freebsd.org> Date: Sun, 11 Jul 2010 14:54:14 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> In-Reply-To: <4C36FB32.30901@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Konstantin Belousov , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 11:54:20 -0000 on 09/07/2010 13:34 Andriy Gapon said the following: > Having thought and experimented more, I don't see why we need inline assembly at > all and why DPCPU_DEFINE can not simply be defined as follows: > > #define DPCPU_DEFINE(t, n) \ > t DPCPU_NAME(n) __section("set_pcpu") \ > __aligned(CACHE_LINE_SIZE) __used > More explanation for this proposal with additional technical details, demonstrations and conclusions. First, this is the patch that I had in mind (note the file name): http://people.freebsd.org/~avg/dpcpu/pcpu.bad.patch Some test code that exercises DPCPU_DEFINE macro in various (redundant) ways: http://people.freebsd.org/~avg/dpcpu/dpcpu.c GCC-generated assembly with current version of pcpu.h: http://people.freebsd.org/~avg/dpcpu/dpcpu.orig.s Note #APP block, this is what gets produced from the inline assembly. Also note that GCC-generated section directive has exactly the same parameters as the parameters we use in the inline assembly - "aw",@progbits. GCC-generated assembly with patched pcpu.h and its diff from the previous version: http://people.freebsd.org/~avg/dpcpu/dpcpu.bad.s http://people.freebsd.org/~avg/dpcpu/dpcpu.bad.diff Note the section definition is exactly the same as before - it has the same flags, its alignment is the same too (.align 128 vs .p2align 7). It's also obvious where I got confused with this patch (bz, thanks!) and why the patch is named "bad". Instead of defining alignment for the section the patch sets CACHE_LINE_SIZE alignment for each variable defined in that section. Which is a waste, not good, etc. So, while this patch is bad, it still demonstrated that the real reason for the inline assembly is defining sections alignment. But the assembly has nothing to do with "aw" vs "a", variable initialization, etc. Which was my main point. For completeness, here is a patch that simply drops the inline assembly and the comment about it, and GCC-generated assembly and its diff: http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff As was speculated above, the only thing really changed is section alignment (from 128 to 4). And to be continued... -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 12:21: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 97DEC1065670; Sun, 11 Jul 2010 12:21:42 +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 05AF48FC19; Sun, 11 Jul 2010 12:21:40 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27402; Sun, 11 Jul 2010 15:21:38 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OXvXO-000DnP-B6; Sun, 11 Jul 2010 15:21:38 +0300 Message-ID: <4C39B751.8070804@freebsd.org> Date: Sun, 11 Jul 2010 15:21:37 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> In-Reply-To: <4C39B0E6.3090400@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Konstantin Belousov , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 12:21:42 -0000 on 11/07/2010 14:54 Andriy Gapon said the following: > For completeness, here is a patch that simply drops the inline assembly and the > comment about it, and GCC-generated assembly and its diff: > http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch > http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s > http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff > > As was speculated above, the only thing really changed is section alignment > (from 128 to 4). After making the above analysis I wondered why we require set_pcpu section alignment at all. After all, it's not used as loaded, data from the sections gets copied into special per-cpu memory areas. So, logically, it's those areas that need to be aligned, not the section. svn log and google quickly pointed me to this excellent analysis and explanation by bz (thanks again!): http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff Summary: this alignment is needed to work around a bug in GNU binutils ld for __start_SECNAME placement. As explained by bz, ld internally generates an equivalent of the following linker script: Where NN is an alignment of the first _input_ pcpu_set section found in whichever .o file happens to be first. Not the resulting alignment of pcpu_set _output_ section. Alignment requirement of input sections is based on largest alignment requirement of section's members. So if section is empty then the required alignment is 1. Alignment of output section, if not explicitly overridden e.g. via linker script, is the largest alignment of the corresponding input sections. I think that the problem can be fixed by making ld define __start_SECNAME like follows: ... pcpu_set : { __start_pcpu_set = ABSOLUTE(.); ... } __stop_pcpu_set = .; This way __start_SECNAME would always point to the actual start of the output section. Here's a patch that implements the idea: http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch This is similar to what was done upstream: http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h The code is quite different there, and approach is somewhat different, but the idea is the same - place __start_SECNAME inside the section, not outside it. My testing shows the expected results. What do you think? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 12:24: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 511321065672; Sun, 11 Jul 2010 12:24:03 +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 9DAE88FC08; Sun, 11 Jul 2010 12:24:01 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27413; Sun, 11 Jul 2010 15:23:59 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OXvZf-000DnS-FF; Sun, 11 Jul 2010 15:23:59 +0300 Message-ID: <4C39B7DE.3030100@freebsd.org> Date: Sun, 11 Jul 2010 15:23:58 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> In-Reply-To: <4C39B0E6.3090400@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Konstantin Belousov , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 12:24:03 -0000 [oops, sorry, this is not a dup - corrected some omissions/mistakes] on 11/07/2010 14:54 Andriy Gapon said the following: > For completeness, here is a patch that simply drops the inline assembly and the > comment about it, and GCC-generated assembly and its diff: > http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch > http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s > http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff > > As was speculated above, the only thing really changed is section alignment > (from 128 to 4). After making the above analysis I wondered why we require set_pcpu section alignment at all. After all, it's not used as loaded, data from the section gets copied into special per-cpu memory areas. So, logically, it's those areas that need to be aligned, not the section. svn log and google quickly pointed me to this excellent analysis and explanation by bz (thanks again!): http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff Summary: this alignment is needed to work around a bug in GNU binutils ld for __start_SECNAME placement. As explained by bz, ld internally generates an equivalent of the following linker script: ... __start_pcpu_set = ALIGN(NN); pcpu_set : { ... } __stop_pcpu_set = .; Where NN is an alignment of the first _input_ pcpu_set section found in whichever .o file happens to be first. Not the resulting alignment of pcpu_set _output_ section. Alignment requirement of input sections is based on largest alignment requirement of section's members. So if section is empty then the required alignment is 1. Alignment of output section, if not explicitly overridden e.g. via linker script, is the largest alignment of the corresponding input sections. I think that the problem can be fixed by making ld define __start_SECNAME like follows: ... pcpu_set : { __start_pcpu_set = ABSOLUTE(.); ... } __stop_pcpu_set = .; This way __start_SECNAME would always point to the actual start of the output section. Here's a patch that implements the idea: http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch This is similar to what was done upstream: http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h The code is quite different there, and approach is somewhat different, but the idea is the same - place __start_SECNAME inside the section, not outside it. My testing shows the expected results. What do you think? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 14:46: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 8C7CE106567B for ; Sun, 11 Jul 2010 14:46:14 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 46A498FC15 for ; Sun, 11 Jul 2010 14:46:14 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 85F7C14DC04E for ; Sun, 11 Jul 2010 16:46:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Pd2PDPziSj1p for ; Sun, 11 Jul 2010 16:46:10 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4EC3C14DC04A for ; Sun, 11 Jul 2010 16:46:10 +0200 (CEST) Message-ID: <4C39D92F.4050605@FreeBSD.org> Date: Sun, 11 Jul 2010 16:46:07 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 14:46:14 -0000 Hi, I have two int64_t variables in kernel code, first is stored internally and the second one is passed from a syscall argument. When I print them with printf %lld modifier, the internal one behaves correctly but the other one I pass from a syscall has a corrupted value. If I pass 1, it prints out 3735348794091372545. I'm not doing anything special with it just reading it out from the struct that was generated with make sysent. Any ideas? Thanks, Gabor From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 14:53:59 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 76DA71065675; Sun, 11 Jul 2010 14:53:59 +0000 (UTC) (envelope-from dimitry@andric.com) 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 394FA8FC1D; Sun, 11 Jul 2010 14:53:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7d06:cebd:c126:bf09] (unknown [IPv6:2001:7b8:3a7:0:7d06:cebd:c126:bf09]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E63A5C43; Sun, 11 Jul 2010 16:53:57 +0200 (CEST) Message-ID: <4C39DB09.6010808@andric.com> Date: Sun, 11 Jul 2010 16:54:01 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100710 Lanikai/3.1.1pre MIME-Version: 1.0 To: Gabor Kovesdan References: <4C39D92F.4050605@FreeBSD.org> In-Reply-To: <4C39D92F.4050605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 14:53:59 -0000 On 2010-07-11 16:46, Gabor Kovesdan wrote: > I have two int64_t variables in kernel code, first is stored internally > and the second one is passed from a syscall argument. When I print them > with printf %lld modifier, the internal one behaves correctly but the > other one I pass from a syscall has a corrupted value. If I pass 1, it > prints out 3735348794091372545. I'm not doing anything special with it > just reading it out from the struct that was generated with make sysent. Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper word got corrupted somehow. Maybe some part of it got non-atomically assigned? Maybe the wrong word was read? It is hard to tell without code... :) From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 14:58:13 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 372C5106567A for ; Sun, 11 Jul 2010 14:58:13 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id B64018FC15 for ; Sun, 11 Jul 2010 14:58:12 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 44F8E14DC04E; Sun, 11 Jul 2010 16:58:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kKPDgbnudevF; Sun, 11 Jul 2010 16:58:09 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 234A414DC04A; Sun, 11 Jul 2010 16:58:09 +0200 (CEST) Message-ID: <4C39DBFF.2000307@FreeBSD.org> Date: Sun, 11 Jul 2010 16:58:07 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dimitry Andric References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> In-Reply-To: <4C39DB09.6010808@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 14:58:13 -0000 Em 2010.07.11. 16:54, Dimitry Andric escreveu: > On 2010-07-11 16:46, Gabor Kovesdan wrote: > >> I have two int64_t variables in kernel code, first is stored internally >> and the second one is passed from a syscall argument. When I print them >> with printf %lld modifier, the internal one behaves correctly but the >> other one I pass from a syscall has a corrupted value. If I pass 1, it >> prints out 3735348794091372545. I'm not doing anything special with it >> just reading it out from the struct that was generated with make sysent. >> > Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper > word got corrupted somehow. Maybe some part of it got non-atomically > assigned? Maybe the wrong word was read? It is hard to tell without > code... :) > Userland syscall calling: killjob(getjid(), SIGINT); //getjid() returns 1 this case, whose type is jid_t Kernel code: int killjob(struct thread *td, struct killjob_args *uap) { struct jobentry *jp, *jtmp; struct procentry *pp, *ptmp; JOBLIST_WLOCK; LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) { if (jp->jid == uap->jid) { /* never reached code, comparison always fail because of corrupted value */ } } JOBLIST_WUNLOCK; /* not such job */ td->td_retval[0] = -1; return (ENOJOB); } Gabor From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 15:13:10 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 472CF106566B; Sun, 11 Jul 2010 15:13:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [77.88.61.37]) by mx1.freebsd.org (Postfix) with ESMTP id E34858FC1E; Sun, 11 Jul 2010 15:13:09 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward7.mail.yandex.net (Yandex) with ESMTP id 0CB341B08471; Sun, 11 Jul 2010 18:57:57 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1278860277; bh=psuEhGOng0eCdJXAa2D9DJN0i4vfU9O/Ungnb1kaGnc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=UKkZ10Eu0Pa013wh+A3QN3ypUlg+PhVmpHZMPj2vQb+ubnqu6GLIrIe6vuwFzt+fe p0Cn3ysJfak9XF5k34IjDHWRk+U4HEvQDQRaaeNJmeyZalPcgnB8G4C11aftpmXLPj K3pm4UzCPzwxCiY7p1ljU6/7N/1NoIxhqs9zpi7w= Received: from [10.43.163.197] (static-76-197.kirovnet.ru [92.39.76.197]) by smtp6.mail.yandex.net (Yandex) with ESMTPSA id C4E1D32804D; Sun, 11 Jul 2010 18:57:56 +0400 (MSD) Message-ID: <4C39DBE4.5080302@yandex.ru> Date: Sun, 11 Jul 2010 18:57:40 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100611 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gabor Kovesdan References: <4C39D92F.4050605@FreeBSD.org> In-Reply-To: <4C39D92F.4050605@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5281CA977818FA5568A2E588" X-Yandex-TimeMark: 1278860276 X-Yandex-Spam: 1 X-Yandex-Front: smtp6.mail.yandex.net Cc: FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:13:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5281CA977818FA5568A2E588 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 11.07.2010 18:46, Gabor Kovesdan wrote: > I have two int64_t variables in kernel code, first is stored internally= > and the second one is passed from a syscall argument. When I print them= > with printf %lld modifier, the internal one behaves correctly but the > other one I pass from a syscall has a corrupted value. If I pass 1, it > prints out 3735348794091372545. I'm not doing anything special with it > just reading it out from the struct that was generated with make sysent= =2E > Any ideas? Can you show some code? --=20 WBR, Andrey V. Elsukov --------------enig5281CA977818FA5568A2E588 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.14 (FreeBSD) iQEcBAEBAgAGBQJMOdvkAAoJEAHF6gQQyKF63HQIAKA3tw7QjekSTrWnNxp7Rfyy rZP4unfpidMb3kCK7J1fWWlGO4NtSH7YFLs2Scq1Q6aE5aRynDo1Fbe1D80KFTDP tWsEGgJ3wYjeKXUhymQQ//LUywPqhzMbgOKHnjOWffgLGSabP9C8XvXyemlncIKA J+LXLrEQIPIQ7+g2HTwMqn7QElC0cEhAdHuw2ppkIwIX0ECoXTp5eRQ1QvGImJvE oVXHiQLfMesvkKerfYGPp0Q+c1e1kzHAxgl/XIiRwDUycWO6fPtKAppUXqG9MDSN lZgoIKyroeewVXu8q1F/q8TZTseKZBgzWFUpQZP2hmI8dEgskjnXmLh0q1GxJ78= =58X9 -----END PGP SIGNATURE----- --------------enig5281CA977818FA5568A2E588-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 16:01:42 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 824E71065677; Sun, 11 Jul 2010 16:01:42 +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 3762D8FC14; Sun, 11 Jul 2010 16:01:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so4806927iwn.13 for ; Sun, 11 Jul 2010 09:01:41 -0700 (PDT) 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=g6zCkwaCLAWT1TzRyX9wLljrJ+JaecmsjL865Za1WZQ=; b=vCmI2AOIQxRBw4PxLWRIEpdC2h6DpLvFjKDc79xFa31IRPLVN/5Nflq3qQvIBNFoa/ xGQtbDeD6AlcgvIF9fZAiP7PLQ3Sc/Rq0wCSiEE55h9GtOHUdK2/rLAOiClt2hOHQIKI fwTaMEKxZF6QnKOZFhFsTyo+PQIhg17DKFtHg= 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=Eyqi15cFVlo6o15K+8yU3lmeaKprlSInGTjGn8oX/x2uXxstOMrSnBUeFc2QWegg/D ec5I79QtqU5lh7Eb0uhdIgOEk3Kupd1R9PDxcEu8asj7DDGv9tF0Be8BhsUZC7FhB1Bj /9Lst6mFVOWsR8ZOrb2Vtwd+fnkEC4EhlCUxc= MIME-Version: 1.0 Received: by 10.42.7.74 with SMTP id d10mr4128455icd.30.1278862390832; Sun, 11 Jul 2010 08:33:10 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.1.201 with HTTP; Sun, 11 Jul 2010 08:33:10 -0700 (PDT) In-Reply-To: <4C39DBFF.2000307@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> Date: Sun, 11 Jul 2010 08:33:10 -0700 X-Google-Sender-Auth: xghavWCCKlYI9hITRW1y_c2LDIg Message-ID: From: mdf@FreeBSD.org To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 16:01:42 -0000 On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan wrote: > Em 2010.07.11. 16:54, Dimitry Andric escreveu: >> >> On 2010-07-11 16:46, Gabor Kovesdan wrote: >> >>> >>> I have two int64_t variables in kernel code, first is stored internally >>> and the second one is passed from a syscall argument. When I print them >>> with printf %lld modifier, the internal one behaves correctly but the >>> other one I pass from a syscall has a corrupted value. If I pass 1, it >>> prints out 3735348794091372545. I'm not doing anything special with it >>> just reading it out from the struct that was generated with make sysent= . >>> >> >> Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper >> word got corrupted somehow. =A0Maybe some part of it got non-atomically >> assigned? =A0Maybe the wrong word was read? =A0It is hard to tell withou= t >> code... =A0:) >> > > Userland syscall calling: > > killjob(getjid(), SIGINT); =A0//getjid() returns 1 this case, whose type = is > jid_t > > Kernel code: > > int > killjob(struct thread *td, struct killjob_args *uap) > { > =A0 =A0 =A0 =A0struct jobentry *jp, *jtmp; > =A0 =A0 =A0 =A0struct procentry *pp, *ptmp; > > =A0 =A0 =A0 =A0JOBLIST_bWLOCK; > =A0 =A0 =A0 =A0LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (jp->jid =3D=3D uap->jid) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* never reached code, com= parison always fail because > of corrupted value */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0JOBLIST_WUNLOCK; > > =A0 =A0 =A0 =A0/* not such job */ > =A0 =A0 =A0 =A0td->td_retval[0] =3D -1; > =A0 =A0 =A0 =A0return (ENOJOB); > } What does struct killjob_args look like? Is this syscall defined in a module, or an addition to the kernel's syscalls.master? Is the user-space 32-bit or 64-bit? What about the kernel? Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 16:05:54 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 07076106566C for ; Sun, 11 Jul 2010 16:05:54 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id AD9DC8FC15 for ; Sun, 11 Jul 2010 16:05:53 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id BB32F14DC04E; Sun, 11 Jul 2010 18:05:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8JpkFXQSg5LB; Sun, 11 Jul 2010 18:05:50 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 346A114DC043; Sun, 11 Jul 2010 18:05:50 +0200 (CEST) Message-ID: <4C39EBDB.2070804@FreeBSD.org> Date: Sun, 11 Jul 2010 18:05:47 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 16:05:54 -0000 Em 2010.07.11. 17:33, mdf@FreeBSD.org escreveu: > What does struct killjob_args look like? > It's just what make sysent generated: +struct killjob_args { + char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)]; + char signal_l_[PADL_(int)]; int signal; char signal_r_[PADR_(int)]; +}; > Is this syscall defined in a module, or an addition to the kernel's > syscalls.master? > In syscalls.master: + { AS(makenewjob_args), (sy_call_t *)makenewjob, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 523 = makenewjob */ + { AS(killjob_args), (sy_call_t *)killjob, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 524 = killjob */ + { 0, (sy_call_t *)getjid, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 525 = getjid */ + { AS(getjlimit_args), (sy_call_t *)getjlimit, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 526 = getjlimit */ + { AS(setjlimit_args), (sy_call_t *)setjlimit, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 527 = setjlimit */ > Is the user-space 32-bit or 64-bit? What about the kernel? > Both are 32-bit. Gabor From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 19:39:40 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 36875106564A for ; Sun, 11 Jul 2010 19:39:40 +0000 (UTC) (envelope-from yanegomi@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 02EA48FC15 for ; Sun, 11 Jul 2010 19:39:39 +0000 (UTC) Received: by iwn35 with SMTP id 35so4934628iwn.13 for ; Sun, 11 Jul 2010 12:39:39 -0700 (PDT) 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=sdip+WrgrBllX4xLKHpy/KTZvbmnjKYECOxJ4JAasAY=; b=LCokYu5B6LqXfQEmcztSDW3x6K2/namufBgcvZ1q/YuMiJ8Pycg8wG3M/1WxyEtGYh hwOneVGWhXCz/eUCqbLzt+MoB8H3FAvg7+AHN33wpBDGL1HhZPMRpTFmmcRIkpXb/FQA kC29WK+WL3hQTT31CbpFEfHV/VHJFCOH+18OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RWMCAiwp6Qw2f0jms7bqz+OupeNjLHoNGJclTCCVU3dJ2nQnwYL+s+QGn3RSJ/xxWF fNRuua7o0IwVF0f7NVvfsnVXdX1oc1qrlZsEiro516QuVkkco+YVAOf/C5mxLzauwbm8 TgNV1V3Ai4FAFe9RTasZGj0OMAWc36tlfQ3BE= MIME-Version: 1.0 Received: by 10.231.10.137 with SMTP id p9mr13199469ibp.91.1278877179194; Sun, 11 Jul 2010 12:39:39 -0700 (PDT) Received: by 10.231.192.147 with HTTP; Sun, 11 Jul 2010 12:39:39 -0700 (PDT) Date: Sun, 11 Jul 2010 12:39:39 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 19:39:40 -0000 So, long story short... I've basically ported the open posix testsuite to FreeBSD, and one of the tests tests out sigpause. Unfortunately the sucker hangs on my dev box at home. I've written a short testcase that demonstrates this. It prints out: $ ~/test_sigpause 0 And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL, as expected). When I monkey around with libc's compat4.3 stuff a bit, this is what comes up: $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause 0 before sigemptyset before _sigsuspend So it's getting stuck after calling _sigsuspend. I tried the same thing on a i386 8-STABLE VM and it hangs as well. I tried applying similar printfs in libthr but it's not hitting that code at all (it's now responding to SIGTERM though, which is interesting, but not too interesting to me). I also wrote similar code that exercised the functionality in sigsuspend, by calling sigprocmask beforehand, and it works. Thoughts? -Garrett Dev machine: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA amd64 VM: FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 r207913: Tue May 11 06:21:57 UTC 2010 root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386 Index: compat-43/sigcompat.c =================================================================== --- compat-43/sigcompat.c (revision 206173) +++ compat-43/sigcompat.c (working copy) @@ -36,6 +36,7 @@ #include "namespace.h" #include #include +#include #include #include "un-namespace.h" #include "libc_private.h" @@ -102,7 +103,9 @@ { sigset_t set; + printf("before sigemptyset\n"); sigemptyset(&set); + printf("before _sigsuspend\n"); set.__bits[0] = mask; return (_sigsuspend(&set)); } @@ -111,10 +114,16 @@ xsi_sigpause(int sig) { sigset_t set; + int rc; + printf("before sigemptyset\n"); sigemptyset(&set); + printf("before sigaddset\n"); sigaddset(&set, sig); - return (_sigsuspend(&set)); + printf("before _sigsuspend\n"); + rc = (_sigsuspend(&set)); + printf("after _sigsuspend\n"); + return rc; } int $ cat ~/test_sigpause.c #include #include int main (void) { printf("0\n"); fflush(stdout); (void) sigpause(1); return 0; } $ cat ~/test_sigsuspend.c #include #include int main (void) { sigset_t oset; sigset_t nset; if (sigprocmask(1, &nset, &oset) == -1) err(1, "sigprocmask(-1, &nset, &oset)"); if (sigprocmask(-1, &nset, &oset) == -1) err(1, "sigprocmask(-1, &nset, &oset)"); return (sigsuspend(&nset)); } From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:08:48 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 21B7B1065740 for ; Sun, 11 Jul 2010 21:08:48 +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 989798FC12 for ; Sun, 11 Jul 2010 21:08:46 +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 o6BL8hmr030507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 00:08:43 +0300 (EEST) (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 o6BL8hgP080519; Mon, 12 Jul 2010 00:08:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6BL8hwW080518; Mon, 12 Jul 2010 00:08:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Jul 2010 00:08:43 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/YnR2r17TIEndSCI" Content-Disposition: inline In-Reply-To: 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:08:48 -0000 --/YnR2r17TIEndSCI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote: > So, long story short... I've basically ported the open posix testsuite > to FreeBSD, and one of the tests tests out sigpause. Unfortunately the > sucker hangs on my dev box at home. >=20 > I've written a short testcase that demonstrates this. It prints out: >=20 > $ ~/test_sigpause > 0 >=20 > And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL, > as expected). >=20 > When I monkey around with libc's compat4.3 stuff a bit, this is what come= s up: >=20 > $ env LD_LIBRARY_PATH=3D$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause > 0 > before sigemptyset > before _sigsuspend >=20 > So it's getting stuck after calling _sigsuspend. >=20 > I tried the same thing on a i386 8-STABLE VM and it hangs as well. >=20 > I tried applying similar printfs in libthr but it's not hitting that > code at all (it's now responding to SIGTERM though, which is > interesting, but not too interesting to me). >=20 > I also wrote similar code that exercised the functionality in > sigsuspend, by calling sigprocmask beforehand, and it works. >=20 > Thoughts? >=20 > -Garrett >=20 > Dev machine: > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 > root@:/usr/obj/usr/src/sys/BAYONETTA amd64 > VM: > FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 > r207913: Tue May 11 06:21:57 UTC 2010 > root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386 >=20 > Index: compat-43/sigcompat.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- compat-43/sigcompat.c (revision 206173) > +++ compat-43/sigcompat.c (working copy) > @@ -36,6 +36,7 @@ > #include "namespace.h" > #include > #include > +#include > #include > #include "un-namespace.h" > #include "libc_private.h" > @@ -102,7 +103,9 @@ > { > sigset_t set; >=20 > + printf("before sigemptyset\n"); > sigemptyset(&set); > + printf("before _sigsuspend\n"); > set.__bits[0] =3D mask; > return (_sigsuspend(&set)); > } > @@ -111,10 +114,16 @@ > xsi_sigpause(int sig) > { > sigset_t set; > + int rc; >=20 > + printf("before sigemptyset\n"); > sigemptyset(&set); > + printf("before sigaddset\n"); > sigaddset(&set, sig); > - return (_sigsuspend(&set)); > + printf("before _sigsuspend\n"); > + rc =3D (_sigsuspend(&set)); > + printf("after _sigsuspend\n"); > + return rc; > } >=20 > int >=20 > $ cat ~/test_sigpause.c > #include > #include >=20 > int > main (void) > { > printf("0\n"); > fflush(stdout); > (void) sigpause(1); > return 0; > } > $ cat ~/test_sigsuspend.c > #include > #include >=20 > int > main (void) > { > sigset_t oset; > sigset_t nset; > if (sigprocmask(1, &nset, &oset) =3D=3D -1) > err(1, "sigprocmask(-1, &nset, &oset)"); > if (sigprocmask(-1, &nset, &oset) =3D=3D -1) > err(1, "sigprocmask(-1, &nset, &oset)"); > return (sigsuspend(&nset)); > } It seems I got a sigmask for sigpause inside the xsi_sigpause() backward. On the other hand, I do not understand what is your issue with sigpause(). diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c index c3ba30a..bab9d5c 100644 --- a/lib/libc/compat-43/sigcompat.c +++ b/lib/libc/compat-43/sigcompat.c @@ -111,9 +111,12 @@ int xsi_sigpause(int sig) { sigset_t set; + int error; =20 - sigemptyset(&set); - sigaddset(&set, sig); + error =3D _sigprocmask(SIG_BLOCK, NULL, &set); + if (error !=3D 0) + return (error); + sigdelset(&set, sig); return (_sigsuspend(&set)); } =20 --/YnR2r17TIEndSCI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw6MtoACgkQC3+MBN1Mb4jTqgCg9rdU4eYbrJ3YSADcalr2zg5c M+4An3E/BmQSG1zHdobQ7me8rWMVN0Mk =jeZe -----END PGP SIGNATURE----- --/YnR2r17TIEndSCI-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:30:02 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 BA60A106566C for ; Sun, 11 Jul 2010 21:30:02 +0000 (UTC) (envelope-from yanegomi@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 7B1118FC1D for ; Sun, 11 Jul 2010 21:30:02 +0000 (UTC) Received: by iwn35 with SMTP id 35so4990407iwn.13 for ; Sun, 11 Jul 2010 14:30:02 -0700 (PDT) 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=a6oJyMIfQ6peHeDhff0l4JNEAMQMHIuI81K6/biAO90=; b=M5HPGlBrEtI8bSeQuFhVbLgnHXPM3RbbbL4jHgohS+mR3fSlzQRWUhhqdk40SnP8Uv OgJBwxeI8o29NBvblPcL/2gtEAhE/XlBML11WP9+HqwAyDL5FxKFPIcfwn6tRCJZ7uTh l3Bod57HJzN6gwcm/+7FRbaPz/tzagbnzj0f0= 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=UjKdIh7Iybr18mBbS0aWaFfoLtJjxLfRGe+/BpmSs5CB1fJyEIE+2ggQ9z7HC/VJ1p DA1xmpyEY7v+lPWUC+KPQZNou55ieAE40CfQl6x9HG7jI0iZAwo1xWTS4HcDDKvNxs1U CLOO6pgxG+Scg/ctouXfcinal1Oihysw8VYls= MIME-Version: 1.0 Received: by 10.231.150.18 with SMTP id w18mr13999196ibv.43.1278883801825; Sun, 11 Jul 2010 14:30:01 -0700 (PDT) Received: by 10.231.192.147 with HTTP; Sun, 11 Jul 2010 14:30:01 -0700 (PDT) In-Reply-To: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> Date: Sun, 11 Jul 2010 14:30:01 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:30:02 -0000 On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrot= e: > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote: >> So, long story short... I've basically ported the open posix testsuite >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the >> sucker hangs on my dev box at home. >> >> I've written a short testcase that demonstrates this. It prints out: >> >> $ ~/test_sigpause >> 0 >> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL, >> as expected). >> >> When I monkey around with libc's compat4.3 stuff a bit, this is what com= es up: >> >> $ env LD_LIBRARY_PATH=3D$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause >> 0 >> before sigemptyset >> before _sigsuspend >> >> So it's getting stuck after calling _sigsuspend. >> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well. >> >> I tried applying similar printfs in libthr but it's not hitting that >> code at all (it's now responding to SIGTERM though, which is >> interesting, but not too interesting to me). >> >> I also wrote similar code that exercised the functionality in >> sigsuspend, by calling sigprocmask beforehand, and it works. >> >> Thoughts? >> >> -Garrett >> >> Dev machine: >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 >> root@:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> VM: >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 >> r207913: Tue May 11 06:21:57 UTC 2010 >> root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC =A0i386 >> >> Index: compat-43/sigcompat.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- compat-43/sigcompat.c =A0 =A0 (revision 206173) >> +++ compat-43/sigcompat.c =A0 =A0 (working copy) >> @@ -36,6 +36,7 @@ >> =A0#include "namespace.h" >> =A0#include >> =A0#include >> +#include >> =A0#include >> =A0#include "un-namespace.h" >> =A0#include "libc_private.h" >> @@ -102,7 +103,9 @@ >> =A0{ >> =A0 =A0 =A0 sigset_t set; >> >> + =A0 =A0 printf("before sigemptyset\n"); >> =A0 =A0 =A0 sigemptyset(&set); >> + =A0 =A0 printf("before _sigsuspend\n"); >> =A0 =A0 =A0 set.__bits[0] =3D mask; >> =A0 =A0 =A0 return (_sigsuspend(&set)); >> =A0} >> @@ -111,10 +114,16 @@ >> =A0xsi_sigpause(int sig) >> =A0{ >> =A0 =A0 =A0 sigset_t set; >> + =A0 =A0 int rc; >> >> + =A0 =A0 printf("before sigemptyset\n"); >> =A0 =A0 =A0 sigemptyset(&set); >> + =A0 =A0 printf("before sigaddset\n"); >> =A0 =A0 =A0 sigaddset(&set, sig); >> - =A0 =A0 return (_sigsuspend(&set)); >> + =A0 =A0 printf("before _sigsuspend\n"); >> + =A0 =A0 rc =3D (_sigsuspend(&set)); >> + =A0 =A0 printf("after _sigsuspend\n"); >> + =A0 =A0 return rc; >> =A0} >> >> =A0int >> >> $ cat ~/test_sigpause.c >> #include >> #include >> >> int >> main (void) >> { >> =A0 =A0 =A0 =A0 printf("0\n"); >> =A0 =A0 =A0 =A0 fflush(stdout); >> =A0 =A0 =A0 =A0 (void) sigpause(1); >> =A0 =A0 =A0 =A0 return 0; >> } >> $ cat ~/test_sigsuspend.c >> #include >> #include >> >> int >> main (void) >> { >> =A0 =A0 =A0 =A0 sigset_t oset; >> =A0 =A0 =A0 =A0 sigset_t nset; >> =A0 =A0 =A0 =A0 if (sigprocmask(1, &nset, &oset) =3D=3D -1) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset)"); >> =A0 =A0 =A0 =A0 if (sigprocmask(-1, &nset, &oset) =3D=3D -1) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset)"); >> =A0 =A0 =A0 =A0 return (sigsuspend(&nset)); >> } > > It seems I got a sigmask for sigpause inside the xsi_sigpause() backward. > On the other hand, I do not understand what is your issue with sigpause()= . The negative testcase from the open posix testsuite was setup so that setting sigpause(-1) would return -1 with EINVAL, according to the sig* manpages (-1 is an invalid signal of course). That isn't being triggered with either function today. 0 seems a bit wonky too (it's an invalid signal number). My bet is that values greater than SIGRTMAX aren't interpreted properly eit= her. > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompa= t.c > index c3ba30a..bab9d5c 100644 > --- a/lib/libc/compat-43/sigcompat.c > +++ b/lib/libc/compat-43/sigcompat.c > @@ -111,9 +111,12 @@ int > =A0xsi_sigpause(int sig) > =A0{ > =A0 =A0 =A0 =A0sigset_t set; > + =A0 =A0 =A0 int error; > > - =A0 =A0 =A0 sigemptyset(&set); > - =A0 =A0 =A0 sigaddset(&set, sig); > + =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, NULL, &set); > + =A0 =A0 =A0 if (error !=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); > + =A0 =A0 =A0 sigdelset(&set, sig); > =A0 =A0 =A0 =A0return (_sigsuspend(&set)); > =A0} Doesn't this violate the restore clause noted in the manpage? The xsi_sigpause() function removes sig from the signal mask of the ca= ll- ing process and suspend the calling process until a signal is received= . The xsi_sigpause() function restores the signal mask of the process to its original state before returning. So if I had a sigset defined above with sig, then redefined it, I would be whacking the previous handler by passing in NULL to _sigprocmask, correct? If so, sigpause has issues too in its implementation. There's also some interesting SIGDELSET action going on in libthr's copy of _sigsuspend's with SIGCANCEL (apparently that's the unofficial alias for SIGRTMIN as defined by libthr), but that's a sidenote for the actual issue seen here. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:38: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 73BD0106566B; Sun, 11 Jul 2010 21:38:56 +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 D55CE8FC0C; Sun, 11 Jul 2010 21:38:54 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA04939; Mon, 12 Jul 2010 00:38:51 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OY4Ec-000E8R-LZ; Mon, 12 Jul 2010 00:38:50 +0300 Message-ID: <4C3A39E9.1070505@freebsd.org> Date: Mon, 12 Jul 2010 00:38:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Jeff Roberson References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Wemm , freebsd-hackers@freebsd.org, Jeff Roberson , Konstantin Belousov , "Bjoern A. Zeeb" Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:38:56 -0000 on 12/07/2010 00:15 Jeff Roberson said the following: > > On Sun, 11 Jul 2010, Andriy Gapon wrote: > >> >> [oops, sorry, this is not a dup - corrected some omissions/mistakes] >> >> on 11/07/2010 14:54 Andriy Gapon said the following: >>> For completeness, here is a patch that simply drops the inline >>> assembly and the >>> comment about it, and GCC-generated assembly and its diff: >>> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch >>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s >>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff >>> >>> As was speculated above, the only thing really changed is section >>> alignment >>> (from 128 to 4). >> >> After making the above analysis I wondered why we require set_pcpu >> section >> alignment at all. After all, it's not used as loaded, data from the >> section >> gets copied into special per-cpu memory areas. So, logically, it's >> those areas >> that need to be aligned, not the section. > > I appreciate your analysis but I don't understand the motivation for > changing working code. Primary reason is that the "working code" produces zero-sized unused/unnecessary pcpu_set sections. See the subject line. As to why I care about those sections - please see the start of this thread. P.S. Short summary: there is no reason to have zero sized sections; some tools either do not expect them or handle them suboptimally. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:40:21 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 5FE70106566C for ; Sun, 11 Jul 2010 21:40:21 +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 BDA0C8FC08 for ; Sun, 11 Jul 2010 21:40:20 +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 o6BLeHuU033023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 00:40:17 +0300 (EEST) (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 o6BLeHA5080977; Mon, 12 Jul 2010 00:40:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6BLeH0M080976; Mon, 12 Jul 2010 00:40:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Jul 2010 00:40:17 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20100711214016.GR2408@deviant.kiev.zoral.com.ua> References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9lPOKfY2vCV97ybw" Content-Disposition: inline In-Reply-To: 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:40:21 -0000 --9lPOKfY2vCV97ybw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote: > On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wr= ote: > > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote: > >> So, long story short... I've basically ported the open posix testsuite > >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the > >> sucker hangs on my dev box at home. > >> > >> I've written a short testcase that demonstrates this. It prints out: > >> > >> $ ~/test_sigpause > >> 0 > >> > >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL, > >> as expected). > >> > >> When I monkey around with libc's compat4.3 stuff a bit, this is what c= omes up: > >> > >> $ env LD_LIBRARY_PATH=3D$PWD:/usr/src/lib/libc/../libthr ~/test_sigpau= se > >> 0 > >> before sigemptyset > >> before _sigsuspend > >> > >> So it's getting stuck after calling _sigsuspend. > >> > >> I tried the same thing on a i386 8-STABLE VM and it hangs as well. > >> > >> I tried applying similar printfs in libthr but it's not hitting that > >> code at all (it's now responding to SIGTERM though, which is > >> interesting, but not too interesting to me). > >> > >> I also wrote similar code that exercised the functionality in > >> sigsuspend, by calling sigprocmask beforehand, and it works. > >> > >> Thoughts? > >> > >> -Garrett > >> > >> Dev machine: > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 > >> root@:/usr/obj/usr/src/sys/BAYONETTA =9Aamd64 > >> VM: > >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 > >> r207913: Tue May 11 06:21:57 UTC 2010 > >> root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC =9Ai386 > >> > >> Index: compat-43/sigcompat.c > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- compat-43/sigcompat.c =9A =9A (revision 206173) > >> +++ compat-43/sigcompat.c =9A =9A (working copy) > >> @@ -36,6 +36,7 @@ > >> =9A#include "namespace.h" > >> =9A#include > >> =9A#include > >> +#include > >> =9A#include > >> =9A#include "un-namespace.h" > >> =9A#include "libc_private.h" > >> @@ -102,7 +103,9 @@ > >> =9A{ > >> =9A =9A =9A sigset_t set; > >> > >> + =9A =9A printf("before sigemptyset\n"); > >> =9A =9A =9A sigemptyset(&set); > >> + =9A =9A printf("before _sigsuspend\n"); > >> =9A =9A =9A set.__bits[0] =3D mask; > >> =9A =9A =9A return (_sigsuspend(&set)); > >> =9A} > >> @@ -111,10 +114,16 @@ > >> =9Axsi_sigpause(int sig) > >> =9A{ > >> =9A =9A =9A sigset_t set; > >> + =9A =9A int rc; > >> > >> + =9A =9A printf("before sigemptyset\n"); > >> =9A =9A =9A sigemptyset(&set); > >> + =9A =9A printf("before sigaddset\n"); > >> =9A =9A =9A sigaddset(&set, sig); > >> - =9A =9A return (_sigsuspend(&set)); > >> + =9A =9A printf("before _sigsuspend\n"); > >> + =9A =9A rc =3D (_sigsuspend(&set)); > >> + =9A =9A printf("after _sigsuspend\n"); > >> + =9A =9A return rc; > >> =9A} > >> > >> =9Aint > >> > >> $ cat ~/test_sigpause.c > >> #include > >> #include > >> > >> int > >> main (void) > >> { > >> =9A =9A =9A =9A printf("0\n"); > >> =9A =9A =9A =9A fflush(stdout); > >> =9A =9A =9A =9A (void) sigpause(1); > >> =9A =9A =9A =9A return 0; > >> } > >> $ cat ~/test_sigsuspend.c > >> #include > >> #include > >> > >> int > >> main (void) > >> { > >> =9A =9A =9A =9A sigset_t oset; > >> =9A =9A =9A =9A sigset_t nset; > >> =9A =9A =9A =9A if (sigprocmask(1, &nset, &oset) =3D=3D -1) > >> =9A =9A =9A =9A =9A =9A =9A =9A err(1, "sigprocmask(-1, &nset, &oset)"= ); > >> =9A =9A =9A =9A if (sigprocmask(-1, &nset, &oset) =3D=3D -1) > >> =9A =9A =9A =9A =9A =9A =9A =9A err(1, "sigprocmask(-1, &nset, &oset)"= ); > >> =9A =9A =9A =9A return (sigsuspend(&nset)); > >> } > > > > It seems I got a sigmask for sigpause inside the xsi_sigpause() backwar= d. > > On the other hand, I do not understand what is your issue with sigpause= (). >=20 > The negative testcase from the open posix testsuite was setup so that > setting sigpause(-1) would return -1 with EINVAL, according to the > sig* manpages (-1 is an invalid signal of course). That isn't being > triggered with either function today. >=20 > 0 seems a bit wonky too (it's an invalid signal number). >=20 > My bet is that values greater than SIGRTMAX aren't interpreted properly e= ither. I will add these checks, thanks. >=20 > > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcom= pat.c > > index c3ba30a..bab9d5c 100644 > > --- a/lib/libc/compat-43/sigcompat.c > > +++ b/lib/libc/compat-43/sigcompat.c > > @@ -111,9 +111,12 @@ int > > =9Axsi_sigpause(int sig) > > =9A{ > > =9A =9A =9A =9Asigset_t set; > > + =9A =9A =9A int error; > > > > - =9A =9A =9A sigemptyset(&set); > > - =9A =9A =9A sigaddset(&set, sig); > > + =9A =9A =9A error =3D _sigprocmask(SIG_BLOCK, NULL, &set); > > + =9A =9A =9A if (error !=3D 0) > > + =9A =9A =9A =9A =9A =9A =9A return (error); > > + =9A =9A =9A sigdelset(&set, sig); > > =9A =9A =9A =9Areturn (_sigsuspend(&set)); > > =9A} >=20 > Doesn't this violate the restore clause noted in the manpage? >=20 > The xsi_sigpause() function removes sig from the signal mask of the = call- > ing process and suspend the calling process until a signal is receiv= ed. > The xsi_sigpause() function restores the signal mask of the process = to > its original state before returning. >=20 > So if I had a sigset defined above with sig, then redefined it, I > would be whacking the previous handler by passing in NULL to > _sigprocmask, correct? If so, sigpause has issues too in its > implementation. No, not correct. Read the description of sigsuspend. Also note that the sigprocmask call does not change process mask. >=20 > There's also some interesting SIGDELSET action going on in libthr's > copy of _sigsuspend's with SIGCANCEL (apparently that's the unofficial > alias for SIGRTMIN as defined by libthr), but that's a sidenote for > the actual issue seen here. >=20 > Thanks! > -Garrett --9lPOKfY2vCV97ybw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw6OkAACgkQC3+MBN1Mb4geJwCgyQz9p1k0/WB8UYWFQQvQwQfn Q9YAoN4NM4ArLLI1TW6TjVSXESBX1iTf =XVE0 -----END PGP SIGNATURE----- --9lPOKfY2vCV97ybw-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 22:35:01 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 DBA921065675 for ; Sun, 11 Jul 2010 22:35:01 +0000 (UTC) (envelope-from yanegomi@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 9F6548FC20 for ; Sun, 11 Jul 2010 22:35:01 +0000 (UTC) Received: by iwn35 with SMTP id 35so5027050iwn.13 for ; Sun, 11 Jul 2010 15:35:01 -0700 (PDT) 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=Fz3dgQdr70qiaMtg0G+NWqDF8kV2+OqsfqIr+e6Y2u0=; b=nRZx+XHN2eD7yZiUdc3BD2jiI7QPOI2Q0e1U8t7Hxq6Uptvyfc1hpAmwfAUuJv66pR +M34rvTGKnTk7B5W/Tz34Lep42GOq8aifC28UFhNtWfoOF/Lqj97wv8HhWyuhldzhriv za1zB6ehSrYdV5KkRfQ3IFsGm7QzJyQU4nvf8= 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=dtVBzD6NcrAxpxFgKkQCkVf4ZK/czKubvCHhg/0K+9tI4cmX1HA84OHxgi17tQYGIZ TxH3RGZNrlP5tzceqdJavPUMNmI3yNIkzLklstXbUYrCtFWmdwJPGJlOqQn97I9n4BCY 5B75YxnqwPEIT4d0Dj7qf+C+/fb4gTmwUK+VA= MIME-Version: 1.0 Received: by 10.231.17.13 with SMTP id q13mr12581020iba.14.1278887700951; Sun, 11 Jul 2010 15:35:00 -0700 (PDT) Received: by 10.231.192.147 with HTTP; Sun, 11 Jul 2010 15:35:00 -0700 (PDT) In-Reply-To: <20100711214016.GR2408@deviant.kiev.zoral.com.ua> References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> Date: Sun, 11 Jul 2010 15:35:00 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 22:35:01 -0000 2010/7/11 Kostik Belousov : > On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote: >> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov w= rote: >> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote: >> >> So, long story short... I've basically ported the open posix testsuit= e >> >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately th= e >> >> sucker hangs on my dev box at home. >> >> >> >> I've written a short testcase that demonstrates this. It prints out: >> >> >> >> $ ~/test_sigpause >> >> 0 >> >> >> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL, >> >> as expected). >> >> >> >> When I monkey around with libc's compat4.3 stuff a bit, this is what = comes up: >> >> >> >> $ env LD_LIBRARY_PATH=3D$PWD:/usr/src/lib/libc/../libthr ~/test_sigpa= use >> >> 0 >> >> before sigemptyset >> >> before _sigsuspend >> >> >> >> So it's getting stuck after calling _sigsuspend. >> >> >> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well. >> >> >> >> I tried applying similar printfs in libthr but it's not hitting that >> >> code at all (it's now responding to SIGTERM though, which is >> >> interesting, but not too interesting to me). >> >> >> >> I also wrote similar code that exercised the functionality in >> >> sigsuspend, by calling sigprocmask beforehand, and it works. >> >> >> >> Thoughts? >> >> >> >> -Garrett >> >> >> >> Dev machine: >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >> >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 >> >> root@:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> >> VM: >> >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 >> >> r207913: Tue May 11 06:21:57 UTC 2010 >> >> root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC =A0i386 >> >> >> >> Index: compat-43/sigcompat.c >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> --- compat-43/sigcompat.c =A0 =A0 (revision 206173) >> >> +++ compat-43/sigcompat.c =A0 =A0 (working copy) >> >> @@ -36,6 +36,7 @@ >> >> =A0#include "namespace.h" >> >> =A0#include >> >> =A0#include >> >> +#include >> >> =A0#include >> >> =A0#include "un-namespace.h" >> >> =A0#include "libc_private.h" >> >> @@ -102,7 +103,9 @@ >> >> =A0{ >> >> =A0 =A0 =A0 sigset_t set; >> >> >> >> + =A0 =A0 printf("before sigemptyset\n"); >> >> =A0 =A0 =A0 sigemptyset(&set); >> >> + =A0 =A0 printf("before _sigsuspend\n"); >> >> =A0 =A0 =A0 set.__bits[0] =3D mask; >> >> =A0 =A0 =A0 return (_sigsuspend(&set)); >> >> =A0} >> >> @@ -111,10 +114,16 @@ >> >> =A0xsi_sigpause(int sig) >> >> =A0{ >> >> =A0 =A0 =A0 sigset_t set; >> >> + =A0 =A0 int rc; >> >> >> >> + =A0 =A0 printf("before sigemptyset\n"); >> >> =A0 =A0 =A0 sigemptyset(&set); >> >> + =A0 =A0 printf("before sigaddset\n"); >> >> =A0 =A0 =A0 sigaddset(&set, sig); >> >> - =A0 =A0 return (_sigsuspend(&set)); >> >> + =A0 =A0 printf("before _sigsuspend\n"); >> >> + =A0 =A0 rc =3D (_sigsuspend(&set)); >> >> + =A0 =A0 printf("after _sigsuspend\n"); >> >> + =A0 =A0 return rc; >> >> =A0} >> >> >> >> =A0int >> >> >> >> $ cat ~/test_sigpause.c >> >> #include >> >> #include >> >> >> >> int >> >> main (void) >> >> { >> >> =A0 =A0 =A0 =A0 printf("0\n"); >> >> =A0 =A0 =A0 =A0 fflush(stdout); >> >> =A0 =A0 =A0 =A0 (void) sigpause(1); >> >> =A0 =A0 =A0 =A0 return 0; >> >> } >> >> $ cat ~/test_sigsuspend.c >> >> #include >> >> #include >> >> >> >> int >> >> main (void) >> >> { >> >> =A0 =A0 =A0 =A0 sigset_t oset; >> >> =A0 =A0 =A0 =A0 sigset_t nset; >> >> =A0 =A0 =A0 =A0 if (sigprocmask(1, &nset, &oset) =3D=3D -1) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset)= "); >> >> =A0 =A0 =A0 =A0 if (sigprocmask(-1, &nset, &oset) =3D=3D -1) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset)= "); >> >> =A0 =A0 =A0 =A0 return (sigsuspend(&nset)); >> >> } >> > >> > It seems I got a sigmask for sigpause inside the xsi_sigpause() backwa= rd. >> > On the other hand, I do not understand what is your issue with sigpaus= e(). >> >> The negative testcase from the open posix testsuite was setup so that >> setting sigpause(-1) would return -1 with EINVAL, according to the >> sig* manpages (-1 is an invalid signal of course). That isn't being >> triggered with either function today. >> >> 0 seems a bit wonky too (it's an invalid signal number). >> >> My bet is that values greater than SIGRTMAX aren't interpreted properly = either. > > I will add these checks, thanks. Much obliged :)... FWIW sigprocmask fails to do the right thing in detecting the signal number: $ ~/test_sigprocmask signo =3D -1 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) signo =3D 0 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) signo =3D 1 result sane signo =3D 9 result sane signo =3D 17 result sane signo =3D 65 result sane signo =3D 64 result sane signo =3D 66 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) Would this fix that? Index: sys/kern/kern_sig.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_sig.c (revision 206173) +++ sys/kern/kern_sig.c (working copy) @@ -988,6 +988,9 @@ struct proc *p; int error; + if (!_SIG_VALID(how)) + return (-EINVAL); + p =3D td->td_proc; if (!(flags & SIGPROCMASK_PROC_LOCKED)) PROC_LOCK(p); I'll look for more low-hanging fruit. >> > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigco= mpat.c >> > index c3ba30a..bab9d5c 100644 >> > --- a/lib/libc/compat-43/sigcompat.c >> > +++ b/lib/libc/compat-43/sigcompat.c >> > @@ -111,9 +111,12 @@ int >> > =A0xsi_sigpause(int sig) >> > =A0{ >> > =A0 =A0 =A0 =A0sigset_t set; >> > + =A0 =A0 =A0 int error; >> > >> > - =A0 =A0 =A0 sigemptyset(&set); >> > - =A0 =A0 =A0 sigaddset(&set, sig); >> > + =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, NULL, &set); >> > + =A0 =A0 =A0 if (error !=3D 0) >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); >> > + =A0 =A0 =A0 sigdelset(&set, sig); >> > =A0 =A0 =A0 =A0return (_sigsuspend(&set)); >> > =A0} >> >> Doesn't this violate the restore clause noted in the manpage? >> >> =A0 =A0 =A0The xsi_sigpause() function removes sig from the signal mask = of the call- >> =A0 =A0 =A0ing process and suspend the calling process until a signal is= received. >> =A0 =A0 =A0The xsi_sigpause() function restores the signal mask of the p= rocess to >> =A0 =A0 =A0its original state before returning. >> >> So if I had a sigset defined above with sig, then redefined it, I >> would be whacking the previous handler by passing in NULL to >> _sigprocmask, correct? If so, sigpause has issues too in its >> implementation. > No, not correct. Read the description of sigsuspend. Yeah, I was wrong here: The sigsuspend() system call temporarily changes the blocked signal ma= sk to the set to which sigmask points, and then waits for a signal to arrive; on return the previous set of masked signals is restored. The signal mask set is usually empty to indicate that all signals are to b= e unblocked for the duration of the call. > Also note that the sigprocmask call does not change process mask. Not so sure about this though: The sigprocmask() system call examines and/or changes the current sign= al mask (those signals that are blocked from delivery). Signals are bloc= ked if they are members of the current signal mask set. >> There's also some interesting SIGDELSET action going on in libthr's >> copy of _sigsuspend's with SIGCANCEL (apparently that's the unofficial >> alias for SIGRTMIN as defined by libthr), but that's a sidenote for >> the actual issue seen here. Here's the test app I wrote and executed above, just for future referen= ce: Thanks! -Garrett $ cat ~/test_sigprocmask.c #include #include #include #include #define TEST_SIGPROCMASK_POS(signo) do { \ printf("signo =3D %d ", signo); \ rc =3D sigprocmask(-1, NULL, &oset); \ if (rc !=3D 0) { \ printf("result not sane (%d !=3D 0, errno: %d)\n", \ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) #define TEST_SIGPROCMASK_NEG(signo) do { \ printf("signo =3D %d ", signo); \ rc =3D sigprocmask(-1, NULL, &oset); \ if (rc !=3D -1 || errno !=3D EINVAL) { \ printf("result not sane (%d !=3D -1, " \ "errno: %d !=3D EINVAL)\n", \ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) int main(void) { sigset_t oset; int rc; TEST_SIGPROCMASK_NEG(-1); TEST_SIGPROCMASK_NEG(0); TEST_SIGPROCMASK_POS(SIGHUP); /* The system quietly disallows SIGKILL or SIGSTOP to be blocked. */ TEST_SIGPROCMASK_POS(SIGKILL); TEST_SIGPROCMASK_POS(SIGSTOP); TEST_SIGPROCMASK_POS(SIGRTMIN); TEST_SIGPROCMASK_POS(SIGRTMIN-1); TEST_SIGPROCMASK_NEG(SIGRTMIN+1); return (0); } From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 22:59:07 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 0445C1065672 for ; Sun, 11 Jul 2010 22:59:07 +0000 (UTC) (envelope-from yanegomi@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 BB2B48FC0C for ; Sun, 11 Jul 2010 22:59:06 +0000 (UTC) Received: by iwn35 with SMTP id 35so5040687iwn.13 for ; Sun, 11 Jul 2010 15:59:06 -0700 (PDT) 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=85mZuks3s0hWrYfZMLs8gqrRunMfnaOfxKcV5p2z3yk=; b=p6r9mzU2S/otqxiQ8bqyVCOC6Tprd2x60j19CjrkcskQtmVowdPkOCEUbdRQiIjc/b SitnySsrECUQHI4pqcrSafLQ6k390FF6s3MV89AIL7o70Fn4slAyLZPa1G5POv9aIXbL dRf5L15ODTHH9yHVWqBqARg79/gjwkZYbOF+g= 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=WaSeIfitR96z4GE2urM/Jfba1eFSMANDf4A0tk9TEjtlBavoKLCMf4OHrXcocm2W8Q u+5ADWg/JBPXIkbSSJvhhJ4+PYeeq1Vh957yhtdHTbWIKuOULfl+yFosA0FkaBx7qf/s D/jxc66S5vGU2CqcCuoFDFS6+Smr+s/BzUEtM= MIME-Version: 1.0 Received: by 10.231.191.138 with SMTP id dm10mr1451296ibb.126.1278889145852; Sun, 11 Jul 2010 15:59:05 -0700 (PDT) Received: by 10.231.192.147 with HTTP; Sun, 11 Jul 2010 15:59:05 -0700 (PDT) In-Reply-To: References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> Date: Sun, 11 Jul 2010 15:59:05 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 22:59:07 -0000 On Sun, Jul 11, 2010 at 3:35 PM, Garrett Cooper wrote: > 2010/7/11 Kostik Belousov : >> On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote: >>> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov = wrote: >>> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote: >>> >> So, long story short... I've basically ported the open posix testsui= te >>> >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately t= he >>> >> sucker hangs on my dev box at home. >>> >> >>> >> I've written a short testcase that demonstrates this. It prints out: >>> >> >>> >> $ ~/test_sigpause >>> >> 0 >>> >> >>> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL= , >>> >> as expected). >>> >> >>> >> When I monkey around with libc's compat4.3 stuff a bit, this is what= comes up: >>> >> >>> >> $ env LD_LIBRARY_PATH=3D$PWD:/usr/src/lib/libc/../libthr ~/test_sigp= ause >>> >> 0 >>> >> before sigemptyset >>> >> before _sigsuspend >>> >> >>> >> So it's getting stuck after calling _sigsuspend. >>> >> >>> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well. >>> >> >>> >> I tried applying similar printfs in libthr but it's not hitting that >>> >> code at all (it's now responding to SIGTERM though, which is >>> >> interesting, but not too interesting to me). >>> >> >>> >> I also wrote similar code that exercised the functionality in >>> >> sigsuspend, by calling sigprocmask beforehand, and it works. >>> >> >>> >> Thoughts? >>> >> >>> >> -Garrett >>> >> >>> >> Dev machine: >>> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >>> >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010 >>> >> root@:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >>> >> VM: >>> >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0 >>> >> r207913: Tue May 11 06:21:57 UTC 2010 >>> >> root@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC =A0i386 >>> >> >>> >> Index: compat-43/sigcompat.c >>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> --- compat-43/sigcompat.c =A0 =A0 (revision 206173) >>> >> +++ compat-43/sigcompat.c =A0 =A0 (working copy) >>> >> @@ -36,6 +36,7 @@ >>> >> =A0#include "namespace.h" >>> >> =A0#include >>> >> =A0#include >>> >> +#include >>> >> =A0#include >>> >> =A0#include "un-namespace.h" >>> >> =A0#include "libc_private.h" >>> >> @@ -102,7 +103,9 @@ >>> >> =A0{ >>> >> =A0 =A0 =A0 sigset_t set; >>> >> >>> >> + =A0 =A0 printf("before sigemptyset\n"); >>> >> =A0 =A0 =A0 sigemptyset(&set); >>> >> + =A0 =A0 printf("before _sigsuspend\n"); >>> >> =A0 =A0 =A0 set.__bits[0] =3D mask; >>> >> =A0 =A0 =A0 return (_sigsuspend(&set)); >>> >> =A0} >>> >> @@ -111,10 +114,16 @@ >>> >> =A0xsi_sigpause(int sig) >>> >> =A0{ >>> >> =A0 =A0 =A0 sigset_t set; >>> >> + =A0 =A0 int rc; >>> >> >>> >> + =A0 =A0 printf("before sigemptyset\n"); >>> >> =A0 =A0 =A0 sigemptyset(&set); >>> >> + =A0 =A0 printf("before sigaddset\n"); >>> >> =A0 =A0 =A0 sigaddset(&set, sig); >>> >> - =A0 =A0 return (_sigsuspend(&set)); >>> >> + =A0 =A0 printf("before _sigsuspend\n"); >>> >> + =A0 =A0 rc =3D (_sigsuspend(&set)); >>> >> + =A0 =A0 printf("after _sigsuspend\n"); >>> >> + =A0 =A0 return rc; >>> >> =A0} >>> >> >>> >> =A0int >>> >> >>> >> $ cat ~/test_sigpause.c >>> >> #include >>> >> #include >>> >> >>> >> int >>> >> main (void) >>> >> { >>> >> =A0 =A0 =A0 =A0 printf("0\n"); >>> >> =A0 =A0 =A0 =A0 fflush(stdout); >>> >> =A0 =A0 =A0 =A0 (void) sigpause(1); >>> >> =A0 =A0 =A0 =A0 return 0; >>> >> } >>> >> $ cat ~/test_sigsuspend.c >>> >> #include >>> >> #include >>> >> >>> >> int >>> >> main (void) >>> >> { >>> >> =A0 =A0 =A0 =A0 sigset_t oset; >>> >> =A0 =A0 =A0 =A0 sigset_t nset; >>> >> =A0 =A0 =A0 =A0 if (sigprocmask(1, &nset, &oset) =3D=3D -1) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset= )"); >>> >> =A0 =A0 =A0 =A0 if (sigprocmask(-1, &nset, &oset) =3D=3D -1) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "sigprocmask(-1, &nset, &oset= )"); >>> >> =A0 =A0 =A0 =A0 return (sigsuspend(&nset)); >>> >> } >>> > >>> > It seems I got a sigmask for sigpause inside the xsi_sigpause() backw= ard. >>> > On the other hand, I do not understand what is your issue with sigpau= se(). >>> >>> The negative testcase from the open posix testsuite was setup so that >>> setting sigpause(-1) would return -1 with EINVAL, according to the >>> sig* manpages (-1 is an invalid signal of course). That isn't being >>> triggered with either function today. >>> >>> 0 seems a bit wonky too (it's an invalid signal number). >>> >>> My bet is that values greater than SIGRTMAX aren't interpreted properly= either. >> >> I will add these checks, thanks. > > =A0 =A0Much obliged :)... FWIW sigprocmask fails to do the right thing in > detecting the signal number: > > $ ~/test_sigprocmask > signo =3D -1 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) > signo =3D 0 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) > signo =3D 1 result sane > signo =3D 9 result sane > signo =3D 17 result sane > signo =3D 65 result sane > signo =3D 64 result sane > signo =3D 66 result not sane (0 !=3D -1, errno: 0 !=3D EINVAL) > > =A0 =A0Would this fix that? > > Index: sys/kern/kern_sig.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_sig.c (revision 206173) > +++ sys/kern/kern_sig.c (working copy) > @@ -988,6 +988,9 @@ > =A0 =A0 =A0 =A0struct proc *p; > =A0 =A0 =A0 =A0int error; > > + =A0 =A0 =A0 if (!_SIG_VALID(how)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-EINVAL); > + > =A0 =A0 =A0 =A0p =3D td->td_proc; > =A0 =A0 =A0 =A0if (!(flags & SIGPROCMASK_PROC_LOCKED)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PROC_LOCK(p); *snickers* no, that definitely doesn't fix the problem: $ ~/test_sigprocmask signo =3D -1 result not sane (-1 !=3D -1, errno: -22 !=3D EINVAL) signo =3D 0 result not sane (-1 !=3D -1, errno: -22 !=3D EINVAL) signo =3D 1 result not sane (-1 !=3D 0, errno: -22) signo =3D 9 result not sane (-1 !=3D 0, errno: -22) signo =3D 17 result not sane (-1 !=3D 0, errno: -22) signo =3D 65 result not sane (-1 !=3D 0, errno: -22) signo =3D 64 result not sane (-1 !=3D 0, errno: -22) signo =3D 66 result not sane (-1 !=3D -1, errno: -22 !=3D EINVAL) > =A0 =A0I'll look for more low-hanging fruit. > >>> > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigc= ompat.c >>> > index c3ba30a..bab9d5c 100644 >>> > --- a/lib/libc/compat-43/sigcompat.c >>> > +++ b/lib/libc/compat-43/sigcompat.c >>> > @@ -111,9 +111,12 @@ int >>> > =A0xsi_sigpause(int sig) >>> > =A0{ >>> > =A0 =A0 =A0 =A0sigset_t set; >>> > + =A0 =A0 =A0 int error; >>> > >>> > - =A0 =A0 =A0 sigemptyset(&set); >>> > - =A0 =A0 =A0 sigaddset(&set, sig); >>> > + =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, NULL, &set); >>> > + =A0 =A0 =A0 if (error !=3D 0) >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); >>> > + =A0 =A0 =A0 sigdelset(&set, sig); >>> > =A0 =A0 =A0 =A0return (_sigsuspend(&set)); >>> > =A0} >>> >>> Doesn't this violate the restore clause noted in the manpage? >>> >>> =A0 =A0 =A0The xsi_sigpause() function removes sig from the signal mask= of the call- >>> =A0 =A0 =A0ing process and suspend the calling process until a signal i= s received. >>> =A0 =A0 =A0The xsi_sigpause() function restores the signal mask of the = process to >>> =A0 =A0 =A0its original state before returning. >>> >>> So if I had a sigset defined above with sig, then redefined it, I >>> would be whacking the previous handler by passing in NULL to >>> _sigprocmask, correct? If so, sigpause has issues too in its >>> implementation. >> No, not correct. Read the description of sigsuspend. > > =A0 =A0Yeah, I was wrong here: > > =A0 =A0 The sigsuspend() system call temporarily changes the blocked sign= al mask > =A0 =A0 to the set to which sigmask points, and then waits for a signal t= o > =A0 =A0 arrive; on return the previous set of masked signals is restored.= =A0The > =A0 =A0 signal mask set is usually empty to indicate that all signals are= to be > =A0 =A0 unblocked for the duration of the call. > >> Also note that the sigprocmask call does not change process mask. > > =A0 =A0Not so sure about this though: > > =A0 =A0 The sigprocmask() system call examines and/or changes the current= signal > =A0 =A0 mask (those signals that are blocked from delivery). =A0Signals a= re blocked > =A0 =A0 if they are members of the current signal mask set. > >>> There's also some interesting SIGDELSET action going on in libthr's >>> copy of _sigsuspend's with SIGCANCEL (apparently that's the unofficial >>> alias for SIGRTMIN as defined by libthr), but that's a sidenote for >>> the actual issue seen here. > > =A0 =A0Here's the test app I wrote and executed above, just for future re= ference: > Thanks! > -Garrett > > $ cat ~/test_sigprocmask.c > #include > #include > #include > #include > > #define TEST_SIGPROCMASK_POS(signo) do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("signo =3D %d ", signo); =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D sigprocmask(-1, NULL, &oset); =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (rc !=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("result not sane (%= d !=3D 0, errno: %d)\n", \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc, errno); =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("result sane\n"); = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0} while (0) > > #define TEST_SIGPROCMASK_NEG(signo) do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("signo =3D %d ", signo); =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D sigprocmask(-1, NULL, &oset); =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (rc !=3D -1 || errno !=3D EINVAL) { =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("result not sane (%= d !=3D -1, " =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"errno: %d !=3D EI= NVAL)\n", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc, errno); =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("result sane\n"); = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0} while (0) > > int > main(void) > { > =A0 =A0 =A0 =A0sigset_t oset; > =A0 =A0 =A0 =A0int rc; > > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_NEG(-1); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_NEG(0); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_POS(SIGHUP); > =A0 =A0 =A0 =A0/* The system quietly disallows SIGKILL or SIGSTOP to be b= locked. */ > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_POS(SIGKILL); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_POS(SIGSTOP); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_POS(SIGRTMIN); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_POS(SIGRTMIN-1); > =A0 =A0 =A0 =A0TEST_SIGPROCMASK_NEG(SIGRTMIN+1); > > =A0 =A0 =A0 =A0return (0); > > } > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 23:19: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 5128F106566C for ; Sun, 11 Jul 2010 23:19:38 +0000 (UTC) (envelope-from yanegomi@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 12C298FC17 for ; Sun, 11 Jul 2010 23:19:37 +0000 (UTC) Received: by iwn35 with SMTP id 35so5052561iwn.13 for ; Sun, 11 Jul 2010 16:19:37 -0700 (PDT) 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=NqTLWK0MC4Td4EXIfGae2UuUG2mPbl66JXp+NM3jUPU=; b=f92/OzjWVOE2ymKD8VH3ZrWSvhbVm3tRm4SbWLLbVegFn/yXXMp25cdR0F2csn1CkD oE/11RhKG9TEcYBD+/atFyF1MJSpN8LJP8CyhN4kz+ps3Xzj72JMQhlQFCNbhZsQG3Rx ++gfI9ZjgcADwz4vxheIto93l5f7V+j0/1MfI= 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=pwUT1+L4zT+zcbhy2XNJ2+i2XAqBSHOGuYhsajYB3BkroF7PVPQol2SCiy0mx0fBIa kAv+shZMv5NkGvdCmm3QDRc4H88pQuOUfymWcb/C/YuAG11gtO71uL3n6Lz+sXQGIgF9 Cfu/NYGtkCqQuzsc57l42DjrrY6TquUPCow+o= MIME-Version: 1.0 Received: by 10.231.31.7 with SMTP id w7mr12876035ibc.83.1278890377470; Sun, 11 Jul 2010 16:19:37 -0700 (PDT) Received: by 10.231.182.74 with HTTP; Sun, 11 Jul 2010 16:19:37 -0700 (PDT) In-Reply-To: <20100711191727.61c812cb@kan.dnsalias.net> References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> <20100711191727.61c812cb@kan.dnsalias.net> Date: Sun, 11 Jul 2010 16:19:37 -0700 Message-ID: From: Garrett Cooper To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 23:19:38 -0000 2010/7/11 Alexander Kabaev : > On Sun, 11 Jul 2010 15:59:05 -0700 > Garrett Cooper wrote: > >> > + =A0 =A0 =A0 if (!_SIG_VALID(how)) >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-EINVAL); > > -EINVAL? Smells too much of Linux, try returning EINVAL instead. Wow, I'm batting 1,000 today. Please completely ignore my previous claim about sigprocmask(2) -- I'm screwing up my function calls. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 23:46:18 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 859701065674 for ; Sun, 11 Jul 2010 23:46:18 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 338228FC17 for ; Sun, 11 Jul 2010 23:46:17 +0000 (UTC) Received: by qwg5 with SMTP id 5so1414712qwg.13 for ; Sun, 11 Jul 2010 16:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=7M1aLeZdTRGy6j/aSjoGwNsm6G5do8D091tbHFTBV/0=; b=KFWh24k64Jqo8Mb+b7lhTToRrsIQTn02Q0vtwYn8XZEVHMy84TLSDQu0AEpv20Sxjg SH6BQ1XfiqxvjsIvt0VVhkYtfS/QOxrhj8mJzxk6hGlxhdzLRZ4e+hCGy8oiokJFcUBW /IWIeDU/mLeIHD8OqGdfYX0xlimoNkvbcxkmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=QTPvKK6NUyEwElG3gqYaBEsHokBGTPeVBzY8qfQegzQ8wQuDymyf1DLm2wj0RG2DmC nhfTm9ZWtYQNSdQdAQ+brLbeUyTQbikdwWhUmKfvv+8nZ2rQRjIsaUhA8kB0XsjmfyGz fPxcx8Kum2K5fb/3H7PbeIB72O0I8GWQDR0z4= Received: by 10.229.250.146 with SMTP id mo18mr7807015qcb.239.1278890254964; Sun, 11 Jul 2010 16:17:34 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id h34sm16562835qcm.14.2010.07.11.16.17.33 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 16:17:34 -0700 (PDT) Date: Sun, 11 Jul 2010 19:17:27 -0400 From: Alexander Kabaev To: Garrett Cooper Message-ID: <20100711191727.61c812cb@kan.dnsalias.net> In-Reply-To: References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Vramf7t6B16FZE.1TlLrFf+"; protocol="application/pgp-signature" Cc: Kostik Belousov , hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 23:46:18 -0000 --Sig_/Vramf7t6B16FZE.1TlLrFf+ Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Sun, 11 Jul 2010 15:59:05 -0700 Garrett Cooper wrote: > > + =9A =9A =9A if (!_SIG_VALID(how)) > > + =9A =9A =9A =9A =9A =9A =9A return (-EINVAL); -EINVAL? Smells too much of Linux, try returning EINVAL instead. --=20 Alexander Kabaev --Sig_/Vramf7t6B16FZE.1TlLrFf+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMOlEMQ6z1jMm+XZYRAr+eAKDXNge5GWE4YQ/M0ty5BsKNsC7SlQCfbO5A oJDvtBfuM60eZsCGD9FZlkg= =CN1N -----END PGP SIGNATURE----- --Sig_/Vramf7t6B16FZE.1TlLrFf+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 00:04:52 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 B6987106564A for ; Mon, 12 Jul 2010 00:04:52 +0000 (UTC) (envelope-from yanegomi@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 407068FC12 for ; Mon, 12 Jul 2010 00:04:52 +0000 (UTC) Received: by iwn35 with SMTP id 35so5078863iwn.13 for ; Sun, 11 Jul 2010 17:04:51 -0700 (PDT) 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=gkT1adOMPBp7M0iu54tw44nPrJPrDtOKU38h47mFWd8=; b=BIBSRjDxmrGrCj6HpEiX+DhyHD/pTGBsey+1CvrNsHrEbyAF1zz8MZauFSPXW96tWz Thi4IqVI1oOFWVEXT/8US/120vHTSOprvd/lZHnrv+8N6QASEShybBaZalDydNQlgjGI HVeqOD58SDwV1U2ZDzfachz96yr5QxObdxpUc= 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=elR05M5ACnSe3KC2Rd4f+ur06mB/7eVHZQ+zsIi+2222eJ0QW7U5Yrp3eRN3ssn5c1 epdubHRhURJZg0RSkOQCSvBdysCbxrUY6FD75QRf2RGQzJCumePOSju9yHFsu1Bda1yD KhbAGQPx+mg2alomfJdvVZ1cTLCt7jVOKWDPc= MIME-Version: 1.0 Received: by 10.231.155.131 with SMTP id s3mr13171897ibw.2.1278893091565; Sun, 11 Jul 2010 17:04:51 -0700 (PDT) Received: by 10.231.182.74 with HTTP; Sun, 11 Jul 2010 17:04:51 -0700 (PDT) In-Reply-To: References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> <20100711191727.61c812cb@kan.dnsalias.net> Date: Sun, 11 Jul 2010 17:04:51 -0700 Message-ID: From: Garrett Cooper To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 00:04:52 -0000 On Sun, Jul 11, 2010 at 4:19 PM, Garrett Cooper wrote: > 2010/7/11 Alexander Kabaev : >> On Sun, 11 Jul 2010 15:59:05 -0700 >> Garrett Cooper wrote: >> >>> > + =A0 =A0 =A0 if (!_SIG_VALID(how)) >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-EINVAL); >> >> -EINVAL? Smells too much of Linux, try returning EINVAL instead. > > Wow, I'm batting 1,000 today. Please completely ignore my previous > claim about sigprocmask(2) -- I'm screwing up my function calls. So after writing more correct tests, everything's fine with sig{add,del}set, as expected: $ cat ~/test_sigaddset.c #include #include #include #include #define TEST_SIGADDSET_POS(signo) do { \ printf("signo =3D %d : ", signo); \ sigemptyset(&set); \ errno =3D 0; \ rc =3D sigaddset(&set, signo); \ if (rc !=3D 0) { \ printf("result not sane (%d !=3D 0, errno: %d)\n",\ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) #define TEST_SIGADDSET_NEG(signo) do { \ printf("signo =3D %d : ", signo); \ sigemptyset(&set); \ errno =3D 0; \ rc =3D sigaddset(&set, signo); \ if (rc !=3D -1 || errno !=3D EINVAL) { \ printf("result not sane (%d !=3D -1, " \ "errno: %d !=3D EINVAL)\n", \ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) #define TEST_SIGDELSET_POS(signo) do { \ printf("signo =3D %d : ", signo); \ sigemptyset(&set); \ errno =3D 0; \ rc =3D sigdelset(&set, signo); \ if (rc !=3D 0) { \ printf("result not sane (%d !=3D 0, errno: %d)\n",\ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) #define TEST_SIGDELSET_NEG(signo) do { \ printf("signo =3D %d : ", signo); \ sigemptyset(&set); \ errno =3D 0; \ rc =3D sigdelset(&set, signo); \ if (rc !=3D -1 || errno !=3D EINVAL) { \ printf("result not sane (%d !=3D -1, " \ "errno: %d !=3D EINVAL)\n", \ rc, errno); \ } else \ printf("result sane\n"); \ } while (0) int main(void) { sigset_t set; int rc; TEST_SIGADDSET_NEG(-1); TEST_SIGADDSET_NEG(0); TEST_SIGADDSET_POS(SIGHUP); /* The system quietly disallows SIGKILL or SIGSTOP to be blocked. */ TEST_SIGADDSET_POS(SIGKILL); TEST_SIGADDSET_POS(SIGSTOP); TEST_SIGADDSET_POS(SIGRTMIN-1); TEST_SIGADDSET_POS(SIGRTMIN); TEST_SIGADDSET_POS(SIGRTMIN+1); TEST_SIGADDSET_POS(SIGRTMAX); TEST_SIGDELSET_NEG(-1); TEST_SIGDELSET_NEG(0); TEST_SIGDELSET_POS(SIGHUP); /* The system quietly disallows SIGKILL or SIGSTOP to be blocked. */ TEST_SIGDELSET_POS(SIGKILL); TEST_SIGDELSET_POS(SIGSTOP); TEST_SIGDELSET_POS(SIGRTMIN-1); TEST_SIGDELSET_POS(SIGRTMIN); TEST_SIGDELSET_POS(SIGRTMIN+1); TEST_SIGDELSET_POS(SIGRTMAX); return (0); } $ ~/test_sigadddelset signo =3D -1 : result sane signo =3D 0 : result sane signo =3D 1 : result sane signo =3D 9 : result sane signo =3D 17 : result sane signo =3D 64 : result sane signo =3D 65 : result sane signo =3D 66 : result sane signo =3D 126 : result sane signo =3D -1 : result sane signo =3D 0 : result sane signo =3D 1 : result sane signo =3D 9 : result sane signo =3D 17 : result sane signo =3D 64 : result sane signo =3D 65 : result sane signo =3D 66 : result sane signo =3D 126 : result sane POSIX spec actually says: The range SIGRTMIN through SIGRTMAX inclusive shall include at least {RTSIG_MAX} signal numbers. POSIX is vague on how many numbers RTSIG_MAX is (it's implementation defined and retrievable via sysconf). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 03:10: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 C8AE11065679 for ; Mon, 12 Jul 2010 03:10:31 +0000 (UTC) (envelope-from dhruvakm@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 838788FC15 for ; Mon, 12 Jul 2010 03:10:31 +0000 (UTC) Received: by qwg5 with SMTP id 5so1463413qwg.13 for ; Sun, 11 Jul 2010 20:10:30 -0700 (PDT) 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 :content-transfer-encoding; bh=F6q4pdwUnFuEHmsB8fpEKOY6nr3g9fZ41UccVmxgQU4=; b=AiAOIs3l34rFJHi/moXLGmj9wGGpBdDmGmdYB+ctBw5d5rd+Mhbt/XirDR2Bg2m+Xa L7o/GYL0N6bza6DtgfbZ+jsEupb8utAPehzymonZuliaLygftcJUzfHYZFSTJCWOHyGN 1NkpaFaO+4YU2+k6nPpPat253SXckBR8I7fms= 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:content-transfer-encoding; b=tyhE7pOpjWpVP/qrd1urI4J71HCEEyoeoS/D+mKpPoBTaZTBt62ADVvRdlnPmUZynt v7+53MXcmnd+sliaYhKKYvfJwthiQ2N328dW5XnCWK/0J3+ssKetJXSDAJrR3lSWpXdF ztiPzdkWGjoFwrpzwgBh/hVcHlpZrw3qBH+xQ= MIME-Version: 1.0 Received: by 10.224.35.229 with SMTP id q37mr7408657qad.323.1278904230575; Sun, 11 Jul 2010 20:10:30 -0700 (PDT) Received: by 10.229.220.16 with HTTP; Sun, 11 Jul 2010 20:10:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Jul 2010 08:40:30 +0530 Message-ID: From: dhruva To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: mallinfo equivalent on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 03:10:31 -0000 Hi, On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote: > Hello, > =A0I would like to know the memory usage (total virtual memory) inside a > process and make decisions accordingly. > To be more specific, I am using BerkeleyDB backed set or std::set (C++ > STL) depending on my current memory usage > as my process will need to run in a resource constrained environment. > By the way, this is user mode application. > > Some things I am considering/tried: > 1. GNU/Linux has mallinfo and I had my code working based on the > information I get from the call. Could anyone please help and throw some light on this topic (mallinfo) equivalent. I am stuck and need resolve this soon. In short, I need to find out the virtual memory used (mapped to the process's address space) in a light weight fashion so that I can make some decision based on it. with best regards, dhruva From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 04:42:41 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 D33C91065675 for ; Mon, 12 Jul 2010 04:42:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 59CC38FC1B for ; Mon, 12 Jul 2010 04:42:40 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6C4gW1u003878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 14:12:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Mon, 12 Jul 2010 14:12:32 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <44ECC517-F96D-4DA3-845E-61E2B5793BCC@gsoft.com.au> References: To: dhruva X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Hackers Subject: Re: mallinfo equivalent on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 04:42:41 -0000 On 12/07/2010, at 12:40, dhruva wrote: > On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote: >> Hello, >> I would like to know the memory usage (total virtual memory) inside = a >> process and make decisions accordingly. >> To be more specific, I am using BerkeleyDB backed set or std::set = (C++ >> STL) depending on my current memory usage >> as my process will need to run in a resource constrained environment. >> By the way, this is user mode application. >>=20 >> Some things I am considering/tried: >> 1. GNU/Linux has mallinfo and I had my code working based on the >> information I get from the call. >=20 > Could anyone please help and throw some light on this topic (mallinfo) > equivalent. I am stuck and need > resolve this soon. In short, I need to find out the virtual memory > used (mapped to the process's address space) > in a light weight fashion so that I can make some decision based on = it. Can't you use getrusage to find that out? As for system wide stats, I think you could look at sysctl, specifically = the vm tree. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 06:11:53 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 A540F1065672 for ; Mon, 12 Jul 2010 06:11:53 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id 628388FC1A for ; Mon, 12 Jul 2010 06:11:53 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OYC3z-000Fe5-AL; Mon, 12 Jul 2010 10:00:23 +0400 Date: Mon, 12 Jul 2010 09:59:33 +0400 From: Ruslan Ermilov To: Garrett Cooper Message-ID: <20100712055933.GA3885@edoofus.dev.vega.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: hackers@FreeBSD.org Subject: Re: [patch] SUBDIR_OVERRIDE `optimization' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:11:53 -0000 On Fri, Jul 09, 2010 at 07:56:37AM -0700, Garrett Cooper wrote: > (Let's try this again with the right email address) >    Something simple that I noticed a while back when I was reviewing > the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the > conditional feature checks, which sets the value of SUBDIRS to the > user defined value. So instead of going through the conditionals, one > could just cut to the chase and set SUBDIRS to SUBDIRS_OVERRIDE, > otherwise detect the conditional directories to include in > Makefile.inc1. > Thanks! > -Garrett > > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 209684) > +++ Makefile.inc1 (working copy) > @@ -41,6 +41,9 @@ > # use that new version. And the new (dynamically-linked) /bin/sh > # will expect to find appropriate libraries in /lib and /libexec. > # > +.if defined(SUBDIR_OVERRIDE) > +SUBDIR= ${SUBDIR_OVERRIDE} > +.else > SUBDIR= share/info lib libexec > SUBDIR+=bin > .if ${MK_GAMES} != "no" > @@ -79,8 +82,6 @@ > .endif > .endfor > > -.if defined(SUBDIR_OVERRIDE) > -SUBDIR= ${SUBDIR_OVERRIDE} > .endif > > .if defined(NOCLEAN) SUBDIR_OVERRIDE is mainly for FreeBSD src/ builders (to quickly check with "buildworld" a particular bit of a tree), and is thus rarely used, so this change would be an optimization for the uncommon case. Having said that, I don't mind if you commit it, if you like. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 07:29:05 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 EB97F106567A for ; Mon, 12 Jul 2010 07:29:05 +0000 (UTC) (envelope-from yanegomi@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 B8C588FC1C for ; Mon, 12 Jul 2010 07:29:05 +0000 (UTC) Received: by iwn35 with SMTP id 35so5428670iwn.13 for ; Mon, 12 Jul 2010 00:29:05 -0700 (PDT) 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=ydWb+TUNANRTI4Mx9uyBt0Hzf1fDJ4atUj3xadnqxcs=; b=qg8GL86WTnHxpeUXupoHPlyrQIfn7ZtCF6K6VHFhFCsGUO6Q2cq2uhEwYFIeedVy1X JK8ZyKxM8bnegO+5nVsxyHi2WAZD5kiH8SUz+8xPqffUqbqGOqTIKkPp4vC2NReekCsF Glgsyn1SOdlCAGnS9lTVxGlaZZUJrdf0Ccb24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mKXfTmYhQ8ZFm3+r9gGM5Q+7tDWjqGYTmMKJW6Mmi/2EEsze57ci+3jVFYIfG69hR3 8GTl52i8pHBKYp4ZjE+Rfr08W2r2mgFu47lWg3UR5qJMygaKfcnfEQC1U+lLRepsO2HF gN5/vQS8DYM9EBM5co1FCaTi9mHkeE+6M7QWs= MIME-Version: 1.0 Received: by 10.231.191.138 with SMTP id dm10mr2041539ibb.126.1278919744810; Mon, 12 Jul 2010 00:29:04 -0700 (PDT) Received: by 10.231.182.74 with HTTP; Mon, 12 Jul 2010 00:29:04 -0700 (PDT) Date: Mon, 12 Jul 2010 00:29:04 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] Use _SIG_VALID macro in ddb/db_command.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 07:29:06 -0000 Spotted this really minor item that I figured could be converted over to _SIG_VALID in ddb: Index: ddb/db_command.c =================================================================== --- ddb/db_command.c (revision 206173) +++ ddb/db_command.c (working copy) @@ -633,7 +633,7 @@ if (!db_expression(&pid)) DB_ERROR(("Missing process ID\n")); db_skip_to_eol(); - if (sig < 1 || sig > _SIG_MAXSIG) + if (!_SIG_VALID(sig)) DB_ERROR(("Signal number out of range\n")); /* considering that the above range and _SIG_VALID are complementing checks. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 07:29:37 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 E6775106566C for ; Mon, 12 Jul 2010 07:29:37 +0000 (UTC) (envelope-from pluknet@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 7C7378FC0C for ; Mon, 12 Jul 2010 07:29:37 +0000 (UTC) Received: by wyb34 with SMTP id 34so3664381wyb.13 for ; Mon, 12 Jul 2010 00:29:36 -0700 (PDT) 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=gT+smn3/k0h+td/tRLXkGwMA8iG424jQxmY+5wny/98=; b=lAq1B7s/L3NhrmAB9mthGmcDe9oqlwXEy7rrtjpTUcVbrOtZd9GBzdy6SW5I2Shu5z j8i4+cQMDRqBtf2XeSM/qD1wwcvHC4VPP3r0GHVb02aKWapzqeZewFGfYvVEs3emhwnf YBaY44q0F3KyWJklOF88nRHSJ1yUmMgnqUWz4= 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=Hg1B1wGuL2f9FSdMXye40OgOj0KIjtEgJ1uclTSsXpcO01bX7Faps/YObB6HEq76/K 2HXl/VkgRnwlW0+O1rXHOH5cq7xmKJKtCpSmhIU/S5DFNbdXatFGOT4XqkMO9enry8h9 bxpzi/+idPeJ+2Jm2+OUNbmFbMynC7EKxDKFw= MIME-Version: 1.0 Received: by 10.227.5.195 with SMTP id 3mr915140wbw.178.1278918008218; Mon, 12 Jul 2010 00:00:08 -0700 (PDT) Received: by 10.216.27.13 with HTTP; Mon, 12 Jul 2010 00:00:08 -0700 (PDT) In-Reply-To: <4C39DBFF.2000307@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> Date: Mon, 12 Jul 2010 11:00:08 +0400 Message-ID: From: pluknet To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 07:29:38 -0000 On 11 July 2010 18:58, Gabor Kovesdan wrote: > Em 2010.07.11. 16:54, Dimitry Andric escreveu: >> >> On 2010-07-11 16:46, Gabor Kovesdan wrote: >> >>> >>> I have two int64_t variables in kernel code, first is stored internally >>> and the second one is passed from a syscall argument. When I print them >>> with printf %lld modifier, the internal one behaves correctly but the >>> other one I pass from a syscall has a corrupted value. If I pass 1, it >>> prints out 3735348794091372545. I'm not doing anything special with it >>> just reading it out from the struct that was generated with make sysent= . >>> >> >> Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper >> word got corrupted somehow. =A0Maybe some part of it got non-atomically >> assigned? =A0Maybe the wrong word was read? =A0It is hard to tell withou= t >> code... =A0:) >> > > Userland syscall calling: > > killjob(getjid(), SIGINT); =A0//getjid() returns 1 this case, whose type = is > jid_t > Looking at getjid() impl, I see you're trying to put jid_t into the one register_t which are 64-bit vs 32-bit capable respectively. You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek()= . --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 07:44:49 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 6A504106566B for ; Mon, 12 Jul 2010 07:44:49 +0000 (UTC) (envelope-from yanegomi@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 36E318FC15 for ; Mon, 12 Jul 2010 07:44:49 +0000 (UTC) Received: by iwn35 with SMTP id 35so5442346iwn.13 for ; Mon, 12 Jul 2010 00:44:48 -0700 (PDT) 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=3CciWMAQo7QvH/JSxL5Ee5wAkUpSf/AbQtAgyVfxnuM=; b=wVkS8KN30imsmaUKCI+c8GCpyksdV/kAgVgjuXak2QHPKhLkL0Xsh1ZkyTsFHEkcw3 Wn34HrNBqlzgDNhGoJfs2wvs3Fd4+UkNd7BPAhAnIhw1umpZl9aJUd2ldkp8LRd5x09a /sIz/8QSDghsI3Sc3NwjstiV4F+FYjgatPR+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HIsqHdd/a4EkOT3eM8VrPhQqE6axMDDKYxjHBr/gNfXjDxQtylhZEh8HADy3I2Fdwn y9AIsT5uAcTKG5/hdFybhW0Y+lFT3k03dUPJlsVV+Rfhbc6qdr7MaOtFHKgKTDtr0eeC JwaRafBEbfqYnXZWOchK9DBYH5cyuLr6Ma6sQ= MIME-Version: 1.0 Received: by 10.231.169.131 with SMTP id z3mr14577766iby.48.1278920688676; Mon, 12 Jul 2010 00:44:48 -0700 (PDT) Received: by 10.231.182.74 with HTTP; Mon, 12 Jul 2010 00:44:48 -0700 (PDT) Date: Mon, 12 Jul 2010 00:44:48 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] Use _SIG_VALID macro in lib/libthr/thread/thr_sig.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 07:44:49 -0000 Found another item that could be converted over to _SIG_VALID in libthr's thr_sig.c this time. Thanks, -Garrett Index: lib/libthr/thread/thr_sig.c =================================================================== --- lib/libthr/thread/thr_sig.c (revision 206173) +++ lib/libthr/thread/thr_sig.c (working copy) @@ -194,7 +194,7 @@ _sigaction(int sig, const struct sigaction * act, struct sigaction * oact) { /* Check if the signal number is out of range: */ - if (sig < 1 || sig > _SIG_MAXSIG || sig == SIGCANCEL) { + if (!_SIG_VALID(sig) || sig == SIGCANCEL) { /* Return an invalid argument: */ errno = EINVAL; return (-1); From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 09:46:51 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 C30931065672 for ; Mon, 12 Jul 2010 09:46:51 +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 38D398FC0C for ; Mon, 12 Jul 2010 09:46:50 +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 o6C9kkxS095835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 12:46:46 +0300 (EEST) (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 o6C9kkYv033262; Mon, 12 Jul 2010 12:46:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6C9kkIQ033261; Mon, 12 Jul 2010 12:46:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Jul 2010 12:46:46 +0300 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20100712094646.GA2381@deviant.kiev.zoral.com.ua> References: <20100711210843.GQ2408@deviant.kiev.zoral.com.ua> <20100711214016.GR2408@deviant.kiev.zoral.com.ua> <20100711191727.61c812cb@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20100711191727.61c812cb@kan.dnsalias.net> 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: Garrett Cooper , hackers@freebsd.org Subject: Re: *sigpause hanging on 8.x+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:46:51 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 11, 2010 at 07:17:27PM -0400, Alexander Kabaev wrote: > On Sun, 11 Jul 2010 15:59:05 -0700 > Garrett Cooper wrote: >=20 > > > + =9A =9A =9A if (!_SIG_VALID(how)) > > > + =9A =9A =9A =9A =9A =9A =9A return (-EINVAL); >=20 > -EINVAL? Smells too much of Linux, try returning EINVAL instead. Mmm, if (!_SIG_VALID(how)) { errno =3D EINVAL; return (-1); } This is libc. --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw65IUACgkQC3+MBN1Mb4huVgCfWr6cDqRcGZBmBPG167OgBWS3 PtcAnjGYydZb9UOwV/H9dPYAy9YZlFj5 =OiVt -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 15:11:35 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 38376106566C; Fri, 9 Jul 2010 15:11:35 +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 D28ED8FC19; Fri, 9 Jul 2010 15:11:34 +0000 (UTC) Received: by gwb15 with SMTP id 15so1198784gwb.13 for ; Fri, 09 Jul 2010 08:11:31 -0700 (PDT) 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=B4PujO+lee/WW158m8cGjNSnjxKMQwuc89/xCCvcPLk=; b=RAxUs6TK0E+fbBhazpjlUXpqHsAaIQmS+7odP8u7qWZjbA4vt6FxhmPyOYwh8VHWPL mhPZ1yxHAQvUfvbVrkpv7NWZ762s6PcppH0HKJbMGcHxvLTmkmK4zsAhIyM7uvvmjn8w eqVqxxDVoMASoS+ozy/e9PRjAP6FcBKAgHloU= 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=ONsHgfDqvAY+nHnYoIPA7MgUHkCLpBAm+9JKd577eGkmJ1ycscrAnZV935fiLliunC TqM6Qz8x8jQxnpXGvxOpw4CBW0GwMPIrGFKHz4n0CB2P1IQSVU2XDi0VArZHyRjykKaL kHXaYXnuDbqw4P/3DtSXFfiOoeVQ1R746wv/U= MIME-Version: 1.0 Received: by 10.151.6.5 with SMTP id j5mr2212065ybi.20.1278688291086; Fri, 09 Jul 2010 08:11:31 -0700 (PDT) Received: by 10.231.214.145 with HTTP; Fri, 9 Jul 2010 08:11:31 -0700 (PDT) Date: Fri, 9 Jul 2010 08:11:31 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd519865e63e6048af5d1be X-Mailman-Approved-At: Mon, 12 Jul 2010 11:07:36 +0000 Cc: portmgr@freebsd.org Subject: [PATCH] Fix typos in bsd.port.mk and minor logic improvements 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, 09 Jul 2010 15:11:35 -0000 --000e0cd519865e63e6048af5d1be Content-Type: text/plain; charset=ISO-8859-1 This is a change I made locally that I figured would be helpful because it: a. Fixes typos. b. Improves branch flow in a few spots. c. Doesn't assume that all strings that come back from pkg_install are empty (this is what's assumed today). Thanks, -Garrett --- /usr/ports/Mk/bsd.port.mk 2010-06-04 01:09:17.000000000 -0700 +++ bsd.port.mk 2010-07-09 08:01:08.000000000 -0700 @@ -20,7 +20,7 @@ # # DO NOT COMMIT CHANGES TO THIS FILE BY YOURSELF, EVEN IF YOU DID NOT GET # A RESPONSE FROM THE MAINTAINER(S) WITHIN A REASONABLE TIMEFRAME! ALL -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! FreeBSD_MAINTAINER= portmgr@FreeBSD.org @@ -3968,7 +3968,7 @@ prfx=`${PKG_INFO} -q -p $${p} 2> /dev/null | ${SED} -ne '1s|^@cwd ||p'`; \ if [ "x${PREFIX}" = "x$${prfx}" ]; then \ df=`${PKG_INFO} -q -f $${p} 2> /dev/null | ${GREP} -v "^@" | ${COMM} -12 - ${TMPPLIST}`; \ - if [ -n "$${df}" ]; then \ + if [ -n "$${df:-}" ]; then \ found_package=$${p}; \ break; \ fi; \ @@ -4551,7 +4551,7 @@ check_name=`${ECHO_CMD} $${p} | ${SED} -e 's/-[^-]*$$//'`; \ if [ "$${check_name}" = "${PKGBASE}" ]; then \ prfx=`${PKG_INFO} -q -p $${p} 2> /dev/null | ${SED} -ne '1s|^@cwd ||p'`; \ - if [ "x${PREFIX}" = "x$${prfx}" ]; then \ + if [ "x${PREFIX}" = "x$${prfx:-}" ]; then \ ${ECHO_MSG} "===> Deinstalling $${p}"; \ ${PKG_DELETE} -f $${p}; \ else \ @@ -4583,7 +4583,7 @@ for oldpkgorigin in $$(${GREP} "|${PKGORIGIN}|" ${PORTSDIR}/MOVED | ${CUT} -f 1 -d '|' | ${SORT} -u); do \ deinstall_names="$${deinstall_names} $$(${PKG_INFO} -q -O $${oldpkgorigin})"; \ done; \ - if [ -n "$${deinstall_names}" ]; then \ + if [ -n "$${deinstall_names:-}" ]; then \ for d in $${deinstall_names}; do \ ${ECHO_MSG} "===> Deinstalling $${d}"; \ ${PKG_DELETE} -f $${d}; \ @@ -5129,7 +5129,7 @@ -e 's/<=/=gt=/; s/=/=lt=/; s/>/=le=/' \ -e 's/=gt=/>/; s/=ge=/>=/; s/=lt=/ Found $$pkg_info, but you need to upgrade to $$prog."; \ exit 1; \ fi; \ @@ -5465,10 +5465,9 @@ if [ "${CHILD_DEPENDS}" ]; then \ installed=$$(${PKG_INFO} -qO ${PKGORIGIN} 2>/dev/null || \ ${TRUE}); \ - if [ "$$installed" ]; then \ + if [ -n "$${installed:-}" ]; then \ break; \ - fi; \ - if [ -z "$$installed" ]; then \ + else \ installed="${PKGNAME}"; \ fi; \ for pkgname in $$installed; do \ @@ -5511,16 +5510,15 @@ while [ $$\# -gt 1 ]; do \ if [ ! -d "${PORTSDIR}/$$2" ]; then \ shift; \ - continue; \ - fi; \ - if [ "$$dir" = "$$2" ]; then \ + elif [ "$$dir" = "$$2" ]; then \ ${ECHO_CMD} $$1:$$dir; \ if [ -e ${PKG_DBDIR}/$$1/+CONTENTS -a -z "${EXPLICIT_PACKAGE_DEPENDS}" ]; then \ packagelist="$$packagelist ${PKG_DBDIR}/$$1/+CONTENTS"; \ fi; \ break; \ + else \ + shift 2; \ fi; \ - shift 2; \ done; \ done; \ [ -z "$$packagelist" ] || ${AWK} -F '( |:)' 'BEGIN { pkgname="broken_contents" } /@pkgdep / { pkgname=$$2 } /@comment DEPORIGIN:/ { printf "%s:%s\n", pkgname, $$3; pkgname="broken_contents" }' $$packagelist; \ @@ -5541,7 +5539,7 @@ (cd $$dir; ${MAKE} package-noinstall); \ done -# Show missing dependiencies +# Show missing dependencies missing: @_origins=$$(${PKG_INFO} -aoq); \ for dir in $$(${ALL-DEPENDS-LIST}); do \ --000e0cd519865e63e6048af5d1be Content-Type: application/octet-stream; name="bsd_dot_port_dot_mk-fix-typos-and-minor-improvements.diff" Content-Disposition: attachment; filename="bsd_dot_port_dot_mk-fix-typos-and-minor-improvements.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbf5w0600 LS0tIC91c3IvcG9ydHMvTWsvYnNkLnBvcnQubWsJMjAxMC0wNi0wNCAwMTowOToxNy4wMDAwMDAw MDAgLTA3MDAKKysrIGJzZC5wb3J0Lm1rCTIwMTAtMDctMDkgMDg6MDE6MDguMDAwMDAwMDAwIC0w NzAwCkBAIC0yMCw3ICsyMCw3IEBACiAjCiAjIERPIE5PVCBDT01NSVQgQ0hBTkdFUyBUTyBUSElT IEZJTEUgQlkgWU9VUlNFTEYsIEVWRU4gSUYgWU9VIERJRCBOT1QgR0VUCiAjIEEgUkVTUE9OU0Ug RlJPTSBUSEUgTUFJTlRBSU5FUihTKSBXSVRISU4gQSBSRUFTT05BQkxFIFRJTUVGUkFNRSEgQUxM Ci0jIFVOQVVUSE9SSVNFRCBDSEFOR0VTIFdJTEwgQkUgVU5DT05ESVRJT05BTExZIFJFVkVSVEVE IQorIyBVTkFVVEhPUklaRUQgQ0hBTkdFUyBXSUxMIEJFIFVOQ09ORElUSU9OQUxMWSBSRVZFUlRF RCEKIAogRnJlZUJTRF9NQUlOVEFJTkVSPQlwb3J0bWdyQEZyZWVCU0Qub3JnCiAKQEAgLTM5Njgs NyArMzk2OCw3IEBACiAJCQkJCQlwcmZ4PWAke1BLR19JTkZPfSAtcSAtcCAkJHtwfSAyPiAvZGV2 L251bGwgfCAke1NFRH0gLW5lICcxc3xeQGN3ZCB8fHAnYDsgXAogCQkJCQkJaWYgWyAieCR7UFJF RklYfSIgPSAieCQke3ByZnh9IiBdOyB0aGVuIFwKIAkJCQkJCQkJZGY9YCR7UEtHX0lORk99IC1x IC1mICQke3B9IDI+IC9kZXYvbnVsbCB8ICR7R1JFUH0gLXYgIl5AIiB8ICR7Q09NTX0gLTEyIC0g JHtUTVBQTElTVH1gOyBcCi0JCQkJCQkJCWlmIFsgLW4gIiQke2RmfSIgXTsgdGhlbiBcCisJCQkJ CQkJCWlmIFsgLW4gIiQke2RmOi19IiBdOyB0aGVuIFwKIAkJCQkJCQkJCQlmb3VuZF9wYWNrYWdl PSQke3B9OyBcCiAJCQkJCQkJCQkJYnJlYWs7IFwKIAkJCQkJCQkJZmk7IFwKQEAgLTQ1NTEsNyAr NDU1MSw3IEBACiAJCQljaGVja19uYW1lPWAke0VDSE9fQ01EfSAkJHtwfSB8ICR7U0VEfSAtZSAn cy8tW14tXSokJC8vJ2A7IFwKIAkJCWlmIFsgIiQke2NoZWNrX25hbWV9IiA9ICIke1BLR0JBU0V9 IiBdOyB0aGVuIFwKIAkJCQkJcHJmeD1gJHtQS0dfSU5GT30gLXEgLXAgJCR7cH0gMj4gL2Rldi9u dWxsIHwgJHtTRUR9IC1uZSAnMXN8XkBjd2QgfHxwJ2A7IFwKLQkJCQkJaWYgWyAieCR7UFJFRklY fSIgPSAieCQke3ByZnh9IiBdOyB0aGVuIFwKKwkJCQkJaWYgWyAieCR7UFJFRklYfSIgPSAieCQk e3ByZng6LX0iIF07IHRoZW4gXAogCQkJCQkJCSR7RUNIT19NU0d9ICI9PT0+ICAgRGVpbnN0YWxs aW5nICQke3B9IjsgXAogCQkJCQkJCSR7UEtHX0RFTEVURX0gLWYgJCR7cH07IFwKIAkJCQkJZWxz ZSBcCkBAIC00NTgzLDcgKzQ1ODMsNyBAQAogCWZvciBvbGRwa2dvcmlnaW4gaW4gJCQoJHtHUkVQ fSAifCR7UEtHT1JJR0lOfXwiICR7UE9SVFNESVJ9L01PVkVEIHwgJHtDVVR9IC1mIDEgLWQgJ3wn IHwgJHtTT1JUfSAtdSk7IGRvIFwKIAkJZGVpbnN0YWxsX25hbWVzPSIkJHtkZWluc3RhbGxfbmFt ZXN9ICQkKCR7UEtHX0lORk99IC1xIC1PICQke29sZHBrZ29yaWdpbn0pIjsgXAogCWRvbmU7IFwK LQlpZiBbIC1uICIkJHtkZWluc3RhbGxfbmFtZXN9IiBdOyB0aGVuIFwKKwlpZiBbIC1uICIkJHtk ZWluc3RhbGxfbmFtZXM6LX0iIF07IHRoZW4gXAogCQlmb3IgZCBpbiAkJHtkZWluc3RhbGxfbmFt ZXN9OyBkbyBcCiAJCQkke0VDSE9fTVNHfSAiPT09PiAgIERlaW5zdGFsbGluZyAkJHtkfSI7IFwK IAkJCSR7UEtHX0RFTEVURX0gLWYgJCR7ZH07IFwKQEAgLTUxMjksNyArNTEyOSw3IEBACiAJCQkJ CQktZSAncy88PS89Z3Q9Lzsgcy88Lz1nZT0vOyBzLz49Lz1sdD0vOyBzLz4vPWxlPS8nIFwKIAkJ CQkJCS1lICdzLz1ndD0vPi87IHMvPWdlPS8+PS87IHMvPWx0PS88Lzsgcy89bGU9Lzw9LydgOyBc CiAJCQkJCXBrZ19pbmZvPWAke1BLR19JTkZPfSAtRSAiJCRpbnZlcnNlX2RlcCIgfHwgJHtUUlVF fWA7IFwKLQkJCQkJaWYgWyAiJCRwa2dfaW5mbyIgIT0gIiIgXTsgdGhlbiBcCisJCQkJCWlmIFsg IiQke3BrZ19pbmZvOi19IiAhPSAiIiBdOyB0aGVuIFwKIAkJCQkJCSR7RUNIT19NU0d9ICI9PT0+ ICAgRm91bmQgJCRwa2dfaW5mbywgYnV0IHlvdSBuZWVkIHRvIHVwZ3JhZGUgdG8gJCRwcm9nLiI7 IFwKIAkJCQkJCWV4aXQgMTsgXAogCQkJCQlmaTsgXApAQCAtNTQ2NSwxMCArNTQ2NSw5IEBACiAJ aWYgWyAiJHtDSElMRF9ERVBFTkRTfSIgXTsgdGhlbiBcCiAJCWluc3RhbGxlZD0kJCgke1BLR19J TkZPfSAtcU8gJHtQS0dPUklHSU59IDI+L2Rldi9udWxsIHx8IFwKIAkJCSR7VFJVRX0pOyBcCi0J CWlmIFsgIiQkaW5zdGFsbGVkIiBdOyB0aGVuIFwKKwkJaWYgWyAtbiAiJCR7aW5zdGFsbGVkOi19 IiBdOyB0aGVuIFwKIAkJCWJyZWFrOyBcCi0JCWZpOyBcCi0JCWlmIFsgLXogIiQkaW5zdGFsbGVk IiBdOyB0aGVuIFwKKwkJZWxzZSBcCiAJCQlpbnN0YWxsZWQ9IiR7UEtHTkFNRX0iOyBcCiAJCWZp OyBcCiAJCWZvciBwa2duYW1lIGluICQkaW5zdGFsbGVkOyBkbyBcCkBAIC01NTExLDE2ICs1NTEw LDE1IEBACiAJCQl3aGlsZSBbICQkXCMgLWd0IDEgXTsgZG8gXAogCQkJCWlmIFsgISAtZCAiJHtQ T1JUU0RJUn0vJCQyIiBdOyB0aGVuIFwKIAkJCQkJc2hpZnQ7IFwKLQkJCQkJY29udGludWU7IFwK LQkJCQlmaTsgXAotCQkJCWlmIFsgIiQkZGlyIiA9ICIkJDIiIF07IHRoZW4gXAorCQkJCWVsaWYg WyAiJCRkaXIiID0gIiQkMiIgXTsgdGhlbiBcCiAJCQkJCSR7RUNIT19DTUR9ICQkMTokJGRpcjsg XAogCQkJCQlpZiBbIC1lICR7UEtHX0RCRElSfS8kJDEvK0NPTlRFTlRTIC1hIC16ICIke0VYUExJ Q0lUX1BBQ0tBR0VfREVQRU5EU30iIF07IHRoZW4gXAogCQkJCQkJcGFja2FnZWxpc3Q9IiQkcGFj a2FnZWxpc3QgJHtQS0dfREJESVJ9LyQkMS8rQ09OVEVOVFMiOyBcCiAJCQkJCWZpOyBcCiAJCQkJ CWJyZWFrOyBcCisJCQkJZWxzZSBcCisJCQkJICAgIHNoaWZ0IDI7IFwKIAkJCQlmaTsgXAotCQkJ CXNoaWZ0IDI7IFwKIAkJCWRvbmU7IFwKIAkJZG9uZTsgXAogCQlbIC16ICIkJHBhY2thZ2VsaXN0 IiBdIHx8ICR7QVdLfSAtRiAnKCB8OiknICdCRUdJTiB7IHBrZ25hbWU9ImJyb2tlbl9jb250ZW50 cyIgfSAvQHBrZ2RlcCAvIHsgcGtnbmFtZT0kJDIgfSAvQGNvbW1lbnQgREVQT1JJR0lOOi8geyBw cmludGYgIiVzOiVzXG4iLCBwa2duYW1lLCAkJDM7IHBrZ25hbWU9ImJyb2tlbl9jb250ZW50cyIg fScgJCRwYWNrYWdlbGlzdDsgXApAQCAtNTU0MSw3ICs1NTM5LDcgQEAKIAkJKGNkICQkZGlyOyAk e01BS0V9IHBhY2thZ2Utbm9pbnN0YWxsKTsgXAogCWRvbmUKIAotIyBTaG93IG1pc3NpbmcgZGVw ZW5kaWVuY2llcworIyBTaG93IG1pc3NpbmcgZGVwZW5kZW5jaWVzCiBtaXNzaW5nOgogCUBfb3Jp Z2lucz0kJCgke1BLR19JTkZPfSAtYW9xKTsgXAogCWZvciBkaXIgaW4gJCQoJHtBTEwtREVQRU5E Uy1MSVNUfSk7IGRvIFwK --000e0cd519865e63e6048af5d1be-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 10 15:31:27 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 8A73C106566C for ; Sat, 10 Jul 2010 15:31:27 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6EADA8FC14 for ; Sat, 10 Jul 2010 15:31:27 +0000 (UTC) Received: from verizon.net ([unknown] [173.54.27.21]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5C00LMNLS1B4VX@vms173019.mailsrvcs.net> for hackers@freebsd.org; Sat, 10 Jul 2010 10:31:16 -0500 (CDT) Sender: root Message-id: <4C386208.291D2FB5@verizon.net> Date: Sat, 10 Jul 2010 08:05:29 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-version: 1.0 To: hackers@freebsd.org Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 12 Jul 2010 11:07:51 +0000 Cc: Subject: TCP over UDP 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, 10 Jul 2010 15:31:27 -0000 Hi guys, I've got this idea, and I wonder if anyone has done it already, and if not then why. The idea is to put the TCP logic over UDP. I've done some googling and all I've found is some academical user-space implementations of TCP that actually try to interoperate with "real" TCP. What I'm thinking about is different. It's to use the TCP-derived logic as a portable library that would do the good flow control, retransmitting, delivery confirmations etc over UDP. Basically, every time you use UDP, you've got to reinvent your own retransmission and reliability protocol. And these protocols are typically no good at all, as the story with NFS switching from UDP to TCP and improving the performance shows. At the same time TCP provides a very good transport control logic, so why not just reuse this logic in a library to solve the UDP issues once and for all? Then of course, why not just use TCP? The problem of TCP is that it's expensive. It uses the kernel memory for its contexts. It also requires a file descriptor per each connection. The file descriptors are an expensive resource, and besides, even if the limit is raised, there is the issue with historic select() fd_set allocating only 1024 bits and nobody checking for the overflow. Even if your own code is carefully designed to avoid using select() at all and/or create large enough bitmasks, it could always happen to use some stupid library that doesn't do that and causes the interesting one-bit memory corruptions. Moving the connection logic to the user space makes the connections cheap. A hundred bytes or so per connection state is no big deal, you can easily create a million of these connections to the same process. All the state stays in the user-space pageable memory. Well, all of them sending data at the same time might not work so well, but caching a large number of currently inactive connections becomes cheap. Think of XMLRPC or SOAP or anything else over HTTP reusing the same TCP connection for multiple sequential requests. Now there is a painful balance of inactivity timeouts: make them too long and you overload the server, make them too short and the connections get dropped all the time. The cheap connections would allow to keep the much longer timeouts. Then there are other interesting possibilities arising from the easy access to the protocol state. The underlying datagramness can be exposed to the top level, and this immediately gives the transactional TCP. Or we could look at the state and find out if the data has been actually delivered to and confirmed by the other side. Or we can even drop the inactive connections at the server without notifying the client. Then if the client sends more requests on this connection, the server could semi-transparently re-establish it (OK, this would require an extension from TCP). Or we can do the better keep-alives, not the TCP's hour-long ones, but something within a few seconds (would not work too well with millions of connections, but it's a different use case where we want to detect the lost peer fast). Or having "sub-channels", each with its own sequence number. If the data gets transferred over 100 parallel logical connections, few bytes at a time for each of them, combining the whole bunch into one datagram would be much more efficient tahn sending 100 datagrams. These are just the ideas off the bat, there's got to be more of these interesting usages. It all looks like such an obviously good idea, that I wonder, why didn't anyone else try it before? Or have they tried it and found that it's not such a good idea after all? -SB From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:40:16 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 02D2E106566B for ; Sun, 11 Jul 2010 21:40:16 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id CECF28FC17 for ; Sun, 11 Jul 2010 21:40:15 +0000 (UTC) Received: by pxi8 with SMTP id 8so1723778pxi.13 for ; Sun, 11 Jul 2010 14:40:15 -0700 (PDT) Received: by 10.114.111.5 with SMTP id j5mr15028256wac.27.1278882852044; Sun, 11 Jul 2010 14:14:12 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id d38sm56250680wam.8.2010.07.11.14.14.09 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 14:14:11 -0700 (PDT) Date: Sun, 11 Jul 2010 11:15:00 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andriy Gapon In-Reply-To: <4C39B7DE.3030100@freebsd.org> Message-ID: References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 12 Jul 2010 11:11:47 +0000 Cc: Peter Wemm , freebsd-hackers@freebsd.org, Jeff Roberson , Konstantin Belousov , "Bjoern A. Zeeb" Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:40:16 -0000 On Sun, 11 Jul 2010, Andriy Gapon wrote: > > [oops, sorry, this is not a dup - corrected some omissions/mistakes] > > on 11/07/2010 14:54 Andriy Gapon said the following: >> For completeness, here is a patch that simply drops the inline assembly and the >> comment about it, and GCC-generated assembly and its diff: >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff >> >> As was speculated above, the only thing really changed is section alignment >> (from 128 to 4). > > After making the above analysis I wondered why we require set_pcpu section > alignment at all. After all, it's not used as loaded, data from the section > gets copied into special per-cpu memory areas. So, logically, it's those areas > that need to be aligned, not the section. I appreciate your analysis but I don't understand the motivation for changing working code. Jeff > > svn log and google quickly pointed me to this excellent analysis and explanation > by bz (thanks again!): > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > > Summary: this alignment is needed to work around a bug in GNU binutils ld for > __start_SECNAME placement. > > As explained by bz, ld internally generates an equivalent of the following > linker script: > ... > __start_pcpu_set = ALIGN(NN); > pcpu_set : { > ... > } > __stop_pcpu_set = .; > > Where NN is an alignment of the first _input_ pcpu_set section found in > whichever .o file happens to be first. Not the resulting alignment of pcpu_set > _output_ section. > Alignment requirement of input sections is based on largest alignment > requirement of section's members. So if section is empty then the required > alignment is 1. Alignment of output section, if not explicitly overridden e.g. > via linker script, is the largest alignment of the corresponding input sections. > > I think that the problem can be fixed by making ld define __start_SECNAME like > follows: > ... > pcpu_set : { > __start_pcpu_set = ABSOLUTE(.); > ... > } > __stop_pcpu_set = .; > > This way __start_SECNAME would always point to the actual start of the output > section. > > Here's a patch that implements the idea: > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > > This is similar to what was done upstream: > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h > The code is quite different there, and approach is somewhat different, but the > idea is the same - place __start_SECNAME inside the section, not outside it. > > My testing shows the expected results. > What do you think? > > -- > Andriy Gapon > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 11:12:03 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 1EB3D1065704 for ; Mon, 12 Jul 2010 11:12:03 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id CA3ED8FC14 for ; Mon, 12 Jul 2010 11:12:02 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 355D914DBFED; Mon, 12 Jul 2010 13:12:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SBSJOnGT8e+t; Mon, 12 Jul 2010 13:11:59 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 1640214DC076; Mon, 12 Jul 2010 13:11:59 +0200 (CEST) Message-ID: <4C3AF87B.3030707@FreeBSD.org> Date: Mon, 12 Jul 2010 13:11:55 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pluknet References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:12:03 -0000 Em 2010.07.12. 9:00, pluknet escreveu: > Looking at getjid() impl, I see you're trying to put jid_t into the > one register_t > which are 64-bit vs 32-bit capable respectively. > You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek(). > Thanks for pointing this out, probably this was the problem, I'll try later because for now, I switched to 32-bit jid_t and that part works but there's other similar problem now: +int +setjlimit(struct thread *td, struct setjlimit_args *uap) +{ + struct jobentry *jp; + + /* sanity check */ + if (uap->resource>= JLIMIT_NLIMITS) { + td->td_retval[0] = -1; + return (EINVAL); + } ... The rest is just generated code with make sysent. I call this with resource parameter set to JLIMIT_NUMPROC (whose value is 3) and then inside the function it is seen as 869787392, so I always get EINVAL. In this case resource is just a normal int so I don't know what's going wrong. Gabor From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 11:39:27 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 91DAA10656BD for ; Mon, 12 Jul 2010 11:39:27 +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 136EE8FC13 for ; Mon, 12 Jul 2010 11:39:26 +0000 (UTC) Received: from [192.168.12.137] (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 o6CBFKUX037061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 11:15:21 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: <4C386208.291D2FB5@verizon.net> Date: Mon, 12 Jul 2010 12:19:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <545831D4-73C5-46E1-9502-E4687DA6EEF5@webweaving.org> References: <4C386208.291D2FB5@verizon.net> To: Sergey Babkin X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (pikmeer.webweaving.org [213.207.101.183]); Mon, 12 Jul 2010 11:15:21 +0000 (UTC) Cc: hackers@freebsd.org Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:39:27 -0000 On 10 Jul 2010, at 13:05, Sergey Babkin wrote: > I've got this idea, and I wonder if anyone has done it already, > and if not then why. The idea is to put the TCP logic over UDP. Have you looked at T/TCP [1,2,3] ? Dw 1: http://www.manpages.info/freebsd/ttcp.4.html 2: http://en.wikipedia.org/wiki/T/TCP 3: = http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20T= CP%20Stack%20-%20Presentation.pdf= From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 12:25: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 32A49106566B for ; Mon, 12 Jul 2010 12:25:19 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id C17A38FC1E for ; Mon, 12 Jul 2010 12:25:18 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+mOkxbsdUq/2dsb2JhbACgOHK9P4J7AYIrBA Received: from 42.213-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.213.42]) by relay.skynet.be with ESMTP; 12 Jul 2010 14:25:16 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o6CCPE8L004078; Mon, 12 Jul 2010 14:25:14 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: "Sam Fourman Jr." Date: Mon, 12 Jul 2010 14:25:13 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.1-PRERELEASE; KDE/4.4.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_pmwOMDgZ36mswJq" Message-Id: <201007121425.13561.tijl@coosemans.org> Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 12:25:19 -0000 --Boundary-00=_pmwOMDgZ36mswJq Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 30 June 2010 01:54:11 Sam Fourman Jr. wrote: > Last Tuesday blizzard release World of Warcraft 3.3.5, and with this > patch World of warcraft stopped working in FreeBSD 8.1 amd64, it > crashes right after login. > > I have been playing World of Warcraft on FreeBSD amd64 since December > of 2009 using the beta Nvidia 64bit drivers and this wine how-to > > http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d > > I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post > 3.3.5 so far as I can tell it is only broken on amd64. Could you give the attached patch a try? cd /usr/src patch -p1 < /path/to/patch-amd64-dr7 make buildkernel installkernel --Boundary-00=_pmwOMDgZ36mswJq Content-Type: text/plain; charset="iso-8859-1"; name="patch-amd64-dr7" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-amd64-dr7" diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index cfb4204..6b5c663 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -243,13 +243,13 @@ store_dr: movq %dr2,%r13 movq %dr3,%r12 movq %dr6,%r11 - andq $0x0000fc00, %rax /* disable all watchpoints */ movq %r15,PCB_DR0(%r8) movq %r14,PCB_DR1(%r8) movq %r13,PCB_DR2(%r8) movq %r12,PCB_DR3(%r8) movq %r11,PCB_DR6(%r8) movq %rax,PCB_DR7(%r8) + andq $0x0000fc00, %rax /* disable all watchpoints */ movq %rax,%dr7 jmp done_store_dr --Boundary-00=_pmwOMDgZ36mswJq-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 11:33: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 B32F8106564A for ; Mon, 12 Jul 2010 11:33:53 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from s2m-is-001.service2media.com (rev-132-102.virtu.nl [217.114.102.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8198FC25 for ; Mon, 12 Jul 2010 11:33:52 +0000 (UTC) Received: from pieter-dev.localnet ([10.0.1.91] RDNS failed) by s2m-is-001.service2media.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 13:33:49 +0200 From: Pieter de Goeje Organization: Service2Media To: freebsd-hackers@freebsd.org Date: Mon, 12 Jul 2010 13:33:48 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-5-amd64; KDE/4.4.4; x86_64; ; ) References: <4C386208.291D2FB5@verizon.net> In-Reply-To: <4C386208.291D2FB5@verizon.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007121333.49017.pdegoeje@service2media.com> X-OriginalArrivalTime: 12 Jul 2010 11:33:49.0629 (UTC) FILETIME=[18EF46D0:01CB21B6] X-Mailman-Approved-At: Mon, 12 Jul 2010 12:43:43 +0000 Cc: Sergey Babkin Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:33:53 -0000 On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote: > Hi guys, > > I've got this idea, and I wonder if anyone has done it already, > and if not then why. The idea is to put the TCP logic over UDP. > > I've done some googling and all I've found is some academical > user-space implementations of TCP that actually try to interoperate > with "real" TCP. What I'm thinking about is different. It's > to use the TCP-derived logic as a portable library that would > do the good flow control, retransmitting, delivery confirmations > etc over UDP. > > Basically, every time you use UDP, you've got to reinvent your > own retransmission and reliability protocol. And these protocols > are typically no good at all, as the story with NFS switching > from UDP to TCP and improving the performance shows. At the same > time TCP provides a very good transport control logic, so why not > just reuse this logic in a library to solve the UDP issues once > and for all? > > Then of course, why not just use TCP? The problem of TCP is that > it's expensive. It uses the kernel memory for its contexts. > It also requires a file descriptor per each connection. The file > descriptors are an expensive resource, and besides, even if > the limit is raised, there is the issue with historic select() > fd_set allocating only 1024 bits and nobody checking for the > overflow. Even if your own code is carefully designed to avoid using > select() at all and/or create large enough bitmasks, it could > always happen to use some stupid library that doesn't do that > and causes the interesting one-bit memory corruptions. > > Moving the connection logic to the user space makes the connections > cheap. A hundred bytes or so per connection state is no big > deal, you can easily create a million of these connections to > the same process. All the state stays in the user-space pageable > memory. Well, all of them sending data at the same time > might not work so well, but caching a large number of currently > inactive connections becomes cheap. Think of XMLRPC or SOAP > or anything else over HTTP reusing the same TCP connection for > multiple sequential requests. Now there is a painful balance > of inactivity timeouts: make them too long and you > overload the server, make them too short and the connections > get dropped all the time. The cheap connections would allow > to keep the much longer timeouts. > > Then there are other interesting possibilities arising from the easy > access to the protocol state. The underlying datagramness can be > exposed to the top level, and this immediately gives the transactional > TCP. Or we could look at the state and find out if the data has > been actually delivered to and confirmed by the other side. > Or we can even drop the inactive connections at the server without > notifying the client. Then if the client sends more requests on this > connection, the server could semi-transparently re-establish it > (OK, this would require an extension from TCP). Or we can do > the better keep-alives, not the TCP's hour-long ones, but > something within a few seconds (would not work too well with > millions of connections, but it's a different use case where > we want to detect the lost peer fast). Or having "sub-channels", > each with its own sequence number. If the data gets transferred > over 100 parallel logical connections, few bytes at a time for > each of them, combining the whole bunch into one datagram would > be much more efficient tahn sending 100 datagrams. These are just > the ideas off the bat, there's got to be more of these interesting > usages. > > It all looks like such an obviously good idea, that I wonder, > why didn't anyone else try it before? Or have they tried > it and found that it's not such a good idea after all? > > -SB TCP actually scales pretty well. All modern operating systems provide a way to do efficient select() operations, for example with FreeBSD's kqueue. Using a small bit of tuning one can effectively deal with 100k+ TCP connections on a single system. This mainly has to do with increasing the maximum number of filedescriptors and decreasing the maximum send/receive buffer sizes to conserve memory. TCP provides very good throughput, and it achieves this using large send and receive buffers. Your userspace implementation will need to implement something similar. A few hundred bytes per connection is simply not enough. If you want to deal with millions of clients, your protocol shall better not have any state at all. A good example of this is DNS. I think that most applications can either use TCP directly with or without tuning or they have such specialized needs that a custom protocol is the only solution. Regards, Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 15:38:41 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 05C7E1065676; Mon, 12 Jul 2010 15:38:41 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 928BF8FC0C; Mon, 12 Jul 2010 15:38:39 +0000 (UTC) Received: from park.js.berklix.net (p549A7BA0.dip.t-dialin.net [84.154.123.160]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6CFcXEQ092773; Mon, 12 Jul 2010 15:38:36 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6CFcNqn033743; Mon, 12 Jul 2010 17:38:24 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6CFcIsm053314; Mon, 12 Jul 2010 17:38:23 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007121538.o6CFcIsm053314@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 12 Jul 2010 17:38:18 +0200 Sender: jhs@berklix.com Cc: re@freebsd.org Subject: tools/ directory is missing on recent install media. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:38:41 -0000 Hi Hackers, FreeBSD install media has lost the tools/ directory from recent CDs & DVDs: Quoting http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html ... to resize your partitions and make space for FreeBSD. The tools directory on the CDROM contains two free software tools which can carry out this task, namely FIPS and PResizer ... PartitionMagic and GParted are known to work on NTFS. GParted is available on a number of Live CD Linux distributions, such as SystemRescueCD. There is no tools/ directory on recent FreeBSD CDROM disc1.iso & dvd1.iso ( or on memstick.img, no suprise as recent ) Maybe an older disc1.iso ran out of room, & tools/ got dropped & forgotten, not replaced for next release ? ( Downloading all of ftp://ftp2.de.freebsd.org/pub/FreeBSD/tools I see just 2 Meg, not much saving there unless desperate. { boot.bin bootinst.exe bsdboot ckdist.exe ckdist.man dist extipl.exe fdimage.exe fips.doc fips.exe fips.faq gunzip.exe gzip.exe ide_conf.exe md5.exe osbs135.exe osbsbeta.exe pfdisk.exe presizer.doc presizer.exe rawrite.exe restorrb.exe srcs } Maybe author of dvd1.iso script didnt realise tools/ used to be on disc1.iso, but had got dropped [for space] ? The DVD could easily take 2 meg (or is it copyright reasons FTP V. DVD?). /pub/FreeBSD/releases/ My local copy has all of these & more: amd64/ISO-IMAGES/7.2/7.2-RELEASE-amd64-disc1.iso amd64/ISO-IMAGES/7.2/7.2-RELEASE-amd64-dvd1.iso amd64/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-amd64-disc1.iso amd64/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-amd64-dvd1.iso amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-bootonly.iso amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-disc1.iso amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-dvd1.iso amd64/ISO-IMAGES/8.0/8.0-RELEASE-amd64-livefs.iso amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-disc1.iso amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-dvd1.iso amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-amd64-memstick.img i386/ISO-IMAGES/4.11/4.11-RELEASE-i386-disc1-gnome.iso i386/ISO-IMAGES/6.3/6.3-RELEASE-i386-disc1.iso i386/ISO-IMAGES/6.4/6.4-RELEASE-i386-disc1.iso i386/ISO-IMAGES/6.4/6.4-RELEASE-i386-dvd1.iso i386/ISO-IMAGES/7.2/7.2-RELEASE-i386-disc1.iso i386/ISO-IMAGES/7.2/7.2-RELEASE-i386-dvd1.iso i386/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-i386-disc1.iso i386/ISO-IMAGES/7.3/FreeBSD-7.3-RELEASE-i386-dvd1.iso i386/ISO-IMAGES/8.0/8.0-RELEASE-i386-disc1.iso i386/ISO-IMAGES/8.0/8.0-RELEASE-i386-dvd1.iso i386/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-i386-disc1.iso i386/ISO-IMAGES/8.1/FreeBSD-8.1-RC2-i386-dvd1.iso ( Inconsistent naming also on ftp://ftp.freebsd.org , with random prepend of .../FreeBSD-... ) I searched media above, tools/ was on 6.3-RELEASE-i386-disc1.iso but not on 6.4: tools/ on ftp site contains: bsdboot dist srcs srcs/EXTIPL srcs/EXTIPL/DEVELOP srcs/bteasy srcs/fips srcs/fips/restorrb srcs/fips/source srcs/ide_conf srcs/pfdisk srcs/rawrite re@, I suggest consider regularising [scripts ?] to avoid inconsistent prepend of .../FreeBSD-... to some image names. dvd1.iso script author, Please consider adding tools/ We might currently be losing some new people, tempted to try BSD, who need to first download a Linux image with disk partition shrinker (to run under Linux or MS, whatever), who then may think: "Why now dowload a BSD DVD too, Let's continue installing with this Linux DVD in the drive." An idea for memstick.img later maybe: Currently the UFS is on /dev/md0a , perhaps either we might put tools ported to BSD on the UFS or tools that run from MS, on an MSDOSFS on /dev/md0s2 ? Partition Shrinker Tools: A friend suggested http://jamesmcdonald.id.au/gnu-linux/linux-tools/shrink-your-windows-xp-ntfs-partition-to-half-size-and-install-linux-while-keeping-the-nt-bootloader URLs/ reccomendations welcome for other public partition shrinkers that run from install media (or MS, but no interest in commercial licensed Partition Magic). 2 I'm downloading to try: KNOPPIX_V6.2CD-2009-11-18-EN.iso loads of mirrors eg: ftp.gwdg.de/pub/linux/knoppix/ http://gparted.sourceforge.net/ http://sourceforge.net/projects/gparted/files/gparted-live-testing/0.6.1-2/gparted-live-0.6.1-2.iso/download Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 17:41: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 8FE14106566B for ; Mon, 12 Jul 2010 17:41:37 +0000 (UTC) (envelope-from nbspjr@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 1957F8FC15 for ; Mon, 12 Jul 2010 17:41:36 +0000 (UTC) Received: by bwz12 with SMTP id 12so3054672bwz.13 for ; Mon, 12 Jul 2010 10:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=I1de6jrwb96nrRUzGxoz9eGR/hKIV9e5NWBhmg8OffA=; b=kJMGIhNtgeN7A7xS1SCnqizqiH0ZPvUFEpvacL5gNgk4oS6lNQLQj/MgC9KyGPXNEa afrt0g2Wcg5lvE6PcqG9jEDrYnwkoGZoRBvW/0XdDdzImaI3ImXufnN1ve1NmDmYaR0z UjzbsB/HUNESIth7UPyIbYxb+S8OF7gUWmsbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=eyVOvcUcwIvHtlhICOZAIutJn4aRMgrFT1iodclFbwxzIpVvCoUdmsXh1WxwGJTPQ0 AMqALbq/v4ZmH0BkCngQR56ftdCnecDfguMrz2tmXLtoV52b3GcTAY/EZV6VtngHejgE rwXTyIXYNJYFa12p1CorAtnrSgujwfCoicWgc= Received: by 10.204.98.148 with SMTP id q20mr10248880bkn.24.1278955006189; Mon, 12 Jul 2010 10:16:46 -0700 (PDT) Received: from lair.localnet ([188.163.44.24]) by mx.google.com with ESMTPS id x19sm19367996bkv.21.2010.07.12.10.16.44 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 10:16:45 -0700 (PDT) From: Sergei Hedgehog Organization: Home To: freebsd-hackers@freebsd.org Date: Mon, 12 Jul 2010 20:16:41 +0300 User-Agent: KMail/1.13.5 (FreeBSD/8.0-RELEASE-p3; KDE/4.4.5; amd64; ; ) References: <201007121425.13561.tijl@coosemans.org> In-Reply-To: <201007121425.13561.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007122016.42490.nbspjr@gmail.com> Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:41:37 -0000 On Monday 12 July 2010 15:25:13 Tijl Coosemans wrote: > Could you give the attached patch a try? > > cd /usr/src > patch -p1 < /path/to/patch-amd64-dr7 > make buildkernel installkernel Thank you! This patch allowed me to login and enter the game world. I'll test the RealID feature later and submit results here. There is an another guy who is able to login after applying this patch too. Our system info: FreeBSD 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE and wine 1.2-rc6 FreeBSD 8.0-RELEASE-p3 amd64 with wine 1.2-rc4 However, there is little problem: the game hangs at login attempt if I enter wrong password. I'll post logs here when I'll get more info. Thank you for the patch. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 18:05:59 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 0A8311065676 for ; Mon, 12 Jul 2010 18:05:59 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id BAB9C8FC1A for ; Mon, 12 Jul 2010 18:05:58 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9BB2C1980; Mon, 12 Jul 2010 13:47:18 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 0014FC1823; Mon, 12 Jul 2010 13:47:17 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id ECAC2C180F; Mon, 12 Jul 2010 13:47:17 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id DF05D207A9; Mon, 12 Jul 2010 13:47:17 -0400 (EDT) From: Ken Smith To: "Julian H. Stacey" In-Reply-To: <201007121538.o6CFcIsm053314@fire.js.berklix.net> References: <201007121538.o6CFcIsm053314@fire.js.berklix.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AohJINwaGNN3xW8aCbyZ" Date: Mon, 12 Jul 2010 13:47:17 -0400 Message-ID: <1278956837.86120.12.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: hackers@freebsd.org, re@freebsd.org Subject: Re: tools/ directory is missing on recent install media. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:05:59 -0000 --=-AohJINwaGNN3xW8aCbyZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2010-07-12 at 17:38 +0200, Julian H. Stacey wrote: > Hi Hackers, > FreeBSD install media has lost the tools/ directory from recent CDs & DVD= s: >=20 > Quoting > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.h= tml > ... to resize your partitions and make space for FreeBSD. The > tools directory on the CDROM contains two free software > tools which can carry out this task, namely FIPS and PResizer > ... > PartitionMagic and GParted are known to work on NTFS. GParted > is available on a number of Live CD Linux distributions, > such as SystemRescueCD. >=20 > There is no tools/ directory on recent FreeBSD CDROM disc1.iso & dvd1.iso > ( or on memstick.img, no suprise as recent ) > Maybe an older disc1.iso ran out of room, > & tools/ got dropped & forgotten, not replaced for next release ? It wasn't a size issue that made me stop bothering to put the tools/ directory on, it was more an issue of the tools just not being current any more and not having an idea of what to replace them with. At the point I stopped putting them on the media the world had gotten to the point any tools that can't handle NTFS were useless. > re@,=20 > I suggest consider regularising [scripts ?] to avoid > inconsistent prepend of .../FreeBSD-... to some image names. FreeBSD- is consistently prepended to all the images that have been generated past the date we decided to start prepending FreeBSD- to the image names. Images that were generated before we decided to start prepending FreeBSD- to the image names consistently do not have FreeBSD- prepended to them... :-) > dvd1.iso script author, > Please consider adding tools/ > We might currently be losing some new people, tempted to > try BSD, who need to first download a Linux image with disk > partition shrinker (to run under Linux or MS, whatever), > who then may think: > "Why now dowload a BSD DVD too, Let's continue > installing with this Linux DVD in the drive." It won't happen in time for 8.1 but I'll try to invest some time in digging up reasonable replacements for the tools that had been there. Thanks for passing on your friend's suggestion. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-AohJINwaGNN3xW8aCbyZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkw7VRwACgkQ/G14VSmup/bPbwCfUmh+RewSRLcMeiljx6sNE8in WqsAn1XQPNluE8OKRV6jkI7xZVwVwaRe =TO06 -----END PGP SIGNATURE----- --=-AohJINwaGNN3xW8aCbyZ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 19:09: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 15D2E1065680 for ; Mon, 12 Jul 2010 19:09:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4F98FC12 for ; Mon, 12 Jul 2010 19:09:45 +0000 (UTC) Received: (qmail 18209 invoked by uid 399); 12 Jul 2010 19:09:44 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 19:09:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3B6876.9000402@FreeBSD.org> Date: Mon, 12 Jul 2010 12:09:42 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:09:46 -0000 On 07/09/10 08:11, Garrett Cooper wrote: > -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! > +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! Couple of comments. The above is not a typo, that's the British spelling. We generally don't change those. (Arguably it adds character to the project.) :) The other is more of a question, I'm not sure what the point of these changes is: ${var:-} The :- parameter substitution kicks in if var is unset or null, but you're not substituting it with anything. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 19:29:26 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 84B3B1065670 for ; Mon, 12 Jul 2010 19:29:26 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8288FC0A for ; Mon, 12 Jul 2010 19:29:26 +0000 (UTC) Received: from unknown (client-86-31-3-93.midd.adsl.virginmedia.com [86.31.3.93]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id ACB765F0C; Mon, 12 Jul 2010 19:29:11 +0000 (UTC) Date: Mon, 12 Jul 2010 20:29:25 +0100 From: Bruce Cran To: Sergey Babkin Message-ID: <20100712202925.00002273@unknown> In-Reply-To: <4C386208.291D2FB5@verizon.net> References: <4C386208.291D2FB5@verizon.net> 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: hackers@freebsd.org Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:29:26 -0000 On Sat, 10 Jul 2010 08:05:29 -0400 Sergey Babkin wrote: > Basically, every time you use UDP, you've got to reinvent your > own retransmission and reliability protocol. And these protocols > are typically no good at all, as the story with NFS switching > from UDP to TCP and improving the performance shows. At the same > time TCP provides a very good transport control logic, so why not > just reuse this logic in a library to solve the UDP issues once > and for all? Have you looked at SCTP? It may provide the features you've looking for: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Motivations -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 20:07: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 1A8151065672 for ; Mon, 12 Jul 2010 20:07:42 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA2CC8FC16 for ; Mon, 12 Jul 2010 20:07:41 +0000 (UTC) Received: by qwg5 with SMTP id 5so1718865qwg.13 for ; Mon, 12 Jul 2010 13:07:41 -0700 (PDT) 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=HwwVOfeQ9YA+CEan92AwncVaS0FQkFAC50h6l3zrdhU=; b=h1rQ223ntAsrPNeFts1U4xHTgme+jPoPt1XWCEzjx/fzomESZk+dbHBKba8IIU0FIu g/mM/Ja1hf9hWE35RMNgI8LQCU0ldVJRiZyUQlr2AgrMnJub2vaLHcGD8MtUJnD08sW6 73wfQobIIMvX8b9NRFCn1/nmrHKnQ29EkJjkQ= 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=nA/ZkpkklEAfc3R9L8olWxHxBFNOU0VBBrIeHub0Z/JPSixMcL7gF6eP2ZMIj/+QZE MyYJQWTd9LhZu97FRipy+6bcgkYVjf4M0FSyCVZt+oFrfu6aeaDzYk0i5NQueU5yZk9f uH7ZKcNWkRvkDXZvMo55K0nxV4CDD55MxCHfA= MIME-Version: 1.0 Received: by 10.224.116.146 with SMTP id m18mr7977356qaq.220.1278965260982; Mon, 12 Jul 2010 13:07:40 -0700 (PDT) Received: by 10.229.240.209 with HTTP; Mon, 12 Jul 2010 13:07:40 -0700 (PDT) In-Reply-To: <201007121425.13561.tijl@coosemans.org> References: <201007121425.13561.tijl@coosemans.org> Date: Mon, 12 Jul 2010 15:07:40 -0500 Message-ID: From: "Sam Fourman Jr." To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:07:42 -0000 On Mon, Jul 12, 2010 at 7:25 AM, Tijl Coosemans wrote: > On Wednesday 30 June 2010 01:54:11 Sam Fourman Jr. wrote: >> Last Tuesday blizzard release World of Warcraft 3.3.5, and with this >> patch World of warcraft stopped working in FreeBSD 8.1 amd64, it >> crashes right after login. >> >> I have been playing World of Warcraft on FreeBSD amd64 since December >> of 2009 using the beta Nvidia 64bit drivers and this wine how-to >> >> http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d >> >> I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post >> 3.3.5 so far as I can tell it is only broken on amd64. > > Could you give the attached patch a try? > > cd /usr/src > patch -p1 < /path/to/patch-amd64-dr7 > make buildkernel installkernel > I can confirm that this fixes wow post 3.3.5 on FreeBSD amd64 using cvs tag RELENG_8 it also works on PC-BSD 8.1 amd64 with the applied patch -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 15:50: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 6F9B2106566B for ; Mon, 12 Jul 2010 15:50:23 +0000 (UTC) (envelope-from s@swa.org.ru) Received: from mx.a-r-b.ru (mx.a-r-b.ru [90.156.229.147]) by mx1.freebsd.org (Postfix) with ESMTP id 37CA38FC15 for ; Mon, 12 Jul 2010 15:50:23 +0000 (UTC) Received: from [172.16.16.2] (helo=home.swa.org.ru) by mx.a-r-b.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OYKlu-0001qy-Vj; Mon, 12 Jul 2010 19:18:19 +0400 Message-ID: <4C3B3234.3010808@swa.org.ru> Date: Mon, 12 Jul 2010 21:18:12 +0600 From: Sergey Nikolenko User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100711 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: Tijl Coosemans References: <201007121425.13561.tijl@coosemans.org> In-Reply-To: <201007121425.13561.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Jul 2010 20:25:15 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:50:23 -0000 On 12.07.2010 18:25, Tijl Coosemans wrote: >> Last Tuesday blizzard release World of Warcraft 3.3.5, and with this >> patch World of warcraft stopped working in FreeBSD 8.1 amd64, it >> crashes right after login. >> >> I have been playing World of Warcraft on FreeBSD amd64 since December >> of 2009 using the beta Nvidia 64bit drivers and this wine how-to >> >> http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d >> >> I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post >> 3.3.5 so far as I can tell it is only broken on amd64. > > Could you give the attached patch a try? > > cd /usr/src > patch -p1< /path/to/patch-amd64-dr7 > make buildkernel installkernel Just tried, it works. Gamers will be happy I suppose. :) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 20:38: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 7AA40106566B for ; Mon, 12 Jul 2010 20:38:00 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8848FC16 for ; Mon, 12 Jul 2010 20:37:59 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id o6CKH1Pc031523 for ; Mon, 12 Jul 2010 22:17:02 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4C3B783D.5050200@fgznet.ch> Date: Mon, 12 Jul 2010 22:17:01 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Subject: sysctl 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: Mon, 12 Jul 2010 20:38:00 -0000 Dear all, I have an issue here, I do read a temperature sensor and I got a value back, in integer. This value is 'encoded', it contains the integer and the fractional part of the temperature I read. This is inside a kernel module. I offer a sysctl interface to read this value. Currently the access is done with sysctl_handle_int. In my userland application I can print this value with the following macro: FIX32TOPRINT(f) ((f) >> 16),((((f) & 0xffff) * 1000) >> 16) But now I wonder how can I teach the sysctl to print my tempreature the same way as my userland app does. Right now it looks this way: dev.sm.1.sensor.cpu_b_ad7417_amb.temp: 2736128 If I feed this 2736128 into the macro above I get this: 41.750 this is what I expect. Is this even possible? TIA for any pointer. Andreas From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 21:02: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 42AFB1065676 for ; Mon, 12 Jul 2010 21:02:06 +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 847768FC1A for ; Mon, 12 Jul 2010 21:02:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA01288; Tue, 13 Jul 2010 00:02:02 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OYQ8Y-000HLy-CP; Tue, 13 Jul 2010 00:02:02 +0300 Message-ID: <4C3B82C9.7070301@freebsd.org> Date: Tue, 13 Jul 2010 00:02:01 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Jeff Roberson References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3A39E9.1070505@freebsd.org> In-Reply-To: <4C3A39E9.1070505@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:02:06 -0000 on 12/07/2010 00:38 Andriy Gapon said the following: > on 12/07/2010 00:15 Jeff Roberson said the following: [snip] >> I appreciate your analysis but I don't understand the motivation for >> changing working code. > > Primary reason is that the "working code" produces zero-sized unused/unnecessary I think that my use of quotes was inappropriate in this sentence. The code is indeed working, just with that certain side-effect. > pcpu_set sections. See the subject line. As to why I care about those sections > - please see the start of this thread. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 21:59: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 0EFD21065677 for ; Mon, 12 Jul 2010 21:59:15 +0000 (UTC) (envelope-from bartek@6bone.be) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB988FC18 for ; Mon, 12 Jul 2010 21:59:14 +0000 (UTC) Received: by bwz12 with SMTP id 12so3214180bwz.13 for ; Mon, 12 Jul 2010 14:59:13 -0700 (PDT) Received: by 10.204.82.130 with SMTP id b2mr10920575bkl.12.1278970569344; Mon, 12 Jul 2010 14:36:09 -0700 (PDT) Received: from brtk-mob (91-145-140-249.internetia.net.pl [91.145.140.249]) by mx.google.com with ESMTPS id bq20sm20338155bkb.4.2010.07.12.14.36.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 14:36:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org Date: Mon, 12 Jul 2010 23:36:06 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Bartosz Marcin Kojak" Message-ID: User-Agent: Opera Mail/10.60 (Win32) Subject: inet_* functions in kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:59:15 -0000 Hi. Currently I'm writing a kernel module using MAC Framework to control binding to local IP addresses (kind of mac_portacl variation) and I need some advice. I want to be able to write rules for module through sysctl (rule will contain IP addresses in human-readable format, e.g. "uid:1002:192.168.2.3") and I'm wondering how to translate addresses to network byte order without inet_* functions. Well, they look like they're available to use in kernel (using ) but it's no able to compile module with inet_* functions using typical Makefile (this one with ".include " line) - it just produces warnings, and all warnings are treated as errors in this case. So, possible solutions are: just add custom CFLAGS without "-Werror" to Makefile (but it's quite ugly though) or write an userspace application that will write an addresses in NBO to sysctl (but now sysctl won't be easy to read and modify by hand). What do you think? Thanks in advance for any useful hints. -- SIGSTOP From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 22:26: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 66A2E106566C for ; Mon, 12 Jul 2010 22:26:11 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 08A3A8FC0C for ; Mon, 12 Jul 2010 22:26:09 +0000 (UTC) Received: (qmail 11480 invoked from network); 12 Jul 2010 22:26:08 -0000 Received: from unknown (HELO ?10.0.0.174?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 12 Jul 2010 22:26:08 -0000 Message-ID: <4C3B9682.2040309@acm.poly.edu> Date: Mon, 12 Jul 2010 18:26:10 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100530) MIME-Version: 1.0 To: Bartosz Marcin Kojak References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: inet_* functions in kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:26:11 -0000 Bartosz Marcin Kojak wrote: > > Hi. > > Currently I'm writing a kernel module using MAC Framework to control > binding to local IP addresses (kind of mac_portacl variation) and I > need some advice. > > I want to be able to write rules for module through sysctl (rule will > contain IP addresses in human-readable format, e.g. > "uid:1002:192.168.2.3") and I'm wondering how to translate addresses > to network byte order without inet_* functions. Well, they look like > they're available to use in kernel (using ) but it's no > able to compile module with inet_* functions using typical Makefile > (this one with ".include " line) - it just produces > warnings, and all warnings are treated as errors in this case. > > So, possible solutions are: just add custom CFLAGS without "-Werror" > to Makefile (but it's quite ugly though) or write an userspace > application that will write an addresses in NBO to sysctl (but now > sysctl won't be easy to read and modify by hand). > > What do you think? > > Thanks in advance for any useful hints. > Check out the byteorder(9) man page. -Boris From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 22:29:01 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 87F291065676 for ; Mon, 12 Jul 2010 22:29:01 +0000 (UTC) (envelope-from oliver.pntr@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 1018B8FC1B for ; Mon, 12 Jul 2010 22:29:00 +0000 (UTC) Received: by bwz12 with SMTP id 12so3236320bwz.13 for ; Mon, 12 Jul 2010 15:29:00 -0700 (PDT) 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=ImIrNMp+OLD+TdiTnqWoe7JlKAFK48bMyR7/VBvEdYE=; b=ivm5DmYqlzNmpRv19VpoIx8x+tLfW6s6Hh62ldm0V2NDz3PUQAagjqYCQADacB4+9w do6O7VejwILE/t/naSxCCg6nsKpSinaCeWtf1uCRVtiOg+PB7KrM+UtRd6WpRJMrHle0 52sEKU9u5p0H3WMghLOwmOZjILbRU0w1R9ZZM= 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=Wa8Kaf2CWQUycS5IF44OOzJvmhScie2IuYTfXltla0uPEdIbeOT3yxwI768MJQMs8v bNvoy/JB4UwBE09X3ls7A0k5G4JXnavzzhehYjsH3JJ0ZzqvpextAJbOPgc7xtNUYinC 7/PZGl4/aKlnCtaKxM9Wrwq4FVFQuW5jo+ako= MIME-Version: 1.0 Received: by 10.204.30.208 with SMTP id v16mr3348986bkc.166.1278973739844; Mon, 12 Jul 2010 15:28:59 -0700 (PDT) Received: by 10.204.54.135 with HTTP; Mon, 12 Jul 2010 15:28:59 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Tue, 13 Jul 2010 00:28:59 +0200 Message-ID: From: Oliver Pinter To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, pipacs@grsecurity.net, hunger@hunger.hu Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:29:01 -0000 CC pipacs and Hunger ;) On 7/1/10, Uffe Jakobsen wrote: > > Garrett writes: >>> Also, is there perhaps a sideeffect dealing with the size of a char on >>> FreeBSD vs Linux? >>> >>> That's a pretty badass way to load assembler instructions on the stack >>> :). >>> > > I may be totally wrong here - but could it be NX/XD/XN protection ? > > /Uffe > > > _______________________________________________ > 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 Jul 12 23:32:03 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 D3B701065673 for ; Mon, 12 Jul 2010 23:32:03 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id B4F318FC1A for ; Mon, 12 Jul 2010 23:32:03 +0000 (UTC) Received: from verizon.net ([unknown] [173.54.27.21]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5G00CCZXCYCID6@vms173001.mailsrvcs.net> for hackers@freebsd.org; Mon, 12 Jul 2010 18:31:50 -0500 (CDT) Sender: root Message-id: <4C3B75AA.BDB74226@verizon.net> Date: Mon, 12 Jul 2010 16:06:02 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-version: 1.0 To: Dirk-Willem van Gulik References: <4C386208.291D2FB5@verizon.net> <545831D4-73C5-46E1-9502-E4687DA6EEF5@webweaving.org> Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 12 Jul 2010 23:44:00 +0000 Cc: hackers@freebsd.org Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:32:03 -0000 Dirk-Willem van Gulik wrote: > > On 10 Jul 2010, at 13:05, Sergey Babkin wrote: > > > I've got this idea, and I wonder if anyone has done it already, > > and if not then why. The idea is to put the TCP logic over UDP. > > Have you looked at T/TCP [1,2,3] ? > > Dw > > 1: http://www.manpages.info/freebsd/ttcp.4.html > 2: http://en.wikipedia.org/wiki/T/TCP > 3: http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack%20-%20Presentation.pdf It's been a sort of a remote inspiration :-) A major problem with it (besides the security stuff listed on Wiki) is that it's implementation is in-kernel, and as such can be used directly only when the OS has the implementation. There is no way to write a portable application with it. Other than that, I'm proposing an opposite approach: why bother about reducing the cost of the initial connection, if we can instead just open the connection once and then keep it open for a very long time at a low cost? -SB From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 02:48: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 EA7E71065709 for ; Tue, 13 Jul 2010 02:48:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A9E528FC16 for ; Tue, 13 Jul 2010 02:48:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6D2k7Df037976; Mon, 12 Jul 2010 20:46:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 12 Jul 2010 20:46:23 -0600 (MDT) Message-Id: <20100712.204623.519459540419523199.imp@bsdimp.com> To: mj@feral.com From: "M. Warner Losh" In-Reply-To: <4C393D36.1050905@feral.com> References: <4C393D36.1050905@feral.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Missing files device_if.h and bus_if.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: Tue, 13 Jul 2010 02:48:58 -0000 Not quite. Make creates them... Matthew Jacob writes: : config(8) creates them I believe : : > line 523 of bus.h : > : > tries to include the following files: : > : > #include "device_if.h" : > #include "bus_if.h" : > : > however, I don't see them any where in my source tree. Are these : > missing or am I suppose to create them or are they built as part of : > the build process and if the latter then why didn't I get a copy when : > I built a custom kernel? : > : > Where do I get these files? Could someone please clue me in here? : > : > And since I am asking questions here, I see BUS_READ_IVAR used a : > couple of places but can't find it's definition. Where is it defined? : > : > Thanks : > Christopher : > _______________________________________________ : > 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" : > : : _______________________________________________ : 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 Jul 12 23: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 ABD0F106566B for ; Mon, 12 Jul 2010 23:51:15 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6E48FC18 for ; Mon, 12 Jul 2010 23:51:15 +0000 (UTC) Received: from verizon.net ([unknown] [173.54.27.21]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5G00AS9Y99JO0B@vms173019.mailsrvcs.net> for freebsd-hackers@freebsd.org; Mon, 12 Jul 2010 18:51:09 -0500 (CDT) Sender: root Message-id: <4C3B7A35.DA85096D@verizon.net> Date: Mon, 12 Jul 2010 16:25:25 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-version: 1.0 To: Pieter de Goeje References: <4C386208.291D2FB5@verizon.net> <201007121333.49017.pdegoeje@service2media.com> Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 13 Jul 2010 03:13:47 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:51:15 -0000 Pieter de Goeje wrote: > > On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote: > > Hi guys, > > > > I've got this idea, and I wonder if anyone has done it already, > > and if not then why. The idea is to put the TCP logic over UDP. > > > > I've done some googling and all I've found is some academical > > user-space implementations of TCP that actually try to interoperate > > with "real" TCP. What I'm thinking about is different. It's > > to use the TCP-derived logic as a portable library that would > > do the good flow control, retransmitting, delivery confirmations > > etc over UDP. > > > TCP actually scales pretty well. All modern operating systems provide a way to > do efficient select() operations, for example with FreeBSD's kqueue. Using a > small bit of tuning one can effectively deal with 100k+ TCP connections on a Not in a single process though. > single system. This mainly has to do with increasing the maximum number of > filedescriptors and decreasing the maximum send/receive buffer sizes to > conserve memory. Only in theory. My practical experience goes like this: How many parallel clients can our multithreaded server handle? Why, it should be easy to scale to almost anywhere, just bump the limit on the file descriptors. Bumped, tried. It crashes soon after 1000 connections. Why? A week later, the investigation has shown that we use PAM, and a PAM library for network authentication opens its own socket, and calls select() on it. It uses the standard fd_set, so when the socket happens to be above 1024, it corrupts the stack. So the only way to get a large number of file descriptors is in a very controlled environment, making sure not to use any 3rd-party or system libraries that might ever want to call select(). > TCP provides very good throughput, and it achieves this using large send and > receive buffers. Your userspace implementation will need to implement > something similar. A few hundred bytes per connection is simply not enough. A hundred or less bytes just for the state, for a connection that doesn't transfer anything at the moment. HTTP 1.1 and SOAP services on top of it do this: open a connection, and then after the first request keep it open, in case if they would want to send more requests. The minimum state would be pretty much a pair of addresses and sequence numbers, plus whatever tree or hash table overhead used to organize them. > If you want to deal with millions of clients, your protocol shall better not > have any state at all. A good example of this is DNS. DNS is actually a very bad example IMO. A very fragile protocol that trips over itself all the time. On the contrary, it's another case that should be able to benefit a lot from TCP-over-UDP. -SB From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 04:23:44 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 D389E1065675 for ; Tue, 13 Jul 2010 04:23:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD2F8FC17 for ; Tue, 13 Jul 2010 04:23:44 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2D847730A4; Tue, 13 Jul 2010 06:15:14 +0200 (CEST) Date: Tue, 13 Jul 2010 06:15:14 +0200 From: Luigi Rizzo To: hackers@freebsd.org Message-ID: <20100713041514.GA93662@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 04:23:44 -0000 Maybe you all love powerpoint for presentations, but sometimes one just needs to put together a few slides, perhaps a few bullets or images grabbed around the net, so i was wondering how hard would it be to do something that accepts a plain text file as input (without a ton of formatting) and lets you do a decent slide show, and supports editing the slides on the fly within the browser. Well, it's not too hard: http://info.iet.unipi.it/~luigi/sttp/ just 400 lines of javascript and 100 lines of css, plus your human-readable text. Have fun, it would be great if you could report how it works on fancy devices (iphone, ipad, androids...) as my testing platforms are limited to Firefox, IE and chrome (which unfortunately cannot save the edited file) cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 23:56:49 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 EDC311065670 for ; Mon, 12 Jul 2010 23:56:49 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by mx1.freebsd.org (Postfix) with ESMTP id CFD8B8FC17 for ; Mon, 12 Jul 2010 23:56:49 +0000 (UTC) Received: from verizon.net ([unknown] [173.54.27.21]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5G00MLSYID7I41@vms173011.mailsrvcs.net> for hackers@freebsd.org; Mon, 12 Jul 2010 18:56:38 -0500 (CDT) Sender: root Message-id: <4C3B7B7E.50A905AC@verizon.net> Date: Mon, 12 Jul 2010 16:30:54 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-version: 1.0 To: Bruce Cran References: <4C386208.291D2FB5@verizon.net> <20100712202925.00002273@unknown> Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 13 Jul 2010 05:40:23 +0000 Cc: hackers@freebsd.org Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:56:50 -0000 Bruce Cran wrote: > > On Sat, 10 Jul 2010 08:05:29 -0400 > Sergey Babkin wrote: > > > Basically, every time you use UDP, you've got to reinvent your > > own retransmission and reliability protocol. And these protocols > > are typically no good at all, as the story with NFS switching > > from UDP to TCP and improving the performance shows. At the same > > time TCP provides a very good transport control logic, so why not > > just reuse this logic in a library to solve the UDP issues once > > and for all? > > Have you looked at SCTP? It may provide the features you've looking > for: > http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Motivations Thanks, it does look like it! -SB From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 05:41:42 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 A834E1065677 for ; Tue, 13 Jul 2010 05:41:42 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB658FC0C for ; Tue, 13 Jul 2010 05:41:42 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C01FF5B81; Mon, 12 Jul 2010 22:41:41 -0700 (PDT) To: Luigi Rizzo In-reply-to: Your message of "Tue, 13 Jul 2010 06:15:14 +0200." <20100713041514.GA93662@onelab2.iet.unipi.it> References: <20100713041514.GA93662@onelab2.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Tue, 13 Jul 2010 06:15:14 +0200." Date: Mon, 12 Jul 2010 22:41:41 -0700 From: Bakul Shah Message-Id: <20100713054141.C01FF5B81@mail.bitblocks.com> Cc: hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 05:41:42 -0000 On Tue, 13 Jul 2010 06:15:14 +0200 Luigi Rizzo wrote: > Maybe you all love powerpoint for presentations, but sometimes > one just needs to put together a few slides, perhaps a few bullets > or images grabbed around the net, so i was wondering how hard > would it be to do something that accepts a plain text file > as input (without a ton of formatting) and lets you do a decent > slide show, and supports editing the slides on the fly within > the browser. > > Well, it's not too hard: > > http://info.iet.unipi.it/~luigi/sttp/ > > just 400 lines of javascript and 100 lines of css, plus > your human-readable text. > > Have fun, it would be great if you could report how it works > on fancy devices (iphone, ipad, androids...) as my testing > platforms are limited to Firefox, IE and chrome (which unfortunately > cannot save the edited file) Seems to work fine in Safari & Opera. Your note inspired me to search the 'Net! Since I prefer \latex{goop} to goop I went looking for a latex class and found 'Prosper'. Looks like it can produce some really nice slides! See the examples here: http://amath.colorado.edu/documentation/LaTeX/prosper/ And here is a tutorial: http://www.math.umbc.edu/~rouben/prosper/ And of course, it is already in /usr/ports/textproc/prosper! I will have to give it a try as I was getting tired of fiddling around in Keynote (and I don't like powerpoint). [Hope you don't mind my mentioning Prosper!] From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 06:04: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 4113D1065672 for ; Tue, 13 Jul 2010 06:04:43 +0000 (UTC) (envelope-from bahamasfranks@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 C55328FC08 for ; Tue, 13 Jul 2010 06:04:42 +0000 (UTC) Received: by iwn35 with SMTP id 35so6821963iwn.13 for ; Mon, 12 Jul 2010 23:04:42 -0700 (PDT) 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=FZOMYx4lSZqN7OEqP4kOahahhFOMX1YUCzjN4Z2mJDo=; b=lfCWnKEDjlKnk1r1pbX6DWuKkvn2QfALEQyEUZe5tZx+AZZy56bhEaeBwJBjom/T/X OyyTIEF+CZfYiB/vy1otkcb5gSWOg2nj1YW2eRI9NAu7yWwDtfIheyd+Z8QZCKrfm8Og jyNV9AlDOFV/nvnWbBIxbNg+0jy/BqoFlmY98= 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=PWnlmCThdH9KSeVhl67Bim+ZKG+dP1ptlqGfl05d3EJsQnIwaXVmilc+cTY6JmGOwp qWd05JY1S0MLJVWsECH9yBrauPDYA07qPAiuNFnSLw1/YCZdomC7pBdVqMctI3vsTUwq N2LtpZkZ0NBVJEQr8L7c8mBU4iu8K2NElA5yg= MIME-Version: 1.0 Received: by 10.231.172.205 with SMTP id m13mr4791986ibz.35.1279001081639; Mon, 12 Jul 2010 23:04:41 -0700 (PDT) Received: by 10.231.143.136 with HTTP; Mon, 12 Jul 2010 23:04:41 -0700 (PDT) In-Reply-To: <20100702013828.3b43639c@gumby.homeunix.com> References: <20100701220855.70d74b03@gumby.homeunix.com> <20100702013828.3b43639c@gumby.homeunix.com> Date: Mon, 12 Jul 2010 23:04:41 -0700 Message-ID: From: Steve Franks To: RW Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 06:04:43 -0000 RW, Thanks! For posterity, this is the full script that works for me for sorting my photos by date: #!/bin/sh for file in *.jpg *.jpeg *.JPG *.JPEG *.avi *.AVI do dir="${targetdir}`stat -f %Sm -t %Y.%m.%d ${file}`" [ -d "${dir}" ] || mkdir "${dir}" mv "${file}" "${dir}" done Best, Steve On Thu, Jul 1, 2010 at 5:38 PM, RW wrote: > On Thu, 1 Jul 2010 22:08:55 +0100 > RW wrote: > > >> dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/" >> [ -d "${dir}"] || mkdir "${dir}" >> mv "${file}" "${dir}"] >> > > Should be: > > dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/" > [ -d "${dir}" ] || mkdir "${dir}" > mv "${file}" "${dir}" > _______________________________________________ > 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 Jul 13 06:11:13 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 82E4B1065674 for ; Tue, 13 Jul 2010 06:11:13 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4CC8FC19 for ; Tue, 13 Jul 2010 06:11:13 +0000 (UTC) Received: by vws6 with SMTP id 6so126050vws.13 for ; Mon, 12 Jul 2010 23:11:11 -0700 (PDT) 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 :content-transfer-encoding; bh=RWGPlOM69JGDQjq9vYGHz4i41RaUx8Vo+3GuXA3tAlY=; b=ik4kCX3LoGQ3W7c9OVCaLEPcC2s4ZsIUK4crh8wMzT1gXxP2P1UBTrUPyjol4+EXXl /aBnweNw4eI4HSTntRqaix9pf3YVjL2rD8whVbaqyehrYcAt6v9BMC+Mk2rjMVdU3H1l 9+Ht+N8R7Or3ZXvM1xeebE1i+lxMgejebJdUc= 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:content-transfer-encoding; b=tCnPgfAcjw9i9+J7qD5AOafU/Gh2ElUfWm9tKyrL+cEYJGZW45M7WQkl57FkOHa3v6 JjmfF+XdJOVv5Cfk4lmwHBr1GFdcxYtvlFTnIc8bArAxQMwOm9WH2rlm+3vN1+WSxXSr 8uLjRiuYoQJqInbrzl7G5ptVmnMM2F+5Bd8b0= MIME-Version: 1.0 Received: by 10.229.240.209 with SMTP id lb17mr9030471qcb.167.1278999749520; Mon, 12 Jul 2010 22:42:29 -0700 (PDT) Received: by 10.229.24.72 with HTTP; Mon, 12 Jul 2010 22:42:29 -0700 (PDT) In-Reply-To: <20100713041514.GA93662@onelab2.iet.unipi.it> References: <20100713041514.GA93662@onelab2.iet.unipi.it> Date: Tue, 13 Jul 2010 02:42:29 -0300 Message-ID: From: Gonzalo Nemmi To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 06:11:13 -0000 On Tue, Jul 13, 2010 at 1:15 AM, Luigi Rizzo wrote: > Maybe you all love powerpoint for presentations, but sometimes > one just needs to put together a few slides, perhaps a few bullets > or images grabbed around the net, so i was wondering how hard > would it be to do something that accepts a plain text file > as input (without a ton of formatting) and lets you do a decent > slide show, and supports editing the slides on the fly within > the browser. > > Well, it's not too hard: > > =A0 =A0 =A0 =A0http://info.iet.unipi.it/~luigi/sttp/ > > just 400 lines of javascript and 100 lines of css, plus > your human-readable text. > > Have fun, it would be great if you could report how it works > on fancy devices (iphone, ipad, androids...) as my testing > platforms are limited to Firefox, IE and chrome (which unfortunately > cannot save the edited file) > > cheers > luigi > _______________________________________________ > 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= " > Wow! Really nice work! Thanks for sharing it Luigi, and kudos for your work! There's one problem though, I just can't download sttp-20100713.tgz because clicking on the link sends me to the TODO page and by taking a look at the source code from the page, I couldn't find any kind of BSD license text :s Best regards Gonzalo Nemmi From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 07:10: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 206621065674; Tue, 13 Jul 2010 07:10:58 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 0030F8FC17; Tue, 13 Jul 2010 07:10:57 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o6D7AvJJ056573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jul 2010 00:10:57 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o6D7Avus056572; Tue, 13 Jul 2010 00:10:57 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01927; Tue, 13 Jul 10 00:06:25 PDT Date: Tue, 13 Jul 2010 00:02:00 -0700 From: perryh@pluto.rain.com To: dougb@freebsd.org Message-Id: <4c3c0f68.3VZ746c3e/FP3QtE%perryh@pluto.rain.com> References: <4C3B6876.9000402@FreeBSD.org> In-Reply-To: <4C3B6876.9000402@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 07:10:58 -0000 Doug Barton wrote: > > -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! > > +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! > ... The above is not a typo, that's the British spelling. > ... (Arguably it adds character to the project.) :) Er, this example just changes one character without adding any :) [ducks] From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:10:50 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 E401D106566C for ; Tue, 13 Jul 2010 08:10:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A8D338FC15 for ; Tue, 13 Jul 2010 08:10:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3101073098; Tue, 13 Jul 2010 10:21:40 +0200 (CEST) Date: Tue, 13 Jul 2010 10:21:40 +0200 From: Luigi Rizzo To: Bakul Shah Message-ID: <20100713082140.GB96122@onelab2.iet.unipi.it> References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713054141.C01FF5B81@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100713054141.C01FF5B81@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:10:51 -0000 On Mon, Jul 12, 2010 at 10:41:41PM -0700, Bakul Shah wrote: > On Tue, 13 Jul 2010 06:15:14 +0200 Luigi Rizzo wrote: > > Maybe you all love powerpoint for presentations, but sometimes > > one just needs to put together a few slides, perhaps a few bullets > > or images grabbed around the net, so i was wondering how hard > > would it be to do something that accepts a plain text file > > as input (without a ton of formatting) and lets you do a decent > > slide show, and supports editing the slides on the fly within > > the browser. > > > > Well, it's not too hard: > > > > http://info.iet.unipi.it/~luigi/sttp/ > > > > just 400 lines of javascript and 100 lines of css, plus > > your human-readable text. > > > > Have fun, it would be great if you could report how it works > > on fancy devices (iphone, ipad, androids...) as my testing > > platforms are limited to Firefox, IE and chrome (which unfortunately > > cannot save the edited file) > > Seems to work fine in Safari & Opera. > > Your note inspired me to search the 'Net! Since I prefer > \latex{goop} to goop I went looking for a latex > class and found 'Prosper'. Looks like it can produce some > really nice slides! See the examples here: > > http://amath.colorado.edu/documentation/LaTeX/prosper/ > > And here is a tutorial: > > http://www.math.umbc.edu/~rouben/prosper/ > > And of course, it is already in /usr/ports/textproc/prosper! > I will have to give it a try as I was getting tired of > fiddling around in Keynote (and I don't like powerpoint). > > [Hope you don't mind my mentioning Prosper!] latex based solutions are great when it comes to show formulas. I normally use prosper or similar things. But placing figures is a bit of a nightmare, though, and at least for slides there is a lot of visual clutter in the latex formatting (of course one could write a preprocessor from plain text to latex/prosper). From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:11:20 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 16D0D1065700 for ; Tue, 13 Jul 2010 08:11:20 +0000 (UTC) (envelope-from nbspjr@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 924168FC16 for ; Tue, 13 Jul 2010 08:11:19 +0000 (UTC) Received: by bwz12 with SMTP id 12so3561895bwz.13 for ; Tue, 13 Jul 2010 01:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=NO7GPkjNaeIA6Vgaha5Ol2mgxHq5IFR5SylTPESJZJA=; b=JMRS5l49WcTBktQ1Yo9ey8GUcdhoGdZg/YULuswtR3cJ2vYJeIWhW1MS04zvXXVcve voqZZsvwOfuhZ/f161VaaK+Zx9Aqb0d0Z1ZHANuuK3M4n8GWc9mSBX4eUa7ab1L0UBxj SuGKwDUVH96nZTZ0+8V7ZHqaj4qOVuo8xbcps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=XoVa6n1FYSJ4wVb/nZaf9KQREE/T2NgIW24m/icQLiw+2Z4V9DdnJdTVSzv8vXsdjW tPZtXOeKirf9+HqWpCgZz6NjW5kVUNCNbajygsp1aABLL8bpLWmXhzI9YTCV1/AAom0d gc11GY9DS4a0YGeJOR2kys9i73pODk5VRZxws= Received: by 10.204.16.82 with SMTP id n18mr11726709bka.212.1279008678424; Tue, 13 Jul 2010 01:11:18 -0700 (PDT) Received: from lair.localnet ([188.163.44.24]) by mx.google.com with ESMTPS id s17sm22581257bkx.18.2010.07.13.01.11.17 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 01:11:17 -0700 (PDT) From: Sergei Hedgehog Organization: Home To: freebsd-hackers@freebsd.org Date: Tue, 13 Jul 2010 11:11:14 +0300 User-Agent: KMail/1.13.5 (FreeBSD/8.0-RELEASE-p3; KDE/4.4.5; amd64; ; ) References: <201007121425.13561.tijl@coosemans.org> In-Reply-To: <201007121425.13561.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007131111.15074.nbspjr@gmail.com> Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:11:20 -0000 On Monday 12 July 2010 15:25:13 Tijl Coosemans wrote: > Could you give the attached patch a try? > > cd /usr/src > patch -p1 < /path/to/patch-amd64-dr7 > make buildkernel installkernel Looks like everything works fine, except that game is crashing sometimes at login. But linux guys reports same behavior after patching their kernel. (FreeBSD 8.0-RELEASE-p3 amd64 && wine-1.2rc4) From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:14: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 182C2106567A for ; Tue, 13 Jul 2010 08:14:28 +0000 (UTC) (envelope-from sfourman@gmail.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 C2F988FC17 for ; Tue, 13 Jul 2010 08:14:27 +0000 (UTC) Received: by qyk30 with SMTP id 30so2376432qyk.13 for ; Tue, 13 Jul 2010 01:14:27 -0700 (PDT) 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=2gDOakmDw2gwk9JReTlRO5NCzyHTROjW6pKES85/ZX0=; b=CU7zav5y0gr85WjrSTMtOVQE4/FSB+Ih7n6PB0Mh105BGRTTx0Vs0tkhtaJGHPAcaJ nRFAu6QSbOPXBQ8NZHEpfm3VrlXlq/xJCklYXu4Npb+u2OG4HlwTIgs617tA8pFTgbkR 1pnU71wwsoPdgB4b07BjnMI45A820xPi4HXVs= 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=A30QyCf3xDOxskilPIQanABtl8Lp6rtdCWvJcCHHvl9DguYUolAoGyvvMNxfOO42l/ o9w6GlQMYg8VrNJJ8bCsUSRDDRQqCO2fZntwwXY6qgROVVYjhJjQoweQroZwnu18URKX I5op3X93ZSfk1I1CqSeptunoHEgFyumwJXfls= MIME-Version: 1.0 Received: by 10.224.97.233 with SMTP id m41mr5795813qan.221.1279008866824; Tue, 13 Jul 2010 01:14:26 -0700 (PDT) Received: by 10.229.240.209 with HTTP; Tue, 13 Jul 2010 01:14:26 -0700 (PDT) In-Reply-To: <201007131111.15074.nbspjr@gmail.com> References: <201007121425.13561.tijl@coosemans.org> <201007131111.15074.nbspjr@gmail.com> Date: Tue, 13 Jul 2010 03:14:26 -0500 Message-ID: From: "Sam Fourman Jr." To: Sergei Hedgehog Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:14:28 -0000 On Tue, Jul 13, 2010 at 3:11 AM, Sergei Hedgehog wrote: > On Monday 12 July 2010 15:25:13 Tijl Coosemans wrote: >> Could you give the attached patch a try? >> >> cd /usr/src >> patch -p1 < /path/to/patch-amd64-dr7 >> make buildkernel installkernel > > Looks like everything works fine, except that game is crashing sometimes at > login. But linux guys reports same behavior after patching their kernel. > on several systems I am having no issue after applying the patch -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:18: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 78423106566C; Tue, 13 Jul 2010 08:18:38 +0000 (UTC) (envelope-from ladrielt@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EA13D8FC21; Tue, 13 Jul 2010 08:18:37 +0000 (UTC) Received: by vws19 with SMTP id 19so84472vws.13 for ; Tue, 13 Jul 2010 01:18:37 -0700 (PDT) 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=+fuvzAqQ1STTTnTmCEPhhh0TC0WI9azF4VP6wKRECKQ=; b=aj+QW7Xz5NVFh05DtPHyiqh4iBQ5YTwQXxrJ5G6HSlhhiiegy6RDnyy+9Ku7c+2WLi z2YWaYVeuJBHDdBMbBkP6Y6WSAZ3I8LSCAZd39ufo7r9Fp2BQvGzYR0xysDPWRDS7jVw F704BqifeH75+eg/O3Zng8sUwVqVLzp+3FMwo= 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=Mu1/+Dn+VVrKyyuumTFx/ayIHLPMJ8vxRYW5ds9PxMHu5kH9mr7rNr+WRpMWaO0PQp ypUDfxNahhLHPFLPwUhluN9vHd4MmbrABBHXymCITNwqJoHItT0yYKVF9Mt7EonBq9Bg dJEPHDnYjw0SxujDM0oKD+087zamcV7h/yg1g= MIME-Version: 1.0 Received: by 10.229.233.137 with SMTP id jy9mr9061439qcb.5.1279007670534; Tue, 13 Jul 2010 00:54:30 -0700 (PDT) Received: by 10.229.81.74 with HTTP; Tue, 13 Jul 2010 00:54:30 -0700 (PDT) In-Reply-To: References: <4B79297D.9080403@FreeBSD.org> Date: Tue, 13 Jul 2010 13:54:30 +0600 Message-ID: From: l adrielt To: Ali Mashtizadeh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , Jack Vogel , FreeBSD Hackers , freebsd-net@freebsd.org Subject: Re: Sudden mbuf demand increase and shortage under the load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:18:38 -0000 Hi, I'm not sure but reading the advisory that just came out today sounds like it could have something to do with your mbuf issues. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D FreeBSD-SA-10:07.mbuf Security Adviso= ry The FreeBSD Projec= t Topic: Lost mbuf flag resulting in data corruption Category: core Module: kern Announced: 2010-07-13 Credits: Ming Fu Affects: FreeBSD 7.x and later. Corrected: 2010-07-13 02:45:17 UTC (RELENG_8, 8.1-PRERELEASE) 2010-07-13 02:45:17 UTC (RELENG_8_1, 8.1-RELEASE) 2010-07-13 02:45:17 UTC (RELENG_8_0, 8.0-RELEASE-p4) 2010-07-13 02:45:17 UTC (RELENG_7, 7.3-STABLE) 2010-07-13 02:45:17 UTC (RELENG_7_3, 7.3-RELEASE-p2) 2010-07-13 02:45:17 UTC (RELENG_7_1, 7.1-RELEASE-p13) CVE Name: CVE-2010-2693 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background An mbuf is a basic unit of memory management in the FreeBSD kernel inter-process communication and networking subsystem. Network packets and socket buffers are dependent on mbufs for their storage. Data can be embedded directly in mbufs, or mbufs can instead reference external buffers. The sendfile(2) system call uses external mbuf storage to directly map the contents of a file into a chain of mbufs for transmission purposes. The mbuf object supports a read-only flag that must be honored to prevent modification or writes to buffer data in cases like these. II. Problem Description The read-only flag is not correctly copied when a mbuf buffer reference is duplicated. When the sendfile(2) system call is used to transmit data over the loopback interface, this can result in the backing pages for the transmitted file being modified, causing data corruption. III. Impact This data corruption can be exploited by an local attacker to escalate their privilege by carefully controlling the corruption of system files. It should be noted that the attacker can corrupt any file they have read access to. NOTE: While systems without untrusted local users are not affected by the security aspects of this issue, the potential for data corruption implies that this should still be treated as a critical erratum. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the RELENG_8_1, RELENG_8_0, RELENG_7_3, or RELENG_7_1 security branch dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to FreeBSD 7.1, 7.3, 8.0 and 8.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-10:07/mbuf.patch # fetch http://security.FreeBSD.org/patches/SA-10:07/mbuf.patch.asc b) Apply the patch. On 7/11/10, Ali Mashtizadeh wrote: > Hi Maxim, > > I experienced the same issue recently on 8-STABLE branch and it seems > it has been fixed since 8.1-RC2 and above. I couldn't track down the > root cause in the code nor could I find a commit that seems to be the > obvious fix. > > Thanks, > ~ Ali > > 2010/2/15 Maxim Sobolev : >> Hi, >> >> Our company have a FreeBSD based product that consists of the numerous >> interconnected processes and it does some high-PPS UDP processing (30-50= K >> PPS is not uncommon). We are seeing some strange periodic failures under >> the >> load in several such systems, which usually evidences itself in IPC (eve= n >> through unix domain sockets) suddenly either breaking down or pausing an= d >> restoring only some time later (like 5-10 minutes). The only sign of >> failure >> I managed to find was the increase of the "requests for mbufs denied" in >> the >> netstat -m and number of total mbuf clusters (nmbclusters) raising up to >> the >> limit. >> >> I have tried to raise some network-related limits (most notably maxusers >> and >> nmbclusters), but it has not helped with the issue - it's still happenin= g >> from time to time to us. Below you can find output from the netstat -m f= ew >> minutes right after that shortage period - you see that somehow the syst= em >> has allocated huge amount of memory for the network (700MB), with only >> tiny >> amount of that being actually in use. This is for the >> kern.ipc.nmbclusters: >> 302400. Eventually the system reclaims all that memory and goes back to >> its >> normal use of 30-70MB. >> >> This problem is killing us, so any suggestions are greatly appreciated. = My >> current hypothesis is that due to some issues either with the network >> driver >> or network subsystem itself, the system goes insane and "eats" up all >> mbufs >> up to nmbclusters limit. But since mbufs are shared between network and >> local IPC, IPC goes down as well. >> >> We observe this issue with systems using both em(4) driver and igb(4) >> driver. I believe both drivers share the same design, however I am not >> sure >> if this is some kind of design flaw in the driver or part of a larger >> problem with the network subsystem. >> >> This happens on amd64 7.2-RELEASE and 7.3-PRERELEASE alike, with 8GB of >> memory. I have not tried upgrading to 8.0, this is production system so >> upgrading will not be easy. =C2=A0I don't believe there are some differe= nces >> that >> let us hope that this problem will go away after upgrade, but I can try = it >> as the last resort. >> >> As I said, this is very critical issue, so I can provide any additional >> debug information upon request. We are ready to go as far as paying >> somebody >> reasonable amount of money for tracking down and resolving the issue. >> >> Regards, >> -- >> Maksym Sobolyev >> Sippy Software, Inc. >> Internet Telephony (VoIP) Experts >> T/F: +1-646-651-1110 >> Web: http://www.sippysoft.com >> MSN: sales@sippysoft.com >> Skype: SippySoft >> >> >> [ssp-root@ds-467 /usr/src]$ netstat -m >> 17061/417669/434730 mbufs in use (current/cache/total) >> 10420/291980/302400/302400 mbuf clusters in use (current/cache/total/max= ) >> 10420/0 mbuf+clusters out of packet secondary zone in use (current/cache= ) >> 19/1262/1281/51200 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) >> 25181K/693425K/718606K bytes allocated to network (current/cache/total) >> 1246681/129567494/67681640 requests for mbufs denied >> (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/0/0 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> >> [FEW MINUTES LATER] >> >> [ssp-root@ds-467 /usr/src]$ netstat -m >> 10001/84574/94575 mbufs in use (current/cache/total) >> 6899/6931/13830/302400 mbuf clusters in use (current/cache/total/max) >> 6899/6267 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 2/1151/1153/51200 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) >> 16306K/39609K/55915K bytes allocated to network (current/cache/total) >> 1246681/129567494/67681640 requests for mbufs denied >> (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/0/0 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Ali Mashtizadeh > =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87 > _______________________________________________ > 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 Jul 13 08:40:24 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 0137C1065675 for ; Tue, 13 Jul 2010 08:40:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 902878FC08 for ; Tue, 13 Jul 2010 08:40:23 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 84C092A28CD9; Tue, 13 Jul 2010 10:40:21 +0200 (CEST) Date: Tue, 13 Jul 2010 10:40:21 +0200 From: Ed Schouten To: Bakul Shah Message-ID: <20100713084021.GT1742@hoeg.nl> References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713054141.C01FF5B81@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NO4xtVTk6ycZDAf4" Content-Disposition: inline In-Reply-To: <20100713054141.C01FF5B81@mail.bitblocks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers , Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:40:24 -0000 --NO4xtVTk6ycZDAf4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Bakul Shah wrote: > I went looking for a latex class and found 'Prosper'. Why not use the `beamer' class? http://bitbucket.org/rivanvx/beamer/wiki/Home This is what I always use to prepare my slides. Works great. --=20 Ed Schouten WWW: http://80386.nl/ --NO4xtVTk6ycZDAf4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw8JnUACgkQ52SDGA2eCwWcRACfbgG9q9VHzqnBmw7wU5SiS0Qo N3wAn0xw2z+4LEb7Ec0HrzjpjnnMrmwF =N27Z -----END PGP SIGNATURE----- --NO4xtVTk6ycZDAf4-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:48: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 3ABE11065672 for ; Tue, 13 Jul 2010 08:48:18 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 013F08FC19 for ; Tue, 13 Jul 2010 08:48:18 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 2ABCD2A28CD7; Tue, 13 Jul 2010 10:48:17 +0200 (CEST) Date: Tue, 13 Jul 2010 10:48:17 +0200 From: Ed Schouten To: Andreas Tobler Message-ID: <20100713084817.GU1742@hoeg.nl> References: <4C3B783D.5050200@fgznet.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oIMVlEQ///Q2JYC7" Content-Disposition: inline In-Reply-To: <4C3B783D.5050200@fgznet.ch> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl 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: Tue, 13 Jul 2010 08:48:18 -0000 --oIMVlEQ///Q2JYC7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andreas Tobler wrote: > But now I wonder how can I teach the sysctl to print my tempreature > the same way as my userland app does. I seem to remember all the other temperature sensors expose their value using tenth Kelvin precision. There is some kind of modifier you can add to the SYSCTL_INT declaration to denote that it's a temperature value. The sysctl(8) code on HEAD seems to suggest the type is "IK". Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --oIMVlEQ///Q2JYC7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw8KFEACgkQ52SDGA2eCwV5qwCcCKKkzb6JdWPoA907OIDLO5Jw zjUAn2kGeIEPmOKv6+NvYm4m8nD01EEy =1tKD -----END PGP SIGNATURE----- --oIMVlEQ///Q2JYC7-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 08:49: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 DC19A106566B for ; Tue, 13 Jul 2010 08:49:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 765D98FC27 for ; Tue, 13 Jul 2010 08:49:45 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D8A192A28CD7; Tue, 13 Jul 2010 10:49:44 +0200 (CEST) Date: Tue, 13 Jul 2010 10:49:44 +0200 From: Ed Schouten To: Bartosz Marcin Kojak Message-ID: <20100713084944.GV1742@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tln/wzp9jsNjmSUr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: inet_* functions in kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:49:45 -0000 --Tln/wzp9jsNjmSUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bartosz, * Bartosz Marcin Kojak wrote: > I want to be able to write rules for module through sysctl (rule > will contain IP addresses in human-readable format, e.g. > "uid:1002:192.168.2.3") and I'm wondering how to translate addresses > to network byte order without inet_* functions. Wouldn't it be possible to do the conversion in userspace and write something like a struct sockaddr_storage/in_addr_t/etc to the kernel? That way you can avoid the string handling in kernel space entirely. --=20 Ed Schouten WWW: http://80386.nl/ --Tln/wzp9jsNjmSUr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw8KKgACgkQ52SDGA2eCwVThwCeIC9mztFeRHj08V2F1va/R8n8 Fr4An1Y1JMKHsdlTs7C3W1B4KMW6Ftyz =wn6b -----END PGP SIGNATURE----- --Tln/wzp9jsNjmSUr-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 09:07:58 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 D12181065679 for ; Tue, 13 Jul 2010 09:07:58 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id BA5438FC1A for ; Tue, 13 Jul 2010 09:07:58 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 34BCB5B23; Tue, 13 Jul 2010 02:07:57 -0700 (PDT) To: Luigi Rizzo In-reply-to: Your message of "Tue, 13 Jul 2010 10:21:40 +0200." <20100713082140.GB96122@onelab2.iet.unipi.it> References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713054141.C01FF5B81@mail.bitblocks.com> <20100713082140.GB96122@onelab2.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Tue, 13 Jul 2010 10:21:40 +0200." Date: Tue, 13 Jul 2010 02:07:57 -0700 From: Bakul Shah Message-Id: <20100713090757.34BCB5B23@mail.bitblocks.com> Cc: hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 09:07:58 -0000 On Tue, 13 Jul 2010 10:21:40 +0200 Luigi Rizzo wrote: > latex based solutions are great when it comes to show formulas. > I normally use prosper or similar things. > But placing figures is a bit of a nightmare, though, and at least > for slides there is a lot of visual clutter in the latex formatting > (of course one could write a preprocessor from plain text to latex/prosper). Basically a unified work flow with latex is what appeals to me. But agreed on the visual clutter. A plain text to prosper preprocessor is a great idea! Very nice work, BTW! And I can already think of new uses for it! Ed Schouten asks: > Why not use the `beamer' class? > http://bitbucket.org/rivanvx/beamer/wiki/Home I didn't know about it. I will certainly check it out now. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 09:53:32 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 D8D56106566B for ; Tue, 13 Jul 2010 09:53:32 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from s2m-is-001.service2media.com (rev-132-102.virtu.nl [217.114.102.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7847D8FC0C for ; Tue, 13 Jul 2010 09:53:31 +0000 (UTC) Received: from pieter-dev.localnet ([10.0.1.91] RDNS failed) by s2m-is-001.service2media.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:53:30 +0200 From: Pieter de Goeje To: Sergey Babkin Date: Tue, 13 Jul 2010 11:53:29 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-5-amd64; KDE/4.4.4; x86_64; ; ) References: <4C386208.291D2FB5@verizon.net> <201007121333.49017.pdegoeje@service2media.com> <4C3B7A35.DA85096D@verizon.net> In-Reply-To: <4C3B7A35.DA85096D@verizon.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007131153.29838.pieter@degoeje.nl> X-OriginalArrivalTime: 13 Jul 2010 09:53:30.0391 (UTC) FILETIME=[3F9A3270:01CB2271] Cc: "freebsd-hackers@freebsd.org" Subject: Re: TCP over UDP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 09:53:33 -0000 On Monday 12 July 2010 22:25:25 Sergey Babkin wrote: > Pieter de Goeje wrote: > > On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote: > > > Hi guys, > > > > > > I've got this idea, and I wonder if anyone has done it already, > > > and if not then why. The idea is to put the TCP logic over UDP. > > > > > > I've done some googling and all I've found is some academical > > > user-space implementations of TCP that actually try to interoperate > > > with "real" TCP. What I'm thinking about is different. It's > > > to use the TCP-derived logic as a portable library that would > > > do the good flow control, retransmitting, delivery confirmations > > > etc over UDP. > > > > TCP actually scales pretty well. All modern operating systems provide a > > way to do efficient select() operations, for example with FreeBSD's > > kqueue. Using a small bit of tuning one can effectively deal with 100k+ > > TCP connections on a > > Not in a single process though. There's no reason why not. I know I've done it before. Obviously there are some practical problems, one of which you've described below. > > > single system. This mainly has to do with increasing the maximum number > > of filedescriptors and decreasing the maximum send/receive buffer sizes > > to conserve memory. > > Only in theory. My practical experience goes like this: How > many parallel clients can our multithreaded server handle? > Why, it should be easy to scale to almost anywhere, just > bump the limit on the file descriptors. Bumped, tried. It > crashes soon after 1000 connections. Why? A week later, > the investigation has shown that we use PAM, and a PAM library > for network authentication opens its own socket, and calls > select() on it. It uses the standard fd_set, so when the socket > happens to be above 1024, it corrupts the stack. So the only > way to get a large number of file descriptors is in a very > controlled environment, making sure not to use any 3rd-party > or system libraries that might ever want to call select(). A bug in a 3rd party library is no excuse not to use lots of filedescriptors. You can theoretically even isolate the library in a different process and use IPC to do the authentication. Your proposed solution to use a userspace TCP over UDP library is only a workaround for that problem IMHO. > > > TCP provides very good throughput, and it achieves this using large send > > and receive buffers. Your userspace implementation will need to > > implement something similar. A few hundred bytes per connection is > > simply not enough. > > A hundred or less bytes just for the state, for a connection > that doesn't transfer anything at the moment. HTTP 1.1 and > SOAP services on top of it do this: open a connection, and then > after the first request keep it open, in case if they would want > to send more requests. The minimum state would be pretty much a pair > of addresses and sequence numbers, plus whatever tree or hash > table overhead used to organize them. It is possible to decrease the send/recv buffer size of a connection when you know the connection is going to be idle. I've just tested this and it's possible to make both buffers 1 byte in size :) > > > If you want to deal with millions of clients, your protocol shall better > > not have any state at all. A good example of this is DNS. > > DNS is actually a very bad example IMO. A very fragile protocol > that trips over itself all the time. On the contrary, it's another > case that should be able to benefit a lot from TCP-over-UDP. Granted, but DNS is plagued by security problems and hacks to solve them. Technically however, a simple (stateless) request/response protocol over UDP is the way to go if the number of clients is basically unbounded. It is unfortunate that the connectionless nature of UDP makes naive servers vulnerable to reflexive DoS attacks, which limits the applicability somewhat to private servers or public servers with very well thought out protocols. - Pieter From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 13:34: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 895511065675 for ; Tue, 13 Jul 2010 13:34:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4425A8FC20 for ; Tue, 13 Jul 2010 13:34:08 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CE97D73098; Tue, 13 Jul 2010 15:44:57 +0200 (CEST) Date: Tue, 13 Jul 2010 15:44:57 +0200 From: Luigi Rizzo To: hackers@freebsd.org Message-ID: <20100713134457.GB1154@onelab2.iet.unipi.it> References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100713131706.GA2459@straylight.ringlet.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:34:09 -0000 On Tue, Jul 13, 2010 at 04:17:06PM +0300, Peter Pentchev wrote: ... > Nice work indeed! > > Just as an aside, though - are you aware of Eric Meyer's S5, > also available in your friendly neighbourhood Ports Collection > as textproc/s5? :) yes, there are many such things -- and i have done a fair amount of work on Slidy, building a distributed version called 'syncslidy' which allows distributed presentations. The problem, after a fair amount of usage, is really editing the slides in a simple way. cheers luigi > But yours does look a bit simpler to enter text in, although > I myself am quite used to typing HTML. > > G'luck, > Peter > > -- > Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > This sentence would be seven words long if it were six words shorter. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 13:46:53 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 133D7106567C for ; Tue, 13 Jul 2010 13:46:53 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from erengrad.hoster.bg (erengrad.hoster.bg [77.77.142.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC698FC14 for ; Tue, 13 Jul 2010 13:46:52 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by erengrad.hoster.bg (Postfix) with ESMTP id 693ADDCA35 for ; Tue, 13 Jul 2010 16:17:17 +0300 (EEST) Received: from straylight.ringlet.net (office.hoster.bg [78.90.131.77]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id AEA2B5C01F for ; Tue, 13 Jul 2010 16:17:07 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 416122 by straylight.ringlet.net (DragonFly Mail Agent) Tue, 13 Jul 2010 16:17:06 +0300 Date: Tue, 13 Jul 2010 16:17:06 +0300 From: Peter Pentchev To: Luigi Rizzo Message-ID: <20100713131706.GA2459@straylight.ringlet.net> Mail-Followup-To: Luigi Rizzo , hackers@freebsd.org References: <20100713041514.GA93662@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20100713041514.GA93662@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: AEA2B5C01F.EF7F0 X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: hackers@freebsd.org X-Spam-Status: No Cc: hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:46:53 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 06:15:14AM +0200, Luigi Rizzo wrote: > Maybe you all love powerpoint for presentations, but sometimes > one just needs to put together a few slides, perhaps a few bullets > or images grabbed around the net, so i was wondering how hard > would it be to do something that accepts a plain text file > as input (without a ton of formatting) and lets you do a decent > slide show, and supports editing the slides on the fly within > the browser. >=20 > Well, it's not too hard: >=20 > http://info.iet.unipi.it/~luigi/sttp/ >=20 > just 400 lines of javascript and 100 lines of css, plus > your human-readable text. Nice work indeed! Just as an aside, though - are you aware of Eric Meyer's S5, also available in your friendly neighbourhood Ports Collection as textproc/s5? :) But yours does look a bit simpler to enter text in, although I myself am quite used to typing HTML. G'luck, Peter --=20 Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. --GvXjxJ+pjyke8COw 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) iQIcBAEBCgAGBQJMPGdOAAoJEGUe77AlJ98TD6EQAJ720Wdtv8wT+Xh0sN8mPVax 4jKxMOTkPqD0E/ZoRwV/SoFU+EfUXbnhr+goZs+tD7NR68xuLWEoH31DZuQcMuzD 9auogBLNUmJjwG4OpW7cQjorzNjW1YqQNhIZE9Nc1zUUkXBUPJ/FY6hZ+nUKbFA/ cy66K/f0qSoCZ9PGd4+0RFjCROEnUro9knsNG/RcAbHRb26+CAFS/62FbQvcIzCG AltmcoAT5AHlgMB4EN7NoAOYl5gQWFjmvo5NZsKgMci373TtF8Ach3RfZyGeMb+E Wt+54HxTfyrn5h6myKcYPakYuWwGPIjI/QDQTfOqt7A2SSRQxHEwJpiT5zu9pJsj aOQgoBPJQRAc4raQM3Po1EmK2GoffmjNsrPeLpNvoK+kgFoUkREd8alRlpbZD9Bl mZ4jbZrJzW185zXKe0gQ9et61Kofa1tDmgvqSemtZ5COnFidyksKdaIVuHFTcO2V 2e8jaG6Ufi+yud236Gjd0qVhL41usbTM9B7UK/iGpx7/kHZ35bbKi4pE3UYJzJeL A9VTtfuWJlf8ncbUARiJU8hTALKXk6npfyoNbB76JJb9KwCDfmA53HRd4z/Nt34t Me6BRr8F3XvxqX20UIxiJqkMJkNLMwFbLMwZ0gScO+QaehqCaaZL8cn1AqPGw1AI hePbJzF2143yOLtbAHAM =ri0q -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 14:05:51 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 EB9891065673; Tue, 13 Jul 2010 14:05:50 +0000 (UTC) (envelope-from pluknet@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 546A68FC16; Tue, 13 Jul 2010 14:05:49 +0000 (UTC) Received: by wwc33 with SMTP id 33so251365wwc.31 for ; Tue, 13 Jul 2010 07:05:49 -0700 (PDT) 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=8PVawZ8ZeOEYS26N5WiLQYtj9GlSV8aYt6N0XBEw558=; b=G3Xz4Hsl7gQKPSusBmqAkgS7PbQ+wu83yaMcf2zGpjE62K4F0UB7LeNzgjH4Ufb74K trWm2Y4w9Tsf6Wig4JE4KO4MnhR8+wuSUwrYdcHHNtqcYVEgl4AhdkqcHt6HsG5a4tXU WX8I0XgPQweOreNcHLRhAsTTo2rJwzmumXphk= 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=J9aexm3lC7y1MSrE1LFW+Mv9g+z0bF0dd1pSNshblT7XH/FfGBLrIIVCNVD4WxEuf7 b6cCUVDKaP7Yix3Q3XC3eAtSmgL4VU1mgwDExLZSMsfrFJC04JlbwBfoiOMZWRrkNHsn ythxZ0sXaNwUyw8f8QrCCyyJH65TJtR+MnQiA= MIME-Version: 1.0 Received: by 10.216.180.131 with SMTP id j3mr10244004wem.107.1279029947831; Tue, 13 Jul 2010 07:05:47 -0700 (PDT) Received: by 10.216.27.13 with HTTP; Tue, 13 Jul 2010 07:05:47 -0700 (PDT) In-Reply-To: <4C3AF87B.3030707@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> <4C3AF87B.3030707@FreeBSD.org> Date: Tue, 13 Jul 2010 18:05:47 +0400 Message-ID: From: pluknet To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:05:51 -0000 On 12 July 2010 15:11, Gabor Kovesdan wrote: > Em 2010.07.12. 9:00, pluknet escreveu: >> >> Looking at getjid() impl, I see you're trying to put jid_t into the >> one register_t >> which are 64-bit vs 32-bit capable respectively. >> You need to cast so you put 64-bit into two 32-bit as done for e.g. >> lseek(). >> > > Thanks for pointing this out, probably this was the problem, I'll try lat= er > because for now, I switched to 32-bit jid_t and that part works but there= 's > other similar problem now: > > +int > +setjlimit(struct thread *td, struct setjlimit_args *uap) > +{ > + =A0 =A0 =A0 struct jobentry *jp; > + > + =A0 =A0 =A0 /* sanity check */ > + =A0 =A0 =A0 if (uap->resource>=3D JLIMIT_NLIMITS) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 td->td_retval[0] =3D -1; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EINVAL); > + =A0 =A0 =A0 } > > ... > > The rest is just generated code with make sysent. > > I call this with resource parameter set to JLIMIT_NUMPROC (whose value is= 3) > and then inside the function it is seen as 869787392, so I always get > EINVAL. In this case resource is just a normal int so I don't know what's > going wrong. > Hmm.. something on your side. # ./setjlimit_test setjlimit returns zero on console: setjlimit called resource: 3 #ifndef _SYS_SYSPROTO_H_ struct setjlimit_args { jid_t jid; int resource; struct rlimit *rlp; }; #endif int setjlimit(td, uap) struct thread *td; struct setjlimit_args /* { jid_t jid; int resource; struct rlimit *rlp; } */ *uap; { printf("%s called\n", __FUNCTION__); printf("resource: %d\n", uap->resource); if (uap->resource >=3D JLIM_NLIMITS) { td->td_retval[0] =3D -1; return (EINVAL); } return (0); } --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 14:51: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 67F7F106566B for ; Tue, 13 Jul 2010 14:51:55 +0000 (UTC) (envelope-from sunpoet@sunpoet.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 044CF8FC1F for ; Tue, 13 Jul 2010 14:51:54 +0000 (UTC) Received: by fxm13 with SMTP id 13so2820282fxm.13 for ; Tue, 13 Jul 2010 07:51:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.63.10 with SMTP id l10mr1300473fga.28.1279030961356; Tue, 13 Jul 2010 07:22:41 -0700 (PDT) Received: by 10.220.178.6 with HTTP; Tue, 13 Jul 2010 07:22:41 -0700 (PDT) In-Reply-To: <4c3c0f68.3VZ746c3e/FP3QtE%perryh@pluto.rain.com> References: <4C3B6876.9000402@FreeBSD.org> <4c3c0f68.3VZ746c3e/FP3QtE%perryh@pluto.rain.com> Date: Tue, 13 Jul 2010 22:22:41 +0800 Message-ID: From: Sunpoet Hsieh To: perryh@pluto.rain.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:51:55 -0000 On Tue, Jul 13, 2010 at 3:02 PM, wrote: > Doug Barton wrote: >> > -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! >> > +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! >> ... The above is not a typo, that's the British spelling. >> ... (Arguably it adds character to the project.) :) > > Er, this example just changes one character without adding any :) > > [ducks] BTW, it adds cvs log. :) I think such spelling variance is acceptable. Regards, Sunpoet From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 15: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 C88111065675 for ; Tue, 13 Jul 2010 15:40:03 +0000 (UTC) (envelope-from yanegomi@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 8FB7C8FC08 for ; Tue, 13 Jul 2010 15:40:03 +0000 (UTC) Received: by iwn35 with SMTP id 35so7348911iwn.13 for ; Tue, 13 Jul 2010 08:40:03 -0700 (PDT) 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=ZcKV+wuPa9gUkSMcMeKQ1gvujDR3aOA/Ah63E3rMZn0=; b=ULwuyNL2Q2DJLwwpp9ySb9ZM2wrkVFOXO93hPmor2FEuIsGV6D1GO2mu4xsoIl+q4j g1gnrmPQmQmFU+KNzy1SeNtwoQGNrmGlp9CWsoCtqkrqYDJEZOBuULmYve5h5E2woxk9 l5O4FIRC2aQn5hxtyH8SPhSiUOor9nQqCs+M0= 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=fDTIkyOEcZOGUQQF8bTZy9kzTzByvBwPtoCFM3I0P4jHEptez0O2czizRaTtXD6iiy utjZoy538MVIhBVz4FWXx5mpfcEdWuOHrlF0b6RkkPJy6XJZP2d4qd6y5KoIrrDbmoZg OP3U9Gs8uDActJt4epeU04mf1xDh0N9NLrlHU= MIME-Version: 1.0 Received: by 10.231.146.205 with SMTP id i13mr12397610ibv.30.1279033941887; Tue, 13 Jul 2010 08:12:21 -0700 (PDT) Received: by 10.231.182.74 with HTTP; Tue, 13 Jul 2010 08:12:21 -0700 (PDT) In-Reply-To: <4C3B6876.9000402@FreeBSD.org> References: <4C3B6876.9000402@FreeBSD.org> Date: Tue, 13 Jul 2010 08:12:21 -0700 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:40:04 -0000 On Mon, Jul 12, 2010 at 12:09 PM, Doug Barton wrote: > On 07/09/10 08:11, Garrett Cooper wrote: >> -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! >> +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! > > Couple of comments. The above is not a typo, that's the British > spelling. We generally don't change those. (Arguably it adds character > to the project.) :) > > The other is more of a question, I'm not sure what the point of these > changes is: ${var:-} The :- parameter substitution kicks in if var is > unset or null, but you're not substituting it with anything. Yeah, that was silly. I was doing this out of habit with set -u... So I'm taking it that the only change of benefit is the attached patch. Thanks, -Garrett --- /usr/ports/Mk/bsd.port.mk 2010-06-04 01:09:17.000000000 -0700 +++ bsd.port.mk 2010-07-13 08:09:13.000000000 -0700 @@ -5465,10 +5465,9 @@ if [ "${CHILD_DEPENDS}" ]; then \ installed=$$(${PKG_INFO} -qO ${PKGORIGIN} 2>/dev/null || \ ${TRUE}); \ - if [ "$$installed" ]; then \ + if [ -n "$$installed" ]; then \ break; \ - fi; \ - if [ -z "$$installed" ]; then \ + else \ installed="${PKGNAME}"; \ fi; \ for pkgname in $$installed; do \ @@ -5511,16 +5510,15 @@ while [ $$\# -gt 1 ]; do \ if [ ! -d "${PORTSDIR}/$$2" ]; then \ shift; \ - continue; \ - fi; \ - if [ "$$dir" = "$$2" ]; then \ + elif [ "$$dir" = "$$2" ]; then \ ${ECHO_CMD} $$1:$$dir; \ if [ -e ${PKG_DBDIR}/$$1/+CONTENTS -a -z "${EXPLICIT_PACKAGE_DEPENDS}" ]; then \ packagelist="$$packagelist ${PKG_DBDIR}/$$1/+CONTENTS"; \ fi; \ break; \ + else \ + shift 2; \ fi; \ - shift 2; \ done; \ done; \ [ -z "$$packagelist" ] || ${AWK} -F '( |:)' 'BEGIN { pkgname="broken_contents" } /@pkgdep / { pkgname=$$2 } /@comment DEPORIGIN:/ { printf "%s:%s\n", pkgname, $$3; pkgname="broken_contents" }' $$packagelist; \ @@ -5541,7 +5539,7 @@ (cd $$dir; ${MAKE} package-noinstall); \ done -# Show missing dependiencies +# Show missing dependencies missing: @_origins=$$(${PKG_INFO} -aoq); \ for dir in $$(${ALL-DEPENDS-LIST}); do \ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 15:48: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 304A31065673 for ; Tue, 13 Jul 2010 15:48:07 +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 DECD78FC13 for ; Tue, 13 Jul 2010 15:48:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OYhiG-0005J9-P1 for freebsd-hackers@freebsd.org; Tue, 13 Jul 2010 17:48:04 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Jul 2010 17:48:04 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Jul 2010 17:48:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 13 Jul 2010 17:48:14 +0200 Lines: 9 Message-ID: References: <20100713041514.GA93662@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <20100713041514.GA93662@onelab2.iet.unipi.it> X-Enigmail-Version: 1.0.1 Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:48:07 -0000 On 07/13/10 06:15, Luigi Rizzo wrote: > Have fun, it would be great if you could report how it works > on fancy devices (iphone, ipad, androids...) For what it's worth, it doesn't work at all on Android :) (and the layout is messed up) From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 16:21:22 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 F22031065672 for ; Tue, 13 Jul 2010 16:21:22 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 771C58FC0A for ; Tue, 13 Jul 2010 16:21:22 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by mp2.macomnet.net (8.14.3/8.14.3) with ESMTP id o6DGLKPt098965; Tue, 13 Jul 2010 20:21:21 +0400 (MSD) (envelope-from maxim.konovalov@gmail.com) Date: Tue, 13 Jul 2010 20:21:20 +0400 (MSD) From: Maxim Konovalov To: Peter Pentchev In-Reply-To: <20100713131706.GA2459@straylight.ringlet.net> Message-ID: References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 13 Jul 2010 16:55:54 +0000 Cc: hackers@freebsd.org, Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:21:23 -0000 On Tue, 13 Jul 2010, 16:17+0300, Peter Pentchev wrote: > On Tue, Jul 13, 2010 at 06:15:14AM +0200, Luigi Rizzo wrote: > > Maybe you all love powerpoint for presentations, but sometimes > > one just needs to put together a few slides, perhaps a few bullets > > or images grabbed around the net, so i was wondering how hard > > would it be to do something that accepts a plain text file > > as input (without a ton of formatting) and lets you do a decent > > slide show, and supports editing the slides on the fly within > > the browser. > > > > Well, it's not too hard: > > > > http://info.iet.unipi.it/~luigi/sttp/ > > > > just 400 lines of javascript and 100 lines of css, plus > > your human-readable text. > > Nice work indeed! > > Just as an aside, though - are you aware of Eric Meyer's S5, > also available in your friendly neighbourhood Ports Collection > as textproc/s5? :) > > But yours does look a bit simpler to enter text in, although > I myself am quite used to typing HTML. > + misc/magicpoint. -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 17:18: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 AD34E1065670 for ; Tue, 13 Jul 2010 17:18:00 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 782C48FC15 for ; Tue, 13 Jul 2010 17:18:00 +0000 (UTC) Received: from jnielsen.socialserve.com ([12.53.251.10]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id o6DH35cr036006 for ; Tue, 13 Jul 2010 13:03:07 -0400 (EDT) (envelope-from lists@jnielsen.net) Message-Id: From: John Nielsen To: freebsd-hackers@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 13:02:59 -0400 References: <20100713041514.GA93662@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:18:00 -0000 On Jul 13, 2010, at 11:48 AM, Ivan Voras wrote: > On 07/13/10 06:15, Luigi Rizzo wrote: > >> Have fun, it would be great if you could report how it works >> on fancy devices (iphone, ipad, androids...) > > For what it's worth, it doesn't work at all on Android :) (and the > layout is messed up) The front page appears to come up fine on my iPhone (3GS+IOS 4) but I'm not able to navigate to any other slides (tap "clicking" doesn't work and I don't have the option of supplying keyboard input). JN From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 17:03: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 D94F01065673 for ; Tue, 13 Jul 2010 17:03:34 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 67C038FC21 for ; Tue, 13 Jul 2010 17:03:33 +0000 (UTC) Received: (qmail 86031 invoked by uid 1000); 13 Jul 2010 16:36:50 -0000 Date: 13 Jul 2010 16:36:50 -0000 Message-ID: <20100713163650.86030.qmail@mailgate.gta.com> From: Larry Baird To: freebsd-hackers@freebsd.org Organization: Global Technology Associates In-Reply-To: <110613.02658.82616@localhost> User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-PRERELEASE (i386)) X-Mailman-Approved-At: Tue, 13 Jul 2010 17:41:48 +0000 Cc: Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:03:34 -0000 In article <110613.02658.82616@localhost> you wrote: > Maybe you all love powerpoint for presentations, but sometimes > one just needs to put together a few slides, perhaps a few bullets > or images grabbed around the net, so i was wondering how hard > would it be to do something that accepts a plain text file > as input (without a ton of formatting) and lets you do a decent > slide show, and supports editing the slides on the fly within > the browser. > > Well, it's not too hard: > > http://info.iet.unipi.it/~luigi/sttp/ Haven't used it in years, but I liked it when I used ports/misc/magicpoint. Port description is: MagicPoint - an X11 based presentation tool MagicPoint is an X11 based presentation tool. It is designed to make simple presentations easy while to make complicated presentations possible. Its presentation file (whose suffix is typically .mgp) is just text so that you can create presentation files quickly with your favorite editor (e.g. Emacs). -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 19:54: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 E46A7106566B for ; Tue, 13 Jul 2010 19:54:25 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 8273D8FC21 for ; Tue, 13 Jul 2010 19:54:24 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id o6DJsIT2038739; Tue, 13 Jul 2010 21:54:19 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4C3CC46A.8080607@fgznet.ch> Date: Tue, 13 Jul 2010 21:54:18 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Ed Schouten References: <4C3B783D.5050200@fgznet.ch> <20100713084817.GU1742@hoeg.nl> In-Reply-To: <20100713084817.GU1742@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl 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: Tue, 13 Jul 2010 19:54:26 -0000 On 13.07.10 10:48, Ed Schouten wrote: > * Andreas Tobler wrote: >> But now I wonder how can I teach the sysctl to print my tempreature >> the same way as my userland app does. > > I seem to remember all the other temperature sensors expose their value > using tenth Kelvin precision. There is some kind of modifier you can add > to the SYSCTL_INT declaration to denote that it's a temperature value. > The sysctl(8) code on HEAD seems to suggest the type is "IK". Thanks Ed! I need to figure out how to format my temperature value to fit with this modifier. Regards, Andreas From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 21:19: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 7BCB1106564A for ; Tue, 13 Jul 2010 21:19:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 077F88FC1C for ; Tue, 13 Jul 2010 21:19:23 +0000 (UTC) Received: from park.js.berklix.net (p549A2EEF.dip.t-dialin.net [84.154.46.239]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6DLJLTs042820; Tue, 13 Jul 2010 21:19:22 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6DLJEjT007271; Tue, 13 Jul 2010 23:19:14 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6DLJ4Qx011409; Tue, 13 Jul 2010 23:19:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007132119.o6DLJ4Qx011409@fire.js.berklix.net> To: John Nielsen From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 13 Jul 2010 13:02:59 EDT." Date: Tue, 13 Jul 2010 23:19:04 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:19:24 -0000 John Nielsen wrote: > On Jul 13, 2010, at 11:48 AM, Ivan Voras wrote: > > > On 07/13/10 06:15, Luigi Rizzo wrote: > > > >> Have fun, it would be great if you could report how it works > >> on fancy devices (iphone, ipad, androids...) > > > > For what it's worth, it doesn't work at all on Android :) (and the > > layout is messed up) > > The front page appears to come up fine on my iPhone (3GS+IOS 4) but > I'm not able to navigate to any other slides (tap "clicking" doesn't > work and I don't have the option of supplying keyboard input). Here is a magicpoint presentation source from 2007, also with HTML output for web preview (as native output is to X screen of laptop connected to a projector) http://www.berklix.com/free/talk/presentations/ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 21:24: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 6126F106566C for ; Tue, 13 Jul 2010 21:24:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 280AB8FC21 for ; Tue, 13 Jul 2010 21:24:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 36F8973098; Tue, 13 Jul 2010 23:35:17 +0200 (CEST) Date: Tue, 13 Jul 2010 23:35:17 +0200 From: Luigi Rizzo To: Larry Baird Message-ID: <20100713213517.GA6266@onelab2.iet.unipi.it> References: <110613.02658.82616@localhost> <20100713163650.86030.qmail@mailgate.gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100713163650.86030.qmail@mailgate.gta.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:24:28 -0000 On Tue, Jul 13, 2010 at 04:36:50PM -0000, Larry Baird wrote: > In article <110613.02658.82616@localhost> you wrote: > > Maybe you all love powerpoint for presentations, but sometimes > > one just needs to put together a few slides, perhaps a few bullets > > or images grabbed around the net, so i was wondering how hard > > would it be to do something that accepts a plain text file > > as input (without a ton of formatting) and lets you do a decent > > slide show, and supports editing the slides on the fly within > > the browser. > > > > Well, it's not too hard: > > > > http://info.iet.unipi.it/~luigi/sttp/ > Haven't used it in years, but I liked it when I used ports/misc/magicpoint. been there, done that: http://info.iet.unipi.it/~luigi/mgpm/ cheers luigi > Port description is: > MagicPoint - an X11 based presentation tool > > MagicPoint is an X11 based presentation tool. It is designed to make > simple presentations easy while to make complicated presentations > possible. Its presentation file (whose suffix is typically .mgp) is > just text so that you can create presentation files quickly with your > favorite editor (e.g. Emacs). > > > > -- > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 21:35: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 A84441065676 for ; Tue, 13 Jul 2010 21:35:54 +0000 (UTC) (envelope-from bf1783@googlemail.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 404858FC1E for ; Tue, 13 Jul 2010 21:35:53 +0000 (UTC) Received: by wwc33 with SMTP id 33so690218wwc.31 for ; Tue, 13 Jul 2010 14:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=pIqYS/aO0ZYHVSBtHsl+m73H36ex/hETVKEKKeV192E=; b=Rn6tsTv5U8RS7euKDwsz+Mb1AAv4g1bO/p7ab9VtEuBG9h5grlO3pZPACS4/0Z9lwc wTBIkmxpV7wOY7Fq27iVIoKP8J9vu3LfNFjwxyDP3Awzb/RRHqgLh4QdRcelugy7EBRC Zx8e31CtDcbGSJPRRVfFaM1CwvPII4jwq9f0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=EWmPghAxEmbSitpX3UDoPRhfNC8THWoZLvDjQJA41Flt324VuistdYGbnhkwOb2Xx9 5M9l+fDVH9SLzX7n8Xs45Z5alYCC/t2FyyeUl0RL4L7e2avKM8BkhjeVruvjTzzAus1p wu1YlIfXePJhcUXO7X3KmnYaJTT8wP65nQ2Nk= MIME-Version: 1.0 Received: by 10.216.232.204 with SMTP id n54mr5691971weq.9.1279056952700; Tue, 13 Jul 2010 14:35:52 -0700 (PDT) Received: by 10.216.171.10 with HTTP; Tue, 13 Jul 2010 14:35:52 -0700 (PDT) Date: Tue, 13 Jul 2010 21:35:52 +0000 Message-ID: From: "b. f." To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:35:54 -0000 >So I'm taking it that the only change of benefit is the attached patch. While you are there, you might also: line 150: s/supercede/supersede/ line 764: s/dependancies/dependencies/ line 2982: s/everthing/everything/ line 6142: s/servicable/serviceable/ b. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 22:58: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 A3D451065674 for ; Tue, 13 Jul 2010 22:58:39 +0000 (UTC) (envelope-from jrytoung@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 3DD328FC13 for ; Tue, 13 Jul 2010 22:58:38 +0000 (UTC) Received: by wwc33 with SMTP id 33so741326wwc.31 for ; Tue, 13 Jul 2010 15:58:38 -0700 (PDT) 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=1Djqu561jGe0EFiOAezuNDbx34e6FVGL4CWIKyF/w60=; b=tlA53IRwjj/RU7S+7yHDG3vfTkWc5HGN1bcpYbcDEhOr1AFQ8jdObEooz+REJ6xdmN PvTtKVeAGY1nywS6nTO4pDxmlfKQnX+xpLZvubFSE04W7TBOqS7/ZPp4W9Woi1uRB6+/ zvCMSZ15jt/W/HrxsF4KeN2Jl2uIcpZ8vQKRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xwo1eYTSvRz/bWkeZOALKCS676uQyDYeRldmzC4iJ5CHJdtb9ryjfSbPKAazukkN6s ZcCeSDS7hzhdVGJUQ0ZcwSjUZMB4zztlfrYx6tgH20bwRhKb3tXZ0S2cJvDxXdUDBMAN REOlS1QOfNsfeuffATcexXrZWV+FO138LUqeU= MIME-Version: 1.0 Received: by 10.227.156.21 with SMTP id u21mr2217541wbw.56.1279060452370; Tue, 13 Jul 2010 15:34:12 -0700 (PDT) Received: by 10.216.68.4 with HTTP; Tue, 13 Jul 2010 15:34:12 -0700 (PDT) Date: Tue, 13 Jul 2010 15:34:12 -0700 Message-ID: From: Jerry Toung To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:58:39 -0000 Hello List, I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2 separate controllers. My I/O throughput tests jumped by ~100MB/sec on both channels, when I commented out the following piece of code from kern/vfs_bio.c void waitrunningbufspace(void) { /* mtx_lock(&rbreqlock); while (runningbufspace > hirunningspace) { ++runningbufreq; msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0); } mtx_unlock(&rbreqlock); */ } so far, I can't observe any side effects of not running it. Am I on a time bomb? Thank you, Jerry From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 23:24: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 96DA11065676 for ; Tue, 13 Jul 2010 23:24:34 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 26DC48FC16 for ; Tue, 13 Jul 2010 23:24:33 +0000 (UTC) Received: from park.js.berklix.net (p549A2EEF.dip.t-dialin.net [84.154.46.239]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6DNOVAM048284; Tue, 13 Jul 2010 23:24:32 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6DNOObd007800; Wed, 14 Jul 2010 01:24:25 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6DNO9Ak013019; Wed, 14 Jul 2010 01:24:19 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007132324.o6DNO9Ak013019@fire.js.berklix.net> To: Luigi Rizzo From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 14 Jul 2010 01:21:24 +0200." Date: Wed, 14 Jul 2010 01:24:09 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 23:24:34 -0000 Whoops I forgot cc hackers so resent. > > Haven't used it in years, but I liked it when I used ports/misc/magicpoint. > > been there, done that: > > http://info.iet.unipi.it/~luigi/mgpm/ > > cheers > luigi Hey That's nice Luigi ! Multicast mgpm ... Hmm so eg BSD tech groups could do presentations eith a bunch of laptops in a room, rather than needing an overhead projector Eh ? Nice ! That I must read more on. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 00:25: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 581D01065670 for ; Wed, 14 Jul 2010 00:25:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 08B0A8FC12 for ; Wed, 14 Jul 2010 00:25:28 +0000 (UTC) Received: by gxk24 with SMTP id 24so4436746gxk.13 for ; Tue, 13 Jul 2010 17:25:28 -0700 (PDT) Received: by 10.101.75.17 with SMTP id c17mr17457563anl.128.1279067126594; Tue, 13 Jul 2010 17:25:26 -0700 (PDT) Received: from papi.localnet ([189.70.227.74]) by mx.google.com with ESMTPS id a12sm71899064and.16.2010.07.13.17.25.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 17:25:25 -0700 (PDT) From: Mario Lobo To: freebsd-hackers@freebsd.org Date: Tue, 13 Jul 2010 21:25:00 +0000 User-Agent: KMail/1.13.3 (FreeBSD/8.1-PRERELEASE; KDE/4.4.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_smNPMippf34UdyY" Message-Id: <201007132125.00541.lobo@bsd.com.br> Subject: ftp-proxy -T tag patch for FBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:25:29 -0000 --Boundary-00=_smNPMippf34UdyY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello; First, forgive me if that's not the right list to post this but I picked the most akin list to the subject I was subscribed to. After all, ftp-proxy is part of the base system now. If any of you is subscribed to a better list for this, please forward it to it. I felt sorry the -T tag option was present in Linux and not on FBSD because I got to a situation where it would really be useful for me. So I decided to stuff my hands on the grease can. What this does is to give the option to put a tag (instead of a queue to the dynamic rules that ftp-proxy creates on the fly. The option to put a queue is nice but it confines the rule to THAT queue only, and you cannot create queues with the same name on different interfaces. You could specify 2 interfaces on the same altq rule, but then again, both interfaces will be confined to the same queue tunings. The -T "tag" option however, besides tagging the packets for the rule, takes the "quick" keyword out of it, so rule processing can continue, to later find a rule that has the keyword "tagged tag" and be sent to any queue you want. A really welcomed flexibility. The application of nat-anchor "ftp-proxy/*" and rdr-anchor "ftp-proxy/*" are still as per man pages. Just make sure you put anchor "ftp-proxy/*" right before the first pass rule rc.conf example --------------------------------------------------- ftpproxy_enable="YES" ftpproxy_flags="-r -v -T ftp_proxy" pf.conf example --------------------------------------------------- # Ftp (it inserts its rules here, like bellow, taken from `pfctl -vv -a ftp-proxy/15780.1 -sr`) anchor "ftp-proxy/*" @0 pass in log inet proto tcp from 172.16.3.145 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 @1 pass out log inet proto tcp from 189.23.180.30 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 # first pass rule of pf.conf pass in log quick on $ext_if inet proto icmp from any to ($ext_if) icmp- type 8 code 0 keep state queue (icmp) --------- then way down there... --------- pass out log quick on $int_if inet proto tcp tagged ftp_proxy keep state queue (ether) --------- even further down, a different match ... --------- pass out log quick on $ext_if inet proto tcp tagged ftp_proxy keep state queue (ftp) ------------------------------------------------------------------- The lines bellow were taken during an ftp session to ftp.openbsd.com from a LAN client station. ================================ # Server [20:14:03] [~]>pfctl -vv -sA ftp-proxy ftp-proxy/15780.1 # Server [20:15:01] [~]> pfctl -vv -a ftp-proxy/15780.1 -sr @0 pass in log inet proto tcp from 172.16.3.145 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 [ Evaluations: 4 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 62 pid 15780 ] @1 pass out log inet proto tcp from 189.12.120.67 to 129.128.5.191 port = 61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0 [ Evaluations: 4 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 62 pid 15780 ] # Server [20:15:11] [~]>pfctl -vv -sA ftp-proxy ftp-proxy/15780.1 # Server [20:15:16] [~]> pfctl -vv -a ftp-proxy/15780.1 -sn @0 nat inet proto tcp from 172.16.3.145 to 129.128.5.191 port = 61076 rtable 0 -> 189.12.120.67 [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 62 pid 15780 ] @0 rdr inet proto tcp from 172.16.3.145 to 129.128.5.191 port = 51973 rtable 0 -> 129.128.5.191 port 61076 [ Evaluations: 6 Packets: 8 Bytes: 1485 States: 0 ] [ Inserted: uid 62 pid 15780 ] # Server [20:15:23] [~]> pfctl -vv -a ftp-proxy/15780.1 -sn pfctl: DIOCGETRULES: Invalid argument # Server [20:16:12] [~]>pfctl -vv -sA ftp-proxy ================================ The nat, rdr and pass rules are correctly created and tagged. Observe the times to see that ftp-proxy removes the rule really fast. To apply the patch, copy it to /usr/src/contrib/pf/ftp-proxy/ then, cd /usr/src/usr.sbin/ftp-proxy/ftp-proxy make [clean] make install Wisdom demands to test it for while before putting into production, but it has been working for me for a couple of weeks. I hope this is useful, because ftp-proxy is really simple. But a great program. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winfoes FREE) --Boundary-00=_smNPMippf34UdyY Content-Type: text/x-patch; charset="ISO-8859-1"; name="ftp-proxy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ftp-proxy.patch" --- ftp-proxy.c.orig 2009-08-03 08:13:06.000000000 +0000 +++ ftp-proxy.c 2010-07-13 12:56:07.000000000 +0000 @@ -116,7 +116,7 @@ struct sockaddr_storage fixed_server_ss, fixed_proxy_ss; char *fixed_server, *fixed_server_port, *fixed_proxy, *listen_ip, *listen_port, - *qname; + *qname, *tname; int anonymous_only, daemonize, id_count, ipv6_mode, loglevel, max_sessions, rfc_mode, session_count, timeout, verbose; extern char *__progname; @@ -601,6 +601,7 @@ loglevel = LOG_NOTICE; max_sessions = 100; qname = NULL; + tname = NULL; rfc_mode = 0; timeout = 24 * 3600; verbose = 0; @@ -609,7 +610,7 @@ id_count = 1; session_count = 0; - while ((ch = getopt(argc, argv, "6Aa:b:D:dm:P:p:q:R:rt:v")) != -1) { + while ((ch = getopt(argc, argv, "6Aa:b:D:dm:P:p:q:R:rt:T:v")) != -1) { switch (ch) { case '6': ipv6_mode = 1; @@ -647,8 +648,9 @@ if (strlen(optarg) >= PF_QNAME_SIZE) errx(1, "queuename too long"); qname = optarg; + tname = NULL; break; - case 'R': + case 'R': fixed_server = optarg; break; case 'r': @@ -659,6 +661,12 @@ if (errstr) errx(1, "timeout %s", errstr); break; + case 'T': + if (strlen(optarg) >= PF_TAG_NAME_SIZE) + errx(1, "tagname too long"); + tname = optarg; + qname = NULL; + break; case 'v': verbose++; if (verbose > 2) @@ -734,7 +742,8 @@ freeaddrinfo(res); /* Initialize pf. */ - init_filter(qname, verbose); + init_filter_q(qname, verbose); + init_filter_t(tname, verbose); if (daemonize) { if (daemon(0, 0) == -1) @@ -1102,6 +1111,6 @@ { fprintf(stderr, "usage: %s [-6Adrv] [-a address] [-b address]" " [-D level] [-m maxsessions]\n [-P port]" - " [-p port] [-q queue] [-R address] [-t timeout]\n", __progname); + " [-p port] [-q queue] [-R address] [-t timeout] [-T tag]\n", __progname); exit(1); } --- filter.c.orig 2007-07-03 12:21:51.000000000 +0000 +++ filter.c 2010-07-13 05:57:20.000000000 +0000 @@ -54,6 +54,7 @@ static struct pfioc_trans_e pfte[TRANS_SIZE]; static int dev, rule_log; static char *qname; +static char *tname; int add_filter(u_int32_t id, u_int8_t dir, struct sockaddr *src, @@ -159,7 +160,7 @@ } void -init_filter(char *opt_qname, int opt_verbose) +init_filter_q(char *opt_qname, int opt_verbose) { struct pf_status status; @@ -179,6 +180,28 @@ errx(1, "pf is disabled"); } +void +init_filter_t(char *opt_tname, int opt_verbose) +{ + struct pf_status status; + + tname = opt_tname; + + if (opt_verbose == 1) + rule_log = PF_LOG; + else if (opt_verbose == 2) + rule_log = PF_LOG_ALL; + + dev = open("/dev/pf", O_RDWR); + if (dev == -1) + err(1, "/dev/pf"); + if (ioctl(dev, DIOCGETSTATUS, &status) == -1) + err(1, "DIOCGETSTATUS"); + if (!status.running) + errx(1, "pf is disabled"); +} + + int prepare_commit(u_int32_t id) { @@ -279,20 +302,29 @@ switch (rs_num) { case PF_RULESET_FILTER: - /* - * pass quick [log] inet[6] proto tcp \ - * from $src to $dst port = $d_port flags S/SA keep state - * (max 1) [queue qname] - */ - pfr.rule.action = PF_PASS; - pfr.rule.quick = 1; - pfr.rule.log = rule_log; - pfr.rule.keep_state = 1; - pfr.rule.flags = TH_SYN; - pfr.rule.flagset = (TH_SYN|TH_ACK); - pfr.rule.max_states = 1; - if (qname != NULL) - strlcpy(pfr.rule.qname, qname, sizeof pfr.rule.qname); + + /* + * pass quick [log] inet[6] proto tcp \ + * from $src to $dst port = $d_port flags S/SA keep state + * (max 1) [queue qname] + */ + + pfr.rule.action = PF_PASS; + pfr.rule.log = rule_log; + pfr.rule.keep_state = 1; + pfr.rule.flags = TH_SYN; + pfr.rule.flagset = (TH_SYN|TH_ACK); + pfr.rule.max_states = 1; + pfr.rule.quick = 1; + + if (qname != NULL) { + strlcpy(pfr.rule.qname, qname, sizeof pfr.rule.qname); + } else { + if (tname != NULL) { + pfr.rule.quick = 0; + strlcpy(pfr.rule.tagname, tname, sizeof pfr.rule.tagname); + } + } break; case PF_RULESET_NAT: /* --- filter.h.orig 2007-07-03 12:21:50.000000000 +0000 +++ filter.h 2010-07-13 05:25:52.000000000 +0000 @@ -26,6 +26,7 @@ struct sockaddr *, u_int16_t); int do_commit(void); int do_rollback(void); -void init_filter(char *, int); +void init_filter_q(char *, int); +void init_filter_t(char *, int); int prepare_commit(u_int32_t); int server_lookup(struct sockaddr *, struct sockaddr *, struct sockaddr *); --- ftp-proxy.8.orig 2009-08-03 08:13:06.000000000 +0000 +++ ftp-proxy.8 2010-07-13 13:22:58.000000000 +0000 @@ -120,7 +120,9 @@ .It Fl q Ar queue Create rules with queue .Ar queue -appended, so that data connections can be queued. +appended, so that data connections can be queued. The -T option +is automatically cancelled. If both are present, the last on the +command line prevails. .It Fl R Ar address Fixed server address, also known as reverse mode. The proxy will always connect to the same server, regardless of @@ -136,6 +138,12 @@ The maximum is 86400 seconds, which is also the default. Do not set this too low, because the control connection is usually idle when large data transfers are taking place. +.It Fl T Ar tag +The filter rules will add tag +.Ar tag +to data connections, and not match quick. This way, alternative rules +that use the tagged key-word can be implemented following the ftp-proxy +anchor that ftp-proxy does not implement itself. .It Fl v Set the 'log' flag on pf rules committed by .Nm . --Boundary-00=_smNPMippf34UdyY-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 00:59:51 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 399D21065670; Wed, 14 Jul 2010 00:59:51 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id ACE478FC1F; Wed, 14 Jul 2010 00:59:50 +0000 (UTC) Received: from park.js.berklix.net (p549A2EEF.dip.t-dialin.net [84.154.46.239]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6E0xk8s049138; Wed, 14 Jul 2010 00:59:47 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6E0jAQe008031; Wed, 14 Jul 2010 02:45:10 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6E0xTdb014154; Wed, 14 Jul 2010 02:59:35 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007140059.o6E0xTdb014154@fire.js.berklix.net> To: Ken Smith From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 12 Jul 2010 13:47:17 EDT." <1278956837.86120.12.camel@bauer.cse.buffalo.edu> Date: Wed, 14 Jul 2010 02:59:29 +0200 Sender: jhs@berklix.com Cc: hackers@freebsd.org, re@freebsd.org Subject: Re: tools/ directory is missing on recent install media. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:59:51 -0000 Hi Ken, cc list Ken Smith wrote: > On Mon, 2010-07-12 at 17:38 +0200, Julian H. Stacey wrote: > > Hi Hackers, > > FreeBSD install media has lost the tools/ directory from recent CDs & DVD= > s: > >=20 > > Quoting > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.h= > tml > > ... to resize your partitions and make space for FreeBSD. The > > tools directory on the CDROM contains two free software > > tools which can carry out this task, namely FIPS and PResizer > > ... > > PartitionMagic and GParted are known to work on NTFS. GParted > > is available on a number of Live CD Linux distributions, > > such as SystemRescueCD. > >=20 > > There is no tools/ directory on recent FreeBSD CDROM disc1.iso & dvd1.iso > > ( or on memstick.img, no suprise as recent ) > > Maybe an older disc1.iso ran out of room, > > & tools/ got dropped & forgotten, not replaced for next release ? > > It wasn't a size issue that made me stop bothering to put the tools/ > directory on, it was more an issue of the tools just not being current > any more and not having an idea of what to replace them with. At > the point I stopped putting them on the media the world had gotten > to the point any tools that can't handle NTFS were useless. Ah, OK. > > re@,=20 > > I suggest consider regularising [scripts ?] to avoid > > inconsistent prepend of .../FreeBSD-... to some image names. > > FreeBSD- is consistently prepended to all the images that have been > generated past the date we decided to start prepending FreeBSD- to > the image names. Images that were generated before we decided > to start prepending FreeBSD- to the image names consistently do > not have FreeBSD- prepended to them... :-) OK :-) > > dvd1.iso script author, > > Please consider adding tools/ > > We might currently be losing some new people, tempted to > > try BSD, who need to first download a Linux image with disk > > partition shrinker (to run under Linux or MS, whatever), > > who then may think: > > "Why now dowload a BSD DVD too, Let's continue > > installing with this Linux DVD in the drive." > > It won't happen in time for 8.1 but I'll try to invest some time > in digging up reasonable replacements for the tools that had been > there. Thanks for passing on your friend's suggestion. Thanks to Gary Jennejohn for finding the URL :-) I removed the 80G NTFS & installed another larger disc (dmesg success report sent to re@). If I learn NTFS crunchers, & have useful comments I'll email you notes. Thanks Ken ! Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 05:06: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 CD35D1065675 for ; Wed, 14 Jul 2010 05:06:03 +0000 (UTC) (envelope-from yanegomi@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 957B18FC1A for ; Wed, 14 Jul 2010 05:06:03 +0000 (UTC) Received: by iwn35 with SMTP id 35so8204121iwn.13 for ; Tue, 13 Jul 2010 22:06:02 -0700 (PDT) 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=IrCmYi490qJPFAJRWs0oyw3449DL1I0NNNPs0cRRKGU=; b=Z1zsAWOkzB0sgxyIbdDCJMw5jTX36zy1JtngdmxStmYsck/6G5bc+UgaNaBrcGChGr LXSorzMqBwIjEoeO3o82ZBDZspEBDpWYUjCFndclAyYaaYSrj0lJY+qjoolLXlYLkK7E yMRPVQXqoYi8WB43ZckZTIEGIZZDfD0s0d6gM= 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=tmfUFBpDPRbTPg2AENeYAFi8YFFKpQcdL6LuTWIvSja/vUsF9Fj0x0mxUK0+aPCU8F z0RI2c+WLTx5ooQpo2tANZPml/r5H9lz60gjXiUQoHx6Wf6A9hzltGtxjDXd3mgPwWtA O7G+WaxeFQrh99y6Imsm4a78FicCwmsDdgnmA= MIME-Version: 1.0 Received: by 10.231.36.134 with SMTP id t6mr16927885ibd.128.1279083962644; Tue, 13 Jul 2010 22:06:02 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Tue, 13 Jul 2010 22:06:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 22:06:02 -0700 Message-ID: From: Garrett Cooper To: bf1783@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix typos in bsd.port.mk and minor logic improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 05:06:03 -0000 On Tue, Jul 13, 2010 at 2:35 PM, b. f. wrote: >>So I'm taking it that the only change of benefit is the attached patch. > > While you are there, you might also: > > line 150: s/supercede/supersede/ > line 764: s/dependancies/dependencies/ > line 2982: s/everthing/everything/ > line 6142: s/servicable/serviceable/ Thanks for the extra eyes on the typos :) .. found a few easy grammatical / spelling errors (eg -> e.g., ie. -> i.e.). I don't want to go much further because I've spotted a number of grammatically incorrect IGNORE error messages, etc. --- /usr/ports/Mk/bsd.port.mk 2010-06-04 01:09:17.000000000 -0700 +++ bsd.port.mk 2010-07-13 22:03:17.000000000 -0700 @@ -147,7 +147,7 @@ # - If set, only use ${MASTER_SITE_BACKUP} for # MASTER_SITES. # CD_MOUNTPTS - List of CDROM mountpoints to look for distfiles under. -# This variable supercedes CD_MOUNTPT, which is +# This variable supersedes CD_MOUNTPT, which is # obsolete. # # Set these if your port should not be built under certain circumstances. @@ -761,7 +761,7 @@ # deinstall-all - Remove all installations with the same PKGORIGIN. # package - Create a package from an _installed_ port. # package-recursive -# - Create a package for a port and _all_ of its dependancies. +# - Create a package for a port and _all_ of its dependencies. # describe - Try to generate a one-line description for each port for # use in INDEX files and the like. # checkpatch - Do a "patch -C" instead of a "patch". Note that it may @@ -988,7 +988,7 @@ # described below except that any line beginning with @comment # is deleted. # SUB_LIST - List of "variable=value" pair for substitution in ${SUB_FILES} -# Some pairs are added by default: eg. PREFIX=${PREFIX} +# Some pairs are added by default, e.g. PREFIX=${PREFIX} # # INSTALLS_SHLIB # - If set, bsd.port.mk will automatically run ldconfig commands @@ -1055,7 +1055,7 @@ # "Name" "Comment" "Icon" "Exec" "Categories" StartupNotify # Rules: # * Only add desktop entries for applications which do not -# require a terminal (ie. X applications). +# require a terminal, i.e. X applications. # * If the upstream distribution already installs .desktop # files, you do not need to use this. # * If you require a more elaborate .desktop file than this @@ -2979,7 +2979,7 @@ PKGFILE?= ${.CURDIR}/${PKGNAME}${PKG_SUFX} .endif -# The "latest version" link -- ${PKGNAME} minus everthing after the last '-' +# The "latest version" link -- ${PKGNAME} minus everything after the last '-' PKGLATESTREPOSITORY?= ${PACKAGES}/Latest PKGBASE?= ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX} LATEST_LINK?= ${PKGBASE} @@ -5465,10 +5465,9 @@ if [ "${CHILD_DEPENDS}" ]; then \ installed=$$(${PKG_INFO} -qO ${PKGORIGIN} 2>/dev/null || \ ${TRUE}); \ - if [ "$$installed" ]; then \ + if [ -n "$$installed" ]; then \ break; \ - fi; \ - if [ -z "$$installed" ]; then \ + else \ installed="${PKGNAME}"; \ fi; \ for pkgname in $$installed; do \ @@ -5511,16 +5510,15 @@ while [ $$\# -gt 1 ]; do \ if [ ! -d "${PORTSDIR}/$$2" ]; then \ shift; \ - continue; \ - fi; \ - if [ "$$dir" = "$$2" ]; then \ + elif [ "$$dir" = "$$2" ]; then \ ${ECHO_CMD} $$1:$$dir; \ if [ -e ${PKG_DBDIR}/$$1/+CONTENTS -a -z "${EXPLICIT_PACKAGE_DEPENDS}" ]; then \ packagelist="$$packagelist ${PKG_DBDIR}/$$1/+CONTENTS"; \ fi; \ break; \ + else \ + shift 2; \ fi; \ - shift 2; \ done; \ done; \ [ -z "$$packagelist" ] || ${AWK} -F '( |:)' 'BEGIN { pkgname="broken_contents" } /@pkgdep / { pkgname=$$2 } /@comment DEPORIGIN:/ { printf "%s:%s\n", pkgname, $$3; pkgname="broken_contents" }' $$packagelist; \ @@ -5541,7 +5539,7 @@ (cd $$dir; ${MAKE} package-noinstall); \ done -# Show missing dependiencies +# Show missing dependencies missing: @_origins=$$(${PKG_INFO} -aoq); \ for dir in $$(${ALL-DEPENDS-LIST}); do \ @@ -6139,7 +6137,7 @@ TMPOPTIONSFILE=$$(mktemp -t portoptions); \ trap "${RM} -f $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \ ${ECHO_CMD} "# This file is auto-generated by 'make config'." > $${TMPOPTIONSFILE}; \ - ${ECHO_CMD} "# No user-servicable parts inside!" >> $${TMPOPTIONSFILE}; \ + ${ECHO_CMD} "# No user-serviceable parts inside!" >> $${TMPOPTIONSFILE}; \ ${ECHO_CMD} "# Options for ${PKGNAME}" >> $${TMPOPTIONSFILE}; \ ${ECHO_CMD} "_OPTIONS_READ=${PKGNAME}" >> $${TMPOPTIONSFILE}; \ for i in $${OPTIONSLIST}; do \ From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 06:09: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 708041065676 for ; Wed, 14 Jul 2010 06:09:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3809B8FC0C for ; Wed, 14 Jul 2010 06:09:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9C7C473098; Wed, 14 Jul 2010 08:19:57 +0200 (CEST) Date: Wed, 14 Jul 2010 08:19:57 +0200 From: Luigi Rizzo To: "Julian H. Stacey" Message-ID: <20100714061957.GA11754@onelab2.iet.unipi.it> References: <201007132324.o6DNO9Ak013019@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007132324.o6DNO9Ak013019@fire.js.berklix.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 06:09:08 -0000 On Wed, Jul 14, 2010 at 01:24:09AM +0200, Julian H. Stacey wrote: > Whoops I forgot cc hackers so resent. > > > > Haven't used it in years, but I liked it when I used ports/misc/magicpoint. > > > > been there, done that: > > > > http://info.iet.unipi.it/~luigi/mgpm/ > > > > cheers > > luigi > > Hey That's nice Luigi ! Multicast mgpm ... > Hmm so eg BSD tech groups could do presentations eith a bunch of laptops > in a room, rather than needing an overhead projector Eh ? Nice ! > That I must read more on. for what matters i had implemented the same thing using a browser-based solution -- the speaker sends its actions through ajax to a simple web server, which logs them. Other listeners also connect to the server which relays events to them as they come. I intend to implement the same thing in this 'sttp' version. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 06:19: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 43A2E1065673 for ; Wed, 14 Jul 2010 06:19:59 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 00F1C8FC15 for ; Wed, 14 Jul 2010 06:19:58 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o6E6Jt5J012903; Tue, 13 Jul 2010 23:19:58 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o6E6JtSe012902; Tue, 13 Jul 2010 23:19:55 -0700 (PDT) Date: Tue, 13 Jul 2010 23:19:55 -0700 (PDT) From: Matthew Dillon Message-Id: <201007140619.o6E6JtSe012902@apollo.backplane.com> To: Jerry Toung References: Cc: freebsd-hackers@freebsd.org Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 06:19:59 -0000 :void :waitrunningbufspace(void) :{ :/* : mtx_lock(&rbreqlock); : while (runningbufspace > hirunningspace) { : ++runningbufreq; : msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0); : } : mtx_unlock(&rbreqlock); :*/ :} : :so far, I can't observe any side effects of not running it. Am I on a time :bomb? : :Thank you, :Jerry You can bump up the related sysctl for hirunningspace if it helps you, no kernel code modification is needed. I recommend setting it to at least 8MB (8388608). sysctl vfs.hirunningspace=8388608 sysctl vfs.lorunningspace=1048576 The waitrunningbufspace() code is designed to protect the system from several degenerate situations and should be left in place. One is where a large backlog of issued WRITE BIOs can accumulate on block devices. Because the related buffers are locked during the I/O, any attempt to access the data via the buffer cache will unnecessarily stall the thread trying to access it. Without a limit several seconds worth of BIOs can accumulate (sometimes tens of seconds worth if the I/O is non-linear). Both accesses to file data and accesses to meta-data can wind up stalling, reducing filesystem peformance. A second issue is that system buffer cache algorithms will become severely inefficient if too much of the buffer cache is held in a locked state. That said, the defaults in bufinit() (lines 623 and 624) are a bit too low for today's high-speed I/O subsystems. They appear to be set to fixed assignments of 512K for lo and 1MB for hi. Even though the defaults are too low they still ought to be enough to maintain maximum I/O throughput since WRITE BIOs usually complete very quickly (they just go into the target device's own write cache and complete). The pipeline should be maintained if the hysteresis is working properly. Perhaps there is something else broken that is causing the hystersis to not work properly. -Matt From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 07:04: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 5ADF21065672 for ; Wed, 14 Jul 2010 07:04:59 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 D64248FC08 for ; Wed, 14 Jul 2010 07:04:58 +0000 (UTC) Received: by bwz12 with SMTP id 12so4383643bwz.13 for ; Wed, 14 Jul 2010 00:04:57 -0700 (PDT) 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=MCHAZE2org+M6fi0qDhlC08rCLxi2RUsfcm8nrHezFc=; b=ruQbSp4gfotw9dtNHfyrALwcMseBmVOkEri2/2AeNFFAnTCe+rKTlo4nQx86GgP5LD U1931GXORID+GQ1nJYElhXzjP/hiKwG1R9qnTDqzaoVH1UC/b8IwK/DpB9Fpyr7hIsWY m9tZXC3Ma5U7baKdpsSY6G9ewne4BQaiiF33c= 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=KIEe/nsju1J1oP+XbGD5SKrkvdcHIbEfHqd6yg88A4u3duEAORtMbC/DoNI5iOSWdG RtoZ84SuOiaNA2mvBoYIHJEPYDmAldOW8NzgP3x0v3QOOfgspZP1Lz7nbSnNbp06XkCU LeOPD7G3nz3FndiPab5NX2ffTMS9YB1CPIxW0= Received: by 10.204.81.146 with SMTP id x18mr5373183bkk.87.1279091097704; Wed, 14 Jul 2010 00:04:57 -0700 (PDT) Received: from ernst.jennejohn.org (p578E2E99.dip.t-dialin.net [87.142.46.153]) by mx.google.com with ESMTPS id y27sm30219844bkw.14.2010.07.14.00.04.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Jul 2010 00:04:57 -0700 (PDT) Date: Wed, 14 Jul 2010 09:04:54 +0200 From: Gary Jennejohn To: Jerry Toung Message-ID: <20100714090454.1177b96b@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.5 (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 Subject: Re: disk I/O, VFS hirunningspace 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: Wed, 14 Jul 2010 07:04:59 -0000 On Tue, 13 Jul 2010 15:34:12 -0700 Jerry Toung wrote: > Hello List, > I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2 > separate > controllers. > My I/O throughput tests jumped by ~100MB/sec on both channels, when I > commented out the > following piece of code from kern/vfs_bio.c > > void > waitrunningbufspace(void) > { > /* > mtx_lock(&rbreqlock); > while (runningbufspace > hirunningspace) { > ++runningbufreq; > msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0); > } > mtx_unlock(&rbreqlock); > */ > } > > so far, I can't observe any side effects of not running it. Am I on a time > bomb? > Rather than commenting out the code try setting the sysctl vfs.hirunningspace to various powers-of-two. Default seems to be 1MB. I just changed it on the command line as a test to 2MB. You can do this in /etc/sysctl.conf. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 11:49: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 A3157106564A for ; Wed, 14 Jul 2010 11:49:08 +0000 (UTC) (envelope-from andrey.zonov@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 329E78FC08 for ; Wed, 14 Jul 2010 11:49:07 +0000 (UTC) Received: by bwz12 with SMTP id 12so4556811bwz.13 for ; Wed, 14 Jul 2010 04:49:07 -0700 (PDT) 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=p2Cf9K3TtILLCweYt5kQzps34Fv5UF1SLoMg+o0sRk4=; b=US/uRY9b3MH5CQUYaogOZUKRNSa4nQi0FufSFNy5U1oq0HXUZ+FAM6aoBW4T8LdQjm mB8VPnSZuUliadpbkUFt5Y3qE3TsfMMAMm9AQYEYJEC10E+uRy9Jc+O8L5B9lxJZtOTU 1hBKyYfWgLnJ/dYJeRf3nD3LI3BncomMMmevo= 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=rbiKMnHhdPmSS3JYt/MtsjmUD5FdjUwh4yffo94ah6VEU4yLT5Tpt5Vqb3zclrXRGN A1zXf7YZg9hKl+7J3YU720i4bWKABmczB2MVv262QXv28UM3d07holybmJEmrSW/00CU jLDCMysWuDh79F/QqQ8pFjj9g+F9ZMqfMJ0GY= MIME-Version: 1.0 Received: by 10.204.146.153 with SMTP id h25mr13205398bkv.86.1279108145350; Wed, 14 Jul 2010 04:49:05 -0700 (PDT) Received: by 10.204.61.145 with HTTP; Wed, 14 Jul 2010 04:49:05 -0700 (PDT) In-Reply-To: <4C2AE37C.5060000@gmail.com> References: <4C2AE37C.5060000@gmail.com> Date: Wed, 14 Jul 2010 15:49:05 +0400 Message-ID: From: Andrey Zonov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: How change process flags from 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: Wed, 14 Jul 2010 11:49:08 -0000 Hi, I resolve this problem (thanks Julian Elischer for his thoughts): === int fd; int cnt; off_t off; void *p; kvm_t *kd; struct kinfo_proc *kip; struct proc *p_mmap; kd = kvm_open(NULL, _PATH_MEM, NULL, O_RDONLY, NULL); kip = kvm_getprocs(kd, KERN_PROC_PID, pid, &cnt); fd = open(_PATH_KMEM, O_RDWR, 0); off = (off_t)((uintptr_t)kip->ki_paddr); p = mmap(0, sizeof(struct proc), PROT_READ | PROT_WRITE, MAP_SHARED, fd, off); p_mmap = (struct proc *)p; p_mmap->p_flag |= P_PROTECTED; ... === I wrote daemon [1] that set P_PROTECTED flag for applications. May be it useful for someone. [1] http://zonov.pp.ru/pprotectd/pprotectd.tbz -- Andrey Zonov 2010/6/30 Andrey Zonov : > Hi, > > I want to set P_PROTECTED flag for some daemons after it start, without > patching application and kernel. > It possible? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 11:49: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 6F9DD1065676 for ; Wed, 14 Jul 2010 11:49:09 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id 3D8B68FC0A for ; Wed, 14 Jul 2010 11:49:09 +0000 (UTC) Received: (qmail 93636 invoked by uid 1000); 14 Jul 2010 11:49:08 -0000 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Date: Wed, 14 Jul 2010 23:49:07 +1200 (NZST) From: Atom Smasher Message-ID: <1007142345320.5546@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt To: freebsd-hackers@freebsd.org X-POM: The Moon is Waxing Crescent (11% of Full) X-Hashcash: 1:20:1007141149:freebsd-hackers@freebsd.org::Meqeb7K6zA7+WjgQ:000000 0000000000000000000000007nnf Subject: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 11:49:09 -0000 http://smasher.org/tmp/zsh-bsd-sysctl-slow.png is there a way to get this information that doesn't take so long? the same info is available on linux via /sys and /proc and on comparable hardware, i can get the info about 100x faster. thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I brainwashed youngsters into doing wrong. I want to say I'm sorry to children everywhere for selling out to concerns who make millions by murdering animals." -- Geoffrey Guiliano, the original Ronald McDonald actor who quit and publicly apologized. http://www.mcspotlight.org/people/interviews/guilliano_geoff.html From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 12:04: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 9A0211065680 for ; Wed, 14 Jul 2010 12:04:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0A98FC18 for ; Wed, 14 Jul 2010 12:04:27 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=zNANCjgXmV0A:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=ObC5tAc8AAAA:8 a=SK0F4O1c5vvvAK1dHYcA:9 a=CWUGavGX5MR_bXaD-J0qKy3VZU0A:4 a=wPNLvfGTeEIA:10 a=mk_83EfxN1QA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1208135615; Wed, 14 Jul 2010 13:54:24 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 14 Jul 2010 13:51:29 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <1007142345320.5546@smasher> In-Reply-To: <1007142345320.5546@smasher> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007141351.29694.hselasky@c2i.net> Cc: Atom Smasher Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 12:04:28 -0000 On Wednesday 14 July 2010 13:49:07 Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png > > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on comparable > hardware, i can get the info about 100x faster. > > thanks... Maybe you are using the sysctls wrong. Did you read man 3 sysctl? --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 12:55: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 C86051065670 for ; Wed, 14 Jul 2010 12:55:07 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id D58DD8FC1B for ; Wed, 14 Jul 2010 12:55:03 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 300FF2A28CDE; Wed, 14 Jul 2010 14:55:03 +0200 (CEST) Date: Wed, 14 Jul 2010 14:55:03 +0200 From: Ed Schouten To: Atom Smasher Message-ID: <20100714125503.GG1742@hoeg.nl> References: <1007142345320.5546@smasher> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XLWMkxR+mZNQ4WTO" Content-Disposition: inline In-Reply-To: <1007142345320.5546@smasher> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 12:55:07 -0000 --XLWMkxR+mZNQ4WTO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png >=20 > is there a way to get this information that doesn't take so long? >=20 > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. So what about other sysctls? Is it just these sysctls? It may be the case that these values are not simply read from some variable in the kernel, but really performs some hardware calls. Still, 436 msec is quite a lot of time. --=20 Ed Schouten WWW: http://80386.nl/ --XLWMkxR+mZNQ4WTO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw9s6cACgkQ52SDGA2eCwV7agCeKNKu7Cj//giRPWH9aOsK5+mV eb8AnAsT4RRxb17o688UnmmXNEMrgKt7 =jmCn -----END PGP SIGNATURE----- --XLWMkxR+mZNQ4WTO-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 13:34:01 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 E69901065676 for ; Wed, 14 Jul 2010 13:34:01 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id A81298FC17 for ; Wed, 14 Jul 2010 13:34:01 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-164-138.rz.uni-karlsruhe.de [141.3.164.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9FF058A21A9; Wed, 14 Jul 2010 15:34:00 +0200 (CEST) Message-ID: <4C3DBCC7.8060500@bsdforen.de> Date: Wed, 14 Jul 2010 15:33:59 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.10) Gecko/20100627 Thunderbird/3.0.5 MIME-Version: 1.0 To: Atom Smasher References: <1007142345320.5546@smasher> In-Reply-To: <1007142345320.5546@smasher> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 13:34:02 -0000 On 14/07/2010 13:49, Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png Why use a screen shot here? > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on comparable > hardware, i can get the info about 100x faster. It probably depends on your BIOS. This is the same call on my system: % time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 100 -1 0 sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 0.00s user 0.01s system 96% cpu 0.013 total As you can see 33 times faster than on your system. I agree that 0.413 seconds is too long, but I don't think it makes sense to call this value more frequently than every 30 seconds. So I'd say it's more of an annoyance than a real problem. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 14:48:16 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 A9DF1106567E for ; Wed, 14 Jul 2010 14:48:16 +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 6C3B08FC14 for ; Wed, 14 Jul 2010 14:48:16 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id F1D6666784 for ; Wed, 14 Jul 2010 16:48:13 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 153951509E; Wed, 14 Jul 2010 16:41:54 +0200 (CEST) Date: Wed, 14 Jul 2010 16:41:54 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100714144154.GB2186@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1007142345320.5546@smasher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1007142345320.5546@smasher> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:48:16 -0000 On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. Are you sure that Linux is not just caching the data? I know of at least one system where it takes more than 100ms to query the battery state due to extremely slow hardware, I wouldn't be surprised if you can do worse. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 14:52: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 39C48106566C for ; Wed, 14 Jul 2010 14:52:10 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id E66028FC18 for ; Wed, 14 Jul 2010 14:52:09 +0000 (UTC) Received: (qmail 61799 invoked by uid 1000); 14 Jul 2010 14:52:08 -0000 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Thu, 15 Jul 2010 02:49:22 +1200 (NZST) From: Atom Smasher In-Reply-To: <4C3DBCC7.8060500@bsdforen.de> Message-ID: <1007150245460.5546@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <1007142345320.5546@smasher> <4C3DBCC7.8060500@bsdforen.de> To: Dominic Fandrey X-POM: The Moon is Waxing Crescent (12% of Full) X-Hashcash: 1:20:1007141449:kamikaze@bsdforen.de::F8iOPqhN3wAYnKHV:0000000000000 0000000000000000000000000FX9 X-Hashcash: 1:20:1007141449:freebsd-hackers@freebsd.org::lAz0mYknZTnFgdch:000000 00000000000000000000000023EM Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:52:10 -0000 On Wed, 14 Jul 2010, Dominic Fandrey wrote: > It probably depends on your BIOS. This is the same call on my > system: > % time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state > 100 > -1 > 0 > sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 0.00s user 0.01s system 96% cpu 0.013 total > > As you can see 33 times faster than on your system. =================== next time i reboot this laptop, i'll stick an ubuntu CD in and see if it takes as long to get the info. i guess if it does take as long, then we can blame the hardware. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Since I entered politics, I have chiefly had men's views confided to me privately. Some of the biggest men in the United States, in the Field of commerce and manufacture, are afraid of something. They know that there is a power somewhere so organized, so subtle, so watchful, so interlocked, so complete, so pervasive, that they better not speak above their breath when they speak in condemnation of it." -- Woodrow Wilson, The New Freedom (1913) From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 15: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 D82A7106566B for ; Wed, 14 Jul 2010 15:52:58 +0000 (UTC) (envelope-from ath@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id B00008FC17 for ; Wed, 14 Jul 2010 15:52:57 +0000 (UTC) Received: from NCES01.mj.niksun.com (nces01.mj.niksun.com [10.25.8.17]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id o6EFPWeb042035 for ; Wed, 14 Jul 2010 11:25:33 -0400 (EDT) (envelope-from ath@niksun.com) Received: from nces01.mj.niksun.com ([10.25.8.17]) by NCES01.mj.niksun.com ([10.25.8.17]) with mapi; Wed, 14 Jul 2010 11:25:31 -0400 From: Andrew Heybey To: "freebsd-hackers@freebsd.org" Date: Wed, 14 Jul 2010 11:25:29 -0400 Thread-Topic: 8.1RC2 amd64 machine check question Thread-Index: AcsjaMtWZG4bgY/oSsWxS3hDJRWGng== Message-ID: <6E83197B-9DD5-4C7E-846D-AD176C25464D@niksun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.95.3 at anuket.mj.niksun.com X-Virus-Status: Clean Subject: 8.1RC2 amd64 machine check 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: Wed, 14 Jul 2010 15:52:58 -0000 Got the following in /var/log/messages on my one-week-old amd64 box running= 8.1RC2: Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0000000000000106, Status 0= x0000000000000000 Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, API= C ID 0 Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c I read through sys/amd64/amd64/mca.c and it seems to be a correctable error= on my L3 cache, but I am not 100% sure I am interpreting it correctly. Motherboard is an ASUS M4A785TD-V EVO w/ 2x 2GB ECC RAM and and an AMD Phen= om X2: FreeBSD 8.1-RC2 #0: Tue Jun 29 20:21:55 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X2 550 Processor (3113.67-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x100f43 Family =3D 10 Model =3D 4 S= tepping =3D 3 Features=3D0x178bfbff Features2=3D0x802009 AMD Features=3D0xee500800 AMD Features2=3D0x37ff TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 4112510976 (3921 MB) ACPI APIC Table: <041510 APIC1115> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 My questions are: 1. Did I interpret the message correctly (correctable error on my L3 cache)= ? 2. Is it anything to worry about? Or is this just one of those things that= happens but now it gets logged whereas before I was blissfully ignorant? thanks, andrew From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 16:06: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 D96D31065673 for ; Wed, 14 Jul 2010 16:06:29 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id A05E78FC17 for ; Wed, 14 Jul 2010 16:06:29 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6EG6Sqx027058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2010 11:06:28 -0500 (CDT) (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 o6EG6Squ071035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2010 11:06:28 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6EG6SFY071034 for freebsd-hackers@freebsd.org; Wed, 14 Jul 2010 11:06:28 -0500 (CDT) (envelope-from dan) Date: Wed, 14 Jul 2010 11:06:28 -0500 From: Dan Nelson To: freebsd-hackers@freebsd.org Message-ID: <20100714160628.GB5485@dan.emsphone.com> References: <1007142345320.5546@smasher> <20100714144154.GB2186@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100714144154.GB2186@britannica.bec.de> X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 14 Jul 2010 11:06:28 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 16:06:29 -0000 In the last episode (Jul 14), Joerg Sonnenberger said: > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: > > the same info is available on linux via /sys and /proc and on comparable > > hardware, i can get the info about 100x faster. > > Are you sure that Linux is not just caching the data? I know of at least > one system where it takes more than 100ms to query the battery state due > to extremely slow hardware, I wouldn't be surprised if you can do worse. I have an old Dell laptop where it takes almost a full second to fetch battery data via ACPI. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 16:27:02 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 AD0C7106567D for ; Wed, 14 Jul 2010 16:27:02 +0000 (UTC) (envelope-from jrytoung@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 41CEA8FC24 for ; Wed, 14 Jul 2010 16:27:01 +0000 (UTC) Received: by wwc33 with SMTP id 33so1409945wwc.31 for ; Wed, 14 Jul 2010 09:27:01 -0700 (PDT) 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=YmW54gwNAz67MEkPiwsJnDDjH6//iPHkbqtXoyDt2To=; b=kJVcSd94IF9gm9lb6GGtZcKGHIBObvvmnMy5vq0JHZVuIgKFzC1CGNsgIZRt+4oncX Az9WDZcwW35VNG39aKYjTMhZP5fYPGvSmjXNCB2YjDqZiDQy08cROAe69Bora3cKdDUp 8n35GCAApMXTB3rbpyHk2OIhRrDQWJ7RtqQfI= 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=vWQz7ITpDPnE8mRk1pEf63xY3egT+ZfXFKSAINOjxRKLI1bdFdQlV7dlalzD+7oy9w 5FmjeVHVqi0JYfWzGWr53q2GHv2TNGSaUkm9VdikFNI1BT6tEjhYfMoYZob5SJk9k2C3 MRS+2Zg3G9YcJGkVIDF+X7of/GeNQzHcpSgCU= MIME-Version: 1.0 Received: by 10.227.138.5 with SMTP id y5mr2348902wbt.204.1279124821014; Wed, 14 Jul 2010 09:27:01 -0700 (PDT) Received: by 10.216.68.4 with HTTP; Wed, 14 Jul 2010 09:27:00 -0700 (PDT) In-Reply-To: <20100714090454.1177b96b@ernst.jennejohn.org> References: <20100714090454.1177b96b@ernst.jennejohn.org> Date: Wed, 14 Jul 2010 09:27:00 -0700 Message-ID: From: Jerry Toung To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 16:27:02 -0000 On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn wrote: > > > Rather than commenting out the code try setting the sysctl > vfs.hirunningspace to various powers-of-two. Default seems to be > 1MB. I just changed it on the command line as a test to 2MB. > > You can do this in /etc/sysctl.conf. > > thank you all, that did it. The settings that Matt recommended are giving the same numbers I had with the code commented out. I was concerned that the lock or msleep may be a problem. Jerry From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 17:55: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 0248C106566B for ; Wed, 14 Jul 2010 17:55:09 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id BA5308FC15 for ; Wed, 14 Jul 2010 17:55:08 +0000 (UTC) Received: (qmail 83765 invoked by uid 1000); 14 Jul 2010 15:08:20 -0000 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Thu, 15 Jul 2010 03:08:04 +1200 (NZST) From: Atom Smasher In-Reply-To: <20100714144154.GB2186@britannica.bec.de> Message-ID: <1007150303431.5546@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <1007142345320.5546@smasher> <20100714144154.GB2186@britannica.bec.de> To: Joerg Sonnenberger X-POM: The Moon is Waxing Crescent (12% of Full) X-Hashcash: 1:20:1007141508:joerg@britannica.bec.de::ufj02bffTJfI7jjr:0000000000 0000000000000000000000003uNe X-Hashcash: 1:20:1007141508:freebsd-hackers@freebsd.org::Vj55QvquCHkNTCcj:000000 000000000000000000000000FBW3 Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 17:55:09 -0000 On Wed, 14 Jul 2010, Joerg Sonnenberger wrote: > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: >> the same info is available on linux via /sys and /proc and on >> comparable hardware, i can get the info about 100x faster. > > Are you sure that Linux is not just caching the data? I know of at least > one system where it takes more than 100ms to query the battery state due > to extremely slow hardware, I wouldn't be surprised if you can do worse. ============== i don't know if linux is caching it. if it is, then freebsd should at least have an option to do the same. the real test will be trying linux on the freebsd hardware and freebsd on the linux hardware. i don't know when i'll get a chance to do it, but i'll update the list with details when it happens. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Anyone who doubts that terrorists could smuggle a nuclear warhead into New York City should note that they could always wrap it in a bale of marijuana." -- Graham Allison, The Boston Globe 27 October 1999 From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 18:35: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 62D51106566C for ; Wed, 14 Jul 2010 18:35:10 +0000 (UTC) (envelope-from amvandemore@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 1D90E8FC17 for ; Wed, 14 Jul 2010 18:35:09 +0000 (UTC) Received: by gwb15 with SMTP id 15so4677555gwb.13 for ; Wed, 14 Jul 2010 11:35:09 -0700 (PDT) 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=LZ2w01k0M0n6AWJKB/Elp6kymCX6QjEb/P5nO71kPEA=; b=jXxjVSO9PUo05MhGPAllJox/UDm9loAdydPiHf4tcFd45PhfY8rIqlfYNSephKQLNP VBZRQokKPrYv36Jl+wCZE9ZipgwXfU7DW+k6obH86sUATVcb0PQ1dKo+htscoc314pNN z0JYzNA3IOKauOugYpVqn9V3L75DFhNNDzNAQ= 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=ulCxgVZWDayylNaGvRDHk0FYT5eKZtvmvvUZD+GkGpoePvWrUJpGDy8Xm/eDGStfei UqRP6RdREmcW+1U9k3pZnDLZs/3RrHnt1HgKfE80sY9EAfh1fvlnTZRo01rR6R0H7FrE rCjKrblcUcDFpJRK/mEbVuK/L3hmYPi2Lc0Yg= MIME-Version: 1.0 Received: by 10.90.96.17 with SMTP id t17mr9672130agb.33.1279132498633; Wed, 14 Jul 2010 11:34:58 -0700 (PDT) Received: by 10.229.86.12 with HTTP; Wed, 14 Jul 2010 11:34:58 -0700 (PDT) In-Reply-To: <1007150303431.5546@smasher> References: <1007142345320.5546@smasher> <20100714144154.GB2186@britannica.bec.de> <1007150303431.5546@smasher> Date: Wed, 14 Jul 2010 13:34:58 -0500 Message-ID: From: Adam Vande More To: Atom Smasher Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Joerg Sonnenberger Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:35:10 -0000 On Wed, Jul 14, 2010 at 10:08 AM, Atom Smasher wrote: > On Wed, 14 Jul 2010, Joerg Sonnenberger wrote: > > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: >> >>> the same info is available on linux via /sys and /proc and on comparable >>> hardware, i can get the info about 100x faster. >>> >> >> Are you sure that Linux is not just caching the data? I know of at least >> one system where it takes more than 100ms to query the battery state due to >> extremely slow hardware, I wouldn't be surprised if you can do worse. >> > ============== > > i don't know if linux is caching it. if it is, then freebsd should at least > have an option to do the same. the real test will be trying linux on the > freebsd hardware and freebsd on the linux hardware. i don't know when i'll > get a chance to do it, but i'll update the list with details when it > happens. > FWIW, my old dell > /usr/bin/time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 100 -1 0 0.01 real 0.00 user 0.01 sys -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 19:54: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 37342106566B for ; Wed, 14 Jul 2010 19:54:24 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1DCB28FC1A for ; Wed, 14 Jul 2010 19:54:23 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta09.emeryville.ca.mail.comcast.net with comcast id hoY01e0011vN32cA9vuPfn; Wed, 14 Jul 2010 19:54:23 +0000 Received: from comcast.net ([98.203.142.76]) by omta22.emeryville.ca.mail.comcast.net with comcast id hvuL1e00D1f6R9u8ivuM1B; Wed, 14 Jul 2010 19:54:23 +0000 Received: by comcast.net (sSMTP sendmail emulation); Wed, 14 Jul 2010 12:54:20 -0700 Date: Wed, 14 Jul 2010 12:54:20 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100714195419.GA49938@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org, Luigi Rizzo , hackers@freebsd.org References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100713131706.GA2459@straylight.ringlet.net> X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org, Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 19:54:24 -0000 On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: > >Just as an aside, though - are you aware of Eric Meyer's S5, >also available in your friendly neighbourhood Ports Collection >as textproc/s5? :) > Yet another alternative for creating presentations is misc/xsw. Or, if you're an old-school textmode type, misc/tpp. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 20:04: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 5B9AD106568E for ; Wed, 14 Jul 2010 20:04:07 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 424C38FC1F for ; Wed, 14 Jul 2010 20:04:07 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id hnny1e0031u4NiLADw46uY; Wed, 14 Jul 2010 20:04:06 +0000 Received: from comcast.net ([98.203.142.76]) by omta21.emeryville.ca.mail.comcast.net with comcast id hw441e0071f6R9u8hw44d7; Wed, 14 Jul 2010 20:04:06 +0000 Received: by comcast.net (sSMTP sendmail emulation); Wed, 14 Jul 2010 13:04:03 -0700 Date: Wed, 14 Jul 2010 13:04:03 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100714200403.GB49938@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org, Luigi Rizzo , hackers@freebsd.org References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> <20100714195419.GA49938@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100714195419.GA49938@comcast.net> X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org, Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 20:04:07 -0000 On Wed 14 Jul 2010 at 12:54:20 PDT Charlie Kester wrote: >On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: >> >>Just as an aside, though - are you aware of Eric Meyer's S5, >>also available in your friendly neighbourhood Ports Collection >>as textproc/s5? :) >> > >Yet another alternative for creating presentations is misc/xsw. > >Or, if you're an old-school textmode type, misc/tpp. and if you're really oldschool and troff is your thing, you might be interested in http://repo.cat-v.org/troff-slider/ :) From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 20:05:07 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 1CF23106566C for ; Wed, 14 Jul 2010 20:05:07 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 0377B8FC23 for ; Wed, 14 Jul 2010 20:05:07 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta03.emeryville.ca.mail.comcast.net with comcast id hpWU1e0011u4NiLA3w460n; Wed, 14 Jul 2010 20:04:06 +0000 Received: from comcast.net ([98.203.142.76]) by omta21.emeryville.ca.mail.comcast.net with comcast id hw441e0071f6R9u8hw44d7; Wed, 14 Jul 2010 20:04:06 +0000 Received: by comcast.net (sSMTP sendmail emulation); Wed, 14 Jul 2010 13:04:03 -0700 Date: Wed, 14 Jul 2010 13:04:03 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100714200403.GB49938@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org, Luigi Rizzo , hackers@freebsd.org References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> <20100714195419.GA49938@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100714195419.GA49938@comcast.net> X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org, Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 20:05:07 -0000 On Wed 14 Jul 2010 at 12:54:20 PDT Charlie Kester wrote: >On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: >> >>Just as an aside, though - are you aware of Eric Meyer's S5, >>also available in your friendly neighbourhood Ports Collection >>as textproc/s5? :) >> > >Yet another alternative for creating presentations is misc/xsw. > >Or, if you're an old-school textmode type, misc/tpp. and if you're really oldschool and troff is your thing, you might be interested in http://repo.cat-v.org/troff-slider/ :) From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 20:07:34 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 5741E10656E3 for ; Wed, 14 Jul 2010 20:07:34 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 3DEEA8FC12 for ; Wed, 14 Jul 2010 20:07:34 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta09.emeryville.ca.mail.comcast.net with comcast id hr7B1e0061vN32cA9vuPfm; Wed, 14 Jul 2010 19:54:23 +0000 Received: from comcast.net ([98.203.142.76]) by omta22.emeryville.ca.mail.comcast.net with comcast id hvuL1e00D1f6R9u8ivuM1B; Wed, 14 Jul 2010 19:54:23 +0000 Received: by comcast.net (sSMTP sendmail emulation); Wed, 14 Jul 2010 12:54:20 -0700 Date: Wed, 14 Jul 2010 12:54:20 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100714195419.GA49938@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org, Luigi Rizzo , hackers@freebsd.org References: <20100713041514.GA93662@onelab2.iet.unipi.it> <20100713131706.GA2459@straylight.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100713131706.GA2459@straylight.ringlet.net> X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org, Luigi Rizzo Subject: Re: an alternative to powerpoint X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 20:07:34 -0000 On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: > >Just as an aside, though - are you aware of Eric Meyer's S5, >also available in your friendly neighbourhood Ports Collection >as textproc/s5? :) > Yet another alternative for creating presentations is misc/xsw. Or, if you're an old-school textmode type, misc/tpp. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 22:09: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 41E76106568F for ; Wed, 14 Jul 2010 22:09:52 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id 090968FC14 for ; Wed, 14 Jul 2010 22:09:51 +0000 (UTC) Received: (qmail 5830 invoked by uid 1000); 14 Jul 2010 13:09:49 -0000 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Thu, 15 Jul 2010 01:09:47 +1200 (NZST) From: Atom Smasher In-Reply-To: <20100714125503.GG1742@hoeg.nl> Message-ID: <1007150056561.5546@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <1007142345320.5546@smasher> <20100714125503.GG1742@hoeg.nl> To: Ed Schouten X-POM: The Moon is Waxing Crescent (11% of Full) X-Hashcash: 1:20:1007141309:ed@80386.nl::nu8tSHIkIChnv2wi:002xQC X-Hashcash: 1:20:1007141309:freebsd-hackers@freebsd.org::zTxrdNfWbBmNsMO8:000000 0000000000000000000000000qFM Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:09:52 -0000 On Wed, 14 Jul 2010, Ed Schouten wrote: > So what about other sysctls? Is it just these sysctls? It may be the > case that these values are not simply read from some variable in the > kernel, but really performs some hardware calls. Still, 436 msec is > quite a lot of time. =================== getting the same info on a linux box from /sys/class/power_supply/BAT0/* takes <10ms, even when reading all 32 files in the directory. meanwhile, on freebsd, the other hw.acpi.* variables i've tried are either reasonably fast (2-7 mS) or as slow, but no slower. at least not the handful that i've tried. hw.acpi.battery.* are the ones i'm actually interested in. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "About all you can do in life is be who you are. Some people will love you for you. Most will love you for what you can do for them, and some won't like you at all." -- Rita Mae Brown From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 00:31: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 3E25C106564A for ; Thu, 15 Jul 2010 00:31:50 +0000 (UTC) (envelope-from swell.k@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 BC51E8FC15 for ; Thu, 15 Jul 2010 00:31:49 +0000 (UTC) Received: by bwz12 with SMTP id 12so138009bwz.13 for ; Wed, 14 Jul 2010 17:31:48 -0700 (PDT) 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=kTCUCC07z0bLu4V/pTR+8WT8nfgxVhvb2qNlQtyhvc8=; b=pCQs4Evm2trbzrpYGcdKIRfxIGZK1Ct9ADc89lKoKukFftzMw0K0Rko6cO50EQ9Gpm 3BbVstffeSaJgqg2K93gmrZwwaSyIv+BTtsVomcPC0Q6xM5QkxzXNhVjgib1YZJrHYXG mDjUhD+WuW5lxjioY9rtHIYauATpyuJjwAUEM= 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=mcJUpGrnwL8CPUVjASZvpifBmqm7T1mvrXr2vhluG/11QUylX5qMPnWgD66O0f8GVj gdrGHHBOi9DxIJPGHQlFWQ5zWXBa3uBnDFAX5FTpbcefvpTZE9R0QAAoR1YLSFOuTjLu 15c9IfN/HdC6ViEm3s5NhxjBpBv+mD8e4jHRM= Received: by 10.204.0.83 with SMTP id 19mr14015897bka.67.1279152424758; Wed, 14 Jul 2010 17:07:04 -0700 (PDT) Received: from localhost ([88.198.6.155]) by mx.google.com with ESMTPS id y2sm3098455bkx.8.2010.07.14.17.06.56 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Jul 2010 17:07:03 -0700 (PDT) From: Anonymous To: Atom Smasher References: <1007142345320.5546@smasher> Date: Thu, 15 Jul 2010 04:06:44 +0400 In-Reply-To: <1007142345320.5546@smasher> (Atom Smasher's message of "Wed, 14 Jul 2010 23:49:07 +1200 (NZST)") Message-ID: <8639vl4nhn.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; charset=us-ascii X-Mailman-Approved-At: Thu, 15 Jul 2010 03:55:08 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl way too slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:31:50 -0000 Atom Smasher writes: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png > > is there a way to get this information that doesn't take so long? If you only need sysctl values for fancy prompt then cache them inside variables, e.g. PROMPT='($hw_acpi_battery_life, $hw_acpi_battery_time, $hw_acpi_battery_state) %# ' PERIOD=30 setopt promptsubst periodic_functions+=(sysctl-to-var) sysctl-to-var() { set -- hw.acpi.battery. for i in $(sysctl -N $@); do eval ${i:gs/./_/:gs/%//}='$(sysctl -n $i)' done } To not pollute global scope using one associative array for sysctls may be better. > > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. > > thanks... From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 10:43:50 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 59498106566C for ; Thu, 15 Jul 2010 10:43:50 +0000 (UTC) (envelope-from uzunchev.stanislav@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 E199C8FC16 for ; Thu, 15 Jul 2010 10:43:49 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 13so337354fxm.13 for ; Thu, 15 Jul 2010 03:43:49 -0700 (PDT) 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=zWF2bXZkXJ3XLJp1mhKih08qmy++LTYrHlXkuJ5ctVM=; b=wPGqlRYOnUNfNBumpR4yvUCWClaTSj3uhNZfo+qUM2aVmVcZuz++rwSTRmaw8uJSOG /C1RSRX7P8OUKV+NO/+su+A/IWfXV/0VTkZjuRbgacksEWhbIfaCe91tB9CVrbd9CWaY uoq290lXnvib7vQIwESM5tC+xzhdIDjrOcWTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bCXzKAQ94nV+iSmuPolXkEdL0OTXMuyBhKI8wwXG71wSboiGshBnog5d4nuirKP9xC PTFHndpDKwiT9ZBti3wOaIaHRh5+3OYeUbgFL2Fcea6f8AbKqUCBgXl206OKEq9/au44 Mkn0/p7gyhv83DBc0HW9vjOqBrnz4VyJyuUTQ= MIME-Version: 1.0 Received: by 10.103.240.8 with SMTP id s8mr3024491mur.78.1279188747278; Thu, 15 Jul 2010 03:12:27 -0700 (PDT) Received: by 10.103.170.15 with HTTP; Thu, 15 Jul 2010 03:12:27 -0700 (PDT) Date: Thu, 15 Jul 2010 13:12:27 +0300 Message-ID: From: Stanislav Uzunchev To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: libjail issues. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 10:43:50 -0000 Hi, all. I have found something very strange to me... It is a problem with static allocating size of buffer where jail param is going to be coppied, using jail_getv function from the libjails. Well for example: buff[size]; jail_getv(0, "name", "1", "host.hostname", buff, NULL); the result for size = 64; is bsnmp.test, size = 257; is bsnmp.test, size = 256; is bs1 ? #sysctl -a | grep "security.jail.param.host.hostname:" 256 #jls JID Hostname 1 bsnmp.test #jls -n | grep "bs1" returns no match. This is really confusing me. Also i will take suggestions, what is the best way, to get and set all value/params using the jailparam struct. I am trying first to set the name or jid, and after that getting the values for the rest parameters with jail_getv, but i face some problems setting jp_value since it is type (void *). From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 10:56: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 063A6106564A for ; Thu, 15 Jul 2010 10:56:49 +0000 (UTC) (envelope-from kalash.nainwal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3E728FC17 for ; Thu, 15 Jul 2010 10:56:48 +0000 (UTC) Received: by vws19 with SMTP id 19so1256163vws.13 for ; Thu, 15 Jul 2010 03:56:48 -0700 (PDT) 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=buVoQfQ9DR78qbKxLMWv4Jrqry1epNjPdun3kIuFCx8=; b=WPqRKmutt57agVdtLh4lQYUycY84VovfLMuhzvZFBGmh7PPkixonYJNcz9N0Mq8foe 2xA3mACM1TFkgtX30E3ivZwHcoQk2DGuNN3tdEu9SUVxXQTcqOL1RN9RYbIeMBVo7CYr 7U2ZrZlPK006FhlHmgBC63zBi4G7md4jpLjv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lC//Lt76Yt2v4/jRma9albxpaZpawf9OctzJD60XgqpA2EeBLNLeQGqlMieOBW72Et ZbQW++l2IL4A6GTzRb7ZV8SSBzkqg4ruNEoPB7ieUCOdwXFZFYAti+Dm0VLHFpi/oLv1 03rSBGDdwZPR24cADe56NxJrIG5CVZvFaTsfI= MIME-Version: 1.0 Received: by 10.220.164.129 with SMTP id e1mr2192737vcy.124.1279189733277; Thu, 15 Jul 2010 03:28:53 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Thu, 15 Jul 2010 03:28:53 -0700 (PDT) Date: Thu, 15 Jul 2010 15:58:53 +0530 Message-ID: From: kalash nainwal To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 10:56:49 -0000 Hi, I want to allocate one (or more) pages in kernel space. I'm not sure what is the api in freebsd (something which is similar to __get_free_pages() of linux). Would malloc(4096, ...) guarantee that the returned address is aligned on page boundary? Thanks and regards, -Kalash From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 10:25: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 A052F106567F for ; Thu, 15 Jul 2010 10:25:59 +0000 (UTC) (envelope-from kcnainwal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57AEF8FC13 for ; Thu, 15 Jul 2010 10:25:58 +0000 (UTC) Received: by vws19 with SMTP id 19so1221165vws.13 for ; Thu, 15 Jul 2010 03:25:58 -0700 (PDT) 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=nU+L3eQA5V6BTYg1h+BWNgyf1cnDi00qBe57rScMMJU=; b=w4//sVDj9zTIcxRWUbOHizbfq0sQsSyLfzovWyIk3WjeQUE1GZ3Ohet5EgnxnFnp4d J2pQGcltijHsnIBfBilHeryMhG9LMM+ibdlubIr+YiwcZJ1fTUk3d1SwTxGqU9fwnE86 deZmYpqRpXNYoPhfMJs+pia4Ifoi2FSBiW08c= 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=mAdfQXcCHjIlu6dcrt83290R8J1lEWvYUI3zmqj58q2aNqTrDP1UDSoMKGto2alksj 2xF8NmwBHU/7w0EHT6heSqr/6JMm4VLDl4RU+IktVhH0X0mi5UlP3V35CDAOQouZ/+SX vs/ECM84tS6YZYh4VH/krb5YwTedcJ8SYAJQw= MIME-Version: 1.0 Received: by 10.220.121.144 with SMTP id h16mr9515675vcr.159.1279187790346; Thu, 15 Jul 2010 02:56:30 -0700 (PDT) Received: by 10.220.163.198 with HTTP; Thu, 15 Jul 2010 02:56:30 -0700 (PDT) Date: Thu, 15 Jul 2010 15:26:30 +0530 Message-ID: From: kc nainwal To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Thu, 15 Jul 2010 10:59:48 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kc nainwal Subject: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 10:25:59 -0000 Hi, I want to allocate one (or more) pages in kernel space. I'm not sure what is the api in freebsd (something which is similar to __get_free_pages() of linux). Would malloc(4096, ...) guarantee that the returned address is aligned on page boundary? Thanks and regards, -Kalash From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 11:25:32 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 4D80A1065679; Thu, 15 Jul 2010 11:25:31 +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 10D788FC21; Thu, 15 Jul 2010 11:25:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29185; Thu, 15 Jul 2010 14:25:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OZMZD-0001hZ-U5; Thu, 15 Jul 2010 14:25:28 +0300 Message-ID: <4C3EF026.7090706@freebsd.org> Date: Thu, 15 Jul 2010 14:25:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> In-Reply-To: <4C39B7DE.3030100@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:25:32 -0000 on 11/07/2010 15:23 Andriy Gapon said the following: > on 11/07/2010 14:54 Andriy Gapon said the following: >> For completeness, here is a patch that simply drops the inline assembly and the >> comment about it, and GCC-generated assembly and its diff: >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff >> >> As was speculated above, the only thing really changed is section alignment >> (from 128 to 4). > > After making the above analysis I wondered why we require set_pcpu section > alignment at all. After all, it's not used as loaded, data from the section > gets copied into special per-cpu memory areas. So, logically, it's those areas > that need to be aligned, not the section. > > svn log and google quickly pointed me to this excellent analysis and explanation > by bz (thanks again!): > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > > Summary: this alignment is needed to work around a bug in GNU binutils ld for > __start_SECNAME placement. > > As explained by bz, ld internally generates an equivalent of the following > linker script: > ... > __start_pcpu_set = ALIGN(NN); > pcpu_set : { > ... > } > __stop_pcpu_set = .; > > Where NN is an alignment of the first _input_ pcpu_set section found in > whichever .o file happens to be first. Not the resulting alignment of pcpu_set > _output_ section. > Alignment requirement of input sections is based on largest alignment > requirement of section's members. So if section is empty then the required > alignment is 1. Alignment of output section, if not explicitly overridden e.g. > via linker script, is the largest alignment of the corresponding input sections. > > I think that the problem can be fixed by making ld define __start_SECNAME like > follows: > ... > pcpu_set : { > __start_pcpu_set = ABSOLUTE(.); > ... > } > __stop_pcpu_set = .; > > This way __start_SECNAME would always point to the actual start of the output > section. > > Here's a patch that implements the idea: > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > > This is similar to what was done upstream: > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h > The code is quite different there, and approach is somewhat different, but the > idea is the same - place __start_SECNAME inside the section, not outside it. Does anybody see any obvious or non-obvious flaw in the above analysis and the proposed patches? Does anyone object against me committing the ld patch and some time later the pcpu.h patch? My plan is to commit the ld patch tomorrow and the pcpu.h patch early next week. P.S. Pro-active testing is welcome! Especially if you have an "unusual" architecture or use epair or both. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 11:39: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 8C250106567B; Thu, 15 Jul 2010 11:39:55 +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 2432C8FC15; Thu, 15 Jul 2010 11:39:54 +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 o6FBdoQJ082478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (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 o6FBdonA043778; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FBdotr043777; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 14:39:50 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3EF026.7090706@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8+OS07CeIgZ706fH" Content-Disposition: inline In-Reply-To: <4C3EF026.7090706@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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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, freebsd-current@freebsd.org Subject: Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:39:55 -0000 --8+OS07CeIgZ706fH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote: > on 11/07/2010 15:23 Andriy Gapon said the following: > > on 11/07/2010 14:54 Andriy Gapon said the following: > >> For completeness, here is a patch that simply drops the inline assembl= y and the > >> comment about it, and GCC-generated assembly and its diff: > >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff > >> > >> As was speculated above, the only thing really changed is section alig= nment > >> (from 128 to 4). > >=20 > > After making the above analysis I wondered why we require set_pcpu sect= ion > > alignment at all. After all, it's not used as loaded, data from the se= ction > > gets copied into special per-cpu memory areas. So, logically, it's tho= se areas > > that need to be aligned, not the section. > >=20 > > svn log and google quickly pointed me to this excellent analysis and ex= planation > > by bz (thanks again!): > > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > >=20 > > Summary: this alignment is needed to work around a bug in GNU binutils = ld for > > __start_SECNAME placement. > >=20 > > As explained by bz, ld internally generates an equivalent of the follow= ing > > linker script: > > ... > > __start_pcpu_set =3D ALIGN(NN); > > pcpu_set : { > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > Where NN is an alignment of the first _input_ pcpu_set section found in > > whichever .o file happens to be first. Not the resulting alignment of = pcpu_set > > _output_ section. > > Alignment requirement of input sections is based on largest alignment > > requirement of section's members. So if section is empty then the requ= ired > > alignment is 1. Alignment of output section, if not explicitly overrid= den e.g. > > via linker script, is the largest alignment of the corresponding input = sections. > >=20 > > I think that the problem can be fixed by making ld define __start_SECNA= ME like > > follows: > > ... > > pcpu_set : { > > __start_pcpu_set =3D ABSOLUTE(.); > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > This way __start_SECNAME would always point to the actual start of the = output > > section. > >=20 > > Here's a patch that implements the idea: > > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > >=20 > > This is similar to what was done upstream: > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=3D1.30= 6&r2=3D1.307&cvsroot=3Dsrc&f=3Dh > > The code is quite different there, and approach is somewhat different, = but the > > idea is the same - place __start_SECNAME inside the section, not outsid= e it. >=20 > Does anybody see any obvious or non-obvious flaw in the above analysis an= d the > proposed patches? > Does anyone object against me committing the ld patch and some time later= the > pcpu.h patch? >=20 > My plan is to commit the ld patch tomorrow and the pcpu.h patch early nex= t week. >=20 > P.S. > Pro-active testing is welcome! Especially if you have an "unusual" archi= tecture > or use epair or both. >=20 Is new behaviour completely identical to the behaviour of the newer ld ? Even if yes, I think that such changes make potential import of newer binutils harder. --8+OS07CeIgZ706fH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw+84UACgkQC3+MBN1Mb4hteACdG6JTcLWlpNSmv/+Nly2eBk2t hlEAoJxEY5TdVYFqCXL1jGMco2VIhTFZ =Wh6A -----END PGP SIGNATURE----- --8+OS07CeIgZ706fH-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 11:43: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 F0FB91065670 for ; Thu, 15 Jul 2010 11:43:12 +0000 (UTC) (envelope-from loerner@gmx.de) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 49D0B8FC14 for ; Thu, 15 Jul 2010 11:43:11 +0000 (UTC) Received: (qmail 4131 invoked by uid 0); 15 Jul 2010 11:16:25 -0000 Received: from 212.185.199.2 by www160.gmx.net with HTTP; Thu, 15 Jul 2010 13:16:22 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Thu, 15 Jul 2010 13:16:22 +0200 From: =?iso-8859-1?Q?=22Marc_L=F6rner=22?= Message-ID: <20100715111622.77770@gmx.net> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #60932973 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX188n1IfHdo8/5wQW34e61kP4jkMewoUD68JXKwmTZ LrvAEVH9X9I7FHDiUch6JGRBP+hI0AcYkTOw== Content-Transfer-Encoding: 8bit X-GMX-UID: MdYIfVMtYmYBd1v0xHQ3pD5CWkZTQdTC X-Mailman-Approved-At: Thu, 15 Jul 2010 11:57:39 +0000 Subject: re: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:43:13 -0000 Hello, what about using contigmalloc(9), there you can specify alignment and boundary. HTH, Marc >Hi, > >I want to allocate one (or more) pages in kernel space. >I'm not sure what is the api in freebsd (something which >is similar to __get_free_pages() of linux). > >Would malloc(4096, ...) guarantee that the returned >address is aligned on page boundary? > >Thanks and regards, >-Kalash -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 12:00: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 E91431065673; Thu, 15 Jul 2010 12:00:45 +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 052698FC35; Thu, 15 Jul 2010 12:00:44 +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 PAA29613; Thu, 15 Jul 2010 15:00:42 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C3EF869.9070804@freebsd.org> Date: Thu, 15 Jul 2010 15:00:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Kostik Belousov References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3EF026.7090706@freebsd.org> <20100715113950.GT2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 12:00:46 -0000 on 15/07/2010 14:39 Kostik Belousov said the following: > > Is new behaviour completely identical to the behaviour of the newer > ld ? No, it's not completely identical. __start_SECNAME placement would be identical, but our ld would still assign the symbol while latest upstream binutils PROVIDES it. > Even if yes, I think that such changes make potential import of > newer binutils harder. How? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 12:34:40 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 2BAA31065673 for ; Thu, 15 Jul 2010 12:34:40 +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 F2F7D8FC0A for ; Thu, 15 Jul 2010 12:34:39 +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 9799546B29; Thu, 15 Jul 2010 08:34:39 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CF7A28A03C; Thu, 15 Jul 2010 08:34:38 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 15 Jul 2010 08:07:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6E83197B-9DD5-4C7E-846D-AD176C25464D@niksun.com> In-Reply-To: <6E83197B-9DD5-4C7E-846D-AD176C25464D@niksun.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007150807.21529.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Jul 2010 08:34:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andrew Heybey Subject: Re: 8.1RC2 amd64 machine check 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: Thu, 15 Jul 2010 12:34:40 -0000 On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: > Got the following in /var/log/messages on my one-week-old amd64 box running 8.1RC2: > > Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0000000000000106, Status 0x0000000000000000 > Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC ID 0 > Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error > Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c I tend to use mcelog to get more detailed results. Unfortunately this is missing the first line which contains the bank number and status register, so I can't provide any extra details. I really should make a port of mcelog, but the patches I have to it aren't a complete port. > My questions are: > > 1. Did I interpret the message correctly (correctable error on my L3 cache)? Probably, though mcelog output would be better. > 2. Is it anything to worry about? Or is this just one of those things that happens but now it gets logged whereas before I was blissfully ignorant? Given that it is correctable it probably isn't an issue. It was not reported in earlier releases, so there is a chance that this could have been happening previously. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 12:34:41 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 5E01C106566C for ; Thu, 15 Jul 2010 12:34:41 +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 30F4C8FC13 for ; Thu, 15 Jul 2010 12:34:41 +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 DC00746B2E; Thu, 15 Jul 2010 08:34:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 12B318A04F; Thu, 15 Jul 2010 08:34:40 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 15 Jul 2010 08:11:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; 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: <201007150811.11721.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Jul 2010 08:34:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kalash nainwal Subject: Re: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 12:34:41 -0000 On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: > Hi, > > I want to allocate one (or more) pages in kernel space. > I'm not sure what is the api in freebsd (something which > is similar to __get_free_pages() of linux). > > Would malloc(4096, ...) guarantee that the returned > address is aligned on page boundary? Well, malloc(PAGE_SIZE) will align it on a page boundary. :) malloc(4096) will be aligned on a 4096-byte boundary if PAGE_SIZE is >= 4096. My understanding is that objects returned from malloc() are aligned to the smallest power-of-2 value >= the requested size up to a page. Allocations larger than a page are page aligned. So a malloc of 24 bytes or 32 bytes is 32-byte aligned for example. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 12:42: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 C3A761065674 for ; Thu, 15 Jul 2010 12:42:10 +0000 (UTC) (envelope-from ath@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7723E8FC21 for ; Thu, 15 Jul 2010 12:42:09 +0000 (UTC) Received: from NCES01.mj.niksun.com (nces01.mj.niksun.com [10.25.8.17]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id o6FCg8bv015937; Thu, 15 Jul 2010 08:42:08 -0400 (EDT) (envelope-from ath@niksun.com) Received: from nces01.mj.niksun.com ([10.25.8.17]) by NCES01.mj.niksun.com ([10.25.8.17]) with mapi; Thu, 15 Jul 2010 08:42:08 -0400 From: Andrew Heybey To: John Baldwin Date: Thu, 15 Jul 2010 08:42:09 -0400 Thread-Topic: 8.1RC2 amd64 machine check question Thread-Index: AcskGyLHf6Wl53kxRLWfEiWnMaR7LA== Message-ID: <0AE2CF53-EBA5-41F1-9433-637D1A6A29E1@niksun.com> References: <6E83197B-9DD5-4C7E-846D-AD176C25464D@niksun.com> <201007150807.21529.jhb@freebsd.org> In-Reply-To: <201007150807.21529.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.95.3 at anuket.mj.niksun.com X-Virus-Status: Clean Cc: "freebsd-hackers@freebsd.org" Subject: Re: 8.1RC2 amd64 machine check 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: Thu, 15 Jul 2010 12:42:10 -0000 On Jul 15, 2010, at 8:07 AM, John Baldwin wrote: > On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: >> Got the following in /var/log/messages on my one-week-old amd64 box runn= ing 8.1RC2: >>=20 >> Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0000000000000106, Statu= s 0x0000000000000000 >> Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, = APIC ID 0 >> Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error >> Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c >=20 > I tend to use mcelog to get more detailed results. Unfortunately this is > missing the first line which contains the bank number and status register= , so > I can't provide any extra details. Doh. Sorry, thought that I had cut-and-paste everything. Jul 13 20:30:17 spaten kernel: MCA: Bank 4, Status 0x942c4880001c017b andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 13:01:40 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 B48431065676 for ; Thu, 15 Jul 2010 13:01:40 +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 6DF6B8FC15 for ; Thu, 15 Jul 2010 13:01:40 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZO4J-0001NE-4x for freebsd-hackers@freebsd.org; Thu, 15 Jul 2010 15:01:39 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jul 2010 15:01:39 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jul 2010 15:01:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 15 Jul 2010 15:01:49 +0200 Lines: 17 Message-ID: References: <20100714090454.1177b96b@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:01:40 -0000 On 07/14/10 18:27, Jerry Toung wrote: > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn > wrote: > >> >> >> Rather than commenting out the code try setting the sysctl >> vfs.hirunningspace to various powers-of-two. Default seems to be >> 1MB. I just changed it on the command line as a test to 2MB. >> >> You can do this in /etc/sysctl.conf. >> >> > thank you all, that did it. The settings that Matt recommended are giving > the same numbers Any objections to raising the defaults to 8 MB / 1 MB in HEAD? From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 13:42: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 14D891065674 for ; Thu, 15 Jul 2010 13:42:21 +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 D95958FC19 for ; Thu, 15 Jul 2010 13:42:20 +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 58A0846B35; Thu, 15 Jul 2010 09:42:20 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7C8358A03C; Thu, 15 Jul 2010 09:42:19 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 15 Jul 2010 09:41:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6E83197B-9DD5-4C7E-846D-AD176C25464D@niksun.com> <201007150807.21529.jhb@freebsd.org> <0AE2CF53-EBA5-41F1-9433-637D1A6A29E1@niksun.com> In-Reply-To: <0AE2CF53-EBA5-41F1-9433-637D1A6A29E1@niksun.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007150941.24830.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Jul 2010 09:42:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andrew Heybey Subject: Re: 8.1RC2 amd64 machine check 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: Thu, 15 Jul 2010 13:42:21 -0000 On Thursday, July 15, 2010 8:42:09 am Andrew Heybey wrote: > On Jul 15, 2010, at 8:07 AM, John Baldwin wrote: > > > On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: > >> Got the following in /var/log/messages on my one-week-old amd64 box running 8.1RC2: > >> > >> Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0000000000000106, Status 0x0000000000000000 > >> Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC ID 0 > >> Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error > >> Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c > > > > I tend to use mcelog to get more detailed results. Unfortunately this is > > missing the first line which contains the bank number and status register, so > > I can't provide any extra details. > > Doh. Sorry, thought that I had cut-and-paste everything. > > Jul 13 20:30:17 spaten kernel: MCA: Bank 4, Status 0x942c4880001c017b This is what mcelog claims: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 2a49464c Northbridge NB Array Error bit43 = L3 subcache in error bit 1 bit46 = corrected ecc error memory/cache error 'evict mem transaction, generic transaction, level generic' STATUS 942c4880001c017b MCGSTATUS 0 MCGCAP 106 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 16 Model 4 > andrew > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 14:07: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 4E6CC1065670 for ; Thu, 15 Jul 2010 14:07:43 +0000 (UTC) (envelope-from krivenok.dmitry@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 D9F2F8FC19 for ; Thu, 15 Jul 2010 14:07:42 +0000 (UTC) Received: by ewy26 with SMTP id 26so241794ewy.13 for ; Thu, 15 Jul 2010 07:07:41 -0700 (PDT) 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=E2ww5eOupjMn95HoqhcUEYWYzCQWEI4SR26bE9QbwZ8=; b=lkKTQKniJBUAzNbqE79QPBnDjzHkLmcjf6RAFxg+JsUYTR0T8WU23vd8g03+AoO0xX rRh7TiyUtCCsRMxBTZZK/zfrQFWbWdiIY1ZMo6We3+Au9qniIxn0l5np79W/kWRW/lEJ NO/Ty+K+6DYRc3riHdBixwf6+357j8RniiUuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NHleFL62eGbBf36TkJd+urQb09hXF7Kvv2P3+7pFAhNFZqCq805biWORNJDDsTnwhE vy0wTEMVuZ9Sq5ngK5gJ3lG8lqIUwU0/vAHxzOYzQQTGLK6BN5FU//z4STyFb0zeiQPn +KLDpCkh5UkcnqxJ/3rWmh4ILLuOhTooJsmmk= MIME-Version: 1.0 Received: by 10.213.108.203 with SMTP id g11mr2717800ebp.51.1279202857226; Thu, 15 Jul 2010 07:07:37 -0700 (PDT) Received: by 10.213.23.14 with HTTP; Thu, 15 Jul 2010 07:07:36 -0700 (PDT) Date: Thu, 15 Jul 2010 18:07:36 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:07:43 -0000 Hello Hackers, I have a question about kernel linker. Please take a look at an example of simple module: ############################################################################ #include #include #include #include #include #include #include /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR BY DEFAULT */ void seltdinit(struct thread* t); static int event_handler(struct module *module, int event, void *arg) { int e = 0; switch (event) { case MOD_LOAD: /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */ seltdinit(curthread); break; case MOD_QUIESCE: break; case MOD_UNLOAD: break; case MOD_SHUTDOWN: break; default: e = EOPNOTSUPP; break; } return(e); }; ############################################################################ As you can see, this module calls seltdinit function declared as _static_ in kern/sys_generic.c file. I added a declaration of seltdinit function w/o static just to avoid compilation error since -Werror is used by default in FreeBSD. Then I successfully built the module: $ make Warning: Object directory not changed from original /usr/home/krived/work/freebsd/trouble cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c trouble.c ld -d -warn-common -r -d -o trouble.ko trouble.o :> export_syms awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J% objcopy % trouble.ko objcopy --strip-debug trouble.ko $ As expected, seltdinit symbol is undefined in trouble.ko file: $ nm trouble.ko | grep seltdinit U seltdinit $ and is local in kernel binary file: $ nm /boot/kernel/kernel | grep seltdinit ffffffff805fda50 t seltdinit $ I expected to get something like "undefined reference to seltdinit" error, but the module was loaded w/o any errors: $ sudo make load /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=2 $ kldstat | grep trouble 2 1 0xffffffff81212000 126 trouble.ko $ sudo make unload /sbin/kldunload -v trouble.ko Unloading trouble.ko, id=2 $ Could you please explain why the linker (or whatever is loading modules in FreeBSD) doesn't complain? For example, ld tool complains for the similar user-space example: ############################################################################ $ cat seltdinit.c static void seltdinit(void* td) { return; } $ cat main.c void seltdinit(void* td); int main() { seltdinit(0); return 0; } $ gcc -Wall -c seltdinit.c seltdinit.c:2: warning: 'seltdinit' defined but not used $ gcc -Wall -c main.c $ gcc seltdinit.o main.o -o sel main.o: In function `main': main.c:(.text+0xa): undefined reference to `seltdinit' collect2: ld returned 1 exit status $ ############################################################################ Thanks in advance! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 14:32: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 1A33A1065670 for ; Thu, 15 Jul 2010 14:32:43 +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 8FF698FC13 for ; Thu, 15 Jul 2010 14:32:42 +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 o6FEWZt0099227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 17:32:35 +0300 (EEST) (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 o6FEWZUi005726; Thu, 15 Jul 2010 17:32:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FEWZPO005725; Thu, 15 Jul 2010 17:32:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 17:32:35 +0300 From: Kostik Belousov To: Dmitry Krivenok Message-ID: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LtN0I0gXzHUftVCi" Content-Disposition: inline In-Reply-To: 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:32:43 -0000 --LtN0I0gXzHUftVCi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote: > Hello Hackers, >=20 > I have a question about kernel linker. > Please take a look at an example of simple module: >=20 > #########################################################################= ### > #include > #include > #include > #include > #include > #include > #include >=20 > /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR > BY DEFAULT */ > void seltdinit(struct thread* t); >=20 > static int event_handler(struct module *module, int event, void *arg) > { > int e =3D 0; > switch (event) > { > case MOD_LOAD: > /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */ > seltdinit(curthread); > break; > case MOD_QUIESCE: > break; > case MOD_UNLOAD: > break; > case MOD_SHUTDOWN: > break; > default: > e =3D EOPNOTSUPP; > break; > } >=20 > return(e); > }; > #########################################################################= ### >=20 > As you can see, this module calls seltdinit function declared as > _static_ in kern/sys_generic.c file. > I added a declaration of seltdinit function w/o static just to avoid > compilation error since -Werror is used > by default in FreeBSD. >=20 > Then I successfully built the module: >=20 > $ make > Warning: Object directory not changed from original > /usr/home/krived/work/freebsd/trouble > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common > -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -c trouble.c > ld -d -warn-common -r -d -o trouble.ko trouble.o > :> export_syms > awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J% > objcopy % trouble.ko > objcopy --strip-debug trouble.ko > $ >=20 > As expected, seltdinit symbol is undefined in trouble.ko file: > $ nm trouble.ko | grep seltdinit > U seltdinit > $ > and is local in kernel binary file: > $ nm /boot/kernel/kernel | grep seltdinit > ffffffff805fda50 t seltdinit > $ >=20 > I expected to get something like "undefined reference to seltdinit" > error, but the module was loaded w/o any errors: >=20 > $ sudo make load > /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko > Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=3D2 > $ kldstat | grep trouble > 2 1 0xffffffff81212000 126 trouble.ko > $ sudo make unload > /sbin/kldunload -v trouble.ko > Unloading trouble.ko, id=3D2 > $ >=20 > Could you please explain why the linker (or whatever is loading > modules in FreeBSD) doesn't complain? >=20 > For example, ld tool complains for the similar user-space example: >=20 > #########################################################################= ### > $ cat seltdinit.c > static void seltdinit(void* td) > { > return; > } > $ cat main.c > void seltdinit(void* td); >=20 > int main() > { > seltdinit(0); > return 0; > } > $ gcc -Wall -c seltdinit.c > seltdinit.c:2: warning: 'seltdinit' defined but not used > $ gcc -Wall -c main.c > $ gcc seltdinit.o main.o -o sel > main.o: In function `main': > main.c:(.text+0xa): undefined reference to `seltdinit' > collect2: ld returned 1 exit status > $ > #########################################################################= ### >=20 > Thanks in advance! The kernel linker ignores weak attribute of the symbol, as you see. There is more bugs in this department, in regard of the list of exported symbols from the modules. I have a patch that fixes the issues, but I am leery to commit it, since the fix effectively breaks significant set of the modules. --LtN0I0gXzHUftVCi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw/HAMACgkQC3+MBN1Mb4gveQCePvcou0othBN8JqHvC+nZIcsC 29AAoLf+OjpT934Bl0mSXn47IeieDuU9 =tz+7 -----END PGP SIGNATURE----- --LtN0I0gXzHUftVCi-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 14:48: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 E1E7B106566C for ; Thu, 15 Jul 2010 14:48:43 +0000 (UTC) (envelope-from kalash.nainwal@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 70BA48FC08 for ; Thu, 15 Jul 2010 14:48:43 +0000 (UTC) Received: by bwz12 with SMTP id 12so557708bwz.13 for ; Thu, 15 Jul 2010 07:48:42 -0700 (PDT) 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=YhboQVI2HBvfzYcWUPW/gb5HxFbqof7JC7Mu47HfkjE=; b=hCwxNMW/tQXFRRy87T6EtjwYiutZ6HHbGb3kWkDujdHKQ/En+GkvnXssNH8VTigO/7 VrPZtNuQQuIpMI0weZ4q3LOgyUNfBr02nT22zZRe0C3Kl7WYgkpDF/yjS7x+9B93KN+e cQCUgnZaWWLVHM9Z8hbl1OdVzYLhiw/+4Ffps= 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=FuUIKH5n5BKqaLxZRDnKcxG8A5iqcz4RbUpyULKccmp4V82rQp1+sZ8/493yND4JiA dfARgY8Ei/bE1ciEZupx2uoYxv8y4rYes8WF8Kbjik1ihujzcKfjodY8mX+5mfds97d7 OboqWSZpmGkWV96onMn/Kh2lAJgD7ByZ+EBV4= MIME-Version: 1.0 Received: by 10.103.197.5 with SMTP id z5mr3127648mup.107.1279205322161; Thu, 15 Jul 2010 07:48:42 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Thu, 15 Jul 2010 07:48:41 -0700 (PDT) In-Reply-To: <20100715111622.77770@gmx.net> References: <20100715111622.77770@gmx.net> Date: Thu, 15 Jul 2010 20:18:41 +0530 Message-ID: From: kalash nainwal To: =?ISO-8859-1?Q?Marc_L=F6rner?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:48:44 -0000 On Thu, Jul 15, 2010 at 4:46 PM, "Marc L=F6rner" wrote: > Hello, > what about using contigmalloc(9), there you can specify > alignment and boundary. > > HTH, > Marc > Thanks Marc. I had thought of using contigmalloc, but was not sure what would be the other args (boundary, low, high etc.) in my case. So was looking for a simpler interface. Regards, -Kalash From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 14:54: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 00383106566B for ; Thu, 15 Jul 2010 14:54:55 +0000 (UTC) (envelope-from kalash.nainwal@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 8C4B08FC29 for ; Thu, 15 Jul 2010 14:54:55 +0000 (UTC) Received: by gxk24 with SMTP id 24so799072gxk.13 for ; Thu, 15 Jul 2010 07:54:54 -0700 (PDT) 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=9Wv380OYlz/ymblggoAruk/j66x2TRI3b1AAMPB2+PI=; b=fxnuF+sP6fNoCE8XmF5dhqBqmNwxfxckOzfq+i21deq9LmB0/28yNCunS9YzY6GdCN +KOQs5mhhlVl5KGttuCyO2y9UgcvDRwzeqyQVCYX5S4TTuw0zU2z7AArDhXbN1gnKsNC ey0Fo4QlrwXXTcDIG51WDNH/9C/llGJdWwp8A= 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=XWiLLH8mmhLLQ2+u2iotrDiSAjo2bYhLXW3MRTqLP8G3bQrn/5SgcDc8VtQb3kmUqm dW3owRuKp++O9ThmbkjZL4Fjg1qUVADMYIpLKN1Igeji+C7ELSGvntL4WTV5MHex6ApJ 9ljgARQbAl61MyWk0JRQsb9cS9y0IpdapC0yU= MIME-Version: 1.0 Received: by 10.103.177.3 with SMTP id e3mr1183189mup.126.1279205693890; Thu, 15 Jul 2010 07:54:53 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Thu, 15 Jul 2010 07:54:53 -0700 (PDT) In-Reply-To: <201007150811.11721.jhb@freebsd.org> References: <201007150811.11721.jhb@freebsd.org> Date: Thu, 15 Jul 2010 20:24:53 +0530 Message-ID: From: kalash nainwal To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:54:56 -0000 On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: >> Hi, >> >> I want to allocate one (or more) pages in kernel space. >> I'm not sure what is the api in freebsd (something which >> is similar to __get_free_pages() of linux). >> >> Would malloc(4096, ...) guarantee that the returned >> address is aligned on page boundary? > > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) =A0malloc(40= 96) > will be aligned on a 4096-byte boundary if PAGE_SIZE is >=3D 4096. =A0My > understanding is that objects returned from malloc() are aligned to the > smallest power-of-2 value >=3D the requested size up to a page. =A0Alloca= tions > larger than a page are page aligned. =A0So a malloc of 24 bytes or 32 byt= es is > 32-byte aligned for example. > Thanks John for explaining. After going through the kernel src I was not sure about malloc, as the code is little hard to follow. However I figured kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my purpose fine. Regards, -Kalash From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 15:04: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 C65D7106567E; Thu, 15 Jul 2010 15:04:25 +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 2448D8FC21; Thu, 15 Jul 2010 15:04:24 +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 o6FF4B8n002155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 18:04:11 +0300 (EEST) (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 o6FF4BBO005966; Thu, 15 Jul 2010 18:04:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FF4Bxv005965; Thu, 15 Jul 2010 18:04:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 18:04:11 +0300 From: Kostik Belousov To: kalash nainwal Message-ID: <20100715150411.GV2381@deviant.kiev.zoral.com.ua> References: <201007150811.11721.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YwTTlJgQ7QoYB9ta" Content-Disposition: inline In-Reply-To: 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=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, 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: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:04:25 -0000 --YwTTlJgQ7QoYB9ta Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 08:24:53PM +0530, kalash nainwal wrote: > On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: > > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: > >> Hi, > >> > >> I want to allocate one (or more) pages in kernel space. > >> I'm not sure what is the api in freebsd (something which > >> is similar to __get_free_pages() of linux). > >> > >> Would malloc(4096, ...) guarantee that the returned > >> address is aligned on page boundary? > > > > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) =9Amalloc(= 4096) > > will be aligned on a 4096-byte boundary if PAGE_SIZE is >=3D 4096. =9AMy > > understanding is that objects returned from malloc() are aligned to the > > smallest power-of-2 value >=3D the requested size up to a page. =9AAllo= cations > > larger than a page are page aligned. =9ASo a malloc of 24 bytes or 32 b= ytes is > > 32-byte aligned for example. > > >=20 > Thanks John for explaining. >=20 > After going through the kernel src I was not sure about > malloc, as the code is little hard to follow. However I figured > kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my ^^^^^^kernel_map. > purpose fine. >=20 > Regards, > -Kalash > _______________________________________________ > 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" --YwTTlJgQ7QoYB9ta Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw/I2sACgkQC3+MBN1Mb4gsqACg4QUGH4z/5/u7u+znZupw0b1i P3kAnRa0rMG7JK/wN7GCM3Q0btfWqaNC =xrbY -----END PGP SIGNATURE----- --YwTTlJgQ7QoYB9ta-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 15:31: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 B897C106566B for ; Thu, 15 Jul 2010 15:31:33 +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 B78688FC1A for ; Thu, 15 Jul 2010 15:31:32 +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 o6FFVSWE004403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jul 2010 18:31:28 +0300 (EEST) (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 o6FFVS3k006125 for ; Thu, 15 Jul 2010 18:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FFVS5H006124 for freebsd-hackers@freebsd.org; Thu, 15 Jul 2010 18:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 18:31:28 +0300 From: Kostik Belousov To: freebsd-hackers@freebsd.org Message-ID: <20100715153128.GW2381@deviant.kiev.zoral.com.ua> References: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ItroYk2LVxvwOvi/" Content-Disposition: inline In-Reply-To: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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 Subject: Re: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:31:33 -0000 --ItroYk2LVxvwOvi/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 05:32:35PM +0300, Kostik Belousov wrote: > On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote: > > Hello Hackers, > >=20 > > I have a question about kernel linker. > > Please take a look at an example of simple module: > >=20 > > #######################################################################= ##### > > #include > > #include > > #include > > #include > > #include > > #include > > #include > >=20 > > /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR > > BY DEFAULT */ > > void seltdinit(struct thread* t); > >=20 > > static int event_handler(struct module *module, int event, void *arg) > > { > > int e =3D 0; > > switch (event) > > { > > case MOD_LOAD: > > /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c = */ > > seltdinit(curthread); > > break; > > case MOD_QUIESCE: > > break; > > case MOD_UNLOAD: > > break; > > case MOD_SHUTDOWN: > > break; > > default: > > e =3D EOPNOTSUPP; > > break; > > } > >=20 > > return(e); > > }; > > #######################################################################= ##### > >=20 > > As you can see, this module calls seltdinit function declared as > > _static_ in kern/sys_generic.c file. > > I added a declaration of seltdinit function w/o static just to avoid > > compilation error since -Werror is used > > by default in FreeBSD. > >=20 > > Then I successfully built the module: > >=20 > > $ make > > Warning: Object directory not changed from original > > /usr/home/krived/work/freebsd/trouble > > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param > > inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-comm= on > > -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 > > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > > -fformat-extensions -c trouble.c > > ld -d -warn-common -r -d -o trouble.ko trouble.o > > :> export_syms > > awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J% > > objcopy % trouble.ko > > objcopy --strip-debug trouble.ko > > $ > >=20 > > As expected, seltdinit symbol is undefined in trouble.ko file: > > $ nm trouble.ko | grep seltdinit > > U seltdinit > > $ > > and is local in kernel binary file: > > $ nm /boot/kernel/kernel | grep seltdinit > > ffffffff805fda50 t seltdinit > > $ > >=20 > > I expected to get something like "undefined reference to seltdinit" > > error, but the module was loaded w/o any errors: > >=20 > > $ sudo make load > > /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko > > Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=3D2 > > $ kldstat | grep trouble > > 2 1 0xffffffff81212000 126 trouble.ko > > $ sudo make unload > > /sbin/kldunload -v trouble.ko > > Unloading trouble.ko, id=3D2 > > $ > >=20 > > Could you please explain why the linker (or whatever is loading > > modules in FreeBSD) doesn't complain? > >=20 > > For example, ld tool complains for the similar user-space example: > >=20 > > #######################################################################= ##### > > $ cat seltdinit.c > > static void seltdinit(void* td) > > { > > return; > > } > > $ cat main.c > > void seltdinit(void* td); > >=20 > > int main() > > { > > seltdinit(0); > > return 0; > > } > > $ gcc -Wall -c seltdinit.c > > seltdinit.c:2: warning: 'seltdinit' defined but not used > > $ gcc -Wall -c main.c > > $ gcc seltdinit.o main.o -o sel > > main.o: In function `main': > > main.c:(.text+0xa): undefined reference to `seltdinit' > > collect2: ld returned 1 exit status > > $ > > #######################################################################= ##### > >=20 > > Thanks in advance! > The kernel linker ignores weak attribute of the symbol, as you see. > There is more bugs in this department, in regard of the list of > exported symbols from the modules. >=20 > I have a patch that fixes the issues, but I am leery to commit it, since > the fix effectively breaks significant set of the modules. Ok, below is the patch. I updated it to the latest HEAD, but did not verified even the build. diff --git a/sys/conf/kmod_syms.awk b/sys/conf/kmod_syms.awk index 677d813..98940c6 100644 --- a/sys/conf/kmod_syms.awk +++ b/sys/conf/kmod_syms.awk @@ -12,7 +12,10 @@ BEGIN { =20 # De-list symbols from the export list. { - delete syms[$0] + split($0, exports) + for (member in exports) { + delete syms[$member] + } } =20 # Strip commons, make everything else local. diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c index dd29302..f3da962 100644 --- a/sys/kern/kern_linker.c +++ b/sys/kern/kern_linker.c @@ -855,7 +855,7 @@ linker_debug_lookup(const char *symstr, c_linker_sym_t = *sym) linker_file_t lf; =20 TAILQ_FOREACH(lf, &linker_files, link) { - if (LINKER_LOOKUP_SYMBOL(lf, symstr, sym) =3D=3D 0) + if (LINKER_LOOKUP_DEBUG_SYMBOL(lf, symstr, sym) =3D=3D 0) return (0); } return (ENOENT); @@ -899,7 +899,7 @@ linker_debug_symbol_values(c_linker_sym_t sym, linker_s= ymval_t *symval) linker_file_t lf; =20 TAILQ_FOREACH(lf, &linker_files, link) { - if (LINKER_SYMBOL_VALUES(lf, sym, symval) =3D=3D 0) + if (LINKER_DEBUG_SYMBOL_VALUES(lf, sym, symval) =3D=3D 0) return (0); } return (ENOENT); diff --git a/sys/kern/link_elf.c b/sys/kern/link_elf.c index b389ace..f494fa5 100644 --- a/sys/kern/link_elf.c +++ b/sys/kern/link_elf.c @@ -127,25 +127,28 @@ typedef struct elf_file { =20 static int link_elf_link_common_finish(linker_file_t); static int link_elf_link_preload(linker_class_t cls, - const char*, linker_file_t*); + const char*, linker_file_t*); static int link_elf_link_preload_finish(linker_file_t); static int link_elf_load_file(linker_class_t, const char*, linker_file_t*); static int link_elf_lookup_symbol(linker_file_t, const char*, - c_linker_sym_t*); -static int link_elf_symbol_values(linker_file_t, c_linker_sym_t, linker_sy= mval_t*); + c_linker_sym_t*); +static int link_elf_lookup_debug_symbol(linker_file_t, const char*, + c_linker_sym_t*); +static int link_elf_symbol_values(linker_file_t, c_linker_sym_t, + linker_symval_t*); +static int link_elf_debug_symbol_values(linker_file_t, c_linker_sym_t, + linker_symval_t*); static int link_elf_search_symbol(linker_file_t, caddr_t value, - c_linker_sym_t* sym, long* diffp); + c_linker_sym_t* sym, long* diffp); =20 static void link_elf_unload_file(linker_file_t); static void link_elf_unload_preload(linker_file_t); static int link_elf_lookup_set(linker_file_t, const char *, void ***, void ***, int *); static int link_elf_each_function_name(linker_file_t, - int (*)(const char *, void *), - void *); + int (*)(const char *, void *), void *); static int link_elf_each_function_nameval(linker_file_t, - linker_function_nameval_callback_t, - void *); + linker_function_nameval_callback_t, void *); static void link_elf_reloc_local(linker_file_t); static long link_elf_symtab_get(linker_file_t, const Elf_Sym **); static long link_elf_strtab_get(linker_file_t, caddr_t *); @@ -153,7 +156,9 @@ static Elf_Addr elf_lookup(linker_file_t lf, Elf_Size s= ymidx, int deps); =20 static kobj_method_t link_elf_methods[] =3D { KOBJMETHOD(linker_lookup_symbol, link_elf_lookup_symbol), + KOBJMETHOD(linker_lookup_debug_symbol, link_elf_lookup_debug_symbol), KOBJMETHOD(linker_symbol_values, link_elf_symbol_values), + KOBJMETHOD(linker_debug_symbol_values, link_elf_debug_symbol_values), KOBJMETHOD(linker_search_symbol, link_elf_search_symbol), KOBJMETHOD(linker_unload, link_elf_unload_file), KOBJMETHOD(linker_load_file, link_elf_load_file), @@ -1160,14 +1165,14 @@ elf_hash(const char *name) } =20 static int -link_elf_lookup_symbol(linker_file_t lf, const char* name, c_linker_sym_t*= sym) +link_elf_lookup_symbol1(linker_file_t lf, const char* name, c_linker_sym_t= * sym, + int see_local) { elf_file_t ef =3D (elf_file_t) lf; unsigned long symnum; const Elf_Sym* symp; const char *strp; unsigned long hash; - int i; =20 /* If we don't have a hash, bail. */ if (ef->buckets =3D=3D NULL || ef->nbuckets =3D=3D 0) { @@ -1194,60 +1199,101 @@ link_elf_lookup_symbol(linker_file_t lf, const cha= r* name, c_linker_sym_t* sym) strp =3D ef->strtab + symp->st_name; =20 if (strcmp(name, strp) =3D=3D 0) { - if (symp->st_shndx !=3D SHN_UNDEF || - (symp->st_value !=3D 0 && - ELF_ST_TYPE(symp->st_info) =3D=3D STT_FUNC)) { - *sym =3D (c_linker_sym_t) symp; - return 0; - } else - return ENOENT; + if (symp->st_shndx !=3D SHN_UNDEF || + (symp->st_value !=3D 0 && + ELF_ST_TYPE(symp->st_info) =3D=3D STT_FUNC)) { + if (see_local || ELF_ST_BIND(symp->st_info) !=3D STB_LOCAL) { + *sym =3D (c_linker_sym_t) symp; + return (0); + } else + return (ENOENT); + } else + return (ENOENT); } =20 symnum =3D ef->chains[symnum]; } =20 - /* If we have not found it, look at the full table (if loaded) */ - if (ef->symtab =3D=3D ef->ddbsymtab) - return ENOENT; + return (ENOENT); +} =20 - /* Exhaustive search */ - for (i =3D 0, symp =3D ef->ddbsymtab; i < ef->ddbsymcnt; i++, symp++) { - strp =3D ef->ddbstrtab + symp->st_name; - if (strcmp(name, strp) =3D=3D 0) { - if (symp->st_shndx !=3D SHN_UNDEF || - (symp->st_value !=3D 0 && - ELF_ST_TYPE(symp->st_info) =3D=3D STT_FUNC)) { - *sym =3D (c_linker_sym_t) symp; - return 0; - } else - return ENOENT; +static int +link_elf_lookup_symbol(linker_file_t lf, const char* name, c_linker_sym_t*= sym) +{ + + return (link_elf_lookup_symbol1(lf, name, sym, 0)); +} + +static int +link_elf_lookup_debug_symbol(linker_file_t lf, const char *name, + c_linker_sym_t *sym) +{ + elf_file_t ef =3D (elf_file_t) lf; + const Elf_Sym* symp; + const char *strp; + int i; + + if (link_elf_lookup_symbol1(lf, name, sym, 1) =3D=3D 0) + return (0); + + for (i =3D 0, symp =3D ef->ddbsymtab; i < ef->ddbsymcnt; i++, symp++) { + strp =3D ef->ddbstrtab + symp->st_name; + if (strcmp(name, strp) =3D=3D 0) { + if (symp->st_shndx !=3D SHN_UNDEF || + (symp->st_value !=3D 0 && + ELF_ST_TYPE(symp->st_info) =3D=3D STT_FUNC)) { + *sym =3D (c_linker_sym_t) symp; + return (0); + } else + return (ENOENT); + } } - } =20 - return ENOENT; + return (ENOENT); } =20 static int -link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym, linker_symval= _t* symval) +link_elf_symbol_values1(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t *symval, int see_local) { elf_file_t ef =3D (elf_file_t) lf; const Elf_Sym* es =3D (const Elf_Sym*) sym; =20 if (es >=3D ef->symtab && es < (ef->symtab + ef->nchains)) { - symval->name =3D ef->strtab + es->st_name; - symval->value =3D (caddr_t) ef->address + es->st_value; - symval->size =3D es->st_size; - return 0; + if (!see_local && ELF_ST_BIND(es->st_info) =3D=3D STB_LOCAL) + return (ENOENT); + symval->name =3D ef->strtab + es->st_name; + symval->value =3D (caddr_t) ef->address + es->st_value; + symval->size =3D es->st_size; + return (0); } - if (ef->symtab =3D=3D ef->ddbsymtab) - return ENOENT; + return (ENOENT); +} + +static int +link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t *symval) +{ + + return (link_elf_symbol_values1(lf, sym, symval, 0)); +} + +static int +link_elf_debug_symbol_values(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t* symval) +{ + elf_file_t ef =3D (elf_file_t) lf; + const Elf_Sym* es =3D (const Elf_Sym*) sym; + + if (link_elf_symbol_values1(lf, sym, symval, 1) =3D=3D 0) + return (0); if (es >=3D ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) { - symval->name =3D ef->ddbstrtab + es->st_name; - symval->value =3D (caddr_t) ef->address + es->st_value; - symval->size =3D es->st_size; - return 0; + symval->name =3D ef->ddbstrtab + es->st_name; + symval->value =3D (caddr_t) ef->address + es->st_value; + symval->size =3D es->st_size; + return (0); } - return ENOENT; + return (ENOENT); } =20 static int diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c index a337fd0..ae8ea04 100644 --- a/sys/kern/link_elf_obj.c +++ b/sys/kern/link_elf_obj.c @@ -127,8 +127,12 @@ static int link_elf_link_preload_finish(linker_file_t); static int link_elf_load_file(linker_class_t, const char *, linker_file_t = *); static int link_elf_lookup_symbol(linker_file_t, const char *, c_linker_sym_t *); +static int link_elf_lookup_debug_symbol(linker_file_t, const char *, + c_linker_sym_t *); static int link_elf_symbol_values(linker_file_t, c_linker_sym_t, linker_symval_t *); +static int link_elf_debug_symbol_values(linker_file_t, c_linker_sym_t, + linker_symval_t *); static int link_elf_search_symbol(linker_file_t, caddr_t value, c_linker_sym_t *sym, long *diffp); =20 @@ -148,7 +152,9 @@ static Elf_Addr elf_obj_lookup(linker_file_t lf, Elf_Si= ze symidx, int deps); =20 static kobj_method_t link_elf_methods[] =3D { KOBJMETHOD(linker_lookup_symbol, link_elf_lookup_symbol), + KOBJMETHOD(linker_lookup_debug_symbol, link_elf_lookup_debug_symbol), KOBJMETHOD(linker_symbol_values, link_elf_symbol_values), + KOBJMETHOD(linker_debug_symbol_values, link_elf_debug_symbol_values), KOBJMETHOD(linker_search_symbol, link_elf_search_symbol), KOBJMETHOD(linker_unload, link_elf_unload_file), KOBJMETHOD(linker_load_file, link_elf_load_file), @@ -1067,7 +1073,8 @@ relocate_file(elf_file_t ef) } =20 static int -link_elf_lookup_symbol(linker_file_t lf, const char *name, c_linker_sym_t = *sym) +link_elf_lookup_symbol1(linker_file_t lf, const char *name, c_linker_sym_t= *sym, + int see_local) { elf_file_t ef =3D (elf_file_t) lf; const Elf_Sym *symp; @@ -1077,27 +1084,64 @@ link_elf_lookup_symbol(linker_file_t lf, const char= *name, c_linker_sym_t *sym) for (i =3D 0, symp =3D ef->ddbsymtab; i < ef->ddbsymcnt; i++, symp++) { strp =3D ef->ddbstrtab + symp->st_name; if (symp->st_shndx !=3D SHN_UNDEF && strcmp(name, strp) =3D=3D 0) { - *sym =3D (c_linker_sym_t) symp; - return 0; + if (see_local || + ELF_ST_BIND(symp->st_info) =3D=3D STB_GLOBAL) { + *sym =3D (c_linker_sym_t) symp; + return (0); + } else + return (ENOENT); } } - return ENOENT; + return (ENOENT); } =20 static int -link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym, - linker_symval_t *symval) +link_elf_lookup_symbol(linker_file_t lf, const char *name, c_linker_sym_t = *sym) +{ + + return (link_elf_lookup_symbol1(lf, name, sym, 0)); +} + +static int +link_elf_lookup_debug_symbol(linker_file_t lf, const char *name, + c_linker_sym_t *sym) +{ + + return (link_elf_lookup_symbol1(lf, name, sym, 1)); +} + +static int +link_elf_symbol_values1(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t *symval, int see_local) { elf_file_t ef =3D (elf_file_t) lf; const Elf_Sym *es =3D (const Elf_Sym*) sym; =20 if (es >=3D ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) { + if (!see_local && ELF_ST_BIND(es->st_info) =3D=3D STB_LOCAL) + return (ENOENT); symval->name =3D ef->ddbstrtab + es->st_name; symval->value =3D (caddr_t)es->st_value; symval->size =3D es->st_size; - return 0; + return (0); } - return ENOENT; + return (ENOENT); +} + +static int +link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t *symval) +{ + + return (link_elf_symbol_values1(lf, sym, symval, 0)); +} + +static int +link_elf_debug_symbol_values(linker_file_t lf, c_linker_sym_t sym, + linker_symval_t *symval) +{ + + return (link_elf_symbol_values1(lf, sym, symval, 1)); } =20 static int diff --git a/sys/kern/linker_if.m b/sys/kern/linker_if.m index 3df592c..030e8eb 100644 --- a/sys/kern/linker_if.m +++ b/sys/kern/linker_if.m @@ -40,12 +40,24 @@ METHOD int lookup_symbol { c_linker_sym_t* symp; }; =20 +METHOD int lookup_debug_symbol { + linker_file_t file; + const char* name; + c_linker_sym_t* symp; +}; + METHOD int symbol_values { linker_file_t file; c_linker_sym_t sym; linker_symval_t* valp; }; =20 +METHOD int debug_symbol_values { + linker_file_t file; + c_linker_sym_t sym; + linker_symval_t* valp; +}; + METHOD int search_symbol { linker_file_t file; caddr_t value; @@ -63,6 +75,12 @@ METHOD int each_function_name { void* opaque; }; =20 +METHOD int each_debug_function_name { + linker_file_t file; + linker_function_name_callback_t callback; + void* opaque; +}; + # # Call the callback with each specified function and it's value # defined in the file. @@ -74,6 +92,12 @@ METHOD int each_function_nameval { void* opaque; }; =20 +METHOD int each_debug_function_nameval { + linker_file_t file; + linker_function_nameval_callback_t callback; + void* opaque; +}; + # # Search for a linker set in a file. Return a pointer to the first # entry (which is itself a pointer), and the number of entries. diff --git a/sys/modules/ata/atacore/Makefile b/sys/modules/ata/atacore/Mak= efile index 7b8d9e2..30a4ccb 100644 --- a/sys/modules/ata/atacore/Makefile +++ b/sys/modules/ata/atacore/Makefile @@ -6,4 +6,6 @@ KMOD=3D ata SRCS=3D ata-all.c ata-lowlevel.c ata-queue.c ata_if.c SRCS+=3D opt_ata.h ata_if.h device_if.h bus_if.h =20 +EXPORT_SYMS=3D YES + .include diff --git a/sys/modules/mii/Makefile b/sys/modules/mii/Makefile index 6232b5e..9740cf2 100644 --- a/sys/modules/mii/Makefile +++ b/sys/modules/mii/Makefile @@ -12,7 +12,11 @@ SRCS+=3D rgephy.c rlphy.c ruephy.c tdkphy.c tlphy.c true= phy.c ukphy.c SRCS+=3D ukphy_subr.c SRCS+=3D xmphy.c =20 -EXPORT_SYMS=3D mii_mediachg \ +EXPORT_SYMS=3D miibus_devclass \ + miibus_driver \ + miibus_readreg_desc \ + miibus_writereg_desc \ + mii_mediachg \ mii_phy_probe \ mii_phy_reset \ mii_pollstat \ diff --git a/sys/modules/pseudofs/Makefile b/sys/modules/pseudofs/Makefile index d5696c5..ea7b112 100644 --- a/sys/modules/pseudofs/Makefile +++ b/sys/modules/pseudofs/Makefile @@ -11,6 +11,7 @@ SRCS=3D opt_pseudofs.h \ pseudofs_vnops.c =20 EXPORT_SYMS=3D pfs_mount \ + pfs_cmount \ pfs_unmount \ pfs_root \ pfs_statfs \ --ItroYk2LVxvwOvi/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw/Kc8ACgkQC3+MBN1Mb4iSpACbBe0l9Xy0cbXDidyeeaoEF+Q1 rfgAnjUtFmHLJc893selq/jjF6OJsyfq =3Gwr -----END PGP SIGNATURE----- --ItroYk2LVxvwOvi/-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 15:34:16 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 B296F1065675; Thu, 15 Jul 2010 15:34:16 +0000 (UTC) (envelope-from kalash.nainwal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0D88FC15; Thu, 15 Jul 2010 15:34:15 +0000 (UTC) Received: by vws19 with SMTP id 19so1603591vws.13 for ; Thu, 15 Jul 2010 08:34:15 -0700 (PDT) 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=xB1ny3muNcjQRLxTp5RJF9PLFJDtl3edvRShR33bgGw=; b=UJBdgNM+2hC0bA2rHjPLQuH+xMz8+PDepC9xifmSq8oBKr+axedhYqtvnysfMmm0X3 wvSKni9E3su5K6Xiw5pmnIc77FqsgSfcHkv9oKXZsY3sKjDymgY74VeTkojn1kmC94DM jJwmvecTsBFUJtVEmK3bML389PIbOQfMa8bUY= 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=swu/RvUkr3eNTA3OSwDwu1/krJQjRgPAlXuANlUFydg30wn7xPeodN5sgH5t1aca4n w4dHPhBbNfTv/eEbo8FLKts/vTli3t7dQW/x08Mh8qbV1AoKsECuvyHe2/OyRZLis2g0 lrC+N9mOQbmA7N6OiIsBRlzY6AtHpQs7Kb6tk= MIME-Version: 1.0 Received: by 10.220.96.4 with SMTP id f4mr4391786vcn.127.1279208055172; Thu, 15 Jul 2010 08:34:15 -0700 (PDT) Received: by 10.220.192.8 with HTTP; Thu, 15 Jul 2010 08:34:15 -0700 (PDT) In-Reply-To: <20100715150411.GV2381@deviant.kiev.zoral.com.ua> References: <201007150811.11721.jhb@freebsd.org> <20100715150411.GV2381@deviant.kiev.zoral.com.ua> Date: Thu, 15 Jul 2010 21:04:15 +0530 Message-ID: From: kalash nainwal To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: how to do page level mem alloc in freebsd kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:34:16 -0000 2010/7/15 Kostik Belousov : > On Thu, Jul 15, 2010 at 08:24:53PM +0530, kalash nainwal wrote: >> On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: >> > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: >> >> Hi, >> >> >> >> I want to allocate one (or more) pages in kernel space. >> >> I'm not sure what is the api in freebsd (something which >> >> is similar to __get_free_pages() of linux). >> >> >> >> Would malloc(4096, ...) guarantee that the returned >> >> address is aligned on page boundary? >> > >> > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) =A0malloc= (4096) >> > will be aligned on a 4096-byte boundary if PAGE_SIZE is >=3D 4096. =A0= My >> > understanding is that objects returned from malloc() are aligned to th= e >> > smallest power-of-2 value >=3D the requested size up to a page. =A0All= ocations >> > larger than a page are page aligned. =A0So a malloc of 24 bytes or 32 = bytes is >> > 32-byte aligned for example. >> > >> >> Thanks John for explaining. >> >> After going through the kernel src I was not sure about >> malloc, as the code is little hard to follow. However I figured >> kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my > =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^kernel_map. oops. my bad. thanks for correcting. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 18:13: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 992891065673 for ; Thu, 15 Jul 2010 18:13:56 +0000 (UTC) (envelope-from krivenok.dmitry@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 1F4778FC08 for ; Thu, 15 Jul 2010 18:13:55 +0000 (UTC) Received: by ewy26 with SMTP id 26so394224ewy.13 for ; Thu, 15 Jul 2010 11:13:55 -0700 (PDT) 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=2g0uAjNjNZNxFq56f+NdclQ4GU3VnvQ6nq6607Q4IZU=; b=HKoIT8ZD+WfkReTX7cZwReCjkQEhfGIpoc/DLO83B1v5SaQr2iLjJj4zkUwVfhw1zv cxcPOCz/37aEvNcrgWcoljHCwYhz+jwVEQerA66uMWpGaqbpetB73e24VBwrWbcEzK5H 2YCbxGJtL8Q87qDn1xXPjtJabFlDCKcW7bsqU= 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=rox56dXuO/cU9/dUFbiy8jz45FNpHWIsIcr4CWQKCV3Tss4h75Kb0u4mpvWTWhJh/v S2YPxEtx1q5UBisIDn2YdUQtKWeYBgNRWnyECo2a0GI2hz/AGu2X4a2qwIpMqiwJ6La2 VS6gUkobc7LcYVuxzkJSQ8eBfkKSduUJEfNKc= MIME-Version: 1.0 Received: by 10.213.20.142 with SMTP id f14mr50953ebb.30.1279217634885; Thu, 15 Jul 2010 11:13:54 -0700 (PDT) Received: by 10.213.23.14 with HTTP; Thu, 15 Jul 2010 11:13:54 -0700 (PDT) In-Reply-To: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> References: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> Date: Thu, 15 Jul 2010 22:13:54 +0400 Message-ID: From: Dmitry Krivenok To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:13:56 -0000 Unfortunately, one can easily miss such problems during build of the module= . I'm working on a system which consists of lots of user-space programs and kernel modules and uses it's own complicated build system. gcc option -Werror is not used by the build system (I believe it should), that's why we just missed a compiler warning when called undeclared function (actually declared as static deep in kernel source). Then we got kernel panic and started investigating it. I disassembled seltdinit function and found that it takes pointer to thread from %eax register and global kernel functions (e.g. kern_select) calling seltdinit copy the pointer to %eax just before "call" instruction. Then I disassembled my own function calling seltdinit and found that it passes the pointer via stack and doesn't do anything with %eax register. I'm not OS/compilers/ASM expert, but I guess that gcc is free to optimize passing of parameters to static functions because it has all the information about callers of these static functions (all stuff is inside one translation unit). So kernel functions call static functions in a right way, but modules compiled separately may use wrong calling convention. On Thu, Jul 15, 2010 at 6:32 PM, Kostik Belousov wrot= e: > On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote: >> Hello Hackers, >> >> I have a question about kernel linker. >> Please take a look at an example of simple module: >> >> ########################################################################= #### >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR >> BY DEFAULT */ >> void seltdinit(struct thread* t); >> >> static int event_handler(struct module *module, int event, void *arg) >> { >> =A0 int e =3D 0; >> =A0 switch (event) >> =A0 =A0 { >> =A0 =A0 =A0 case MOD_LOAD: >> =A0 =A0 =A0 =A0 /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_gen= eric.c */ >> =A0 =A0 =A0 =A0 seltdinit(curthread); >> =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 case MOD_QUIESCE: >> =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 case MOD_UNLOAD: >> =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 case MOD_SHUTDOWN: >> =A0 =A0 =A0 =A0 break; >> =A0 =A0 =A0 default: >> =A0 =A0 =A0 =A0 e =3D EOPNOTSUPP; >> =A0 =A0 =A0 =A0 break; >> =A0 =A0 } >> >> =A0 return(e); >> }; >> ########################################################################= #### >> >> As you can see, this module calls seltdinit function declared as >> _static_ in kern/sys_generic.c file. >> I added a declaration of seltdinit function w/o static just to avoid >> compilation error since -Werror is used >> by default in FreeBSD. >> >> Then I successfully built the module: >> >> $ make >> Warning: Object directory not changed from original >> /usr/home/krived/work/freebsd/trouble >> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc =A0 -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param >> inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-commo= n >> -fno-omit-frame-pointer =A0-mcmodel=3Dkernel -mno-red-zone =A0-mfpmath= =3D387 >> -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow =A0-msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector >> -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign >> -fformat-extensions -c trouble.c >> ld =A0-d -warn-common -r -d -o trouble.ko trouble.o >> :> export_syms >> awk -f /sys/conf/kmod_syms.awk trouble.ko =A0export_syms | xargs -J% >> objcopy % trouble.ko >> objcopy --strip-debug trouble.ko >> $ >> >> As expected, seltdinit symbol is undefined in trouble.ko file: >> $ nm trouble.ko | grep seltdinit >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0U seltdinit >> $ >> and is local in kernel binary file: >> $ nm /boot/kernel/kernel | grep seltdinit >> ffffffff805fda50 t seltdinit >> $ >> >> I expected to get something like "undefined reference to seltdinit" >> error, but the module was loaded w/o any errors: >> >> $ sudo make load >> /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko >> Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=3D2 >> $ kldstat | grep trouble >> =A02 =A0 =A01 0xffffffff81212000 126 =A0 =A0 =A0trouble.ko >> $ sudo make unload >> /sbin/kldunload -v trouble.ko >> Unloading trouble.ko, id=3D2 >> $ >> >> Could you please explain why the linker (or whatever is loading >> modules in FreeBSD) doesn't complain? >> >> For example, ld tool complains for the similar user-space example: >> >> ########################################################################= #### >> $ cat seltdinit.c >> static void seltdinit(void* td) >> { >> =A0 return; >> } >> $ cat main.c >> void seltdinit(void* td); >> >> int main() >> { >> =A0 seltdinit(0); >> =A0 return 0; >> } >> $ gcc -Wall -c seltdinit.c >> seltdinit.c:2: warning: 'seltdinit' defined but not used >> $ gcc -Wall -c main.c >> $ gcc seltdinit.o main.o -o sel >> main.o: In function `main': >> main.c:(.text+0xa): undefined reference to `seltdinit' >> collect2: ld returned 1 exit status >> $ >> ########################################################################= #### >> >> Thanks in advance! > The kernel linker ignores weak attribute of the symbol, as you see. > There is more bugs in this department, in regard of the list of > exported symbols from the modules. > > I have a patch that fixes the issues, but I am leery to commit it, since > the fix effectively breaks significant set of the modules. > --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 18:18: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 348131065686 for ; Thu, 15 Jul 2010 18:18:30 +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 9C7738FC29 for ; Thu, 15 Jul 2010 18:18:29 +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 o6FIINdc019061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 21:18:23 +0300 (EEST) (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 o6FIINYg007710; Thu, 15 Jul 2010 21:18:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FIINSJ007709; Thu, 15 Jul 2010 21:18:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 21:18:23 +0300 From: Kostik Belousov To: Dmitry Krivenok Message-ID: <20100715181823.GX2381@deviant.kiev.zoral.com.ua> References: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jn/MQTzma+jNUHFC" Content-Disposition: inline In-Reply-To: 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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:18:30 -0000 --jn/MQTzma+jNUHFC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 10:13:54PM +0400, Dmitry Krivenok wrote: > Unfortunately, one can easily miss such problems during build of the modu= le. > I'm working on a system which consists of lots of user-space programs > and kernel modules and > uses it's own complicated build system. > gcc option -Werror is not used by the build system (I believe it > should), that's why we just missed > a compiler warning when called undeclared function (actually declared > as static deep in kernel source). >=20 > Then we got kernel panic and started investigating it. > I disassembled seltdinit function and found that it takes pointer to > thread from %eax register and global kernel > functions (e.g. kern_select) calling seltdinit copy the pointer to > %eax just before "call" instruction. >=20 > Then I disassembled my own function calling seltdinit and found that > it passes the pointer via stack and > doesn't do anything with %eax register. >=20 > I'm not OS/compilers/ASM expert, but I guess that gcc is free to > optimize passing of parameters to static functions > because it has all the information about callers of these static > functions (all stuff is inside one translation unit). > So kernel functions call static functions in a right way, but modules > compiled separately may use wrong calling > convention. Your message does not contain the question, but right answer is that you should not call static functions. --jn/MQTzma+jNUHFC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw/UO8ACgkQC3+MBN1Mb4jasACaAiWFcsVIS4oembr8K0+bYKR/ jhMAnjor+jwXCBIciTiQDpMJPt8psLKK =Mx2q -----END PGP SIGNATURE----- --jn/MQTzma+jNUHFC-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 18:36: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 565F81065670 for ; Thu, 15 Jul 2010 18:36:24 +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 005C68FC27 for ; Thu, 15 Jul 2010 18:36:23 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward12.mail.yandex.net (Yandex) with ESMTP id 325F022103A6; Thu, 15 Jul 2010 22:36:22 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1279218982; bh=grgceZ81OJ5sssnBhk2+DzFm0sv1S3OZKqT6DKl7pQg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=NCW1LWOkkL8xdaXSaiHHYwZeb4n914OhdOQ8TgjjOJvMDnD/Gy2o0oAHlrr91D5fl pINVFqKsRPe63+S3IC3/HYf9LIA8XbiVzlLCJAqZs/WJKBv2z6BA4Botz6omn5jYo/ zbtupu1TBZ+EEkFjYtiU1M+dEhmi/iuTKoDqVM6A= Received: from [10.43.163.197] (static-76-197.kirovnet.ru [92.39.76.197]) by smtp11.mail.yandex.net (Yandex) with ESMTPSA id DD0DA44D8070; Thu, 15 Jul 2010 22:36:21 +0400 (MSD) Message-ID: <4C3F5514.70308@yandex.ru> Date: Thu, 15 Jul 2010 22:36:04 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100611 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov References: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD51D48E71C3208D4A04FD9C7" X-Yandex-TimeMark: 1279218982 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.mail.yandex.net Cc: freebsd-hackers@freebsd.org, Dmitry Krivenok Subject: Re: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:36:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD51D48E71C3208D4A04FD9C7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.07.2010 18:32, Kostik Belousov wrote: > The kernel linker ignores weak attribute of the symbol, as you see. > There is more bugs in this department, in regard of the list of > exported symbols from the modules. >=20 > I have a patch that fixes the issues, but I am leery to commit it, sinc= e > the fix effectively breaks significant set of the modules. Hi, Kostik i want to remind that some time ago there was a report about another bug. #include #include #include #include static int tst_modevent(module_t mod, int type, void *unused) { switch (type) { case MOD_LOAD: return (EINVAL); case MOD_UNLOAD: break; }; return (0); } static moduledata_t tstmod =3D { "tst", tst_modevent, 0 }; DECLARE_MODULE(tst, tstmod, SI_SUB_ROOT_CONF, SI_ORDER_ANY); # kldload -v ./tst.ko Loaded ./tst.ko, id=3D16 I think loading of this module should be rejected on MOD_LOAD, but it doesn't. --=20 WBR, Andrey V. Elsukov --------------enigD51D48E71C3208D4A04FD9C7 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.14 (FreeBSD) iQEcBAEBAgAGBQJMP1UUAAoJEAHF6gQQyKF67oQH/0xHmFc9+XAFCvqxAxYYyi4O ngaGasxW34/Jwpu9txBFkY/jeSGCv81ZPi/yfAxP956pbp6Fbv60/eR8gnZhvAnI 6N0KZ/fal9YgGTMwmgiERvF1oz5C4ydpn/MsEEMTk7XbC22KRIiGIZiFWyj9O0Fg JGcXt7zoMqlI3joSIXmy3W1qiMSjV5Vo1FjcY9ZGomvyfbR3wZL+5HiXG1GQdAOV SrJrYPvOcRSLev+5/GByueYAKfNR4O0FdF+EJohnrB8RfnCvQE81LlOxmevr4q6T WzBoNQvNDABmpAzlxDjM0yzVULTXkOEE5OdnObDIh8s5RwLSA+8yXmYCeD3qnfQ= =pwAX -----END PGP SIGNATURE----- --------------enigD51D48E71C3208D4A04FD9C7-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 18:52: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 0C18C1065670; Thu, 15 Jul 2010 18:52:45 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0B6A8FC1E; Thu, 15 Jul 2010 18:52:44 +0000 (UTC) Received: by qwg5 with SMTP id 5so389767qwg.13 for ; Thu, 15 Jul 2010 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=atV4FYuegbeDOqI3Kb59oLRCm41d1VIopi/+voKdfp4=; b=GCeMi4iCTtfFNgudQIxz984VtJbz5udEsrppVPdG1aXhL/DQ4Xy+N3LdYXmMH8Qt9M 2VU4JKYqX9GFyS61D33z2SG+fb+DAtwnKCpdtg2iG7cHHAOkSGwB5DuNYRr/uB4MrQCd 4NTIaxq7DzCwfVrwucNVSk/bpvUO8Pnk+YTbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=oH/lwKcw6b07tOOCXNOJ//qBafpC1rWLJpnGul+4lDOdKR4sspzSSiOmaJghLkpbYc qmRxCVFqtUcF6pdaUqc7e42Hr8KTbySZ9kcIYKXHwVFjy7C6I0Ro2hWck6ufeY+vrmj+ 4iYKUa852MrURVN3tcp+5H0eKNnUD/W5M+mpI= MIME-Version: 1.0 Received: by 10.224.65.138 with SMTP id j10mr7228232qai.147.1279219963551; Thu, 15 Jul 2010 11:52:43 -0700 (PDT) Received: by 10.229.239.5 with HTTP; Thu, 15 Jul 2010 11:52:43 -0700 (PDT) In-Reply-To: References: <20100714090454.1177b96b@ernst.jennejohn.org> Date: Thu, 15 Jul 2010 13:52:43 -0500 Message-ID: From: Alan Cox To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:52:45 -0000 On Thu, Jul 15, 2010 at 8:01 AM, Ivan Voras wrote: > On 07/14/10 18:27, Jerry Toung wrote: > > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn > > wrote: > > > >> > >> > >> Rather than commenting out the code try setting the sysctl > >> vfs.hirunningspace to various powers-of-two. Default seems to be > >> 1MB. I just changed it on the command line as a test to 2MB. > >> > >> You can do this in /etc/sysctl.conf. > >> > >> > > thank you all, that did it. The settings that Matt recommended are giving > > the same numbers > > Any objections to raising the defaults to 8 MB / 1 MB in HEAD? > > > Keep in mind that we still run on some fairly small systems with limited I/O capabilities, e.g., a typical arm platform. More generally, with the range of systems that FreeBSD runs on today, any particular choice of constants is going to perform poorly for someone. If nothing else, making these sysctls a function of the buffer cache size is probably better than any particular constants. Alan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 19:16: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 8B8AC106564A for ; Thu, 15 Jul 2010 19:16:28 +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 046C58FC1A for ; Thu, 15 Jul 2010 19:16:27 +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 o6FJGOIR023951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 22:16:24 +0300 (EEST) (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 o6FJGOJW008007; Thu, 15 Jul 2010 22:16:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FJGOVh008006; Thu, 15 Jul 2010 22:16:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 22:16:24 +0300 From: Kostik Belousov To: "Andrey V. Elsukov" Message-ID: <20100715191624.GY2381@deviant.kiev.zoral.com.ua> References: <20100715143235.GU2381@deviant.kiev.zoral.com.ua> <4C3F5514.70308@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OEa2bCMk+rg6xBXy" Content-Disposition: inline In-Reply-To: <4C3F5514.70308@yandex.ru> 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=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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, Dmitry Krivenok Subject: Re: Kernel linker and undefined references in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 19:16:28 -0000 --OEa2bCMk+rg6xBXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 10:36:04PM +0400, Andrey V. Elsukov wrote: > On 15.07.2010 18:32, Kostik Belousov wrote: > > The kernel linker ignores weak attribute of the symbol, as you see. > > There is more bugs in this department, in regard of the list of > > exported symbols from the modules. > >=20 > > I have a patch that fixes the issues, but I am leery to commit it, since > > the fix effectively breaks significant set of the modules. >=20 > Hi, Kostik >=20 > i want to remind that some time ago there was a report about another > bug. >=20 > #include > #include > #include > #include >=20 > static int > tst_modevent(module_t mod, int type, void *unused) > { > switch (type) { > case MOD_LOAD: > return (EINVAL); > case MOD_UNLOAD: > break; > }; > return (0); > } > static moduledata_t tstmod =3D { > "tst", > tst_modevent, > 0 > }; >=20 > DECLARE_MODULE(tst, tstmod, SI_SUB_ROOT_CONF, SI_ORDER_ANY); >=20 > # kldload -v ./tst.ko > Loaded ./tst.ko, id=3D16 >=20 > I think loading of this module should be rejected on MOD_LOAD, > but it doesn't. Did you tried this ? It works for me. There was a thread about the issue where apparently submitter used binutils 2.20.1. The solution of reverting r103230 was mentioned by peter. --OEa2bCMk+rg6xBXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw/XocACgkQC3+MBN1Mb4g77wCfbThSeOK4hcqZ1zLusP/r/cLZ UJkAniaNr3hMFExzLK2sDjyFNyWMqA5y =I0pQ -----END PGP SIGNATURE----- --OEa2bCMk+rg6xBXy-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 19:36:19 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 96D2D1065678 for ; Thu, 15 Jul 2010 19:36:19 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [208.92.232.93]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2558FC1E for ; Thu, 15 Jul 2010 19:36:18 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.14.3/8.14.3) with ESMTP id o6FJDs0r044157; Thu, 15 Jul 2010 13:13:55 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4C3F5D51.6000903@FreeBSD.org> Date: Thu, 15 Jul 2010 13:11:13 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100103 Thunderbird/3.0 MIME-Version: 1.0 To: Stanislav Uzunchev References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jail@FreeBSD.org, hackers@FreeBSD.org Subject: Re: libjail issues. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 19:36:19 -0000 On 07/15/10 04:12, Stanislav Uzunchev wrote: > I have found something very strange to me... It is a problem with static > allocating size of buffer where jail param is going to be coppied, using > jail_getv function from the libjails. Well for example: > > buff[size]; > jail_getv(0, "name", "1", "host.hostname", buff, NULL); > > the result for size = 64; is bsnmp.test, size = 257; is bsnmp.test, size = > 256; is bs1 ? > > #sysctl -a | grep "security.jail.param.host.hostname:" > 256 > > #jls > JID Hostname > 1 bsnmp.test > > #jls -n | grep "bs1" > returns no match. > > This is really confusing me. That's a bug in jail_getv, which I'm committing the fix for now. Unfortunately, it's too late to get it in the 8.1 release, but it will at least be in future releases. The issue is that jail_getv wrongly allocated temporary space based on the length of the parameters passed in, which don't even have values yet. The different array sizes in your sample code would coincidentally locate the "buff" array with different garbage contents, leading to different behavior with the bug. > Also i will take suggestions, what is the best way, to get and set all > value/params using the jailparam struct. > I am trying first to set the name or jid, and after that getting the values > for the rest parameters with jail_getv, but i face some problems setting > jp_value since it is type (void *). You don't value to set jp_value directly, but use the jailparam_import function. That will set jp_value correctly based on the parameter's type. - Jamie From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 21:42:55 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 2497C1065676 for ; Thu, 15 Jul 2010 21:42:55 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id CCBD48FC13 for ; Thu, 15 Jul 2010 21:42:54 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id B61A114DC146; Thu, 15 Jul 2010 23:42:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DF2i8rrDgrvy; Thu, 15 Jul 2010 23:42:50 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 663F714DBFCA; Thu, 15 Jul 2010 23:42:50 +0200 (CEST) Message-ID: <4C3F80D3.8080809@FreeBSD.org> Date: Thu, 15 Jul 2010 23:42:43 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pluknet References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> <4C3AF87B.3030707@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:42:55 -0000 Em 2010.07.13. 16:05, pluknet escreveu: > #ifndef _SYS_SYSPROTO_H_ > struct setjlimit_args { > jid_t jid; > int resource; > struct rlimit *rlp; > }; > #endif > int > setjlimit(td, uap) > struct thread *td; > struct setjlimit_args /* { > jid_t jid; > int resource; > struct rlimit *rlp; > } */ *uap; > { > > printf("%s called\n", __FUNCTION__); > > printf("resource: %d\n", uap->resource); > if (uap->resource>= JLIM_NLIMITS) { > td->td_retval[0] = -1; > return (EINVAL); > } > return (0); > } > Thanks for trying this out. I still couldn't find the problem. Is this generate code? I mean the prototype of the function. I'm using C99 syntax and I manually added the implementation, the generated code what I'm using is just what make sysent generated. Besides, the generated code in sysproto.h is different from this struct that you have here, there are padding members, as well: +struct setjlimit_args { + char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)]; + char resource_l_[PADL_(int)]; int resource; char resource_r_[PADR_(int)]; + char rlp_l_[PADL_(struct rlimit *)]; struct rlimit * rlp; char rlp_r_[PADR_(struct rlimit *)]; +}; And what do you have in syscalls.master? Is it the same as I have? +527 AUE_NULL STD { int setjlimit(__jid_t jid, int resource, \ + struct rlimit *rlp); } Gabor From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 21:52:35 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 B87E3106566C for ; Thu, 15 Jul 2010 21:52:35 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 8291F8FC0C for ; Thu, 15 Jul 2010 21:52:35 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o6FLs59A090137 for ; Thu, 15 Jul 2010 14:54:05 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C3F8322.40700@mahan.org> Date: Thu, 15 Jul 2010 14:52:34 -0700 From: Patrick Mahan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Use of printf's inside a kernel thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:52:35 -0000 Just wondering if there is some constraints to using printf() calls inside a kernel thread (created by kthread_create()). I'm currently trying to debug a worker thread but the printf's are coming out garbled. Not entirely sure why this could be occurring. OS: FreeBSD 7.3 on an Intel Xeon with 8 Gbytes of memory. Any ideas? Thanks, Patrick From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 15 23:08: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 3DC681065675 for ; Thu, 15 Jul 2010 23:08:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCBD58FC08 for ; Thu, 15 Jul 2010 23:08:26 +0000 (UTC) Received: by vws19 with SMTP id 19so2184916vws.13 for ; Thu, 15 Jul 2010 16:08:26 -0700 (PDT) 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 :reply-to:user-agent:mime-version:followup-to:to:subject:x-priority :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=xIJS+TImvTzWWpCRIS558fy9FckCBVc8wLUjZ9Y2e5c=; b=RFQwd6sktVtAMovJRyVeUSz/c8QNC98LtXSbTl1jdhHJvwFDc5cOBN8ImKbIAsGc8e 4TtYlMxmdcB5/vClKD6/+EdjoJ8Ew2sKG2cLI0pLQxKHuRf1pUFoNwK9ZRazDfrM51g4 W3k/GeNX6u4cPYG2g36juI2HJJ3rWI8BkvlVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version :followup-to:to:subject:x-priority:x-enigmail-version:openpgp :content-type:content-transfer-encoding; b=hPo0WyHQVsfIEjHlINXBoROZwPXRjY9uGVNz6/agxl4YWKtAXIBfYSNjWGRm56N1di bgevFCLoz/K7j+56ZHdfYt5C3MIqrX/4DvlHhtgZxq0chkrhgqPGBcHsb9K+7tKRP683 UgDSxthTWJ/jxfErz5ogGxRG9+Whkul21Yrkk= Received: by 10.224.60.211 with SMTP id q19mr168254qah.160.1279235305839; Thu, 15 Jul 2010 16:08:25 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id h41sm6939810qcz.25.2010.07.15.16.08.24 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 16:08:25 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3F94E7.7030705@dataix.net> Date: Thu, 15 Jul 2010 19:08:23 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 Followup-To: FreeBSD,Hackers, To: FreeBSD Hackers X-Priority: 2 (High) X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" + X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD Hackers List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:08:27 -0000 Through 3 recent ``buildkernel'' runs I have logged the following. The build logs are available to those with interest. I have tested this with three variations to the environment i.e. make.conf, src.conf, make -j{N}, & a vanilla build. The errors come up the same way but with a variation of the lines in the log file where the errors appear. I still have the tar'd object directory for the last vanilla build that was performed. Though these errors are prominent in the log I don't believe it has a negative impact other than not being traceable by dtrace. I have not observed any other impact that this could have so I decided to report what I have here for someone else to decide on the outcome. Summary of errors in the logs: ctfconvert -L VERSION -g kern_ktr.o kern_ktr.c: kern_ktr.o: Cannot get sect .bss data: Invalid section descriptor ctfconvert -L VERSION -g tcp_debug.o tcp_debug.c: tcp_debug.o: Cannot get sect .bss data: Invalid section descriptor ctfconvert -L VERSION -g clnt_rc.o ctfconvert -L VERSION -g ffs_tables.o ctfconvert -L VERSION -g ufs_gjournal.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] ctfconvert -L VERSION -g local_apic.o local_apic.c: local_apic.o: Cannot get sect .bss data: Invalid section descriptor ctfconvert -L VERSION msp34xx.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] dtrace.c: dtrace.o: Cannot get sect .bss data: Invalid section descriptor ctfconvert -L VERSION if_ed_3c503.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] ctfconvert -L VERSION if_ed_hpp.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] ctfconvert -L VERSION if_ed_sic.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] ctfconvert -L VERSION mfi_debug.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] ctfconvert -L VERSION ufs_gjournal.o ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] Regards, -- jhell,v From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 00:02: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 02F30106564A for ; Fri, 16 Jul 2010 00:02:05 +0000 (UTC) (envelope-from jhellenthal@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 A3DAC8FC13 for ; Fri, 16 Jul 2010 00:02:04 +0000 (UTC) Received: by gxk24 with SMTP id 24so1218159gxk.13 for ; Thu, 15 Jul 2010 17:02:03 -0700 (PDT) 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:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=uWiJJyZWfL6ACU1b/IGxVKB9jBVuIxcbNKHOiqFLmU4=; b=BIXuM1uDdYgOcuzU5BFaYbDRxC8PhMxJCm6lO9pv2Kf7TiWJ4ElVng5dMs2Z2LZM/g XdZEXn/UEgQ9GEZKiriBzewiX8TK8XyeMRwiHAXanvtzPJO7PzRz84yTQogqP7boFkNJ lrjRZBTbdJU63J8PsYAaaRVIDY5d91xVuigos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ga/UiXI6mdgeHtIbUak/JmGA6H165JyGERq+uOgJSzav4sxUct8E/4axvFWUu5I5dh brp2HeKz5pVqRzWwBWFKAUAhpuZMHXs5yXAgvrJn7IwYZTKSpaOWUn35A5GDumIwEhcm idvL68QeD4gYy99VjIwpw1BpWaT5WMRCvBG5g= Received: by 10.150.8.21 with SMTP id 21mr636524ybh.422.1279238523649; Thu, 15 Jul 2010 17:02:03 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id q36sm967135yba.0.2010.07.15.17.02.02 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 17:02:02 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3FA179.8040109@dataix.net> Date: Thu, 15 Jul 2010 20:02:01 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: FreeBSD Hackers References: <4C3F94E7.7030705@dataix.net> In-Reply-To: <4C3F94E7.7030705@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" + X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:02:05 -0000 I should probably note that this is on stable/8 i386 r210115. And that this was before the 210145:210147 commits. Regards, -- jhell,v From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 00:26:02 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 1D0811065673; Fri, 16 Jul 2010 00:26:02 +0000 (UTC) (envelope-from asmrookie@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 9CFB78FC08; Fri, 16 Jul 2010 00:26:01 +0000 (UTC) Received: by qyk7 with SMTP id 7so384319qyk.13 for ; Thu, 15 Jul 2010 17:26:00 -0700 (PDT) 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=DxlY2GGh2nir/zrFASXWrTQobmUF7MHb3UKqO0XMoUg=; b=TABix2h3a4zitfhV5P34ya32MIGHIHKpJ+mEPPzWNc7X+Y78iubILIqEutD4ETCH3w GUowpehnNThc07MyNMLmnGmG01eujee2MkVgv+tK9ST5J7iAjkmoEngDBFIIC9ZDk+4H JiLTnDUEjus88HVDNgtB5WarMzGs0Web4/utA= 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=vALSod/jKOlqY6MfQlSB0dbTDx5oYhocqDO+XybvAbnMP4x+Jnjc2x+cE9/TfvtY5w XblV+LTl4MNWfNgcoB33ivjEL9Wa40G935wCGr/V3bejz6mCKIXqqBc9tRmjyIL0fDVh kAQqTf5zbFfganxsb/tYbd/T2wmZSdkuGxKrc= MIME-Version: 1.0 Received: by 10.224.45.77 with SMTP id d13mr267015qaf.39.1279239960683; Thu, 15 Jul 2010 17:26:00 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.248.12 with HTTP; Thu, 15 Jul 2010 17:26:00 -0700 (PDT) In-Reply-To: References: <20100714090454.1177b96b@ernst.jennejohn.org> Date: Fri, 16 Jul 2010 02:26:00 +0200 X-Google-Sender-Auth: zJ_CgKXqci6217ICagfREffHcrk Message-ID: From: Attilio Rao To: alc@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:26:02 -0000 2010/7/15 Alan Cox : > On Thu, Jul 15, 2010 at 8:01 AM, Ivan Voras wrote: > >> On 07/14/10 18:27, Jerry Toung wrote: >> > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn >> > wrote: >> > >> >> >> >> >> >> Rather than commenting out the code try setting the sysctl >> >> vfs.hirunningspace to various powers-of-two. =C2=A0Default seems to b= e >> >> 1MB. =C2=A0I just changed it on the command line as a test to 2MB. >> >> >> >> You can do this in /etc/sysctl.conf. >> >> >> >> >> > thank you all, that did it. The settings that Matt recommended are giv= ing >> > the same numbers >> >> Any objections to raising the defaults to 8 MB / 1 MB in HEAD? >> >> >> > Keep in mind that we still run on some fairly small systems with limited = I/O > capabilities, e.g., a typical arm platform. =C2=A0More generally, with th= e range > of systems that FreeBSD runs on today, any particular choice of constants= is > going to perform poorly for someone. =C2=A0If nothing else, making these = sysctls > a function of the buffer cache size is probably better than any particula= r > constants. What about making a MD sysctl? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 00:46:35 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 2738E1065673 for ; Fri, 16 Jul 2010 00:46:35 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id BE5628FC19 for ; Fri, 16 Jul 2010 00:46:34 +0000 (UTC) Received: (qmail 23718 invoked from network); 16 Jul 2010 00:46:33 -0000 Received: from unknown (HELO ?10.0.0.174?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 16 Jul 2010 00:46:33 -0000 Message-ID: <4C3FABED.4090104@acm.poly.edu> Date: Thu, 15 Jul 2010 20:46:37 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100530) MIME-Version: 1.0 To: Patrick Mahan , freebsd-hackers@freebsd.org References: <4C3F8322.40700@mahan.org> In-Reply-To: <4C3F8322.40700@mahan.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Use of printf's inside a kernel thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:46:35 -0000 Patrick Mahan wrote: > > Just wondering if there is some constraints to using printf() calls > inside a kernel thread (created by kthread_create()). I'm currently > trying to debug a worker thread but the printf's are coming out > garbled. Not entirely sure why this could be occurring. > > OS: FreeBSD 7.3 on an Intel Xeon with 8 Gbytes of memory. > > Any ideas? > > Thanks, > > Patrick > I don't think printf() output from the kernel is serialized. The PRINTF_BUFR_SIZE=128 GENERIC kernel option in 8.x alleviates this to a good extent, and there is a reference to it in /usr/src/sys/conf/options in 7.3, so it might be available there as well. Try it out. -Boris From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 04:32: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 4C934106567D for ; Fri, 16 Jul 2010 04:32:12 +0000 (UTC) (envelope-from kabaev@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 EF0A38FC20 for ; Fri, 16 Jul 2010 04:32:11 +0000 (UTC) Received: by qyk7 with SMTP id 7so497014qyk.13 for ; Thu, 15 Jul 2010 21:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=4G/DfhADKsoCKan6jVGjC4DG5e/NjfSwxSssXYgPw90=; b=hCc0NpoRQubxHIXY6RdbmIvCg84xcBzwyJR1JYfowdNH0zQ7n1d6Kuds1ZyT0qTcUd hreQxNcjat3EktaGYsCWXELMcP/nILrU9M/lw4nIcekh/OPB+J5zHhNUO2gqUalhIZZE gogKHuKv7fqPuGqwHGOi2GM8i2v1PnWRErRc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=HvIwpHi0MnRZxI4FWEFfc/mQm6AwnzZ9uxMXc0li2UpODkhCNIY6SNoXI0ILMvb3kt 59h6EUSeo+nIz3KvuYm4TXOBZXUG9WY20iCFtBuy4NbjdeRuMorOvT58RSDbYBM46n9j kCShx8SUNRM12702yNYefUgjkVWEYyhi3OoPY= Received: by 10.224.110.206 with SMTP id o14mr457718qap.69.1279254730731; Thu, 15 Jul 2010 21:32:10 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id m24sm8101261qck.5.2010.07.15.21.32.09 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 21:32:09 -0700 (PDT) Date: Fri, 16 Jul 2010 00:31:55 -0400 From: Alexander Kabaev To: jhell Message-ID: <20100716003155.187e9b64@kan.dnsalias.net> In-Reply-To: <4C3FA179.8040109@dataix.net> References: <4C3F94E7.7030705@dataix.net> <4C3FA179.8040109@dataix.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/KBLtU+9kBZ4F082gtEQYQeV"; protocol="application/pgp-signature" Cc: FreeBSD Hackers Subject: Re: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" + X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 04:32:12 -0000 --Sig_/KBLtU+9kBZ4F082gtEQYQeV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 15 Jul 2010 20:02:01 -0400 jhell wrote: >=20 > I should probably note that this is on stable/8 i386 r210115. And that > this was before the 210145:210147 commits. >=20 This is a message from ctfconvert bogusly trying to read non-existent data from .bss. I have fix for this which I forwarded to our libelf author. The bug if harmless otherwise. --=20 Alexander Kabaev PS. I usually avoid responding to messages from strangely named entities, but there's always a place for exception... --Sig_/KBLtU+9kBZ4F082gtEQYQeV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMP+DHQ6z1jMm+XZYRAjigAJ4sZ2s7h/oBWKU6hJhCk8lph/s8pgCgwYNI HPLG66wcZO3ZdGH0jtn1PI8= =tMOX -----END PGP SIGNATURE----- --Sig_/KBLtU+9kBZ4F082gtEQYQeV-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 05: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 B3FDF1065673 for ; Fri, 16 Jul 2010 05:20:08 +0000 (UTC) (envelope-from jhellenthal@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 6CA598FC17 for ; Fri, 16 Jul 2010 05:20:08 +0000 (UTC) Received: by iwn35 with SMTP id 35so2193516iwn.13 for ; Thu, 15 Jul 2010 22:20:07 -0700 (PDT) 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:openpgp:content-type:content-transfer-encoding; bh=QU7JlLI0Ma7ffun5RIRlymQmjzV+Tbgf1hI7p2v5YEA=; b=PZweYD7TOw3WadWJNlXzSTsU0NIPtMDH2AA/sH0xgcSVMzwz5A3WZFE3sUJiaCq1Un noZxPXkpSrH/lWLuicCk41orHmD6PlIp6gLrEVKf7AsF9YAQ/iziSlfi2DPwjQuhtIQO j9jjVACkuDhDMroOjk3IOYTeMSz6Cd/y3Lxw4= 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:openpgp:content-type :content-transfer-encoding; b=t0ecgPSZSEj7nLSAkgtVh8kuElEtB1gIwXx54Clvsiot4IWTqtWOUMnl9Z5nvqd/cq sWPDzGO6MiMRhhLIJWx43/Udp/4zTDJoRzDMnxkcIuscZmUen1BGv0klbVpw8Xbo+pMF 3cdC6lGRyQfBxG/CwGlD4HFYT7wI8mXucApRM= Received: by 10.231.147.18 with SMTP id j18mr401904ibv.19.1279257607701; Thu, 15 Jul 2010 22:20:07 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id 34sm7878109ibi.12.2010.07.15.22.20.06 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 22:20:06 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3FEC05.5050009@dataix.net> Date: Fri, 16 Jul 2010 01:20:05 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Alexander Kabaev References: <4C3F94E7.7030705@dataix.net> <4C3FA179.8040109@dataix.net> <20100716003155.187e9b64@kan.dnsalias.net> In-Reply-To: <20100716003155.187e9b64@kan.dnsalias.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" + X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 05:20:08 -0000 On 07/16/2010 00:31, Alexander Kabaev wrote: > On Thu, 15 Jul 2010 20:02:01 -0400 > jhell wrote: > >> >> I should probably note that this is on stable/8 i386 r210115. And that >> this was before the 210145:210147 commits. >> > This is a message from ctfconvert bogusly trying to read non-existent > data from .bss. I have fix for this which I forwarded to our libelf > author. The bug if harmless otherwise. > Alright, thank you for confirming this. I thought this was the case but did not want to make any assumptions as to exactly what it was caused by even though the error that was popping up looked like ctfconvert's fault. Thanks again, -- jhell,v From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 09:30: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 F151A1065676; Fri, 16 Jul 2010 09:30:46 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEF08FC21; Fri, 16 Jul 2010 09:30:46 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6G9UhOK002430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 19:30:44 +1000 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 o6G9Ugc5027340; Fri, 16 Jul 2010 19:30:42 +1000 (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 o6G9UfrO027339; Fri, 16 Jul 2010 19:30:41 +1000 (EST) (envelope-from peter) Date: Fri, 16 Jul 2010 19:30:41 +1000 From: Peter Jeremy To: alc@freebsd.org Message-ID: <20100716093041.GB26367@server.vk2pj.dyndns.org> References: <20100714090454.1177b96b@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: 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: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 09:30:47 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Regarding vfs.lorunningspace and vfs.hirunningspace... On 2010-Jul-15 13:52:43 -0500, Alan Cox wrote: >Keep in mind that we still run on some fairly small systems with limited I= /O >capabilities, e.g., a typical arm platform. More generally, with the range >of systems that FreeBSD runs on today, any particular choice of constants = is >going to perform poorly for someone. If nothing else, making these sysctls >a function of the buffer cache size is probably better than any particular >constants. That sounds reasonable but brings up a related issue - the buffer cache. Given the unified VM system no longer needs a traditional Unix buffer cache, what is the buffer cache still used for? Is the current tuning formula still reasonable (for virtually all current systems it's basically 10MB + 10% RAM)? How can I measure the effectiveness of the buffer cache? The buffer cache size is also very tightly constrained (vfs.hibufspace and vfs.lobufspace differ by 64KB) and at least one of the underlying tuning parameters have comments at variance with current reality: In : * MAXBSIZE - Filesystems are made out of blocks of at most MAXBSIZE bytes * per block. MAXBSIZE may be made larger without effecting =2E.. * * BKVASIZE - Nominal buffer space per buffer, in bytes. BKVASIZE is the =2E.. * The default is 16384, roughly 2x the block size used by a * normal UFS filesystem. */ #define MAXBSIZE 65536 /* must be power of 2 */ #define BKVASIZE 16384 /* must be power of 2 */ There's no mention of the 64KiB limit in newfs(8) and I recall seeing occasional comments from people who have either tried or suggested trying larger blocksizes. Likewise, the default UFS blocksize has been 16KiB for quite a while. Are the comments still valid and, if so, should BKVASIZE be doubled to 32768 and a suitable note added to newfs(8) regarding the maximum block size? --=20 Peter Jeremy --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxAJsEACgkQ/opHv/APuIdtNwCcC7os0X2nYev7WEg1gfMLtOy+ 910AoKokwZhcQWpcrcqCGqmSihJa2CQo =x3RR -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 10:17:39 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 9EA1A1065674; Fri, 16 Jul 2010 10:17:39 +0000 (UTC) (envelope-from pluknet@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 089108FC15; Fri, 16 Jul 2010 10:17:38 +0000 (UTC) Received: by wyf22 with SMTP id 22so1903666wyf.13 for ; Fri, 16 Jul 2010 03:17:37 -0700 (PDT) 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=IdcPZtrWqv6YboyKc+aNQv3ep8RHUQx9mrVoddfghQU=; b=MpU9nSPXSXwB9F2AQThQ3PcHqFTWg2J/H3VUPm/YePQ09srMnpznKnID+zVTvFP2pn GY4KBzpTZYxIV0ZqaQDW02IJZBxGHhhe2CdPVUH4P5bnt6kyvKO4cZM1r0xywu4l+mbp c8P0zNHi5Cfl2OS5vSrI8h1zFutV9UwK3wyJE= 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=FE+LR4GzTD7eYT+nOW2uxLimq80l4gUKpp5Xzi2RlkRc9XVZlVRYbGodXzlmrSel20 ++zHeKMEk7yEokmmpiRHurOWMATZhjfxmR8ssEuQ9TJse7+Yk5F1RH5/ypbBp3oiVz+2 hY7p6gl71/qOCoutEMAVgxh1VsVuXbpjyI1qI= MIME-Version: 1.0 Received: by 10.227.147.211 with SMTP id m19mr748689wbv.63.1279275457650; Fri, 16 Jul 2010 03:17:37 -0700 (PDT) Received: by 10.216.137.23 with HTTP; Fri, 16 Jul 2010 03:17:37 -0700 (PDT) In-Reply-To: <4C3F80D3.8080809@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> <4C3AF87B.3030707@FreeBSD.org> <4C3F80D3.8080809@FreeBSD.org> Date: Fri, 16 Jul 2010 14:17:37 +0400 Message-ID: From: pluknet To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 10:17:39 -0000 On 16 July 2010 01:42, Gabor Kovesdan wrote: > Em 2010.07.13. 16:05, pluknet escreveu: >> >> #ifndef _SYS_SYSPROTO_H_ >> struct setjlimit_args { >> =A0 =A0 =A0 =A0 jid_t =A0 jid; >> =A0 =A0 =A0 =A0 int =A0 =A0 resource; >> =A0 =A0 =A0 =A0 struct rlimit *rlp; >> }; >> #endif >> int >> setjlimit(td, uap) >> =A0 =A0 =A0 =A0 struct thread *td; >> =A0 =A0 =A0 =A0 struct setjlimit_args /* { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jid_t =A0 jid; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 resource; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct rlimit *rlp; >> =A0 =A0 =A0 =A0 } */ *uap; >> { >> >> =A0 =A0 =A0 =A0 printf("%s called\n", __FUNCTION__); >> >> =A0 =A0 =A0 =A0 printf("resource: %d\n", uap->resource); >> =A0 =A0 =A0 =A0 if (uap->resource>=3D JLIM_NLIMITS) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 td->td_retval[0] =3D -1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EINVAL); >> =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 =A0 return (0); >> } >> > > Thanks for trying this out. I still couldn't find the problem. Is this > generate code? I mean the prototype of the function. I'm using C99 syntax > and I manually added the implementation, the generated code what I'm usin= g > is just what make sysent generated. Besides, the generated code in > sysproto.h is different from this struct that you have here, there are > padding members, as well: > > +struct setjlimit_args { > + =A0 =A0 =A0 char jid_l_[PADL_(__jid_t)]; __jid_t jid; char > jid_r_[PADR_(__jid_t)]; > + =A0 =A0 =A0 char resource_l_[PADL_(int)]; int resource; char > resource_r_[PADR_(int)]; > + =A0 =A0 =A0 char rlp_l_[PADL_(struct rlimit *)]; struct rlimit * rlp; c= har > rlp_r_[PADR_(struct rlimit *)]; > +}; > > > And what do you have in syscalls.master? Is it the same as I have? > > +527 AUE_NULL STD { int setjlimit(__jid_t jid, int resource= , \ > + struct rlimit *rlp); } Almost the same (#__jid_t#jid_t#). struct setjlimit_args { char jid_l_[PADL_(jid_t)]; jid_t jid; char jid_r_[PADR_(jid_t)]; char resource_l_[PADL_(int)]; int resource; char resource_r_[PADR_(int)]; char rlp_l_[PADL_(struct rlimit *)]; struct rlimit * rlp; char rlp_r_[PADR_(struct rlimit *)]; }; 526 AUE_NULL STD { int setjlimit(jid_t jid, int resource, \ struct rlimit *rlp); } The difference (and probably a trigger of bug elsewhere) might be in that this lives on amd64 arch (while yours on i386 afair). Just a food for thoughts. --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 10:29:23 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 2705C1065675 for ; Fri, 16 Jul 2010 10:29:23 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id D24CF8FC1C for ; Fri, 16 Jul 2010 10:29:22 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 1377314DC162; Fri, 16 Jul 2010 12:29:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y6Mlr01G84uD; Fri, 16 Jul 2010 12:29:17 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id C8FDF14DC159; Fri, 16 Jul 2010 12:29:17 +0200 (CEST) Message-ID: <4C403476.4020704@FreeBSD.org> Date: Fri, 16 Jul 2010 12:29:10 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pluknet References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> <4C3AF87B.3030707@FreeBSD.org> <4C3F80D3.8080809@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 10:29:23 -0000 Em 2010.07.16. 12:17, pluknet escreveu: > Almost the same (#__jid_t#jid_t#). > > Did you have to include any header for that? IIRC, I used __jid_t because it didn't compile with jid_t. > The difference (and probably a trigger of bug elsewhere) might be in > that this lives > on amd64 arch (while yours on i386 afair). Just a food for thoughts. > Yes, and now I also added the entries to sys/compat/freebsd32/syscalls.master, although I think it's just for 32-bit binaries on 64-bit systems but let's see if that helps. Thanks for your help. Gabor From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 16 23:33: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 B90E01065675; Fri, 16 Jul 2010 23:33:45 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 743D08FC08; Fri, 16 Jul 2010 23:33:45 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id E101E2C2ADC; Fri, 16 Jul 2010 18:33:44 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id psDCIW6jhpCh; Fri, 16 Jul 2010 18:33:37 -0500 (CDT) Received: from [10.209.194.97] (unknown [10.209.194.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 1578F2C2ACE; Fri, 16 Jul 2010 18:33:37 -0500 (CDT) Message-ID: <4C40EC32.3030700@cs.rice.edu> Date: Fri, 16 Jul 2010 18:33:06 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Peter Jeremy References: <20100714090454.1177b96b@ernst.jennejohn.org> <20100716093041.GB26367@server.vk2pj.dyndns.org> In-Reply-To: <20100716093041.GB26367@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: alc@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: disk I/O, VFS hirunningspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 23:33:45 -0000 Peter Jeremy wrote: > Regarding vfs.lorunningspace and vfs.hirunningspace... > > On 2010-Jul-15 13:52:43 -0500, Alan Cox wrote: > >> Keep in mind that we still run on some fairly small systems with limited I/O >> capabilities, e.g., a typical arm platform. More generally, with the range >> of systems that FreeBSD runs on today, any particular choice of constants is >> going to perform poorly for someone. If nothing else, making these sysctls >> a function of the buffer cache size is probably better than any particular >> constants. >> > > That sounds reasonable but brings up a related issue - the buffer > cache. Given the unified VM system no longer needs a traditional Unix > buffer cache, what is the buffer cache still used for? Today, it is essentially a mapping cache. So, what does that mean? After you've set aside a modest amount of physical memory for the kernel to hold its own internal data structures, all of the remaining physical memory can potentially be used to cache file data. However, on many architectures this is far more memory than the kernel can instantaneously access. Consider i386. You might have 4+ GB of physical memory, but the kernel address space is (by default) only 1 GB. So, at any instant in time, only a fraction of the physical memory is instantaneously accessible to the kernel. In general, to access an arbitrary physical page, the kernel is going to have to replace an existing virtual-to-physical mapping in its address space with one for the desired page. (Generally speaking, on most architectures, even the kernel can't directly access physical memory that isn't mapped by a virtual address.) The buffer cache is essentially a region of the kernel address space that is dedicated to mappings to physical pages containing cached file data. As applications access files, the kernel dynamically maps (and unmaps) physical pages containing cached file data into this region. Once the desired pages are mapped, then read(2) and write(2) can essentially "bcopy" from the buffer cache mapping to the application's buffer. (Understand that this buffer cache mapping is a prerequisite for the copy out to occur.) So, why did I call it a mapping cache? There is generally locality in the access to file data. So, rather than map and unmap the desired physical pages on every read and write, the mappings to file data are allowed to persist and are managed much like many other kinds of caches. When the kernel needs to map a new set of file pages, it finds an older, not-so-recently used mapping and destroys it, allowing those kernel virtual addresses to be remapped to the new pages. So far, I've used i386 as a motivating example. What of other architectures? Most 64-bit machines take advantage of their large address space by implementing some form of "direct map" that provides instantaneous access to all of physical memory. (Again, I use "instantaneous" to mean that the kernel doesn't have to dynamically create a virtual-to-physical mapping before being able to access the data.) On these machines, you could, in principle, use the direct map to implement the "bcopy" to the application's buffer. So, what is the point of the buffer cache on these machines? A trivial benefit is that the file pages are mapped contiguously in the buffer cache. Even though the underlying physical pages may be scattered throughout the physical address space, they are mapped contiguously. So, the "bcopy" doesn't need to worry about every page boundary, only buffer boundaries. The buffer cache also plays a role in the page replacement mechanism. Once mapped into the buffer cache, a page is "wired", that is, it removed from the paging lists, where the page daemon could reclaim it. However, a page in the buffer cache should really be thought of as being "active". In fact, when a page is unmapped from the buffer cache, it is placed at the tail of the virtual memory system's "inactive" list. The same place where the virtual memory system would place a physical page that it is transitioning from "active" to "inactive". If an application later performs a read(2) from or write(2) to the same page, that page will be removed from the "inactive" list and mapped back into the buffer cache. So, the mapping and unmapping process contributes to creating an LRU-ordered "inactive" queue. Finally, the buffer cache limits the amount of dirty file system data that is cached in memory. > ... Is the current > tuning formula still reasonable (for virtually all current systems > it's basically 10MB + 10% RAM)? It's probably still good enough. However, this is not a statement for which I have supporting data. So, I reserve the right to change my opinion. :-) Consider what the buffer cache now does. It's just a mapping cache. Increasing the buffer cache size doesn't affect (much) the amount of physical memory available for caching file data. So, unlike ancient times, increasing the size of the buffer cache isn't going to have nearly the same effect on the amount of actual I/O that your machine does. For some workloads, increasing the buffer cache size may have greater impact on CPU overhead than I/O overhead. For example, all of your file data might fit into physical memory, but you're doing random read accesses to it. That would cause the buffer cache to thrash, even though you wouldn't do any actual I/O. Unfortunately, mapping pages into the buffer cache isn't trivial. For example, it requires every processor to be interrupted to invalidate some entries from its TLB. (This is a so-called "TLB shootdown".) > ... How can I measure the effectiveness > of the buffer cache? > > I'm not sure that I can give you a short answer to this question. > The buffer cache size is also very tightly constrained (vfs.hibufspace > and vfs.lobufspace differ by 64KB) and at least one of the underlying > tuning parameters have comments at variance with current reality: > In: > > * MAXBSIZE - Filesystems are made out of blocks of at most MAXBSIZE bytes > * per block. MAXBSIZE may be made larger without effecting > ... > * > * BKVASIZE - Nominal buffer space per buffer, in bytes. BKVASIZE is the > ... > * The default is 16384, roughly 2x the block size used by a > * normal UFS filesystem. > */ > #define MAXBSIZE 65536 /* must be power of 2 */ > #define BKVASIZE 16384 /* must be power of 2 */ > > There's no mention of the 64KiB limit in newfs(8) and I recall seeing > occasional comments from people who have either tried or suggested > trying larger blocksizes. I believe that larger than 64KB would fail an assertion. > Likewise, the default UFS blocksize has > been 16KiB for quite a while. Are the comments still valid and, if so, > should BKVASIZE be doubled to 32768 and a suitable note added to newfs(8) > regarding the maximum block size? > > If I recall correctly, increasing BKVASIZE would only reduce the number buffer headers. In other words, it might avoid wasting some memory on buffer headers that won't be used. Alan From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 13:56: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 2974C106566B for ; Sat, 17 Jul 2010 13:56:18 +0000 (UTC) (envelope-from joris.dedieu@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 A8C7C8FC0A for ; Sat, 17 Jul 2010 13:56:17 +0000 (UTC) Received: by ewy26 with SMTP id 26so1161040ewy.13 for ; Sat, 17 Jul 2010 06:56:15 -0700 (PDT) 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=3LR4Fn354UeoHZ+yOnQGLUF0rpDYQ3nTYHsWyTLwaW8=; b=FxsWR0oaQUnY1RaAlLlUVTvaZUBNQNJ7snJ83xcOVrblpr0GioSydnIeNM5SD3zCjd IktVzR6gEUUUSQ7V8Ad3gLwHemCEVHrPCiaJmYwRmPsaNb5Wf7obk3Chy8O66oXv0tKb EPpeAk6jBvEkop7ICn3XEch/uy8lY7aCkhFpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=muETtJtVgjmorvJPVxhUs2GJ5yLJPx3M5QyuznkeoSuhsF2AQHAx19NuAfFNp8EhMg nRps9MUgOb6cgk+AdXmeX2nxq6mMO5VuWYvtM1pL+VM3dJfN0mXZhZVC+92PYwJ37ut2 WAdq4b3SZ5ntPJcjW36XYLK5FRiuuOE+2b8wY= MIME-Version: 1.0 Received: by 10.213.13.133 with SMTP id c5mr692557eba.4.1279373648934; Sat, 17 Jul 2010 06:34:08 -0700 (PDT) Received: by 10.213.36.15 with HTTP; Sat, 17 Jul 2010 06:34:08 -0700 (PDT) Date: Sat, 17 Jul 2010 15:34:08 +0200 Message-ID: From: joris dedieu To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0015174bdea4e13a5f048b95636a Subject: [PATCH] allow empty files creation with install 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, 17 Jul 2010 13:56:18 -0000 --0015174bdea4e13a5f048b95636a Content-Type: text/plain; charset=ISO-8859-1 This patch add a -t switch to install(3). This is a small feature for lazy sysadmins. before : touch /usr/home/foo/.history /usr/home/foo/.bash_history chown foo /usr/home/foo/.history /usr/home/foo/.bash_history chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history after : install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history /usr/home/foo/.bash_history Regards, Joris --0015174bdea4e13a5f048b95636a Content-Type: application/octet-stream; name="xinstall.patch" Content-Disposition: attachment; filename="xinstall.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbqhwci90 ZGlmZiAtTnVyIHVzci5iaW4veGluc3RhbGwub3JpZy9pbnN0YWxsLjEgdXNyLmJpbi94aW5zdGFs bC9pbnN0YWxsLjEKLS0tIHVzci5iaW4veGluc3RhbGwub3JpZy9pbnN0YWxsLjEJMjAxMC0wNy0w NSAwODozNTowMS4wMDAwMDAwMDAgKzAyMDAKKysrIHVzci5iaW4veGluc3RhbGwvaW5zdGFsbC4x CTIwMTAtMDctMTcgMTQ6NTk6NDAuMTI3MDI0NTE5ICswMjAwCkBAIC02Miw2ICs2MiwxNSBAQAog Lk9wIEZsIG0gQXIgbW9kZQogLk9wIEZsIG8gQXIgb3duZXIKIC5BciBkaXJlY3RvcnkgLi4uCisu Tm0KKy5GbCB0CisuT3AgRmwgdgorLk9wIEZsIGcgQXIgZ3JvdXAKKy5PcCBGbCBmIEFyIGZsYWdz CisuT3AgRmwgbSBBciBtb2RlCisuT3AgRmwgbyBBciBvd25lcgorLkFyIGZpbGUgLi4uCisKIC5T aCBERVNDUklQVElPTgogVGhlIGZpbGUocykgYXJlIGNvcGllZAogdG8gdGhlIHRhcmdldCBmaWxl IG9yIGRpcmVjdG9yeS4KQEAgLTExMiw2ICsxMjEsOCBAQAogLkl0IEZsIGQKIENyZWF0ZSBkaXJl Y3Rvcmllcy4KIE1pc3NpbmcgcGFyZW50IGRpcmVjdG9yaWVzIGFyZSBjcmVhdGVkIGFzIHJlcXVp cmVkLgorLkl0IEZsIHQKK0NyZWF0ZSBhbiBlbXB0eSBmaWxlCiAuSXQgRmwgZgogU3BlY2lmeSB0 aGUgdGFyZ2V0J3MgZmlsZSBmbGFnczsgc2VlCiAuWHIgY2hmbGFncyAxCkZpbGVzIHhpbnN0YWxs Lm9yaWcvaW5zdGFsbC5vbGQgYW5kIHhpbnN0YWxsL2luc3RhbGwub2xkIGRpZmZlcgpkaWZmIC1O dXIgdXNyLmJpbi94aW5zdGFsbC5vcmlnL3hpbnN0YWxsLmMgdXNyLmJpbi94aW5zdGFsbC94aW5z dGFsbC5jCi0tLSB1c3IuYmluL3hpbnN0YWxsLm9yaWcveGluc3RhbGwuYwkyMDEwLTA3LTA1IDA4 OjM1OjAxLjAwMDAwMDAwMCArMDIwMAorKysgdXNyLmJpbi94aW5zdGFsbC94aW5zdGFsbC5jCTIw MTAtMDctMTcgMTQ6NTk6MTUuMTgxNDM1MjUzICswMjAwCkBAIC04Miw3ICs4Miw3IEBACiBzdHJ1 Y3QgZ3JvdXAgKmdwOwogZ2lkX3QgZ2lkOwogdWlkX3QgdWlkOwotaW50IGRvYmFja3VwLCBkb2Nv bXBhcmUsIGRvZGlyLCBkb3ByZXNlcnZlLCBkb3N0cmlwLCBub21tYXAsIHNhZmVjb3B5LCB2ZXJi b3NlOworaW50IGRvYmFja3VwLCBkb2NvbXBhcmUsIGRvZGlyLCBkb3ByZXNlcnZlLCBkb3N0cmlw LCBkb2ZpbGUsIGRvbW9kZSwgbm9tbWFwLCBzYWZlY29weSwgdmVyYm9zZTsKIG1vZGVfdCBtb2Rl ID0gU19JUldYVSB8IFNfSVJHUlAgfCBTX0lYR1JQIHwgU19JUk9USCB8IFNfSVhPVEg7CiBjb25z dCBjaGFyICpzdWZmaXggPSBCQUNLVVBfU1VGRklYOwogCkBAIC05NCw2ICs5NCw3IEBACiB2b2lk CWluc3RhbGxfZGlyKGNoYXIgKik7CiB1X2xvbmcJbnVtZXJpY19pZChjb25zdCBjaGFyICosIGNv bnN0IGNoYXIgKik7CiB2b2lkCXN0cmlwKGNvbnN0IGNoYXIgKik7Cit2b2lkCXRvdWNoX2ZpbGUo Y2hhciAqLCB1X2ludCk7CiBpbnQJdHJ5bW1hcChpbnQpOwogdm9pZAl1c2FnZSh2b2lkKTsKIApA QCAtMTEwLDcgKzExMSw3IEBACiAKIAlpZmxhZ3MgPSAwOwogCWdyb3VwID0gb3duZXIgPSBOVUxM OwotCXdoaWxlICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgIkI6YkNjZGY6ZzpNbTpvOnBTc3Yi KSkgIT0gLTEpCisJd2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiQjpiQ2NkZjpnOk1t Om86cFNzdHYiKSkgIT0gLTEpCiAJCXN3aXRjaCgoY2hhciljaCkgewogCQljYXNlICdCJzoKIAkJ CXN1ZmZpeCA9IG9wdGFyZzsKQEAgLTE0MCw2ICsxNDEsNyBAQAogCQkJbm9tbWFwID0gMTsKIAkJ CWJyZWFrOwogCQljYXNlICdtJzoKKwkJCWRvbW9kZSA9IDE7CiAJCQlpZiAoIShzZXQgPSBzZXRt b2RlKG9wdGFyZykpKQogCQkJCWVycngoRVhfVVNBR0UsICJpbnZhbGlkIGZpbGUgbW9kZTogJXMi LAogCQkJCSAgICAgb3B0YXJnKTsKQEAgLTE1OCw2ICsxNjAsOSBAQAogCQljYXNlICdzJzoKIAkJ CWRvc3RyaXAgPSAxOwogCQkJYnJlYWs7CisJCWNhc2UgJ3QnOgorCQkJZG9maWxlID0gMTsKKwkJ CWJyZWFrOwogCQljYXNlICd2JzoKIAkJCXZlcmJvc2UgPSAxOwogCQkJYnJlYWs7CkBAIC0xNjgs MTkgKzE3MywyNyBAQAogCWFyZ2MgLT0gb3B0aW5kOwogCWFyZ3YgKz0gb3B0aW5kOwogCi0JLyog c29tZSBvcHRpb25zIG1ha2Ugbm8gc2Vuc2Ugd2hlbiBjcmVhdGluZyBkaXJlY3RvcmllcyAqLwor CS8qIHNvbWUgb3B0aW9ucyBtYWtlIG5vIHNlbnNlIHdoZW4gY3JlYXRpbmcgZGlyZWN0b3JpZXMg b3IgZmlsZXMgKi8KIAlpZiAoZG9zdHJpcCAmJiBkb2RpcikgewogCQl3YXJueCgiLWQgYW5kIC1z IG1heSBub3QgYmUgc3BlY2lmaWVkIHRvZ2V0aGVyIik7CiAJCXVzYWdlKCk7CiAJfQorCWlmIChk b3N0cmlwICYmIGRvZmlsZSkgeworCQl3YXJueCgiLXQgYW5kIC1zIG1heSBub3QgYmUgc3BlY2lm aWVkIHRvZ2V0aGVyIik7CisJCXVzYWdlKCk7CisJfQorCWlmIChkb2RpciAmJiBkb2ZpbGUpIHsK KwkJd2FybngoIi10IGFuZCAtZCBtYXkgbm90IGJlIHNwZWNpZmllZCB0b2dldGhlciIpOworCQl1 c2FnZSgpOworCX0KIAogCWlmIChnZXRlbnYoIkRPTlRTVFJJUCIpICE9IE5VTEwpIHsKIAkJd2Fy bngoIkRPTlRTVFJJUCBzZXQgLSB3aWxsIG5vdCBzdHJpcCBpbnN0YWxsZWQgYmluYXJpZXMiKTsK IAkJZG9zdHJpcCA9IDA7CiAJfQogCi0JLyogbXVzdCBoYXZlIGF0IGxlYXN0IHR3byBhcmd1bWVu dHMsIGV4Y2VwdCB3aGVuIGNyZWF0aW5nIGRpcmVjdG9yaWVzICovCi0JaWYgKGFyZ2MgPT0gMCB8 fCAoYXJnYyA9PSAxICYmICFkb2RpcikpCisJLyogbXVzdCBoYXZlIGF0IGxlYXN0IHR3byBhcmd1 bWVudHMsIGV4Y2VwdCB3aGVuIGNyZWF0aW5nIGZpbGVzIG9yIGRpcmVjdG9yaWVzICovCisJaWYg KGFyZ2MgPT0gMCAgfHwgKGFyZ2MgPT0gMSAmJiAhKGRvZGlyIHx8IGRvZmlsZSkpKQogCQl1c2Fn ZSgpOwogCiAJLyogbmVlZCB0byBtYWtlIGEgdGVtcCBjb3B5IHNvIHdlIGNhbiBjb21wYXJlIHN0 cmlwcGVkIHZlcnNpb24gKi8KQEAgLTIxMSw2ICsyMjQsMTMgQEAKIAkJLyogTk9UUkVBQ0hFRCAq LwogCX0KIAorCWlmIChkb2ZpbGUpIHsKKwkJZm9yICg7ICphcmd2ICE9IE5VTEw7ICsrYXJndikK KwkJCXRvdWNoX2ZpbGUoKmFyZ3YsIGlmbGFncyk7CisJCWV4aXQoRVhfT0spOworCQkvKiBOT1RS RUFDSEVEICovCisJfQorCiAJbm9fdGFyZ2V0ID0gc3RhdCh0b19uYW1lID0gYXJndlthcmdjIC0g MV0sICZ0b19zYik7CiAJaWYgKCFub190YXJnZXQgJiYgU19JU0RJUih0b19zYi5zdF9tb2RlKSkg ewogCQlmb3IgKDsgKmFyZ3YgIT0gdG9fbmFtZTsgKythcmd2KQpAQCAtNzY3LDYgKzc4Nyw0NyBA QAogfQogCiAvKgorICogdG91Y2hfZmlsZSAtLQorICoJY3JlYXRlIGFuIGVtcHR5IGZpbGUKKyAq Lwordm9pZAordG91Y2hfZmlsZShjaGFyICpwYXRoLCB1X2ludCBmbGFncykKK3sKKwlzdHJ1Y3Qg c3RhdCBzYjsKKwlpbnQgZmQ7CisJaWYgKHN0YXQocGF0aCwgJnNiKSkgeworCQlmZCA9IG9wZW4o cGF0aCwgIE9fV1JPTkxZIHwgT19DUkVBVCwKKwkJCURFRkZJTEVNT0RFKTsKKwkJaWYgKGZkIDwg MCkgCQorCQkJZXJyKEVYX09TRVJSLCAidG91Y2ggJXMiLCBwYXRoKTsKKwkJZWxzZSBjbG9zZShm ZCk7CisJfSBlbHNlIGlmICh2ZXJib3NlKQorCQkodm9pZClwcmludGYoImluc3RhbGw6IHRvdWNo ICVzXG4iLCBwYXRoKTsKKwllbHNlIGlmICghU19JU1JFRyhzYi5zdF9tb2RlKSkKKwkJZXJyeChF WF9PU0VSUiwgIiVzIGV4aXN0cyBidXQgaXMgbm90IGEgcmVndWxhciBmaWxlIiwgcGF0aCk7CisJ aWYgKChnaWQgIT0gKGdpZF90KS0xIHx8IHVpZCAhPSAodWlkX3QpLTEpICYmIGNob3duKHBhdGgs IHVpZCwgZ2lkKSkKKwkJd2FybigiY2hvd24gJXU6JXUgJXMiLCB1aWQsIGdpZCwgcGF0aCk7CisJ LyogQWxsb3cgbW9kZSBjaGFuZ2Ugb24gZmlsZSBidXQgZG9uJ3QgYXBwbHkgZGVmYXVsdCBtb2Rl IHdoaWNoIGhhcyBleGVjCisJICogYml0CisJICovCisJaWYgKGRvbW9kZSkgeworCQlpZiAoY2ht b2QocGF0aCwgbW9kZSkpCisJCQl3YXJuKCJjaG1vZCAlbyAlcyIsIG1vZGUsIHBhdGgpOworCX0K KwlpZiAoZmxhZ3MpIHsKKwkJaWYgKGNoZmxhZ3MocGF0aCwgZmxhZ3MpIDwgMCkgeworCQkJLyog ZnMgZG9lc24ndCBzdXBwb3J0IGZsYWdzICovCisJCQlpZiAoZXJybm8gPT0gRU9QTk9UU1VQUCkK KwkJCQl3YXJuKCIlczogY2hmbGFncyIsIHBhdGgpOworCQkJZWxzZQorCQkJCWVycihFWF9PU0VS UiwgIiVzOiBjaGZsYWdzIiwgcGF0aCk7CisJCX0KKwl9CisKK30KKworCisvKgogICogdXNhZ2Ug LS0KICAqCXByaW50IGEgdXNhZ2UgbWVzc2FnZSBhbmQgZGllCiAgKi8KQEAgLTc3OCw3ICs4Mzks OCBAQAogIiAgICAgICAgICAgICAgIFstbyBvd25lcl0gZmlsZTEgZmlsZTJcbiIKICIgICAgICAg aW5zdGFsbCBbLWJDY3BTc3ZdIFstQiBzdWZmaXhdIFstZiBmbGFnc10gWy1nIGdyb3VwXSBbLW0g bW9kZV1cbiIKICIgICAgICAgICAgICAgICBbLW8gb3duZXJdIGZpbGUxIC4uLiBmaWxlTiBkaXJl Y3RvcnlcbiIKLSIgICAgICAgaW5zdGFsbCAtZCBbLXZdIFstZyBncm91cF0gWy1tIG1vZGVdIFst byBvd25lcl0gZGlyZWN0b3J5IC4uLlxuIik7CisiICAgICAgIGluc3RhbGwgLWQgWy12XSBbLWcg Z3JvdXBdIFstbSBtb2RlXSBbLW8gb3duZXJdIGRpcmVjdG9yeSAuLi5cbiIKKyIgICAgICAgaW5z dGFsbCAtdCBbLXZdIFstZyBncm91cF0gWy1mIGZsYWdzXSBbLW0gbW9kZV0gWy1vIG93bmVyXSBm aWxlIC4uLlxuIik7CiAJZXhpdChFWF9VU0FHRSk7CiAJLyogTk9UUkVBQ0hFRCAqLwogfQo= --0015174bdea4e13a5f048b95636a-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 14:11:41 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 D1857106566B for ; Sat, 17 Jul 2010 14:11:41 +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 4E12D8FC15 for ; Sat, 17 Jul 2010 14:11:40 +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 o6HEBafj034245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Jul 2010 17:11:36 +0300 (EEST) (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 o6HEBaKc003900; Sat, 17 Jul 2010 17:11:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6HEBaum003899; Sat, 17 Jul 2010 17:11:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Jul 2010 17:11:36 +0300 From: Kostik Belousov To: joris dedieu Message-ID: <20100717141136.GH2381@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5joxkA65nhhP20dL" Content-Disposition: inline In-Reply-To: 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.5 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: [PATCH] allow empty files creation with install 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, 17 Jul 2010 14:11:41 -0000 --5joxkA65nhhP20dL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 17, 2010 at 03:34:08PM +0200, joris dedieu wrote: > This patch add a -t switch to install(3). This is a small feature for > lazy sysadmins. >=20 > before : >=20 > touch /usr/home/foo/.history /usr/home/foo/.bash_history > chown foo /usr/home/foo/.history /usr/home/foo/.bash_history > chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history > chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history >=20 > after : >=20 > install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history > /usr/home/foo/.bash_history >=20 Isn't /dev/null as a source file work better ? --5joxkA65nhhP20dL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxBuhgACgkQC3+MBN1Mb4girgCdFcSXrQzl6fGE602syziU+/WM qRcAniD68jpSHbvNxllZP/5HDr8m/wG1 =GD2J -----END PGP SIGNATURE----- --5joxkA65nhhP20dL-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 14:11: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 035B11065785 for ; Sat, 17 Jul 2010 14:11:56 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9BD38FC08 for ; Sat, 17 Jul 2010 14:11:55 +0000 (UTC) Received: by pxi8 with SMTP id 8so1504641pxi.13 for ; Sat, 17 Jul 2010 07:11:55 -0700 (PDT) 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=5bHA5y7o0doKDz/SIfqw2HtVfidu3NXcTJsJR7y4TY4=; b=iH8OagThBvqBK1bw5TLIqNR1F0fn1G3182ja/sclmtX2ZfwqLNcty0kFbHfsAoKmb3 V5d5GlQbNBORxC+VSsrJfiDmIqlguVx5tfiE9UjKzzjWd0qhKRsLNWff6+XNfBNoHi9E kc47gtE+WeneL9QG5UfhQg1QRZmCa6HoScTVc= 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=Qji/4w4TOfhwDY6rBXe6P+6/FH31ocqYIp1E8YseFMaxo28IoEyjcZOdJevEvs87BJ UmJMS1c5+9KwNsEWWOc2S/Gj6Fw+2lPdCrVSOJ/l5iD0YZVSXObtElEBSnSb32LH0jQN +MuWTQ0MOHYuk9uIEMtLxWyqk7SVdye+PExLY= Received: by 10.142.216.21 with SMTP id o21mr3371049wfg.231.1279375915096; Sat, 17 Jul 2010 07:11:55 -0700 (PDT) Received: from localhost ([120.50.40.184]) by mx.google.com with ESMTPS id c15sm14578173rvi.23.2010.07.17.07.11.47 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 07:11:53 -0700 (PDT) From: Anonymous To: joris dedieu References: Date: Sat, 17 Jul 2010 18:11:29 +0400 In-Reply-To: (joris dedieu's message of "Sat, 17 Jul 2010 15:34:08 +0200") Message-ID: <86630emc4u.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; charset=us-ascii X-Mailman-Approved-At: Sat, 17 Jul 2010 14:33:18 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] allow empty files creation with install 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, 17 Jul 2010 14:11:56 -0000 joris dedieu writes: > This patch add a -t switch to install(3). This is a small feature for > lazy sysadmins. > > before : > > touch /usr/home/foo/.history /usr/home/foo/.bash_history > chown foo /usr/home/foo/.history /usr/home/foo/.bash_history > chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history > chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history for f in .history .bash_history; do install -o foo -g foo -m 600 -f sappend /dev/null /usr/home/foo/$f done > > after : > > install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history /usr/home/foo/.bash_history Your example doesn't use `-t' option. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 18:19: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 5D7351065674 for ; Sat, 17 Jul 2010 18:19:17 +0000 (UTC) (envelope-from joris.dedieu@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 E41958FC1A for ; Sat, 17 Jul 2010 18:19:16 +0000 (UTC) Received: by eyh6 with SMTP id 6so894535eyh.13 for ; Sat, 17 Jul 2010 11:19:15 -0700 (PDT) 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=tb93iwCXGJKKhdpa70BBV422ExkJItLwFNKrDOlg90Y=; b=FbP3OjGr2QI3wwHAtOH3zhigF9wOAq0SmsYfL2TNXwVM0iw6su2ixfmlXiPxuNtcCP RkotCcbq90r8nhpOfLNVe7PeHNtaWKQ5C6yMCow41bpLsObgFYfFxgquqroyl7/o8Fhn SyuCyg+y6QXIZFPL4cWhN8hVwUl7E/qGrwL4I= 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=FZL4nG4NVoBo+zD0reY09AKj0/qFGtpxcHK2gKwE5PWQySkMRTfyBTdichZ3SLikBJ 67ufNUxwIaf6IuHrWKqK1mUM75bFgWUWk+GFLOJ7x7xi06tJM84yuxJhQfvsvvlhkfCp R3Uga6rXUy2reZKE/mUgyEgiCMt0d3JlfIV2A= MIME-Version: 1.0 Received: by 10.213.13.133 with SMTP id c5mr915825eba.4.1279390755700; Sat, 17 Jul 2010 11:19:15 -0700 (PDT) Received: by 10.213.36.15 with HTTP; Sat, 17 Jul 2010 11:19:15 -0700 (PDT) In-Reply-To: <20100717141136.GH2381@deviant.kiev.zoral.com.ua> References: <20100717141136.GH2381@deviant.kiev.zoral.com.ua> Date: Sat, 17 Jul 2010 20:19:15 +0200 Message-ID: From: joris dedieu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PATCH] allow empty files creation with install 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, 17 Jul 2010 18:19:17 -0000 2010/7/17 Kostik Belousov : > On Sat, Jul 17, 2010 at 03:34:08PM +0200, joris dedieu wrote: >> This patch add a -t switch to install(3). This is a small feature for >> lazy sysadmins. >> >> before : >> >> touch /usr/home/foo/.history /usr/home/foo/.bash_history >> chown foo /usr/home/foo/.history /usr/home/foo/.bash_history >> chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history >> chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history >> >> after : >> >> install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history >> /usr/home/foo/.bash_history >> > > Isn't /dev/null as a source file work better ? Damned ! Why I never thought about this ? > From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 18:20: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 D950E106566C for ; Sat, 17 Jul 2010 18:20:43 +0000 (UTC) (envelope-from joris.dedieu@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 6C92D8FC20 for ; Sat, 17 Jul 2010 18:20:43 +0000 (UTC) Received: by ewy26 with SMTP id 26so1191824ewy.13 for ; Sat, 17 Jul 2010 11:20:42 -0700 (PDT) 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 :content-transfer-encoding; bh=jAjRNJscL1se+x1nqxQvBVXbw67PGAF2SbcOAjAM4v8=; b=wDBwoE4jz+i15tGjxBEHnt72w5v6Bcc+Nk2u+OwZFghHvQFHZ0iCa2t8Z9bq/10sRO imGyLSGzFmSKzImVV3XGDrON8r2U1fxyweR62ccVI1WY3slo/dJXz+YU+kJjcH9NbS7x ffdycdJGOsd/YBvQuROjoYo3lCqfRP7zN6aGU= 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:content-transfer-encoding; b=eLj/H2spAF/afui+ZPcq83wNYfmQ/yJnVFAlgemPFO75nl1zK2Pv1XCFD4wBK+wk2n jntfYs4Gb2hjDkO5+DBxw9z0M58mB/pocIPrYram7PeNZjtOsX+/txKZBLgXKIlOA9Ui /hNKW7J+TMJyQc3vURkPJEJYGDYdXJcVAs8ic= MIME-Version: 1.0 Received: by 10.213.20.10 with SMTP id d10mr2429065ebb.87.1279390842216; Sat, 17 Jul 2010 11:20:42 -0700 (PDT) Received: by 10.213.36.15 with HTTP; Sat, 17 Jul 2010 11:20:42 -0700 (PDT) In-Reply-To: <86630emc4u.fsf@gmail.com> References: <86630emc4u.fsf@gmail.com> Date: Sat, 17 Jul 2010 20:20:42 +0200 Message-ID: From: joris dedieu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] allow empty files creation with install 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, 17 Jul 2010 18:20:43 -0000 2010/7/17 Anonymous : > joris dedieu writes: > >> This patch add a -t switch to install(3). This is a small feature for >> lazy sysadmins. >> >> before : >> >> touch /usr/home/foo/.history /usr/home/foo/.bash_history >> chown foo /usr/home/foo/.history /usr/home/foo/.bash_history >> chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history >> chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history > > =A0for f in .history .bash_history; do > =A0 =A0 =A0install -o foo -g foo -m 600 -f sappend /dev/null /usr/home/fo= o/$f > =A0done > >> >> after : >> >> install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history /usr/home= /foo/.bash_history > > Your example doesn't use `-t' option. And it doesn't work sorry. install -o foo -g foo -m 600 -f sappend -t /usr/home/foo/.history > From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 21: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 92DFC106564A for ; Sat, 17 Jul 2010 21:22:49 +0000 (UTC) (envelope-from yanegomi@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 58B0E8FC1F for ; Sat, 17 Jul 2010 21:22:49 +0000 (UTC) Received: by iwn35 with SMTP id 35so4180053iwn.13 for ; Sat, 17 Jul 2010 14:22:48 -0700 (PDT) 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=jdj1TrJUlJiWsBKMFOPQeT00+gAdMQRoHr8z/0z5I4g=; b=S/tdXWoqnQHiq9Ch8xkYtDbgLQI11H00W9wVX/IyGbIFe44mlOheZdRhoRvz4g88yk A7548Jn/o8o+ZGltTrkRY7aefRetcqDWm7QAGT22/y25kZusBWJIdxaSH3SLWP8e6coZ TIqOIIf+TX8f8vRZEnqMP3Fout7netzod2GhM= 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=UTiZMvw5ZBjPCwaSgRXGkyEC7QmSI1lC/9Qs2v64Z3MI4vu4vA/5hHoqDgiorFAl+3 UsPnPfJ3yvJogBiMJVQHEDB2QvF82OeILb06zaxiL8XqvYtAvrXtaA+GuZ7Z7p0N6OhV Krq0gF7Cs1Kg4cj2R35QvyudfAyK0uKEbXjGY= MIME-Version: 1.0 Received: by 10.231.200.146 with SMTP id ew18mr2432989ibb.117.1279401768594; Sat, 17 Jul 2010 14:22:48 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.169.18 with HTTP; Sat, 17 Jul 2010 14:22:48 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Jul 2010 14:22:48 -0700 X-Google-Sender-Auth: 26KzLbxrl3bZDxLtkNbNK-hHyz4 Message-ID: From: Garrett Cooper To: joris dedieu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] allow empty files creation with install 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, 17 Jul 2010 21:22:49 -0000 On Sat, Jul 17, 2010 at 6:34 AM, joris dedieu wrote: > This patch add a -t switch to install(3). This is a small feature for > lazy sysadmins. > > before : > > touch /usr/home/foo/.history /usr/home/foo/.bash_history > chown foo /usr/home/foo/.history /usr/home/foo/.bash_history > chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history > chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history > > after : > > install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history > /usr/home/foo/.bash_history And why isn't creating a 4-command bourne shell script which does all of these operations an option? install is used a lot in the build process both on the FreeBSD side and the ports side, so I'd prefer if it was as minimalist as possible. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 17 23:59: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 0D8F7106566B for ; Sat, 17 Jul 2010 23:59:56 +0000 (UTC) (envelope-from joris.dedieu@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 93E468FC16 for ; Sat, 17 Jul 2010 23:59:55 +0000 (UTC) Received: by ewy26 with SMTP id 26so1223314ewy.13 for ; Sat, 17 Jul 2010 16:59:54 -0700 (PDT) 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 :content-transfer-encoding; bh=oTBAlpgvr1AgdaKXPOSIxg2NnuBRmClPdjxOGWI/kBI=; b=iNbdGBlvCBQBPdcXqDwkEPmDr0aWJaDCmEcMKqLhCGA8P2Oa+fINsYHO6B96/fb0L+ qNyOtgCdVtgHFhJmi3E4GL5DLz+zfN/xqAG9sUJ+j6fMzo2Yp9286eJt5jcd7Z8uaseo nJ/T76DqdIZeAu0dDqTOKK2qsAtQcB6rLmc2c= 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:content-transfer-encoding; b=YkYT3sBk5KQPMNA68RKGy4gY5wjfLkI2Em18SwcAE5osDJtRnG5Svq7+WtbPtyqIq0 ZFHCGKCO69lLmxMGU8FqanD2W9IPmTYtN/HRPFC+aCZbPdoYSTg27eByaECKykZpwDVz pNjL1Bol1hobsaoNyToRmWAiyyDMIXTGl7sk0= MIME-Version: 1.0 Received: by 10.213.25.138 with SMTP id z10mr2755459ebb.52.1279411194244; Sat, 17 Jul 2010 16:59:54 -0700 (PDT) Received: by 10.213.36.15 with HTTP; Sat, 17 Jul 2010 16:59:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Jul 2010 01:59:54 +0200 Message-ID: From: joris dedieu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] allow empty files creation with install 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, 17 Jul 2010 23:59:56 -0000 2010/7/17 Garrett Cooper : > On Sat, Jul 17, 2010 at 6:34 AM, joris dedieu wr= ote: >> This patch add a -t switch to install(3). This is a small feature for >> lazy sysadmins. >> >> before : >> >> touch /usr/home/foo/.history /usr/home/foo/.bash_history >> chown foo /usr/home/foo/.history /usr/home/foo/.bash_history >> chmod 600 /usr/home/foo/.history /usr/home/foo/.bash_history >> chflags sappend /usr/home/foo/.history /usr/home/foo/.bash_history >> >> after : >> >> install -o foo -g foo -m 600 -f sappend /usr/home/foo/.history >> /usr/home/foo/.bash_history > > =A0 =A0And why isn't creating a 4-command bourne shell script which does There are a lot of one shot things that don't need a script. > all of these operations an option? install is used a lot in the build > process both on the FreeBSD side and the ports side, so I'd prefer if > it was as minimalist as possible. Well, install is also powerful cp, mkdir, useful on everyday administration so I thought it should also be a powerful touch. And why not more than that ? a powerful file management tool. I understand that build process is critical and with FreeBSD it's "just work". In this perspective this patch is maybe not a necessity. It was fun to do it :) Joris > Thanks, > -Garrett >