From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 12 07:38: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 41F20106564A for ; Sun, 12 Dec 2010 07:38:35 +0000 (UTC) (envelope-from artemb@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 E18E78FC15 for ; Sun, 12 Dec 2010 07:38:34 +0000 (UTC) Received: by vws9 with SMTP id 9so3012265vws.13 for ; Sat, 11 Dec 2010 23:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+fCsIpFPSZOFwYUwZPDjBZtkdEGCfUoCGl0cYLBV53s=; b=ktbk6RE2OpmFFaB5KR0bQAHolkJzHkkbJ71gHZ30HZGa5Nokub3dL2/I9IDyCyIdwE vW+7egPP0U4mXAMCLaM4qxDmUSZ0vSr0U5ywmzr5f44TJuaqY71AqljeyYUz+BVot1j+ b7uNGLTIAhLXPbtjOEuMQoaw++I8RdwJmkchI= 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=wiQpm09Kd2jshGqufqwV1mst6/A7qvd6Z5CuurnfXIvqodY3Hj5uIhwI6Kc5bz0Nmr aq8IbSR2F1tUeITCENDvXIccbON0PXob9xTkrllm8zjcs8F+dBtRqx3meHf2hRxmnQ7F Mz1fWl+Ia7SV5+h5xOyQgY598j0tOQfNhJdV0= MIME-Version: 1.0 Received: by 10.220.193.203 with SMTP id dv11mr854342vcb.1.1292139512708; Sat, 11 Dec 2010 23:38:32 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.177.195 with HTTP; Sat, 11 Dec 2010 23:38:32 -0800 (PST) In-Reply-To: <20101211215341.0000097c@unknown> References: <20101211215341.0000097c@unknown> Date: Sat, 11 Dec 2010 23:38:32 -0800 X-Google-Sender-Auth: S-fSv6Csd3w1hmHpCXNM_q6DKBY Message-ID: From: Artem Belevich To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Dec 2010 07:38:35 -0000 > Maybe a little bit related: do you know about my (unfortunately > out-of-date) branch to add dtrace providers to the linuxulator? > http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/ > > If you are interested feel free to borrow things from there. I'll take a look. >> I'm leaning towards using 'module' but I would appreciate hackers@ >> opinion on the best way to proceed. > > My first thought was that this is a good idea. > > My second thought was the question if you can make the provided values > there compatible enough that a dtrace script is able to cope with it > when someone does not uses a specific module but the wirldcard > operator. If not I suggest to think again about it. Installing wildcard probes should work fine either way. If we use module to differentiate between emulation variants then syscall::write:entry will install probes for all variants of write syscall. In cases when we use wildcard syscall probes that would typically be the right thing to do. For instance, in case of one-liner like 'syscall:::entry { @num[pid,execname] = count(); }'. That's in fact why I started tinkering with this -- the one-liner above didn't show anything for 32-bit binaries I've been running. On the other hand, most of the current scripts that use syscall provider do not specify module. Such scripts would now match more than one syscall. I.e. if the intent was to catch only native write syscall, the probe would now be installed for freeebsd32 and linux32 variants as well. Given the fact that most of available Dtrace scripts that come from Solaris need modifications/tweaking anyways, that's probably not such a big deal. If we use different provider names, then one could do syscall*::write: and that would work, too. This reverses situation above. Current wildcard probes will remain limited to native syscalls and would need to be changed. If someone would want to include syscalls from other emulation layers they would have to explicitly install probes for corresponding providers. Functionally both approaches are about the same functionally. Each has pluses and minuses. Using module, though, looks somewhat cleaner. --Artem From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 12 16:52:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC4FA106564A for ; Sun, 12 Dec 2010 16:52:44 +0000 (UTC) (envelope-from extrudedaluminiu@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 7DEA88FC15 for ; Sun, 12 Dec 2010 16:52:44 +0000 (UTC) Received: by qwj9 with SMTP id 9so5375003qwj.13 for ; Sun, 12 Dec 2010 08:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:x-x-sender :to:subject:message-id:user-agent:mime-version:content-type; bh=pX9MAS/c0Jchyms+ke4S6pb3Lyw5Pd34Zev56ZOY5zQ=; b=LTM2iPZVzqvBqjCZZiHEIL4+Iy/bIbKK+HjpUyDr5zZG7ZIxw55MJ0zNZq90q6KlOB M3NM+Yg6LbxDRkDIVyiShKDvP3T4Kepp6xalPtDiG2nujp8MTUvnb6+QPPjz9armaqNE sHozPeTbdz1DIFgFq9lBHE6m4pgmShRsmgRXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:x-x-sender:to:subject:message-id:user-agent :mime-version:content-type; b=W1uBCTMnMuFSMYdfX1jY6iD/MDXDkIGbidAz7yKMDIb3JoWhMvyR6/JTlFyXCKYuXW ie6B1MeqLcI/8BqnRvzPMcKdu/tEGBsdTum7iyCTTMBvM0FiaY9Y/qGoTlSDWrLz+A9j fhSr//tK32eRoxSGU+gfDqNK4aYB1m+oGOTzM= Received: by 10.229.85.203 with SMTP id p11mr2855586qcl.76.1292172763504; Sun, 12 Dec 2010 08:52:43 -0800 (PST) Received: from batman.acm.jhu.edu (batman.acm.jhu.edu [128.220.251.35]) by mx.google.com with ESMTPS id y17sm3428061qci.33.2010.12.12.08.52.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 08:52:43 -0800 (PST) Sender: Venkatesh Srinivas Date: Sun, 12 Dec 2010 11:52:42 -0500 (EST) From: Venkatesh Srinivas X-X-Sender: me@centaur.acm.jhu.edu To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Sun, 12 Dec 2010 17:39:46 +0000 Subject: amd64 pmap pagecopy() 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: Sun, 12 Dec 2010 16:52:44 -0000 Hi, In svn r127653, a microoptimized pagecopy() implementation was added to amd64's support.S. The pagecopy() prefetches the entire page first and then uses a partly-unrolled loop of loads & non-temporal stores. The commit notes 'it is roughly four times faster than bcopy() for uncached pages'. Just wondering, how was this measured? I ported the routine to i386 and tried it out in userland, but found it between four and six times slower than the BSD and GNU libc bcopy()ies; I admit to not trying very hard to measure on only uncached pages though... Also, why prefetch the entire page before the load / NT store loop? If I read the Intel optimization guide correctly, a loop of prefetch(n+1) / load / store would be a better call? (I tried this on i386 also, it was a bit faster than the current style, but still nowhere near bcopy()...). Thanks! -- vs From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 12 17:08: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 638E71065670 for ; Sun, 12 Dec 2010 17:08:43 +0000 (UTC) (envelope-from extrudedaluminiu@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 186BC8FC12 for ; Sun, 12 Dec 2010 17:08:42 +0000 (UTC) Received: by qwj9 with SMTP id 9so5383377qwj.13 for ; Sun, 12 Dec 2010 09:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:x-x-sender :to:subject:message-id:user-agent:mime-version:content-type; bh=+KosSb2BvhD520qlNwub6ypkei9hzJSeghjtF7o6vUg=; b=EONmLGe7646ilu86pYn1PEdXFnBFOk/8UV89+mJW66NwnlbzqpixMpDTWHdLBYgVPQ DN9QwIXQWF0iZ/F2jVeUlU6Nj5kER0yJV5t0u1Jg1pLPv0Tf1/xGetAuu2M8XL6zR1mY cNf4u5l6WOS478zyRfxjqbte4cboU7lqDbyls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:x-x-sender:to:subject:message-id:user-agent :mime-version:content-type; b=WaGii/+QBf3497MM63YkRizqVunLSp8XHLDyCeQQFOGF/wPGAlDL0ug3ZfJgLSWNMi ZAicYeZgYVsxQwASbh2ogt6CJiOtjch+7KgCdEB4l/zHZg36+5W8tk/pVNkXscnV/P3Z F5u3obaLMiroyPYQAL58GFBZ/+5vBCTWCU7gw= Received: by 10.229.84.135 with SMTP id j7mr2859292qcl.180.1292172066687; Sun, 12 Dec 2010 08:41:06 -0800 (PST) Received: from batman.acm.jhu.edu (batman.acm.jhu.edu [128.220.251.35]) by mx.google.com with ESMTPS id n7sm3424297qcu.16.2010.12.12.08.41.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 08:41:05 -0800 (PST) Sender: Venkatesh Srinivas Date: Sun, 12 Dec 2010 11:40:59 -0500 (EST) From: Venkatesh Srinivas X-X-Sender: me@centaur.acm.jhu.edu To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Sun, 12 Dec 2010 17:39:58 +0000 Subject: i386 pmap_zero_page() late sched_pin()? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Dec 2010 17:08:43 -0000 Hi, In the i386 pmap's pmap_zero_page(), there is a fragment... sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; mtx_lock(&sysmaps->lock); * sched_pin(); /*map the page we mean to zero at sysmaps->CADDR2*/ pagezero(sysmaps->CADDR2); sched_unpin(); I don't know this bit of code too well, so I don't know if the sched_pin() being where it is is okay or not. My first reading says its not okay; if a thread is moved to another CPU before it is able to pin, it will use the wrong sysmaps structure. Is this the case? Is it alright that the wrong sysmap structure is used? Oh, Nathaniel Filardo (nwf@cs.jhu.edu) first spotted this, not I. Thanks, -- vs From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 12 19:13:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC75F106564A for ; Sun, 12 Dec 2010 19:13:21 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6A28FC19 for ; Sun, 12 Dec 2010 19:13:21 +0000 (UTC) Received: by fxm19 with SMTP id 19so5124924fxm.36 for ; Sun, 12 Dec 2010 11:13:20 -0800 (PST) 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=GRDszQ6eCVd/26ffoAuy746jij4mO1Pvg8jkm8rChm8=; b=ZAh0oQ4UbYgKeEYUIpY31pXFZXsYAjoPSKfStVNPsFNusmsnqUHxC9QwI6+zDDx/2F fxP/Hj72fZQNjuCO2II1JhUPEWWlV20ojEc3njYfJ2rdQWIlhCwQc2wjZ2E9xS/urAsa D11NwmQWSRoVZHPapiFdEdkVugkqYeczt8RZc= 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=cck5YpMYyfYaznU3o4ooBpcPyZP31800j5DkgC5TiNcT/4LwUPigh6ZEqa6PoyJQj4 /bHAck5M0QHYWbjUOBVY/8TbfU8jARHa7Bc+DP6YExG2PgnFBXD0x2KuWsw+eQxpHaKI cPVBHyo6t5nqqD1IdYGmw1NJeuh3Qw2cXqbXc= MIME-Version: 1.0 Received: by 10.223.53.68 with SMTP id l4mr3589669fag.44.1292179700811; Sun, 12 Dec 2010 10:48:20 -0800 (PST) Received: by 10.223.116.205 with HTTP; Sun, 12 Dec 2010 10:48:20 -0800 (PST) In-Reply-To: References: Date: Sun, 12 Dec 2010 12:48:20 -0600 Message-ID: From: Alan Cox To: Venkatesh Srinivas Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: i386 pmap_zero_page() late sched_pin()? 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: Sun, 12 Dec 2010 19:13:22 -0000 On Sun, Dec 12, 2010 at 10:40 AM, Venkatesh Srinivas < vsrinivas@dragonflybsd.org> wrote: > Hi, > > In the i386 pmap's pmap_zero_page(), there is a fragment... > > sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > * sched_pin(); > /*map the page we mean to zero at sysmaps->CADDR2*/ > pagezero(sysmaps->CADDR2); > sched_unpin(); > > I don't know this bit of code too well, so I don't know if the sched_pin() > being where it is is okay or not. My first reading says its not okay; if a > thread is moved to another CPU before it is able to pin, it will use the > wrong sysmaps structure. Is this the case? Is it alright that the wrong > sysmap structure is used? > > Oh, Nathaniel Filardo (nwf@cs.jhu.edu) first spotted this, not I. > > This isn't a bug. There is nothing about the code that mandates that processor i must always use sysmap entry i. In the unlikely event that the thread migrates from processor X to processor Y before the sched_pin(), the mutex on sysmap entry X will prevent it from being used by processor X until processor Y is done with it. So, it doesn't matter to correctness that the "wrong" sysmap entry is used, and it is extremely unlikely to matter to performance. Alan From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 13 08:46: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 C88141065674; Mon, 13 Dec 2010 08:46:03 +0000 (UTC) (envelope-from aponomarenko@ispras.ru) Received: from smtp.ispras.ru (smtp.ispras.ru [83.149.198.201]) by mx1.freebsd.org (Postfix) with ESMTP id 51C0D8FC19; Mon, 13 Dec 2010 08:46:03 +0000 (UTC) Received: from ispserv.ispras.ru (ispserv.ispras.ru [83.149.198.72]) by smtp.ispras.ru (Postfix) with ESMTP id 8106A5D4099; Mon, 13 Dec 2010 11:12:27 +0300 (MSK) Received: from [10.10.2.130] (unknown [83.149.198.236]) by ispserv.ispras.ru (Postfix) with ESMTP id 592B93FC48; Mon, 13 Dec 2010 11:18:20 +0300 (MSK) Message-ID: <4D05D5A1.1030103@ispras.ru> Date: Mon, 13 Dec 2010 11:13:21 +0300 From: Andrey Ponomarenko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101026 SUSE/3.0.10 Thunderbird/3.0.10 MIME-Version: 1.0 To: freebsd-java@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Backward compatibility of Java libraries API in 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, 13 Dec 2010 08:46:03 -0000 Hello, I am preparing a service for automatic monitoring changes in Java libraries and testing backward binary/source compatibility [1]. First hundred or more libraries will be included to the tracker freely for testing purposes. If anyone want to add some library then feel free to write me a request [2]. For example, "slf4j" library (from the list of FreeBSD Java Ports [3]) has an entry in the tracker at [4]. [1] http://linuxtesting.org/upstream-tracker/java/ [2] upstream-tracker@linuxtesting.org [3] http://www.freebsd.org/ports/java.html [4] http://linuxtesting.org/upstream-tracker/java/versions/slf4j.html -- Andrey Ponomarenko Department for Operating Systems at ISPRAS web: http://www.LinuxTesting.org mail: aponomarenko@ispras.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 13 09:35: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 066C0106564A for ; Mon, 13 Dec 2010 09:35:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B33F88FC08 for ; Mon, 13 Dec 2010 09:35:41 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B43C.dip.t-dialin.net [87.179.180.60]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id BB16E84400D; Mon, 13 Dec 2010 10:35:38 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id B68D31D5C; Mon, 13 Dec 2010 10:35:35 +0100 (CET) Date: Mon, 13 Dec 2010 10:35:35 +0100 From: Alexander Leidinger To: Artem Belevich Message-ID: <20101213103535.00005f3d@unknown> In-Reply-To: References: <20101211215341.0000097c@unknown> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: BB16E84400D.A423F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1292837739.22739@9x+KH+CexuL6Q45tcOC/eA X-EBL-Spam-Status: No X-Mailman-Approved-At: Mon, 13 Dec 2010 12:11:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2010 09:35:42 -0000 On Sat, 11 Dec 2010 23:38:32 -0800 Artem Belevich wrote: > Functionally both approaches are about the same functionally. Each has > pluses and minuses. Using module, though, looks somewhat cleaner. I agree. Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 13 13:22:13 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 89300106566B for ; Mon, 13 Dec 2010 13:22:13 +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 B7BAF8FC13 for ; Mon, 13 Dec 2010 13:22:12 +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 PAA22937; Mon, 13 Dec 2010 15:22:09 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D061E00.7050606@freebsd.org> Date: Mon, 13 Dec 2010 15:22:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artem Belevich References: <20101211215341.0000097c@unknown> <20101213103535.00005f3d@unknown> In-Reply-To: <20101213103535.00005f3d@unknown> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2010 13:22:13 -0000 on 13/12/2010 11:35 Alexander Leidinger said the following: > On Sat, 11 Dec 2010 23:38:32 -0800 Artem Belevich > wrote: > >> Functionally both approaches are about the same functionally. Each has >> pluses and minuses. Using module, though, looks somewhat cleaner. > > I agree. +1, just in case. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 13 17:58: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 C3CE7106566B for ; Mon, 13 Dec 2010 17:58:05 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id 877C98FC0A for ; Mon, 13 Dec 2010 17:58:05 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id oBDGtd5e019539; Mon, 13 Dec 2010 11:56:02 -0500 Message-ID: <4D06500B.7000206@FreeBSD.org> Date: Mon, 13 Dec 2010 11:55:39 -0500 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Xin LI References: <4CEEC3BD.3080204@delphij.net> <4CF36253.2090902@delphij.net> In-Reply-To: <4CF36253.2090902@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.50 (*) [Hold at 15.00] COMBINED_FROM,RATWARE_GECKO_BUILD X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: FreeBSD-Hackers Subject: Re: Is it possible to have file removed upon process exit? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Dec 2010 17:58:05 -0000 On 11/29/10 3:20 AM, Xin LI wrote: > On 11/28/10 20:43, Garrett Cooper wrote: > >> On Thu, Nov 25, 2010 at 12:14 PM, Xin LI wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> >>> For certain applications it is sometimes desirable to (e.g. for unix >>> domain sockets) have file removed when the process quit, regardless >>> whether the process is quit cleanly. Is there a clean way to do this? >>> >> Does it have to be nameless and/or unique? >> > Not nameless. > > Speaking for uniqueness, I think it's unrelated (not good nor bad) for > the use case. The name should be predictable (e.g. can be configured, > so non-child process can find it), though. > How much of a kludge are you willing to live with? :-) I assume you want to create these files in /tmp. You could create a subdirectory named something like "AutoRM". In that directory, create a directory by process name. The process could then create whatever filename it wants in /tmp, and then hard-link that file to a name under /tmp/AutoRM//. So if the process 1242 created /tmp/be_gone, it would also create a hardlink to /tmp/AutoRM/1242/be_gone . Then some other process could come along periodically and check all the directories in /tmp/AutoRM. If the process matching some subdirectory does not exist, the cleanup process would remove the files in that subdirectory, as well as the matching files under /tmp. So when process 1242 no longer exists, this cleanup process would see the file /tmp/AutoRM/1242/be_gone , and then check if /tmp/be_gone exists and if it's the same inode as /tmp/AutoRM/1242/be_gone . If so, the cleanup process removes both files. If not, the cleanup process only removes the file under /tmp/AutoRM/1242. You'd have to think through the security issues of this setup. It might be better to have the files under /tmp/AutoRM/ be symlinks, and then check that the owner of the symlink is the same as the owner of the file it points to. At that point you wouldn't need to have the filenames match, so maybe have name of the symlink match the name of the inode of the original file. The nice thing about either of these is that you have to write that cleanup program just once, and then you can use it for any temp file created by any process. The files can be named whatever you want to name them, to keep things easy for other non-child processes to find the correct temp files. For instance, the process could call some library routine which it (the process) has no way to modify, but which returns a filename. Once that library routine returns, the process could then add the appropriate entry for that filename under the AutoRM directory. Still, it is a bit of a kludge. And the files won't disappear immediately when the process exits. This may not be a great solution, but it might at least give you some ideas of other ways to approach the problem. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 14 03:10: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 923C21065673 for ; Tue, 14 Dec 2010 03:10:01 +0000 (UTC) (envelope-from artemb@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 437DA8FC1C for ; Tue, 14 Dec 2010 03:10:00 +0000 (UTC) Received: by qyk8 with SMTP id 8so3831773qyk.13 for ; Mon, 13 Dec 2010 19:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=OWZ94GfS1sb3j5dxi1wmnZAG+DOkaaGIi8d05mxPKV4=; b=LMPveHzVgtHaAlC6Mm9DzykRMOmEQ1adPjLpl9bayAKQWEPZmAMWztZgzmPkaRayTM ai7SAZycYecsXFhgOdkc346BkTgj2h8oLYfVl51YBtoGkCQwf28rRYKeEqmWUlOI6eN9 nKKKR4htGGdMiVkuzTIHIIPDAR4H2uODjsUVM= 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:content-type; b=kgbd/HqJD2TlBOambF/F94dXvtvSNGB0kqrSzah6Cnc10sQffbgPwOKlS0PWs8qcjC A7KmFQ2n3lou+3Bhup/xsC/PzsxFxl8DAo19giWvB4tSCXPevI6DAUaoTEnGXM5q+O9k 5osMsU0USGpR+HAXMQvDqByRtbHWjOZ64e0Y4= MIME-Version: 1.0 Received: by 10.224.37.74 with SMTP id w10mr4693762qad.163.1292296200468; Mon, 13 Dec 2010 19:10:00 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.177.195 with HTTP; Mon, 13 Dec 2010 19:10:00 -0800 (PST) In-Reply-To: <4D061E00.7050606@freebsd.org> References: <20101211215341.0000097c@unknown> <20101213103535.00005f3d@unknown> <4D061E00.7050606@freebsd.org> Date: Mon, 13 Dec 2010 19:10:00 -0800 X-Google-Sender-Auth: poGtlcu4kOhG41qZhJD1qlmHurE Message-ID: From: Artem Belevich To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Dec 2010 03:10:01 -0000 I've posted updated version of the patch here: https://sites.google.com/site/abc678site/files/dt-systrace.patch.gz This patch uses DTrace module field to specify syscall's compat variant in the syscall probe name. The patch also adds syscall probe for linux32 binaries on amd64. I'll try to add i386 support soon, too, but I have no i386 box I could compile and test the changes on. I'll try to get one set up under VirtualBox later, but for now the patch is for 8-STABLE/amd64 only. --Artem From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 11:38: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 5FF5B1065694 for ; Wed, 15 Dec 2010 11:38:25 +0000 (UTC) (envelope-from ehaupt@FreeBSD.org) Received: from mx.critical.ch (cl-8.zrh-02.ch.sixxs.net [IPv6:2001:1620:f00:7::2]) by mx1.freebsd.org (Postfix) with ESMTP id D42578FC15 for ; Wed, 15 Dec 2010 11:38:24 +0000 (UTC) Received: from wiggles.bwns.ch (localhost [IPv6:::1]) by mx.critical.ch (8.14.3/8.14.3/critical-1.0) with SMTP id oBFBcNvZ065217 for ; Wed, 15 Dec 2010 12:38:23 +0100 (CET) (envelope-from ehaupt@FreeBSD.org) Date: Wed, 15 Dec 2010 12:38:23 +0100 From: Emanuel Haupt To: freebsd-hackers@FreeBSD.org Message-Id: <20101215123823.90e381ed.ehaupt@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: LED support for ALIX 2/3 series X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 11:38:25 -0000 Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series [2]? The following version uses linux API's. I'd gladly write a port for it if someone could port it. Emanuel [1] http://people.freebsd.org/~ehaupt/misc/leds-alix-0.0.1/leds-alix.c [2] http://www.pcengines.ch/ From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 12:26: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 3337E106566B; Wed, 15 Dec 2010 12:26:25 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id A5D648FC0C; Wed, 15 Dec 2010 12:26:24 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 15 Dec 2010 13:16:37 +0100 id 00033C19.4D08B1A5.0000EE2A From: Milan Obuch To: freebsd-hackers@freebsd.org Date: Wed, 15 Dec 2010 13:16:19 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.4; i386; ; ) References: <20101215123823.90e381ed.ehaupt@FreeBSD.org> In-Reply-To: <20101215123823.90e381ed.ehaupt@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012151316.20255.freebsd-hackers@dino.sk> Cc: Emanuel Haupt Subject: Re: LED support for ALIX 2/3 series X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 12:26:25 -0000 On Wednesday 15 December 2010 12:38:23 Emanuel Haupt wrote: > Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series > [2]? The following version uses linux API's. > > I'd gladly write a port for it if someone could port it. > > Emanuel > > [1] http://people.freebsd.org/~ehaupt/misc/leds-alix-0.0.1/leds-alix.c > [2] http://www.pcengines.ch/ > Hi, we have in CURRENT gpio framework with gpioctl control program and gpioled device. I think we should use this approach instead. In past I tested something similar on WRAP (older product, ALIX could be considered ancestor of it) and it works. Also, if you look at sys/i386/geode.c, there is already something written, which should be working... Regards, Milan From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 12:31: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 B5702106566B; Wed, 15 Dec 2010 12:31:01 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2AE8FC23; Wed, 15 Dec 2010 12:31:01 +0000 (UTC) Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 6C1631C089D2; Wed, 15 Dec 2010 13:12:32 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-62-193.dynamic.mnet-online.de [93.104.62.193]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS id 5E1AB1C000B3; Wed, 15 Dec 2010 13:12:32 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id E29492BA07; Wed, 15 Dec 2010 13:12:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id DB3B32BA06; Wed, 15 Dec 2010 13:12:31 +0100 (CET) Date: Wed, 15 Dec 2010 13:12:31 +0100 (CET) From: Michael Reifenberger To: Emanuel Haupt In-Reply-To: <20101215123823.90e381ed.ehaupt@FreeBSD.org> Message-ID: References: <20101215123823.90e381ed.ehaupt@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 Cc: freebsd-hackers@FreeBSD.org Subject: Re: LED support for ALIX 2/3 series X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 12:31:01 -0000 On Wed, 15 Dec 2010, Emanuel Haupt wrote: > Date: Wed, 15 Dec 2010 12:38:23 +0100 > From: Emanuel Haupt > To: freebsd-hackers@FreeBSD.org > Subject: LED support for ALIX 2/3 series > > Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series [2]? > The following version uses linux API's. > > I'd gladly write a port for it if someone could port it. > Probably it should use the led(4) framework and reside in the base OS. Like sys/arm/xscale/ixp425/cambria_led.c Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 15:15: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 C4AC6106564A for ; Wed, 15 Dec 2010 15:15:23 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from sam.nabble.com (216-139-236-26.aus.us.siteprotect.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A1DC38FC1A for ; Wed, 15 Dec 2010 15:15:23 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1PSsmo-0006P8-Os for freebsd-hackers@freebsd.org; Wed, 15 Dec 2010 06:56:58 -0800 Message-ID: <30464535.post@talk.nabble.com> Date: Wed, 15 Dec 2010 06:56:58 -0800 (PST) From: Jakub Lach To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl Subject: IPSEC allegations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 15:15:23 -0000 Hello. http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 What's your insight? regards, - Jakub Lach -- View this message in context: http://old.nabble.com/IPSEC-allegations-tp30464535p30464535.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 15:20: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 91F931065693; Wed, 15 Dec 2010 15:20:16 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1temp.jnielsen.net (ns1temp.jnielsen.net [69.55.230.42]) by mx1.freebsd.org (Postfix) with ESMTP id 40CA38FC1F; Wed, 15 Dec 2010 15:20:15 +0000 (UTC) Received: from jnielsen.socialserve.com ([12.249.176.26]) (authenticated bits=0) by ns1temp.jnielsen.net (8.14.3/8.14.3) with ESMTP id oBFEu3eN030741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Dec 2010 09:56:04 -0500 (EST) (envelope-from lists@jnielsen.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John Nielsen In-Reply-To: Date: Wed, 15 Dec 2010 09:55:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <023281D4-7DB8-42E9-8E81-FA52EA24CB6E@jnielsen.net> References: <20101215123823.90e381ed.ehaupt@FreeBSD.org> To: Michael Reifenberger X-Mailer: Apple Mail (2.1082) X-DCC-CollegeOfNewCaledonia-Metrics: ns1temp.jnielsen.net; whitelist X-Virus-Scanned: clamav-milter 0.96.3 at ns1temp.jnielsen.net X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Emanuel Haupt Subject: Re: LED support for ALIX 2/3 series X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 15:20:16 -0000 On Dec 15, 2010, at 7:12 AM, Michael Reifenberger wrote: > On Wed, 15 Dec 2010, Emanuel Haupt wrote: >=20 >> Date: Wed, 15 Dec 2010 12:38:23 +0100 >> From: Emanuel Haupt >> To: freebsd-hackers@FreeBSD.org >> Subject: LED support for ALIX 2/3 series >> Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 = series [2]? >> The following version uses linux API's. >>=20 >> I'd gladly write a port for it if someone could port it. >>=20 >=20 > Probably it should use the led(4) framework and reside in the base OS. > Like sys/arm/xscale/ixp425/cambria_led.c The LED's on my Alix 3d2 work just fine already with led(4) under 8.2. I = think the code gets pulled in by "options CPU_GEODE". I have three = device nodes under /dev/led/ that work as described in the led(4) = manpage. Am I missing something? JN From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 13:00: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 45234106566B for ; Wed, 15 Dec 2010 13:00:30 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web120712.mail.ne1.yahoo.com (web120712.mail.ne1.yahoo.com [98.138.82.219]) by mx1.freebsd.org (Postfix) with SMTP id CF20D8FC18 for ; Wed, 15 Dec 2010 13:00:29 +0000 (UTC) Received: (qmail 84030 invoked by uid 60001); 15 Dec 2010 12:33:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1292416428; bh=fjTYVH8XZSswoXRiSt0rEo56fk+RRMIekR0BzWdnK9Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=LbZc2XmMFOVs+bxs2UGTmgztMtCVI3Pq8vz5GSdO6vbhwjdY+xnBgp0oh9qknQx3RxlmfytvbAsUloCciWEI6A9Rd7Fm5t9fdoxk8SBX7VNZXETwdYO1KPz4lPTe4w+ixMXrcxuYIS3yht/Ew4CCAVqrrUTWSVieOr4APhzwyhE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=UI3Ay4VlKU6wSLzzbmK4NBougw0mMtbdqLkF260PJnpp2sxVPGJqPTajFNAP2+wrUyFBkvuGyYJiy7QOcFDqeNkcZbxfBTzVroax2AxgAmSzUQmZiCVku4WzMwpVXA/vBJ0oTFqQ4VGA0/lLz14R3lG4JONEB0oK3X+vkHPLyZo=; Message-ID: <66322.83509.qm@web120712.mail.ne1.yahoo.com> X-YMail-OSG: c57IfE4VM1lh2gEocVibESHY5tResKYYUBRp6kTOBZ6g0I6 QF0b3EZ5UWzDhju10e2E9vUhUaxwg3RbanB7kGL4udn58vc_kjHS6pBXiw4T wyPn7qfh8dL50nmIazEepKY_I1tDVxhkjfkgvizbZqzgGgOMO1ZLGNHp0kBb mFt6YlaMRSyGnHFnL3PINYYuv70mpyKDt4NXS0RUFZJM.vcWv7nvGOUo16AV GZoTCo_kbw_KWkCe4iMYq1.kr0TW41vFjZfPffuyi Received: from [64.238.244.146] by web120712.mail.ne1.yahoo.com via HTTP; Wed, 15 Dec 2010 04:33:48 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 Date: Wed, 15 Dec 2010 04:33:48 -0800 (PST) From: "Dr. Baud" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 15 Dec 2010 16:13:02 +0000 Subject: Driver memory allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 13:00:30 -0000 Is there a cap on the amount of memory a driver (via bus_dmamem_alloc) can allocate, other than the obvious physical memory limit minus the memory already allocated? Dr. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 15:32: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 62410106566C; Wed, 15 Dec 2010 15:32:57 +0000 (UTC) (envelope-from ehaupt@critical.ch) Received: from mx.critical.ch (cl-8.zrh-02.ch.sixxs.net [IPv6:2001:1620:f00:7::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7FFE8FC28; Wed, 15 Dec 2010 15:32:56 +0000 (UTC) Received: from wiggles.bwns.ch (localhost [IPv6:::1]) by mx.critical.ch (8.14.3/8.14.3/critical-1.0) with SMTP id oBFFWsbw068387; Wed, 15 Dec 2010 16:32:54 +0100 (CET) (envelope-from ehaupt@critical.ch) Date: Wed, 15 Dec 2010 16:32:54 +0100 From: Emanuel Haupt To: John Nielsen Message-Id: <20101215163254.e50ee713.ehaupt@critical.ch> In-Reply-To: <023281D4-7DB8-42E9-8E81-FA52EA24CB6E@jnielsen.net> References: <20101215123823.90e381ed.ehaupt@FreeBSD.org> <023281D4-7DB8-42E9-8E81-FA52EA24CB6E@jnielsen.net> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Dec 2010 16:34:46 +0000 Cc: freebsd-hackers@freebsd.org, Emanuel Haupt Subject: Re: LED support for ALIX 2/3 series X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 15:32:57 -0000 John Nielsen wrote: > On Dec 15, 2010, at 7:12 AM, Michael Reifenberger wrote: > > > On Wed, 15 Dec 2010, Emanuel Haupt wrote: > > > >> Date: Wed, 15 Dec 2010 12:38:23 +0100 > >> From: Emanuel Haupt > >> To: freebsd-hackers@FreeBSD.org > >> Subject: LED support for ALIX 2/3 series > >> Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 > >> series [2]? The following version uses linux API's. > >> > >> I'd gladly write a port for it if someone could port it. > >> > > > > Probably it should use the led(4) framework and reside in the base > > OS. Like sys/arm/xscale/ixp425/cambria_led.c > > The LED's on my Alix 3d2 work just fine already with led(4) under > 8.2. I think the code gets pulled in by "options CPU_GEODE". I have > three device nodes under /dev/led/ that work as described in the led > (4) manpage. Am I missing something? No, in this case I guess I was the one missing something :-) Thanks for pointing it out. Emanuel From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 16:06: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 28CDC10656AC for ; Wed, 15 Dec 2010 16:06:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D9C028FC14 for ; Wed, 15 Dec 2010 16:06:49 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F10F71FFC3E; Wed, 15 Dec 2010 16:06:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BED498448E; Wed, 15 Dec 2010 17:06:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jakub Lach References: <30464535.post@talk.nabble.com> Date: Wed, 15 Dec 2010 17:06:48 +0100 In-Reply-To: <30464535.post@talk.nabble.com> (Jakub Lach's message of "Wed, 15 Dec 2010 06:56:58 -0800 (PST)") Message-ID: <867hfbkokn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 15 Dec 2010 16:39:39 +0000 Cc: freebsd-security@freebsd.org Subject: Re: IPSEC allegations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 16:06:50 -0000 [redirected from -hackers to -security] Jakub Lach writes: > http://marc.info/?l=3Dopenbsd-tech&m=3D129236621626462&w=3D2 http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-= allegations.html DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 17:15: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 0F161106566C for ; Wed, 15 Dec 2010 17:15:55 +0000 (UTC) (envelope-from rwmaillists@googlemail.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 9572A8FC14 for ; Wed, 15 Dec 2010 17:15:54 +0000 (UTC) Received: by wyf19 with SMTP id 19so1682839wyf.13 for ; Wed, 15 Dec 2010 09:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=aa5mPqchiGgY3Z3Iy/wNKaz/8MavIACce/eVdTNrsrw=; b=vQQ17N2+UuKg5v3NPCY95EcKdFaR4T9y3LeRKeJBWQfsW+TuunIIFR4Nv9VDt9p8aY MdT78rUSLuhzNE3XDrZpsovCOpj/7KTGM8OkFUEQoIk/yZ6XDpq0oMa9DRhnDBKk23W5 rypzOQ4mUzMG6O87rHBYFlU2365wlD9Ha4AwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=Eg4nbjkrQLGX4Y3JJmUx1NgziMi4FyaV1xFIHIpt0LR8GnT9cqLhCs+E7qWYvaUVNP VJ2vV6RJB2QcVHUeN5XjlFcnDiUcUxg1Ba/PL3vV3U/GzXkhxziDl7UqhKn2CiUZmNXo 7r9h9qPNQ6hlBEOclasNmiw3rgpKDcGvSXxXM= Received: by 10.216.52.206 with SMTP id e56mr6410057wec.19.1292433353564; Wed, 15 Dec 2010 09:15:53 -0800 (PST) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk [87.194.105.247]) by mx.google.com with ESMTPS id m7sm1029313wer.42.2010.12.15.09.15.50 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 09:15:52 -0800 (PST) Date: Wed, 15 Dec 2010 17:15:45 +0000 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20101215171545.000ed129@gumby.homeunix.com> In-Reply-To: <30464535.post@talk.nabble.com> References: <30464535.post@talk.nabble.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: IPSEC allegations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 17:15:55 -0000 On Wed, 15 Dec 2010 06:56:58 -0800 (PST) Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? There's already a thread on this on the security list. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 17:27: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 44E5D1065679 for ; Wed, 15 Dec 2010 17:27:32 +0000 (UTC) (envelope-from ingvar@somecodehere.com) Received: from somecodehere.com (somecodehere.com [195.250.189.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC598FC1C for ; Wed, 15 Dec 2010 17:27:31 +0000 (UTC) Received: from www.somecodehere.com (localhost [127.0.0.1]) by www.somecodehere.com (8.14.4/8.14.4) with ESMTP id oBFDVDt7026377; Wed, 15 Dec 2010 15:31:13 +0200 (EET) (envelope-from ingvar@somecodehere.com) Received: (from ingvar@localhost) by www.somecodehere.com (8.14.4/8.14.4/Submit) id oBFDVD7A026376; Wed, 15 Dec 2010 15:31:13 +0200 (EET) (envelope-from ingvar) Date: Wed, 15 Dec 2010 15:31:13 +0200 From: ingvar harjaks To: Jakub Lach Message-ID: <20101215133113.GA26360@somecodehere.com> References: <30464535.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30464535.post@talk.nabble.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: IPSEC allegations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 17:27:32 -0000 On Wed, Dec 15, 2010 at 06:56:58AM -0800, Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? > Someone has figured out how to get free code audit. Lots of paranoid people started to look at the code. Ingvar From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 17:27: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 70B771065696 for ; Wed, 15 Dec 2010 17:27:33 +0000 (UTC) (envelope-from ingvar@somecodehere.com) Received: from somecodehere.com (somecodehere.com [195.250.189.114]) by mx1.freebsd.org (Postfix) with ESMTP id D6A5B8FC1F for ; Wed, 15 Dec 2010 17:27:32 +0000 (UTC) Received: from www.somecodehere.com (localhost [127.0.0.1]) by www.somecodehere.com (8.14.4/8.14.4) with ESMTP id oBFDOp82026324; Wed, 15 Dec 2010 15:24:51 +0200 (EET) (envelope-from ingvar@somecodehere.com) Received: (from ingvar@localhost) by www.somecodehere.com (8.14.4/8.14.4/Submit) id oBFDOoJf026323; Wed, 15 Dec 2010 15:24:50 +0200 (EET) (envelope-from ingvar) Date: Wed, 15 Dec 2010 15:24:50 +0200 From: ingvar harjaks To: Jakub Lach Message-ID: <20101215132450.GB26240@www.somecodehere.com> References: <30464535.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30464535.post@talk.nabble.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: IPSEC allegations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 17:27:33 -0000 On Wed, Dec 15, 2010 at 06:56:58AM -0800, Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? > Someone has figured out how to get free code audit. Lots of paranoid people started to look at the code. Ingvar From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 15 18:26: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 993EA106566C for ; Wed, 15 Dec 2010 18:26:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE668FC13 for ; Wed, 15 Dec 2010 18:26:41 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oBFIQeXc024693; Wed, 15 Dec 2010 10:26:40 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 9ABFD2D6013; Wed, 15 Dec 2010 10:26:39 -0800 (PST) Message-ID: <4D09085D.7050006@freebsd.org> Date: Wed, 15 Dec 2010 10:26:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Dr. Baud" References: <66322.83509.qm@web120712.mail.ne1.yahoo.com> In-Reply-To: <66322.83509.qm@web120712.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: Driver memory allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Dec 2010 18:26:41 -0000 On 12/15/10 4:33 AM, Dr. Baud wrote: > Is there a cap on the amount of memory a driver (via bus_dmamem_alloc) can > allocate, other than the obvious physical memory limit minus the memory already > allocated? > well it has to fit into the kernel virtual space too. this is quite limited on x86 though for amd64 it is a lot bigger. I have seen drivers on amd64 setting asside a couple of GB (but you need a new kernel that has the kernel virtual space expanded). The kernel can make use of the direct-map space for driver allocation too. > Dr. > > > > > _______________________________________________ > 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 Thu Dec 16 01:38:13 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 DF60E1065670 for ; Thu, 16 Dec 2010 01:38:13 +0000 (UTC) (envelope-from extrudedaluminiu@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4C38FC12 for ; Thu, 16 Dec 2010 01:38:13 +0000 (UTC) Received: by gxk28 with SMTP id 28so2082092gxk.17 for ; Wed, 15 Dec 2010 17:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:reply-to:received :from:date:x-google-sender-auth:message-id:subject:to:content-type; bh=V8sNR9fIPdgn60NcaW9Oxssh/+FHaBVqUpmy7okMo+U=; b=CgSN6i8gLVGd1XcDWMUJ/8XdasrDNfOmGI7+lBqjq6dzmYkRQqrgwY2lvy5IeG8Zxx E3w7ujVdEqMm0zEgmfb7nvn6A9GQ6hLNXg+eFzZFoo85HQ11/BIMocvhQlQyCPIcoZ/G p2DJvMlPqLC7yVhOGaDh5ffUwqsh+PLaEqfHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:from:date:x-google-sender-auth :message-id:subject:to:content-type; b=RuAjJxPlBH1brvnzAgOIZef3BuBctBFrkc52EHLst2+xp8RNppKEcNfXKPJn24sxp6 5rJxLXgugXUHd3KCNQ70sEXBXl8hf5Kx2QW1zlDXwjwh6NSyl6/aMWUKpAe6gvCNgg4A +/Eu0TbO2hDUV5bpUxU347SH9yOyGA+ZHnblM= Received: by 10.236.109.12 with SMTP id r12mr10211333yhg.32.1292463492803; Wed, 15 Dec 2010 17:38:12 -0800 (PST) MIME-Version: 1.0 Sender: extrudedaluminiu@gmail.com Received: by 10.236.110.172 with HTTP; Wed, 15 Dec 2010 17:37:52 -0800 (PST) From: Venkatesh Srinivas Date: Wed, 15 Dec 2010 20:37:52 -0500 X-Google-Sender-Auth: xzv3mVOlykhvRLM_UNk0mz3dy20 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 16 Dec 2010 04:41:50 +0000 Subject: vm_map_findspace space search? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: me@endeavour.zapto.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 01:38:14 -0000 Hi, In svn r133636, there was a commit to convert the linear search in vm_map_findspace() to use the vm_map splay tree. Just curious, were there any discussions about that particular change? Any measurements other than the ones noted in the commit log? Any notes on why that design was used rather than any other? I've seen the 'Some mmap observations...' thread from about a year earlier and was wondering about some of the possible designs discussed there. In particular the Bonwick/Adams vmem allocator was brought up; I think that something inspired by it (and strangely close to the QuickFit malloc) would be appropriate: Here's how I see it working: * Add a series of power-of-two or logarithmic sized freelists to the vm_map structure; they would point to vm_map_entries immediately to the left of free space holes of a given size. * finding free space would just pop an entry off of the free space list and split in the usual way; deletion could coalesce in constant time. * Unlike the vmem allocator, we would not need to allocate external boundary tags; the vm_map_entries themselves would be the tags. At least from looking at the pattern of vm_map_findspace()s on DFly, the most common requests were for 1 page, 4 page, and 16 page-sized holes (iirc these combined for 75% of requests there; I imagine the pattern in FreeBSD would be very similar). The fragmentation concerns from this would be pretty minor with that pattern... Seem okay? Thoughts? Thanks! -- vs From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 16 18:43: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 1F233106564A for ; Thu, 16 Dec 2010 18:43:45 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by mx1.freebsd.org (Postfix) with ESMTP id A508C8FC0A for ; Thu, 16 Dec 2010 18:43:44 +0000 (UTC) Received: by fxm19 with SMTP id 19so3576845fxm.36 for ; Thu, 16 Dec 2010 10:43:43 -0800 (PST) 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=ZTry7633MBlZ01rA85atSXFUWg2LhGhJgfaKGUWpb4k=; b=WvqOUObodde9CfftLDhxapO0hLjixrmzzKMnnaeo+VbNIRht13mFLiRtt8XuQzJLZ+ Uxhzvn2vCijsPMG+gAOPtuti2u53D58nQJuG5MWGg3e//gTpCJAdbxcjB4aXn+U7xTrg o1ZUzoH4Y1M8vHrZujkdwm4ydnVh/cjPEddzw= 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=L5Bg+VXPj4U+3APj+Q7306M4ARQukhvvDLxEQO7sWz/i6j9ljTBYCT34A7ufRtQWcX P9iijJ+TIqvShHdML1/UsQLIq2/8AEIuu1sOo7udN6xHqo4NYBAsZM0bC84z1LRk8dTa X3gttK0tZPkM8+6S4+YZCSf8puJU2PHkTQ3BU= MIME-Version: 1.0 Received: by 10.223.96.194 with SMTP id i2mr142610fan.25.1292525023550; Thu, 16 Dec 2010 10:43:43 -0800 (PST) Received: by 10.223.116.205 with HTTP; Thu, 16 Dec 2010 10:43:43 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Dec 2010 12:43:43 -0600 Message-ID: From: Alan Cox To: me@endeavour.zapto.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: vm_map_findspace space search? 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, 16 Dec 2010 18:43:45 -0000 On Wed, Dec 15, 2010 at 7:37 PM, Venkatesh Srinivas < vsrinivas@dragonflybsd.org> wrote: > Hi, > > In svn r133636, there was a commit to convert the linear search in > vm_map_findspace() to use the vm_map splay tree. Just curious, were > there any discussions about that particular change? Any measurements > other than the ones noted in the commit log? Any notes on why that > design was used rather than any other? > > I've seen the 'Some mmap observations...' thread from about a year > earlier and was wondering about some of the possible designs discussed > there. In particular the Bonwick/Adams vmem allocator was brought up; > I think that something inspired by it (and strangely close to the > QuickFit malloc) would be appropriate: > > Here's how I see it working: > * Add a series of power-of-two or logarithmic sized freelists to the > vm_map structure; they would point to vm_map_entries immediately to the > left of free space holes of a given size. > * finding free space would just pop an entry off of the free space list > and split in the usual way; deletion could coalesce in constant time. > * Unlike the vmem allocator, we would not need to allocate external > boundary tags; the vm_map_entries themselves would be the tags. > > At least from looking at the pattern of vm_map_findspace()s on DFly, > the most common requests were for 1 page, 4 page, and 16 page-sized > holes (iirc these combined for 75% of requests there; I imagine the > pattern in FreeBSD would be very similar). The fragmentation concerns > from this would be pretty minor with that pattern... > > I'm afraid that the pattern is is not always so simple. Sometimes external fragmentation is, in fact, a problem. For example, search for "ZFS ARC kmem_map fragmentation". I recall there being at least one particularly detailed e-mail that quantified the fragmentation being caused by the ZFS ARC. There are also microbenchmarks that simulate an mmap() based web server, which will show a different pattern than you describe. If you're interested in working on something in this general area, I can suggest something. Alan From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 18 05:50: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 D6AF7106566B for ; Sat, 18 Dec 2010 05:50:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0B68FC13 for ; Sat, 18 Dec 2010 05:50:07 +0000 (UTC) Received: (qmail 9696 invoked by uid 399); 18 Dec 2010 05:50:06 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Dec 2010 05:50:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D0C4B8D.5040409@FreeBSD.org> Date: Fri, 17 Dec 2010 21:50:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Discussion about upgrading BIND in RELENG_7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Dec 2010 05:50:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 For those interested in the topic I have opened a discussion about the idea of upgrading BIND in RELENG_7 on freebsd-stable. You can find the post here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060640.html If you have anything to contribute please follow up on that list. Thanks, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJNDEuMAAoJEFzGhvEaGryEJMgIAMDmYwcX9vLOd9nh+XnZk/7S WJ2brZWl0BSG57J369rp3wQnQvFh9xMnUdUG2gnMnQOR/JwLKeBsQdcVfxhL6RgT mzelwstEa+OzmS4+cj96jWZYwQN1jyT5jMJCrbdM7JKTTPZG5PhUJTYvy7w68qNm lhzdBbyQnw5iVKv/tsCU7m1ioSa7Aq1fRgj7O5/GkBAfcXSrF31S66LxRPtcM5OP Ebxk4ttmJxZx5HXbQkU8xMhluYGvUaVt2quUks7mqkJ83NR6wNyL5A7WiP5aRHoA UWj5bfCiACnblRRL89d2jT858okQ/eeqUBMZ8DQLzlOSKB/FNJxj7iIL+6+evX0= =22Q7 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 18 20:09:37 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1225E106566C; Sat, 18 Dec 2010 20:09:37 +0000 (UTC) Date: Sat, 18 Dec 2010 20:09:37 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101218200937.GA2932@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: question about CFLAGS, CXXFLAGS and DEBUG_FLAGS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Dec 2010 20:09:37 -0000 hi there, i just stumbled over these lines: otaku% grep -n \${DEBUG_FLAGS} /usr/share/mk/bsd.prog.mk 24:CFLAGS+=${DEBUG_FLAGS} 25:CXXFLAGS+=${DEBUG_FLAGS} is it really necessary to assign the debug flags to both CFLAGS *and* CXXFLAGS? cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 18 20:40: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 F31BF106564A for ; Sat, 18 Dec 2010 20:40:57 +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 6FB448FC17 for ; Sat, 18 Dec 2010 20:40:57 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by erengrad.hoster.bg (Postfix) with ESMTP id 0E8B2DCCDD for ; Sat, 18 Dec 2010 22:40:55 +0200 (EET) Received: from straylight.ringlet.net (93-152-170-58.ddns.onlinedirect.bg [93.152.170.58]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id A521C5C089 for ; Sat, 18 Dec 2010 22:40:48 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 50631d by straylight.ringlet.net (DragonFly Mail Agent) Sat, 18 Dec 2010 22:40:47 +0200 Date: Sat, 18 Dec 2010 22:40:47 +0200 From: Peter Pentchev To: Alexander Best Message-ID: <20101218204047.GA4214@straylight.ringlet.net> Mail-Followup-To: Alexander Best , freebsd-hackers@freebsd.org References: <20101218200937.GA2932@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20101218200937.GA2932@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: A521C5C089.2ED7D X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-hackers@freebsd.org X-Spam-Status: No Cc: freebsd-hackers@freebsd.org Subject: Re: question about CFLAGS, CXXFLAGS and DEBUG_FLAGS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Dec 2010 20:40:58 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 18, 2010 at 08:09:37PM +0000, Alexander Best wrote: > hi there, >=20 > i just stumbled over these lines: >=20 > otaku% grep -n \${DEBUG_FLAGS} /usr/share/mk/bsd.prog.mk > 24:CFLAGS+=3D${DEBUG_FLAGS} > 25:CXXFLAGS+=3D${DEBUG_FLAGS} >=20 > is it really necessary to assign the debug flags to both CFLAGS *and* CXX= FLAGS? Uhm... yes, so they can be used in both C and C++ programs :) =2E..or are you making the mistake I've made too many times (and still make sometimes) of confusing CXXFLAGS with CPPFLAGS? :) 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 Hey, out there - is it *you* reading me, or is it someone else? --u3/rZRmxL6MmkK24 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) iQIcBAEBCAAGBQJNDRxJAAoJEGUe77AlJ98TAYoQAIXPMREiogWQiNJ5S56OzfMh agWlZe4imMPzEiiQliDraSUBo/7T4hKWdsMOuEYwqw4hGcHFp85UaUK6TuTDZjdY w46AnxmswByJa1FBNJIxmkQJpqdGMn4trwpNcBeXxos362aQ9c99MQn9d8hJbF/f hgRk3BzptS4cc1eCfcE8PXmUCMqvyqIhtMtxxFCRNIWLZRrG9vRXHPj7guB6pLGU ZA4apdJtLwBHUObk8tTOXz0sIVhpMZveXJj3lilCSgPwJPekZV0ivoqErXwMiKKN 73mp2gqefnRY8GEb7XO6WrbwjJmLhndlX4NjuhXjYRyR90M0/LwenFJ0t4gEHuSZ mO+lQk4Dx1Qix3MUtdWFN9VqU4q2vQMiUefWAmB5+poizOp3EsTZTu1cWs7IaIHz /yX6Tx4goLEvQgeWNDEr6I8yit+uxc5uDWRxcMzyBMgp4986FTsaOiIDACiEd0/A OM6X9x+z4HkhXo6NebgCniLxj09boMyCYzFY1N/RXFH45HHsx7U/yQBdDah4cXBP bA4HfOxoDZjbPf/GsdsBw95LtWFhHl7qetOodYAzhcCy0dh6l9AHM+OV4OItcruE Kztp4LKdMbVJ9QFvetR6PUVXdH7CoOc0U9PuXS+H4qtqgv71f08ZHj5z1+tIabJ+ tXCDnYiMfGaca1Vl29iz =mxDc -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 18 21:24:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 72C85106566B; Sat, 18 Dec 2010 21:24:31 +0000 (UTC) Date: Sat, 18 Dec 2010 21:24:31 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101218212431.GA35554@freebsd.org> References: <20101218200937.GA2932@freebsd.org> <20101218204047.GA4214@straylight.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101218204047.GA4214@straylight.ringlet.net> Cc: Subject: Re: question about CFLAGS, CXXFLAGS and DEBUG_FLAGS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Dec 2010 21:24:31 -0000 On Sat Dec 18 10, Peter Pentchev wrote: > On Sat, Dec 18, 2010 at 08:09:37PM +0000, Alexander Best wrote: > > hi there, > > > > i just stumbled over these lines: > > > > otaku% grep -n \${DEBUG_FLAGS} /usr/share/mk/bsd.prog.mk > > 24:CFLAGS+=${DEBUG_FLAGS} > > 25:CXXFLAGS+=${DEBUG_FLAGS} > > > > is it really necessary to assign the debug flags to both CFLAGS *and* CXXFLAGS? > > Uhm... yes, so they can be used in both C and C++ programs :) > ...or are you making the mistake I've made too many times (and still > make sometimes) of confusing CXXFLAGS with CPPFLAGS? :) *hehehe* i don't think so. i just saw a lot of these lines in buildworld: clang++ -O2 -pipe -DNDEBUG -g -I/usr/obj/usr/subversion-src/tmp/legacy/usr/include -I/usr/subversion-src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/subversion-src/gnu/usr.bin/gperf -g -c /usr/subversion-src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc clang++: warning: argument unused during compilation: '-g' clang++: warning: argument unused during compilation: '-g' as you can see -g gets specified twice, so i thought maybe adding -g to CFLAGS makes adding it to CXXFLAGS obsolete. cheers. alex > > 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 > Hey, out there - is it *you* reading me, or is it someone else? -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 18 22:39: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 C51EE106566B for ; Sat, 18 Dec 2010 22:39:17 +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 9BF038FC12 for ; Sat, 18 Dec 2010 22:39:17 +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 oBIMOZfR067213 for ; Sat, 18 Dec 2010 14:24:35 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id oBIMOYfl067212; Sat, 18 Dec 2010 14:24:34 -0800 (PST) Date: Sat, 18 Dec 2010 14:24:34 -0800 (PST) From: Matthew Dillon Message-Id: <201012182224.oBIMOYfl067212@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: MONITOR/MWAIT question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 22:39:17 -0000 Does anyone know if an IRET cancels/triggers a MONITOR event? Here's the problem: (1) main line kernel code is executing a MONITOR/MWAIT sequence. It executes its MONITOR but has not yet gotten to the MWAIT. (2) An interrupt occurs inbetween the MONITOR and the MWAIT. This triggers/cancels the main-line MONITOR but that doesn't help us (see below). (3) The interrupt code itself executes a MONITOR but the data check after the MONITOR determines the data has changed so MWAIT is skipped (e.g. MONITOR, CMPL, JNE 2f ,MWAIT, 2:). Because the data may have changed prior to the interrupt's MONITOR instruction the MONITOR may not be triggered in this case. Therefore the interrupt code leaves the monitor untriggered and active. i.e. never ran MWAIT. (4) The interrupt then IRETs. (5) The main line code continues on and gets to its MWAIT instruction which now waits for the trigger on the wrong MONITOR. (6) We blow up (or at least, until the next interrupt/SMI/whatever cancels the MWAIT). If IRET does not trigger/cancel the monitor then any code using the monitor/mwait sequence needs to somehow trigger/cancel it in the CMPL/JNE path. Presumably this can be done by doing a fake monitor on a stack address and then explicitly writing to it but it would be nice if IRETQ also trigger/canceled it. I can't find any documentation that clarifies whether IRET triggers/cancels the MONITOR. -Matt