From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 7 23:33:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED9BE106564A; Sat, 7 Jul 2012 23:33:46 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95EF88FC08; Sat, 7 Jul 2012 23:33:46 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q67NXhxq029465; Sat, 7 Jul 2012 19:33:43 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id q67NXhFi029462; Sat, 7 Jul 2012 19:33:43 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20472.51031.308284.775990@hergotha.csail.mit.edu> Date: Sat, 7 Jul 2012 19:33:43 -0400 From: Garrett Wollman To: Doug Barton In-Reply-To: <4FF8C3A1.9080805@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 07 Jul 2012 19:33:43 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 08 Jul 2012 00:32:43 +0000 Cc: "Bjoern A. Zeeb" , FreeBSD Hackers , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Jul 2012 23:33:47 -0000 < said: > BIND in the base today comes with a full-featured local resolver > configuration, which I'm confident that Dag-Erling can do for unbound > (and which I would be glad to assist with if needed). Other than that, > what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation.... -GAWollman From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 00:35:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 107FF106567C; Sun, 8 Jul 2012 00:35:14 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 04C0D8FC14; Sun, 8 Jul 2012 00:35:12 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so1501146wib.13 for ; Sat, 07 Jul 2012 17:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2CTH9upuzO+LJD76N93BdCTBQgg2aRfHsKhVUB5ciYE=; b=ha/NVrvf9W5ezvevnEri2qY3Oa3tF1Tg2bpvoczrfCfev8bteVwzq+CFvn/QOTt//0 nrziOcAcvhU6b5NkRmJ8mP5zE+ufGR8l3qIvfmQ89OfwDwEnqyVqDgPMz/W6ZG4PvcTe mb/nWy2ReQFHzQwZEuwuyTRv5Zren53dfsCJ7pMDbMbOVmHjk4YBFFoAc1gUMNsCCqRM 9OtHvntAYYx7UHJeKOu8L/NEoy21P34UkM6fBXet94eN7gC1VbN69hj+HBmSeCsdCG3A dIz7Zqv3Mbi+VfqqMBON5jMvHrgJ5eMOfX6wJfRYjTXO4LDsGI6kk9pWtvVi4yR8ZhQp 6Eyw== MIME-Version: 1.0 Received: by 10.180.105.130 with SMTP id gm2mr18539835wib.6.1341707712042; Sat, 07 Jul 2012 17:35:12 -0700 (PDT) Received: by 10.223.88.155 with HTTP; Sat, 7 Jul 2012 17:35:11 -0700 (PDT) In-Reply-To: <4FF8CA35.7040209@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> Date: Sat, 7 Jul 2012 19:35:11 -0500 Message-ID: From: Adam Vande More To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , FreeBSD Hackers , freebsd-security@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 00:35:14 -0000 On Sat, Jul 7, 2012 at 6:45 PM, Doug Barton wrote: > On 07/07/2012 16:34, Bjoern A. Zeeb wrote: > > On 7. Jul 2012, at 23:17 , Doug Barton wrote: > > > >> On 07/07/2012 14:16, Bjoern A. Zeeb wrote: > >>> > >>> On 3. Jul 2012, at 12:39 , Dag-Erling Sm=F8rgrav wrote: > >>> > >>>> Doug Barton writes: > >>>>> The correct solution to this problem is to remove BIND from the bas= e > >>>>> altogether, but I have no energy for all the whinging that would > happen > >>>>> if I tried (again) to do that. > >>>> > >>>> I don't think there will be as much whinging as you expect. Times > have > >>>> changed. > >>>> > >>>> I'm willing to import and maintain unbound (BSD-licensed validating, > >>>> recursive, and caching DNS resolver) if you remove BIND. > >>> > >>> I'd object to it. Trading one for another without gaining anything > does > >>> not help us much. > >> > >> Au contraire. It solves the problem of BIND release cycles not matchin= g > >> up with ours. This is a very important problem to solve. > > > > Right and unbound et al are better? Bind at least gives us long term > > support releases these days. We just need to make sure we pick them > > for releases. > > > > > >> I've already written at length as to what I think the dream solution i= s, > >> but we don't have anyone willing to code that yet, and even if we did, > >> there is no guarantee that we'd get the buy-in to make it happen. In > >> addition to being a good first step, doing this for DNS will also help > >> us shake out the exact issues you allude to below. > >> > >>> Don't get me wrong I have both running for years and even maintain > patches > >>> for unbound for 2 years now for functionality they do not provide, > which > >>> named happily gives me. > >> > >> Other than authoritative DNS, what features does unbound lack that you > want? > > > > DNS64 as a start. > > Personally I would classify that as a highly-specialized request, and > would point you to the bind* ports. I acknowledge that others may have a > different view. I am unclear on how this solves the main problem I think was stated about syncing up with release branches. If it doesn't solve that, isn't this just busy work? --=20 Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 00:48:48 2012 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 31323106566C; Sun, 8 Jul 2012 00:48:48 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) by mx1.freebsd.org (Postfix) with ESMTP id 05EF88FC12; Sun, 8 Jul 2012 00:48:48 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [131.252.214.6]) by rush.bluerosetech.com (Postfix) with ESMTPSA id E98F711437; Sat, 7 Jul 2012 17:48:40 -0700 (PDT) Received: from [IPv6:2001:470:8643:970:39f4:367d:dc6b:4e95] (unknown [IPv6:2001:470:8643:970:39f4:367d:dc6b:4e95]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id CD15B24CA6; Sat, 7 Jul 2012 17:48:39 -0700 (PDT) Message-ID: <4FF8D8E7.5060409@bluerosetech.com> Date: Sat, 07 Jul 2012 17:48:39 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Doug Barton References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> In-Reply-To: <4FF8CA35.7040209@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 00:48:48 -0000 On 2012-07-07 16:45, Doug Barton wrote: > Also re DNSSEC integration in the base, I've stated before that I > believe very strongly that any kind of hard-coding of trust anchors as > part of the base resolver setup is a bad idea, and should not be done. > We need to leverage the ports system for this so that we don't get stuck > with a scenario where we have stale stuff in the base that is hard for > users to upgrade. Considering the current root update cert bundle has a 20-year root CA and 5-year DNSSEC and email CAs, I don't think it's unreasonable to maintain a copy of icannbundle.pem in the source tree or simply rely on the copy built into unbound-anchor. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 02:45:10 2012 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 96EDA1065670 for ; Sun, 8 Jul 2012 02:45:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 484AE8FC0A for ; Sun, 8 Jul 2012 02:45:03 +0000 (UTC) Received: by obbun3 with SMTP id un3so21922171obb.13 for ; Sat, 07 Jul 2012 19:45:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1Fa+50Q+UL146sIdSFGP2bWQJfYwystOSjcsfvD5sTM=; b=gMozp0p21/mVa9Os4zZ695vfBd/kkHZ5OE6xL344cH+xq5bhXR4OmFGeKKpQ/7WjEN x8Ty8n7SynPhRwfsAOuy31oBNI0NRVPvvZSsyJd7Q91E82R2Vylxug71LqZMZLM5nTmv 7VzwgHF6mnonRngeg2xbXwO6V4lZvTqrRYYaM+6VKoQM609rZY1IOEn9sA640I13SHvc nK2xo0iLvLw4J0oWwDfmXLbBfrbtFAqZEBu5jDIRYHkHCHbKLQLReeyE9cXa+ILBYOAO GX4QXWJqceaUCNmIBAboMTwJ5/U1JzQ4gsJANElOJXRJqCCXPCWk9CxQADHTkEMSzq6p wF9w== Received: by 10.50.190.163 with SMTP id gr3mr5548256igc.74.1341715502782; Sat, 07 Jul 2012 19:45:02 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pb3sm12962076igc.17.2012.07.07.19.45.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 19:45:02 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20472.51031.308284.775990@hergotha.csail.mit.edu> Date: Sat, 7 Jul 2012 20:44:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQma1pHjYTOchoL4wyAXmJcHZhbnHppJaqrwJRkq7aTjKCK7X+cWsc08H5nHHS9+9At5T1zx Cc: "Bjoern A. Zeeb" , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Doug Barton , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 02:45:10 -0000 On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: > < = said: >=20 >> BIND in the base today comes with a full-featured local resolver >> configuration, which I'm confident that Dag-Erling can do for unbound >> (and which I would be glad to assist with if needed). Other than = that, >> what integration are you concerned about? >=20 > The utilities (specifically host(1) and dig(1)) are the only > user-visible interfaces I care about. I don't see any need for there > to be an authoritative name server in the base system. So long as the > resolver works properly and does DNSsec validation.... The only reason I want it in the base system is that ports don't cross = build very well, but the base system does. That's a weak +1 for keeping = something in the base system, but I'll be the first to admit it is a = second or third tier argument at best. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 03:45:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A31EC1065672; Sun, 8 Jul 2012 03:45:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 093218FC08; Sun, 8 Jul 2012 03:45:01 +0000 (UTC) Received: by werp13 with SMTP id p13so6946195wer.13 for ; Sat, 07 Jul 2012 20:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U+D6VfMM2kQNK9uaMHYA2P8UIhIpkPwnsCLznRT92Mo=; b=HebBeh8J8mi/23+/4aEtilloe6UXx9mJkGKZi2OHiur6X5kOhr952vQaPD6iDrN8ul M1waa7YGNOJ8P21PPBuLQKwlThaWi7vUars37SZgsjDWo5Wd5lMBH/p0fal+PVp+4Who hJzbT57757W8vebE1GAYiS+a40mY4Cj2SQupj/payopyEWK0s/O98Tq89Al39suUDxnj n5xFW5PdZiRppDixTlODv01o0/N1xbJSM2PR+tAEanrvfLNB596uxrgRqfrkNZJ4dm09 wIvd60brxMJ9Xxm2CoWyIV5qVafnLXtOhLPzwhVUJFx+tp5fARDrX60Wzs7fJb+SaF7r z8xw== MIME-Version: 1.0 Received: by 10.181.13.142 with SMTP id ey14mr19229386wid.19.1341719100905; Sat, 07 Jul 2012 20:45:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sat, 7 Jul 2012 20:45:00 -0700 (PDT) In-Reply-To: <1341686865.70246.22.camel@revolution.hippie.lan> References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> Date: Sat, 7 Jul 2012 23:45:00 -0400 Message-ID: From: Arnaud Lacombe To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 03:45:02 -0000 Hi, On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore wrote: > On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore >> wrote: >> > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: >> >> > That's neither correct nor robust in a couple of way: >> >> > 1) you have no guarantee a device unit will always give you the same resource. >> >> this raises the following question: how can a device, today, figure >> >> out which parent in a given devclass would give it access to resources >> >> it needs. >> >> >> >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by >> >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >> >> attachment is conditional to some BIOS setting. How can you tell >> >> gpioled(4) to attach on the chipset provided GPIO without hardcoding >> >> unit number either way ? >> >> >> >> AFAIK, you can not. >> >> >> >> Even hints provided layout description is defeated. Each device in a >> >> given devclass need to have a set of unique attribute to allow a child >> >> to distinguish it from other potential parent in the same devclass... >> >> >> >> - Arnaud >> > >> > Talking about a child being unable to choose the correct parent seems to >> > indicate that this whole problem is turned upside-down somehow; children >> > don't choose their parents. >> > >> actually, I think I was wrong, I thought device were attached to a >> devclass, but they are truly attached to a given device. My mistake. >> >> > Just blue-sky dreaming here on the fly... what we really have is a >> > resource-management problem. A device comes along that needs a GPIO >> > resource, how does it find and use that resource? >> > >> > Well, we have a resource manager, could that help somehow? Could a >> > driver that provides access to GPIO somehow register its availability so >> > that another driver can find and access it? The "resource" may be a >> > callable interface, it doesn't really matter, I'm just wondering if the >> > current rman stuff could be leveraged to help make the connection >> > between unrelated devices. I think that implies that there would have >> > to be something near the root of the hiearchy willing to be the >> > owner/manager of dynamic resources. >> > >> AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. >> The more I think about it, the more FTD is the answer. The open >> question now being "how to map a flexible device structure (FTD) to a >> less flexible structure (Newbus)" :/ >> >> - Arnaud > > Memory- and IO-mapped regions and IRQs are the only current uses of rman > (that I know of), but it was designed to be fairly agnostic about the > resources it manages. It just works with ranges of values (that it > really doesn't know how to interpret at all), leaving lots of room to > define new types of things it can manage. > > The downside is that it's designed to be used hierarchically in the > context of newbus, specifically to help parents manage the resources > that they are able to provide to their children. Trying to use it in a > way that allows devices which are hierarchically unrelated to allocate > resources from each other may amount to a square-peg/round-hole > situation. But the alternative is writing a new facility to allow > registration and allocation of resources using some sort symbolic method > of representing the resources such that the new manager doesn't have to > know much about what it's managing. I think it would be better to find > a way to reuse what we've already got if that's possible. > > I think we have two semi-related aspects to this problem... > > How do we symbolically represent the resources that drivers can provide > to each other? (FDT may be the answer; I don't know much about it.) > > How do devices use that symbolic representation to locate the provider > of the resource, and how is the sharing of those resources managed? > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 Smart Mobile Reference Design Board"[0], We first have SoC generic definition in `imx53.dtsi': soc { compatible = "simple-bus"; aips@50000000 { /* AIPS1 */ compatible = "fsl,aips-bus", "simple-bus"; spba@50000000 { compatible = "fsl,spba-bus", "simple-bus"; esdhc@50004000 { /* ESDHC1 */ compatible = "fsl,imx53-esdhc"; reg = <0x50004000 0x4000>; interrupts = <1>; status = "disabled"; }; [...] gpio2: gpio@53f8c000 { /* GPIO3 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f8c000 0x4000>; }; gpio3: gpio@53f90000 { /* GPIO4 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f90000 0x4000>; }; [...] } then board specific definition overriding its parent's in `imx53-smd.dts': soc { aips@50000000 { /* AIPS1 */ spba@50000000 { esdhc@50004000 { /* ESDHC1 */ cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ status = "okay"; }; [...] } Now the challenge is to make this to work within newbus. One of the problem I see is mixing FTD enumerated and bus (PCI, PnP ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device using GPIO from a SuperIO and the chipset on the PCI bus. I would have to describe the SuperIO *and* the chipset GPIO in the FDT to be able to refer to them in my device... - Arnaud [0]: see Linux' arch/arm/boot/dts/imx53* > -- Ian > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 05:05:07 2012 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 99998106566B for ; Sun, 8 Jul 2012 05:05:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83FEF8FC12 for ; Sun, 8 Jul 2012 05:05:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so18403192pbb.13 for ; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TW9rTklz1TjMt39Mu+Qv/XscBwApKQZokjtafvl8Tzc=; b=N8D1EYGQzg1zz2TBWmEgiNhovg8qGSokBo6F2X2/XrU1XBhZvRRnfP026WvNYAJeze l+o5PO29exZ6geaEMLxzXeT7vx6NIGs9aUsVl3oZKI4ec0XrOciQudLMed++x+jk/XDU Qn6g3ds2fuziYnYtjBRvRujTurzdIemu0eQML2wHhXkhfIwaPS2YyWtxuVUhVHP3uzCV VyWa4ZSsHCu1M6qi9DqrP87rq4Z6vY1SteykScTSHMhhUGuf7Jz4BX4U6B8B7qZadR46 jDfwE2tjft9IKkKkxZHs5J5WPqIGPOpsCdoyEviOO6JmXK4BGCgbip02F0KWzC9a8142 xvRg== Received: by 10.66.84.71 with SMTP id w7mr56525402pay.33.1341723900265; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id tj8sm25088132pbc.10.2012.07.07.22.04.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 22:04:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 7 Jul 2012 23:04:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnFxLCpF0D6W0oLot+zAa3PrFj+BzA/2WGVLO479ZDYDtVX2g/5sCXNStsjw8WFHDLXbC13 Cc: Ian Lepore , FreeBSD Current , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 05:05:07 -0000 On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore > wrote: >> On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: >>> Hi, >>>=20 >>> On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore >>> wrote: >>>> On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >>>>> Hi, >>>>>=20 >>>>> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe = wrote: >>>>>> That's neither correct nor robust in a couple of way: >>>>>> 1) you have no guarantee a device unit will always give you the = same resource. >>>>> this raises the following question: how can a device, today, = figure >>>>> out which parent in a given devclass would give it access to = resources >>>>> it needs. >>>>>=20 >>>>> Say, you have gpiobus0 provided by a superio and gpiobus1 provided = by >>>>> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >>>>> attachment is conditional to some BIOS setting. How can you tell >>>>> gpioled(4) to attach on the chipset provided GPIO without = hardcoding >>>>> unit number either way ? >>>>>=20 >>>>> AFAIK, you can not. >>>>>=20 >>>>> Even hints provided layout description is defeated. Each device in = a >>>>> given devclass need to have a set of unique attribute to allow a = child >>>>> to distinguish it from other potential parent in the same = devclass... >>>>>=20 >>>>> - Arnaud >>>>=20 >>>> Talking about a child being unable to choose the correct parent = seems to >>>> indicate that this whole problem is turned upside-down somehow; = children >>>> don't choose their parents. >>>>=20 >>> actually, I think I was wrong, I thought device were attached to a >>> devclass, but they are truly attached to a given device. My mistake. >>>=20 >>>> Just blue-sky dreaming here on the fly... what we really have is a >>>> resource-management problem. A device comes along that needs a = GPIO >>>> resource, how does it find and use that resource? >>>>=20 >>>> Well, we have a resource manager, could that help somehow? Could a >>>> driver that provides access to GPIO somehow register its = availability so >>>> that another driver can find and access it? The "resource" may be = a >>>> callable interface, it doesn't really matter, I'm just wondering if = the >>>> current rman stuff could be leveraged to help make the connection >>>> between unrelated devices. I think that implies that there would = have >>>> to be something near the root of the hiearchy willing to be the >>>> owner/manager of dynamic resources. >>>>=20 >>> AFAIR, rman is mostly there to manage memory vs. i/o mapped = resources. >>> The more I think about it, the more FTD is the answer. The open >>> question now being "how to map a flexible device structure (FTD) to = a >>> less flexible structure (Newbus)" :/ >>>=20 >>> - Arnaud >>=20 >> Memory- and IO-mapped regions and IRQs are the only current uses of = rman >> (that I know of), but it was designed to be fairly agnostic about the >> resources it manages. It just works with ranges of values (that it >> really doesn't know how to interpret at all), leaving lots of room to >> define new types of things it can manage. >>=20 >> The downside is that it's designed to be used hierarchically in the >> context of newbus, specifically to help parents manage the resources >> that they are able to provide to their children. Trying to use it in = a >> way that allows devices which are hierarchically unrelated to = allocate >> resources from each other may amount to a square-peg/round-hole >> situation. But the alternative is writing a new facility to allow >> registration and allocation of resources using some sort symbolic = method >> of representing the resources such that the new manager doesn't have = to >> know much about what it's managing. I think it would be better to = find >> a way to reuse what we've already got if that's possible. >>=20 >> I think we have two semi-related aspects to this problem... >>=20 >> How do we symbolically represent the resources that drivers can = provide >> to each other? (FDT may be the answer; I don't know much about it.) >>=20 >> How do devices use that symbolic representation to locate the = provider >> of the resource, and how is the sharing of those resources managed? >>=20 > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 > Smart Mobile Reference Design Board"[0], >=20 > We first have SoC generic definition in `imx53.dtsi': >=20 > soc { > compatible =3D "simple-bus"; > aips@50000000 { /* AIPS1 */ > compatible =3D "fsl,aips-bus", "simple-bus"; >=20 > spba@50000000 { > compatible =3D "fsl,spba-bus", "simple-bus"; >=20 > esdhc@50004000 { /* ESDHC1 */ > compatible =3D "fsl,imx53-esdhc"; > reg =3D <0x50004000 0x4000>; > interrupts =3D <1>; > status =3D "disabled"; > }; >=20 > [...] >=20 > gpio2: gpio@53f8c000 { /* GPIO3 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f8c000 0x4000>; > }; >=20 > gpio3: gpio@53f90000 { /* GPIO4 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f90000 0x4000>; > }; >=20 > [...] > } >=20 > then board specific definition overriding its parent's in = `imx53-smd.dts': >=20 > soc { > aips@50000000 { /* AIPS1 */ > spba@50000000 { > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio3 11 0>; /* GPIO4_11 */ > status =3D "okay"; > }; >=20 > [...] > } >=20 > Now the challenge is to make this to work within newbus. >=20 > One of the problem I see is mixing FTD enumerated and bus (PCI, PnP > ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device > using GPIO from a SuperIO and the chipset on the PCI bus. I would have > to describe the SuperIO *and* the chipset GPIO in the FDT to be able > to refer to them in my device... I'm starting to think that newbus device names aren't a good fit here. = gpio2 isn't a newbus name, but an fdt one. I think that you'll the gpio = driver providing GPIO services that can map these pins to actions. = Trying to do it all within newbus likely is a mistake. At the very = least you'll want to make the providers have an earlier pass number than = the devices that are provided for. The GPIO driver should provide a = GPIO service or resource that other devices can access and use. This = would make it non unloadable (or effectively so), must like the PCI bus = is effectively non-unloadable since too many things will depend on this = device.... I face similar challenges in my work to refactor the Atmel GPIO stuff. Warner > - Arnaud >=20 > [0]: see Linux' arch/arm/boot/dts/imx53* >=20 >> -- Ian >>=20 >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 06:08:59 2012 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 AA5F7106566C for ; Sun, 8 Jul 2012 06:08:59 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F36D08FC12 for ; Sun, 8 Jul 2012 06:08:58 +0000 (UTC) Received: by obbun3 with SMTP id un3so22164629obb.13 for ; Sat, 07 Jul 2012 23:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition; bh=eI3IBevTuT2/45BJO+zD8YDUNztJuT/jAv4qMMI+b60=; b=NWJbCbG4grhQ+wnr2+JxQ8O1rMnCTbHKe+YFM3bDOCsu2+SZgrqhZVa8W/gTeMSCAo ZBSf/vGUZ8gox1UINOtKICSXNr73hAx+VYbUWTeBPe1pBWvOyuLtdGiUSUthU+IU4GP4 4Gk67zfspptmvFTO67qkw4Y0FF9fIlG84DXMo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-gm-message-state; bh=eI3IBevTuT2/45BJO+zD8YDUNztJuT/jAv4qMMI+b60=; b=SbtQqfFgGz6yJRKBO3y0mWZCVjpbSCEw4RmXh40zw+idyeH8g6Tf1s/qhpJyVSkr7d Ol5/dfbKpn/b9xfFLRbG//qBVqtUeTV/SUdKPzVlAb14ZIGmbDODqKULmYo7DrEKgXjz IZNL4eJxyEXH7jnTucgu6zWz4mGHcKg8nJOW480VprH3KZHq7Sdy0ll9lluRmOWC+OKS jfH6SVLfqla5g8mhB/nASY8mU9amLcxMFH3JeAFU4lWJubJBTZfETb915sm00qHaWbJn WEvc9oJbnINn1Jt3kQchUUuvYOAi38p+vTqp42fMKl9kSBvX8w1D2cCCjFMQZhinNrs1 qtSA== Received: by 10.50.40.193 with SMTP id z1mr5937303igk.0.1341727738298; Sat, 07 Jul 2012 23:08:58 -0700 (PDT) Received: from DataIX.net ([99.109.126.183]) by mx.google.com with ESMTPS id k6sm6269783igz.9.2012.07.07.23.08.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 23:08:57 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6868rr7048878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 02:08:54 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6868rUm048877; Sun, 8 Jul 2012 02:08:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 8 Jul 2012 02:08:53 -0400 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120708060853.GA44046@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline X-Gm-Message-State: ALoCoQl8pSuiTsNW81GGvz1V76Z+WeMijfGO1Q1QrLs14WJEwYq1Fuh0aiLp+hm/w79zXoKLHfMF Cc: hackers@freebsd.org Subject: mtree(8) reservation of 16 -1 char[] in mtree files... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stable@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 06:08:59 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I was just going through mtree(8) and happen to notice that mtree while populating a mtree file by the following [1] reference that it suffixes spaces as some sort of way to either reserve or pad the result for every value. Has anyone else see this behavior in Xterm or cons2* terminals from stable/8 i386 @ r238072 ? I tested this with /bin/sh /bin/csh /bin/bash /bin/ksh on cons25 cons50 xterm logged in directly as either a user or root through ssh and local. I looked over the mtree files in /etc/mtree and they do not exhibit the same thing so it now has me curious if something snuck in that would have changed this behavior. I have not had time to see if this repeats on other arch's 1). mtree -c -d -i -n -k uname,gname,mode,nochange >mtree.out Thanks to anyone that hits me with the clue bat if I have missed something. --=20 - (2^(N-1)) --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP+SP1AAoJEBSh2Dr1DU7WI3IH/0XyxmqX94g1KRj1kjRjIsIO fSyjIvMMEb3DTDfZWXdAuS4JXINjHG13XQhwqM7YJxGe9Ibp8TjUm/AbLWQGFjp7 ZeKzXZC3//F03fq1/wM15LC2y48IMXnDC+dm3CdGAoLUBs8OdfKsYW/zDy4rnaes DhCYnPNuEWPRQTcp/6AePyp3Gtd6U+9yXA/T3sfEI+uULTKxCywPywfg+VRrrp0b wGSWmlhkl//cdOjxKEzS+EDTB9i8ShSNo/b4J96yyBFGAIusJ+bPCtgR6ESqdy8D PrmVPFp3WgG7x9FK0L6iTdN/kLAMHbym7IpwsQdOmJgRm2aDfwk+B0JLYvIAte8= =khoY -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 07:46:19 2012 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 91DFA1065673; Sun, 8 Jul 2012 07:46:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id E67C38FC0A; Sun, 8 Jul 2012 07:46:18 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q687k4TK001564; Sun, 8 Jul 2012 09:46:05 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q687k45T001561; Sun, 8 Jul 2012 09:46:04 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 8 Jul 2012 09:46:04 +0200 (CEST) From: Wojciech Puchar To: Garrett Wollman In-Reply-To: <20472.51031.308284.775990@hergotha.csail.mit.edu> Message-ID: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 08 Jul 2012 09:46:05 +0200 (CEST) Cc: "Bjoern A. Zeeb" , =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , Doug Barton , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 07:46:19 -0000 >> what integration are you concerned about? > > The utilities (specifically host(1) and dig(1)) are the only > user-visible interfaces I care about. I don't see any need for there > to be an authoritative name server in the base system. So long as the > resolver works properly and does DNSsec validation.... fully agree. i don't see a real reason to have named in base system. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 08:03:19 2012 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 7B5181065675; Sun, 8 Jul 2012 08:03:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 32D348FC08; Sun, 8 Jul 2012 08:03:19 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 5AF6725D37C3; Sun, 8 Jul 2012 08:03:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> Date: Sun, 8 Jul 2012 08:03:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Hackers , Doug Barton , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 08:03:19 -0000 On 8. Jul 2012, at 02:44 , Warner Losh wrote: >=20 > On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: >> < = said: >>=20 >>> BIND in the base today comes with a full-featured local resolver >>> configuration, which I'm confident that Dag-Erling can do for = unbound >>> (and which I would be glad to assist with if needed). Other than = that, >>> what integration are you concerned about? >>=20 >> The utilities (specifically host(1) and dig(1)) are the only >> user-visible interfaces I care about. I don't see any need for there >> to be an authoritative name server in the base system. So long as = the >> resolver works properly and does DNSsec validation.... >=20 > The only reason I want it in the base system is that ports don't cross = build very well, but the base system does. That's a weak +1 for keeping = something in the base system, but I'll be the first to admit it is a = second or third tier argument at best. The real reason you want exactly these tools in base is that otherwise = you end up rewriting tiny parts of freebsd-update etc that actually depend = on host, etc. to query SRV for SRV records. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 08:07:12 2012 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 97FA6106566C; Sun, 8 Jul 2012 08:07:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 514498FC14; Sun, 8 Jul 2012 08:07:12 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 58E8625D37C3; Sun, 8 Jul 2012 08:07:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FF8CA35.7040209@FreeBSD.org> Date: Sun, 8 Jul 2012 08:07:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6A57F340-D9F0-4352-B009-4C211CB931F9@lists.zabbadoz.net> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 08:07:12 -0000 On 7. Jul 2012, at 23:45 , Doug Barton wrote: > On 07/07/2012 16:34, Bjoern A. Zeeb wrote: >> On 7. Jul 2012, at 23:17 , Doug Barton wrote: >>> Other than authoritative DNS, what features does unbound lack that = you want? >>=20 >> DNS64 as a start.=20 >=20 > Personally I would classify that as a highly-specialized request, and > would point you to the bind* ports. I acknowledge that others may have = a > different view. Just to give you an idea - there are US nation-wide networks that depend on it these days. It's become an essential feature unfortunately. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:19:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1A8B11065672 for ; Sun, 8 Jul 2012 09:19:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8433E179422; Sun, 8 Jul 2012 09:19:49 +0000 (UTC) Message-ID: <4FF950B5.3080207@FreeBSD.org> Date: Sun, 08 Jul 2012 02:19:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Warner Losh References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> In-Reply-To: <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling?=, "Bjoern A. Zeeb" , =?ISO-8859-1?Q?_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:19:50 -0000 On 07/07/2012 19:44, Warner Losh wrote: > > On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: >> < said: >> >>> BIND in the base today comes with a full-featured local resolver >>> configuration, which I'm confident that Dag-Erling can do for unbound >>> (and which I would be glad to assist with if needed). Other than that, >>> what integration are you concerned about? >> >> The utilities (specifically host(1) and dig(1)) are the only >> user-visible interfaces I care about. I don't see any need for there >> to be an authoritative name server in the base system. So long as the >> resolver works properly and does DNSsec validation.... > > The only reason I want it in the base system is that ports don't cross build very well, but the base system does. That's a weak +1 for keeping something in the base system, but I'll be the first to admit it is a second or third tier argument at best. With the proper ports infrastructure, this issue goes away. Meanwhile, we're already in basic agreement that importing unbound into the base is a good stopgap. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:21:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 22EDC106564A for ; Sun, 8 Jul 2012 09:21:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B4E07155E8B; Sun, 8 Jul 2012 09:21:46 +0000 (UTC) Message-ID: <4FF9512A.8050803@FreeBSD.org> Date: Sun, 08 Jul 2012 02:21:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:21:47 -0000 On 07/08/2012 01:03, Bjoern A. Zeeb wrote: > > On 8. Jul 2012, at 02:44 , Warner Losh wrote: > >> >> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: >>> < said: >>> >>>> BIND in the base today comes with a full-featured local resolver >>>> configuration, which I'm confident that Dag-Erling can do for unbound >>>> (and which I would be glad to assist with if needed). Other than that, >>>> what integration are you concerned about? >>> >>> The utilities (specifically host(1) and dig(1)) are the only >>> user-visible interfaces I care about. I don't see any need for there >>> to be an authoritative name server in the base system. So long as the >>> resolver works properly and does DNSsec validation.... >> >> The only reason I want it in the base system is that ports don't cross build very well, but the base system does. That's a weak +1 for keeping something in the base system, but I'll be the first to admit it is a second or third tier argument at best. > > The real reason you want exactly these tools in base is that otherwise you > end up rewriting tiny parts of freebsd-update etc that actually depend on > host, etc. to query SRV for SRV records. That's an implementation issue, and is easily handled with drill, or the host-like program we all agree is a really-nice-to-have. -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:24:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E139B106564A for ; Sun, 8 Jul 2012 09:24:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7FD3F1790DA; Sun, 8 Jul 2012 09:24:21 +0000 (UTC) Message-ID: <4FF951C5.8030400@FreeBSD.org> Date: Sun, 08 Jul 2012 02:24:21 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <6A57F340-D9F0-4352-B009-4C211CB931F9@lists.zabbadoz.net> In-Reply-To: <6A57F340-D9F0-4352-B009-4C211CB931F9@lists.zabbadoz.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:24:38 -0000 On 07/08/2012 01:07, Bjoern A. Zeeb wrote: > On 7. Jul 2012, at 23:45 , Doug Barton wrote: > >> On 07/07/2012 16:34, Bjoern A. Zeeb wrote: >>> On 7. Jul 2012, at 23:17 , Doug Barton wrote: > >>>> Other than authoritative DNS, what features does unbound lack that you want? >>> >>> DNS64 as a start. >> >> Personally I would classify that as a highly-specialized request, and >> would point you to the bind* ports. I acknowledge that others may have a >> different view. > > Just to give you an idea - there are US nation-wide networks that depend > on it these days. It's become an essential feature unfortunately. I didn't say it was unimportant, unused, or un-anything else. I said that we already have a solution for it, which doesn't need to stay in the base. In fact, no base BIND version supports DNS64 robustly. 9.8 (in 9-RELEASE) supports it weakly. If you have an enterprise network that relies on DNS64 you're infinitely better off with BIND 9.9, which hasn't been (and isn't likely to be) imported. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:29:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 05D2E106566C; Sun, 8 Jul 2012 09:29:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 68D30161B1B; Sun, 8 Jul 2012 09:29:31 +0000 (UTC) Message-ID: <4FF952FB.10200@FreeBSD.org> Date: Sun, 08 Jul 2012 02:29:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adam Vande More References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , freebsd-security@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:29:32 -0000 On 07/07/2012 17:35, Adam Vande More wrote: > I am unclear on how this solves the main problem I think was stated > about syncing up with release branches. I've already explained this at length in the past. ISC has changed both their release schedule and their policy regarding not allowing new features in a release branch. As a result, they release more frequently than we do, and EOL supported branches sooner than we do. Unbound has different policies and release schedules that are more in line with ours. So in the short term (as in, the next few years) we're better off with unbound in the base. The ideal, long-term solution is to re-think what "The Base" is, and give users more flexibility at install time. Unfortunately, there is a knee-jerk "zomg, we don't want to be like linux!" reaction to that idea which (to date) has prevented a rational discussion about it. I hope that changes. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:31:33 2012 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 58F6D1065678; Sun, 8 Jul 2012 09:31:33 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B0E8D8FC1C; Sun, 8 Jul 2012 09:31:32 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q689VLBX002039; Sun, 8 Jul 2012 11:31:21 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q689VL9u002036; Sun, 8 Jul 2012 11:31:21 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 8 Jul 2012 11:31:21 +0200 (CEST) From: Wojciech Puchar To: Doug Barton In-Reply-To: <4FF952FB.10200@FreeBSD.org> Message-ID: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 08 Jul 2012 11:31:22 +0200 (CEST) Cc: freebsd-security@freebsd.org, Adam Vande More , =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:31:33 -0000 > line with ours. So in the short term (as in, the next few years) we're > better off with unbound in the base. > > The ideal, long-term solution is to re-think what "The Base" is, and > give users more flexibility at install time. Unfortunately, there is a making base as minimal as possible give you exactly that! > knee-jerk "zomg, we don't want to be like linux!" reaction to that idea it is proper reaction. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 09:33:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DD388106566B; Sun, 8 Jul 2012 09:33:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5EA501637BC; Sun, 8 Jul 2012 09:31:18 +0000 (UTC) Message-ID: <4FF95365.7010605@FreeBSD.org> Date: Sun, 08 Jul 2012 02:31:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Darren Pilgrim References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF8D89B.1030308@bluerosetech.com> In-Reply-To: <4FF8D89B.1030308@bluerosetech.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 09:33:30 -0000 On 07/07/2012 17:47, Darren Pilgrim wrote: > On 2012-07-07 16:45, Doug Barton wrote: >> Also re DNSSEC integration in the base, I've stated before that I >> believe very strongly that any kind of hard-coding of trust anchors as >> part of the base resolver setup is a bad idea, and should not be done. >> We need to leverage the ports system for this so that we don't get stuck >> with a scenario where we have stale stuff in the base that is hard for >> users to upgrade. > > Considering the current root update cert bundle has a 20-year root CA > and 5-year DNSSEC and email CAs, Neither of which has any relevance to the actual root zone ZSK, which could require an emergency roll tomorrow. > I don't think it's unreasonable to > maintain a copy of icannbundle.pem in the source tree Again, that has nothing to do with the actual ZSK, other than providing a way to validate the *existing* one. That's not the issue, at all. -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 10:21:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C4121065673; Sun, 8 Jul 2012 10:21:49 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63A7E8FC12; Sun, 8 Jul 2012 10:21:48 +0000 (UTC) Received: by bkcje9 with SMTP id je9so4804967bkc.13 for ; Sun, 08 Jul 2012 03:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ac4PAmgxVKm+Bt8a1cb9tZUZ+9HQITv1YbyOeV+/bvk=; b=x6+6wfTEQEcQpG9XfvWMgVNLCm+ivkfhpAPwZl7qFJpE4IshV14qVydiNM325xoNDK vdg1BdpaYYg6ydYfJsTL51CsPxApvIu0p1m1vg2+l29RFFpPQ7Joahp2yjAn4LAJuySE JkI4rFnJ83RNdhs0TxX5eOBFu1EcoweRIbthNeHwi95TKFb+j8NdFqC/I8bdU02SvDKM 1GbpLLPw9PX5QE275eH4vCnnCBf5X3iF1Se1BzT3YHta2aNtYP/nhKTdjMoNOLhK2wry wgkaeaGzwe0SuJr4KJCTrAHC8SK19ie4PACwOGCbm3GMd/rxApCJKC0aCC7/duFY3u88 Q8Ag== Received: by 10.205.134.137 with SMTP id ic9mr3571968bkc.57.1341742907361; Sun, 08 Jul 2012 03:21:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.49.87 with HTTP; Sun, 8 Jul 2012 03:21:17 -0700 (PDT) From: Chris Rees Date: Sun, 8 Jul 2012 11:21:17 +0100 Message-ID: To: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Naram Qashat , pho@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: port devel/doxygen failing to test on -CURRENT and -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 10:21:49 -0000 Hi all / David, doxygen has been failing for a while now on -CURRENT and apparently -STABLE too. The current fix is disabling one of the tests in the build, but obviously it points to a problem with our base system.... I've trussed [1] the failing code [2], and it looks as though it's hanging on a _umtx call. I'm gratuitously ignorant of what goes on there... but the timings of recent commits to umtx.h [3] could indicate a link (hope it's not bogus...). Any pointers on what I should do next? Chris [1] http://www.bayofrum.net/~crees/scratch/doxygen-truss [2] http://www.bayofrum.net/tb/index.php?action=display_markup_log&build=10-local&id=1037 [3] http://svnweb.freebsd.org/base/head/sys/sys/umtx.h?view=log From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 11:05:32 2012 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 285E2106564A for ; Sun, 8 Jul 2012 11:05:32 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 932268FC0C for ; Sun, 8 Jul 2012 11:05:31 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q68B5OdQ050278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 8 Jul 2012 21:05:24 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q68B5GhI038655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2012 21:05:17 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q68B5GxM038654 for freebsd-hackers@freebsd.org; Sun, 8 Jul 2012 21:05:16 +1000 (EST) (envelope-from peter) Date: Sun, 8 Jul 2012 21:05:16 +1000 From: Peter Jeremy To: freebsd-hackers@freebsd.org Message-ID: <20120708110516.GA38312@server.rulingia.com> References: <20120703111753.GB72292@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20120703111753.GB72292@server.rulingia.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: contigmalloc() breaking Xorg X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 11:05:32 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-03 21:17:53 +1000, Peter Jeremy wro= te: >I have a reasonably recent 8-stable/amd64 system (r237444) with a "ATI >Radeon HD 2400 Pro", xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1 >8GB RAM and ZFS. I'm seeing fairly consistent problems with Xorg =2E.. >How difficult would it be to modify bus_dmamem_alloc() [at least on >x86] to handle multi-segment allocations? I think I've managed to create an amd64 bus_dmamem_alloc() that allows page-sized allocations as long as no boundary condition is specified and no more than page-sized alignment is required (porting it to other architectures would be trivial). I've given it a quick whirl inside a VBox and no smoke came out but I'd appreciate someone with a better understanding of bus_dma(9) and vm/vm_contig.c giving http://www.rulingia.com/bugs/patch-wiredmalloc a once-over. Note that this patch is against 8.x but there's only a trivial difference to head. BTW, the comment in busdma_machdep.c:bus_dmamem_alloc() * XXX Use Contigmalloc until it is merged into this facility * and handles multi-seg allocations. Nobody is doing * multi-seg allocations yet though. * XXX Certain AGP hardware does. does not appear to be accurate. Apart from drm, quite a few drivers call bus_dma_tag_create(9) with multiple segments and also call bus_dmamem_alloc(9) [though I haven't verified that the calls share the same bus_dma_tag, so I can't be absolutely certain]. BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've noticed they appear to potentially allocate substantial kernel stack under some conditions as several bus_dma(9) functions include: bus_dma_segment_t dm_segments[dmat->nsegments]; What prevents this overflowing the kernel stack? --=20 Peter Jeremy --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/5aWwACgkQ/opHv/APuIdzaACaA4AO/KTUaGipf+W8ON6dy6ud 7WIAoMNon9i8PrZ+k72+fX+keyE4m87i =nFuQ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 11:39:46 2012 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 6A5C8106564A for ; Sun, 8 Jul 2012 11:39:46 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC6B18FC14 for ; Sun, 8 Jul 2012 11:39:45 +0000 (UTC) Received: by bkcje9 with SMTP id je9so4822013bkc.13 for ; Sun, 08 Jul 2012 04:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Kvm57G5mEb2VrAvztscWQN6yDGev6BN0fU1yIM5GD0M=; b=BOHugCGlEWbW7MW1w2Foc4lv5NT3Ow8z5e5nv8c+QZNSG6w8nb6nHHuf5uA06LDc0v HV/SJId4tFaTZcuXsU/S2PeAkwTGovkwtDfweTNkU7BcJ5i5plWdAAd6XuZGHe03gvqG 5XwxTIyAFyNl9mJQSYxR1RsovcfX8HcTpk8TB58BId/0MdDnwSz780weNtsBF7Pf+Lo5 GFeblLk+uMs1zcDgio2JzaPBzpsdswDx4ID2VX7xdEsB/3iuqIeAyMchNffJezXaX7am osEdhKclo8IoCHGiTbPG29et08yM832d91/hTFTXKyIN5DilpJAq4ODmzzH62oJXVK6k l9kQ== Received: by 10.204.152.137 with SMTP id g9mr18494275bkw.95.1341747584675; Sun, 08 Jul 2012 04:39:44 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.49.87 with HTTP; Sun, 8 Jul 2012 04:39:14 -0700 (PDT) In-Reply-To: <8E9DECBB-3D1E-4129-A958-9DB0DF69ECC3@kientzle.com> References: <86bojxow6x.fsf@ds4.des.no> <4FF35864.5030109@FreeBSD.org> <20120704185104.GA42355@DataIX.net> <4FF4B36A.2040608@FreeBSD.org> <20120704180134.7c649e1b@bhuda.mired.org> <4FF4BEED.10103@FreeBSD.org> <20120704225519.GB19945@DataIX.net> <4FF4CAD1.8080804@FreeBSD.org> <20120704234104.GA392@DataIX.net> <8E9DECBB-3D1E-4129-A958-9DB0DF69ECC3@kientzle.com> From: Chris Rees Date: Sun, 8 Jul 2012 12:39:14 +0100 X-Google-Sender-Auth: u8aupiYaKflksJ1sigF2InUbhss Message-ID: To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 11:39:46 -0000 On 5 July 2012 01:30, Tim Kientzle wrote: > On Jul 4, 2012, at 4:41 PM, Jason Hellenthal wrote: >> >> On Wed, Jul 04, 2012 at 03:59:29PM -0700, Doug Barton wrote: >>> On 07/04/2012 15:55, Jason Hellenthal wrote: >>>> Seeing as sudo plays a big part of this >>> >>> No ... not only is sudo not a necessary component, it shouldn't be >>> involved at all. The feature works on debian/ubuntu for regular >>> userspace commands. >>> >> >> What are they using to authenticate for the install ? do you know ? > > Huh? What install? Who's talking about install? > > The version of this I've seen looks like this: > > $ svn co https://some.url/ > svn: Command not found. > To use this command, install one of the following packages: > devel/subversion > devel/subversion-freebsd > devel/subversion16 > > That's all it does: It just prints out a more informative error message. > It does not install anything, it requires no special permissions, > and does not (as far as I can see) introduce any security or > performance problems. > > The implementation is pretty simple: > * A tool for building a database that maps command names > to package names. (This would run against a ports tree or > package repository. Conceptually, it's pretty similar to > how port/package indexes get built today.) > * Some way to distribute that database (Probably as part of ISO > releases, maybe extend 'portsnap' or 'pkg_add' to update it?) > * A program to look up command names in that database > and print out the results. > * A shell hook to run said program whenever a "command not found" > error occurs. > > As a first prototype, the database could just be a text file > and the look up program could be a shell script that uses > grep and sed. Anyone looking to implement something like this could also talk to Sulev-Madis Silber (ketas on EFNet) about his code for making a universal list of files provided by all ports-- he has written a conflicts checker recently and may know some shortcuts. Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 12:58:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A01D1065670; Sun, 8 Jul 2012 12:58:36 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5E35A8FC15; Sun, 8 Jul 2012 12:58:36 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [IPv6:2610:10:20:214::6]) by rush.bluerosetech.com (Postfix) with ESMTPSA id 2288311437; Sun, 8 Jul 2012 05:58:35 -0700 (PDT) Received: from [IPv6:2001:470:8643:970:d8c4:f522:d6a8:ec14] (unknown [IPv6:2001:470:8643:970:d8c4:f522:d6a8:ec14]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id 9E36824D87; Sun, 8 Jul 2012 05:58:33 -0700 (PDT) Message-ID: <4FF983F8.5070006@bluerosetech.com> Date: Sun, 08 Jul 2012 05:58:32 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Doug Barton References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF8D89B.1030308@bluerosetech.com> <4FF95365.7010605@FreeBSD.org> In-Reply-To: <4FF95365.7010605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 12:58:36 -0000 On 2012-07-08 02:31, Doug Barton wrote: > On 07/07/2012 17:47, Darren Pilgrim wrote: >> On 2012-07-07 16:45, Doug Barton wrote: >>> Also re DNSSEC integration in the base, I've stated before that I >>> believe very strongly that any kind of hard-coding of trust anchors as >>> part of the base resolver setup is a bad idea, and should not be done. >>> We need to leverage the ports system for this so that we don't get stuck >>> with a scenario where we have stale stuff in the base that is hard for >>> users to upgrade. >> >> Considering the current root update cert bundle has a 20-year root CA >> and 5-year DNSSEC and email CAs, > > Neither of which has any relevance to the actual root zone ZSK, which > could require an emergency roll tomorrow. Emergency root key change is handled by just running unbound-anchor again and have it download the new ZSK. The only thing it can't do is retrieve the root cert chain--it either uses the compiled-in copy or a PEM file passed with the -c flag. Am I missing something in that process? From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 17:10:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB16E1065674 for ; Sun, 8 Jul 2012 17:10:23 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 910F38FC17 for ; Sun, 8 Jul 2012 17:10:23 +0000 (UTC) Received: by obbun3 with SMTP id un3so23039443obb.13 for ; Sun, 08 Jul 2012 10:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=8PEbW/p36b6kVGBcoADx0aPBFnTkp83vaUchzXQG1fQ=; b=JeJB/TsZ/7n6oWuy5/xAQc4UmpgM/7yzMHjE3iOLE+zmK2nLleeKAIutpD9Nd7H9qn tH1so7CAe9bmlYUKZlE9I3Mc1JnLC/iEbCy8V1idl5Fohr5nFhC956EE0omqS8F6Bi0S WyoH7QaCy0yFdi+cCfgA2Y19hTesa9QBXBsYY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=8PEbW/p36b6kVGBcoADx0aPBFnTkp83vaUchzXQG1fQ=; b=kLoZ6nZ+oDvO7IZRQvYekTzFpWaatgBkO5r9DSnwsorkoIfZMNsbYJTly5xKR4KoKG HksPCm37LzajSISvp3ZvSVxZrpNw49E2Eqh8JbQbH++8+xY0Kpn8l+/RtU1HEVFAbxcL YNTj7uqv0Wb5wcD/mlvpnLfolDWoWSYFetpErPms5F2XmMRXngKYYnNZGMWxwoHAP7KL opbtWl0sDuIm3wWbeIUVHoGnjD0LQsHDBVRaoHV0CF8qqIM+wOp/eydn6cZiDfv2+b2C 8xWB920z6OAALyIH8C4FGEkm7HG9uOQE24efk+EKoHAZVFOEl7SkQ8/RDzSr3IRBA94D d1EQ== Received: by 10.50.135.1 with SMTP id po1mr6471746igb.67.1341767422617; Sun, 08 Jul 2012 10:10:22 -0700 (PDT) Received: from DataIX.net (adsl-99-109-126-183.dsl.klmzmi.sbcglobal.net. [99.109.126.183]) by mx.google.com with ESMTPS id q1sm15858678igj.15.2012.07.08.10.10.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 10:10:21 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q68HAJlX081930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 13:10:19 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q68HAIh7081929; Sun, 8 Jul 2012 13:10:18 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 8 Jul 2012 13:10:18 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20120708171018.GA81070@DataIX.net> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <4FF9512A.8050803@FreeBSD.org> X-Gm-Message-State: ALoCoQmkf3z+HB2HSqAbR4SXYWn6e4oZ4EPuUrkKf/FjSQNMV8F79rfc3x4yUzwAtPF0LJaDWdji Cc: "Bjoern A. Zeeb" , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 17:10:24 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 02:21:46AM -0700, Doug Barton wrote: > On 07/08/2012 01:03, Bjoern A. Zeeb wrote: > >=20 > > On 8. Jul 2012, at 02:44 , Warner Losh wrote: > >=20 > >> > >> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: > >>> <= said: > >>> > >>>> BIND in the base today comes with a full-featured local resolver > >>>> configuration, which I'm confident that Dag-Erling can do for unbound > >>>> (and which I would be glad to assist with if needed). Other than tha= t, > >>>> what integration are you concerned about? > >>> > >>> The utilities (specifically host(1) and dig(1)) are the only > >>> user-visible interfaces I care about. I don't see any need for there > >>> to be an authoritative name server in the base system. So long as the > >>> resolver works properly and does DNSsec validation.... > >> > >> The only reason I want it in the base system is that ports don't cross= build very well, but the base system does. That's a weak +1 for keeping s= omething in the base system, but I'll be the first to admit it is a second = or third tier argument at best. > >=20 > > The real reason you want exactly these tools in base is that otherwise = you > > end up rewriting tiny parts of freebsd-update etc that actually depend = on > > host, etc. to query SRV for SRV records. >=20 > That's an implementation issue, and is easily handled with drill, or the > host-like program we all agree is a really-nice-to-have. >=20 =46rom first impression it seems that drill(1) has a syntax that leaves something to be desired like the eased use of host or dig. Specifically and not trying to make this thread about such but "+trace +short" styles just simply do not exist. I suppose a wrapper could be written to parse thoise syntaxes into there correct meaning dig.sh host.sh but thatd be one hell of a compatability problem rather than just having bind-tools in base. --=20 - (2^(N-1)) --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP+b75AAoJEBSh2Dr1DU7WWd4IAJjXprOy+6oIZtqz//+f0Qz4 hlaMJQ1PlLQmAeUltxTQaK+yoZh7XH+uPFprm+dR3e3HQZe1Aif0n1uqMwJwp+WU XRSzJW1elnSPT9HCLaDW04zyl9E/pA8qpmhEaXhG+qM+mKcvdQnoJriQi23TnsiD yL+rZYGuNhCE9xVgsNvPyEoWaiUu1UknKV2GtA/LVUgmmKYKvdMVF0qiDeksZvF3 r07QIPZEwDSYoyhnUaa0YmcS1joQnKzaXC4dThQn4x+NXJCrJRh5Btrg7N4t8f36 VzSo6kkXVygzzf8ndxEXM2nz4oBdv4lU92caUnszh3a17dlo2Y1lJp0TRuA9elQ= =NBNb -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 14:41:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 607B31065670; Sun, 8 Jul 2012 14:41:27 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id DE2D48FC16; Sun, 8 Jul 2012 14:41:26 +0000 (UTC) Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id q68EfMPP045644; Sun, 8 Jul 2012 16:41:24 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4FF99C12.8070004@obluda.cz> Date: Sun, 08 Jul 2012 16:41:22 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Jul 2012 17:22:49 +0000 Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 14:41:27 -0000 > The ideal, long-term solution is to re-think what "The Base" is, and > give users more flexibility at install time. Flexibility is double-edged sword. Feel free to replace one resolver with another resolver (but don't do it so often, please). Applications can be patched to fit new API, scripts can be modified to use other command-line utilities. It is OK for me, as long as it is rare big bang. But "right to select one from N resolvers at install time" sounds like way to hell for me. FreeBSD is known to be fast and reliable network server. Resolver is critical component. There should be ONE resolver in the base which is guaranteed to work with all other baseline utilities and script. Also, network related ports should compile against selected base resolver. No problem if someone will replace system's resolver with another one from ports, but such administrator is just on it's own. He must be ready to resolve issues related to compatibility and reliability by self. Can we maintain three (or so) resolvers to be perfectly compatible with all utilities and scripts in the base ? I don't think so. I suspect that port maintainers will not maintain their ports compatible with all "recommended" resolvers as well. I'm definitely not interested to make decisions like ... "if I will select resolver A at install time, then utility X will not work correctly with them - it work with resolver B only, unfortunately, port P can't be compiled against resolver B because it's maintainer is using A only" ... in the future. Just my $0.02 Dan P.S. English is not my native language, so look for ideas, not for grammar. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 17:43:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83D4F106566C; Sun, 8 Jul 2012 17:43:16 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC938FC08; Sun, 8 Jul 2012 17:43:15 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q68HhFMS041049; Sun, 8 Jul 2012 13:43:15 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id q68HhFwA041046; Sun, 8 Jul 2012 13:43:15 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20473.50867.199081.295841@hergotha.csail.mit.edu> Date: Sun, 8 Jul 2012 13:43:15 -0400 From: Garrett Wollman To: Doug Barton In-Reply-To: <4FF95365.7010605@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF8D89B.1030308@bluerosetech.com> <4FF95365.7010605@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 08 Jul 2012 13:43:15 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 08 Jul 2012 18:48:57 +0000 Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 17:43:16 -0000 < said: > Neither of which has any relevance to the actual root zone ZSK, which > could require an emergency roll tomorrow. Surely that's why there's a separate KSK. The ZSK can be rolled at any time. -GAWollman From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 20:25:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE808106566C; Sun, 8 Jul 2012 20:25:50 +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 8B0828FC12; Sun, 8 Jul 2012 20:25:50 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 8475714E7BC5; Sun, 8 Jul 2012 22:25:40 +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 GbEBOWeVLFD6; Sun, 8 Jul 2012 22:25:40 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AA6F614E7BC4; Sun, 8 Jul 2012 22:25:38 +0200 (CEST) Message-ID: <4FF9ECB5.5090507@FreeBSD.org> Date: Sun, 08 Jul 2012 22:25:25 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120604 Thunderbird/14.0a2 MIME-Version: 1.0 To: Doug Barton References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> In-Reply-To: <4FF8C3A1.9080805@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , freebsd-security@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 20:25:51 -0000 On 2012.07.08. 1:17, Doug Barton wrote: > Other than authoritative DNS, what features does unbound lack that you want? [Picking up a random mail from the thread.] Other than the functionality, when we replace something, it is also important to do some benchmarks and assure that the performance is not reasonably worse. Some time back I committed the error of not carefully pass this requirement with BSD grep but so far it seems it went fine with the recent BSD sort change. It would be nice to also ensure this with the unbound change if it really happens. Gabor From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 21:39:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 3C2AC1065670 for ; Sun, 8 Jul 2012 21:39:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D2A1714F613; Sun, 8 Jul 2012 21:39:55 +0000 (UTC) Message-ID: <4FF9FE2B.90800@FreeBSD.org> Date: Sun, 08 Jul 2012 14:39:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jason Hellenthal References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> <20120708171018.GA81070@DataIX.net> In-Reply-To: <20120708171018.GA81070@DataIX.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 21:39:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/08/2012 10:10, Jason Hellenthal wrote: > From first impression it seems that drill(1) has a syntax that > leaves something to be desired like the eased use of host or dig. So once again, if you need the exact capabilities of ISC host and dig, install them from the port. - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+f4rAAoJEFzGhvEaGryE7e0IAI9oluMoQ6anREfk6aMSGYG2 F8YrL0I/Tz9zid3AR7FEUexPygD5TUHMXF5Tsp2SanBowBx5pju2hslS7GyBuGTM A4mBmVxL3PtRmY/KW55/cIkyV5LPwDPWnul7E7YugQBNPOmAeGIeHwNeNjOLGdV4 Dy3TWnKM+42k9pENezSfeoD83g2Z9xnmAvE1SLOvnyzxMKbPnMmQZ5eikcb1U0WY sfubflPS2OXFgQb/6Qp3rgEpIvij2vBgSl7OJEwXsN01WqN+a7966tqWE4QwZFyD LE5FTijpyKXRpYeyqq/cpZBBdzPSQSi51YvWokF+X5hA/PlVhU8vqTDR+Rg/cLM= =9zzy -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 21:42:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 69EEB106564A; Sun, 8 Jul 2012 21:42:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 681EA14DE5A; Sun, 8 Jul 2012 21:41:57 +0000 (UTC) Message-ID: <4FF9FEA5.7060201@FreeBSD.org> Date: Sun, 08 Jul 2012 14:41:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Garrett Wollman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF8D89B.1030308@bluerosetech.com> <4FF95365.7010605@FreeBSD.org> <20473.50867.199081.295841@hergotha.csail.mit.edu> In-Reply-To: <20473.50867.199081.295841@hergotha.csail.mit.edu> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 21:42:59 -0000 On 07/08/2012 10:43, Garrett Wollman wrote: > < said: > >> Neither of which has any relevance to the actual root zone ZSK, which >> could require an emergency roll tomorrow. > > Surely that's why there's a separate KSK. The ZSK can be rolled at > any time. The ZSK is rolled on a regular schedule already. But that's irrelevant to any future need to roll the KSK. -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 21:43:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 886C71065702; Sun, 8 Jul 2012 21:43:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id ACCEB15702D; Sun, 8 Jul 2012 21:42:51 +0000 (UTC) Message-ID: <4FF9FEDB.5050602@FreeBSD.org> Date: Sun, 08 Jul 2012 14:42:51 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gabor Kovesdan References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <4FF9ECB5.5090507@FreeBSD.org> In-Reply-To: <4FF9ECB5.5090507@FreeBSD.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , freebsd-security@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 21:43:27 -0000 On 07/08/2012 13:25, Gabor Kovesdan wrote: > On 2012.07.08. 1:17, Doug Barton wrote: >> Other than authoritative DNS, what features does unbound lack that you >> want? > [Picking up a random mail from the thread.] > > Other than the functionality, when we replace something, it is also > important to do some benchmarks and assure that the performance is not > reasonably worse. Agreed, and while I have no concerns in that regard, I leave the actual benchmarking in Dag-Erling's capable hands. :) -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 21:55:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 368A61065672; Sun, 8 Jul 2012 21:55:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DD39714DBCD; Sun, 8 Jul 2012 21:55:35 +0000 (UTC) Message-ID: <4FFA01D7.8090807@FreeBSD.org> Date: Sun, 08 Jul 2012 14:55:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Dan Lukes References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FF99C12.8070004@obluda.cz> In-Reply-To: <4FF99C12.8070004@obluda.cz> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 21:55:36 -0000 On 07/08/2012 07:41, Dan Lukes wrote: >> The ideal, long-term solution is to re-think what "The Base" is, and >> give users more flexibility at install time. > > Flexibility is double-edged sword. > > Feel free to replace one resolver with another resolver (but don't do it > so often, please). Applications can be patched to fit new API, scripts > can be modified to use other command-line utilities. It is OK for me, as > long as it is rare big bang. Sorry, you're not understanding what is being proposed. Specifically you're confusing the system stub resolver (the bit that's compiled into libc, and used by binaries) and the resolving name server (BIND). No one is proposing to replace the stub. > I'm definitely not interested to make decisions like ... > > "if I will select resolver A at install time, then utility X will not > work correctly with them - it work with resolver B only, unfortunately, > port P can't be compiled against resolver B because it's maintainer is > using A only" No one is suggesting anything similar to what you're concerned about. -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 8 22:44:33 2012 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 9B69B106564A; Sun, 8 Jul 2012 22:44:33 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id 23EDC8FC08; Sun, 8 Jul 2012 22:44:32 +0000 (UTC) Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id q68MiUch055967; Mon, 9 Jul 2012 00:44:31 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4FFA0D4E.3050507@obluda.cz> Date: Mon, 09 Jul 2012 00:44:30 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FF99C12.8070004@obluda.cz> <4FFA01D7.8090807@FreeBSD.org> In-Reply-To: <4FFA01D7.8090807@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Jul 2012 23:28:43 +0000 Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Jul 2012 22:44:33 -0000 On 07/08/12 23:55, Doug Barton: > On 07/08/2012 07:41, Dan Lukes wrote: ... > Sorry, you're not understanding what is being proposed. Specifically > you're confusing the system stub resolver (the bit that's compiled into > libc, and used by binaries) and the resolving name server (BIND). No one > is proposing to replace the stub. libc stub resolver is BIND code based, so I assumed that arguments against BIND apply to it as well. I'm happy it's not true. In my humble opinion, no resolving name server need to be part of base at all. We have no DHCP, VPN, RADIUS, WWW, ... server in the base as well. Thank you for clarifying. Dan From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 01:09:07 2012 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 5A8E6106566C for ; Mon, 9 Jul 2012 01:09:07 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEB138FC12 for ; Mon, 9 Jul 2012 01:09:06 +0000 (UTC) Received: by ggnm2 with SMTP id m2so11129950ggn.13 for ; Sun, 08 Jul 2012 18:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=wCrMuRujQKwkMKHh6SLpseEX1j5tjSrC6lQMlyuDP2Y=; b=Yh060jMGxu4zNb5z99lDlMXw+OFE6vzgVzdq+oDPM7A/2Gzjp0PowUb54P/qcqzfk8 KO1WTl3caZEdMoiTYbgWMjyGYK0e76NuiCwOnGsxzduF7Qenx+BcmYVONQGqzhCe+kRv FEESXK+QW/hgtj+h9ibAT6LQZDxFPqTKvr7Jw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=wCrMuRujQKwkMKHh6SLpseEX1j5tjSrC6lQMlyuDP2Y=; b=KBzMN0mfCkZ3UFV19slS5ACZ0p1EV8CEn8Zx90Uztv24l8CsKnAyYNq6/qOHid4XLb sIB4X3R6UxAT7aX0+VW2FbvicZdrfyGvoMKz5kzv2dGyO0hsJxumKBZyCBD+j6zA1VDV 3y+3m8F1xN5alKqIsvIZO9w921NFjpk9YVjMTqkmVLWK7wbncvBM1gRLeYaWHOsJLSdJ lsM4yWVwc9QTLUu3S2GUU6dJPu5nqXg87JvSgevETTY2hTQRIkPl4BKkq9m4Qo8kRjmY OH3rC7oi95N0FgDpxeRg6gLojHRMFnlLHIHNeI2WOc+S5kiQkGXK0DydOibeXQbW5WPY CTXQ== Received: by 10.50.207.36 with SMTP id lt4mr7352804igc.5.1341796140218; Sun, 08 Jul 2012 18:09:00 -0700 (PDT) Received: from DataIX.net ([99.181.149.105]) by mx.google.com with ESMTPS id uy3sm7914185igc.14.2012.07.08.18.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 18:08:59 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6918t8f060574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 21:08:55 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6918rLP060573; Sun, 8 Jul 2012 21:08:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 8 Jul 2012 21:08:53 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20120709010853.GA60386@DataIX.net> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> <20120708171018.GA81070@DataIX.net> <4FF9FE2B.90800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF9FE2B.90800@FreeBSD.org> X-Gm-Message-State: ALoCoQkaWWwELvfREH+VNVfMj0ui7R+4D4XOAqbMke6nZbFCK2w5RBsmdUkzmYB8qSMrD7tBPpHD Cc: "Bjoern A. Zeeb" , Dag-Erling Sm?rgrav , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 01:09:07 -0000 On Sun, Jul 08, 2012 at 02:39:55PM -0700, Doug Barton wrote: > On 07/08/2012 10:10, Jason Hellenthal wrote: > > From first impression it seems that drill(1) has a syntax that > > leaves something to be desired like the eased use of host or dig. > > So once again, if you need the exact capabilities of ISC host and dig, > install them from the port. > Sorry that was not really meant to be negative but more informative lookout for those that are not aware. Whatever ends up in base I am sure I will most likely use WITHOUT_ vars to achieve my own goals as long as that facility is provided. What would be a keen approach for new users is offer in the menu... kinda like sysinstall where you have the option of minimal, src, man ... but also have one for chunks of system utilities such as BIND, unbound, GCC, clang, etc... But thanks to the good work of everyone anyhow it makes no difference as I find the system easily tweakable. -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 01:22:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BB76106564A; Mon, 9 Jul 2012 01:22:19 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE648FC0C; Mon, 9 Jul 2012 01:22:18 +0000 (UTC) Received: by werp13 with SMTP id p13so7396880wer.13 for ; Sun, 08 Jul 2012 18:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pXICLcFOZ+Eei5tfX/FTSS3eI+kM+W0rnm/YTkAhd7w=; b=CvZxxpvVqxo428ODPph5dk07TLbGstkvCS5/tg8Py4L3qAi8PF1Ei/W1MLXWuH04EC 1DBZnaJALRA74W7HRWP+fs2fAT0VO1EUYGGfpkd3mppo0vIiMw9E6+eGA02PrH6J6Jl0 8XHVdJ9ySiJuBX/ZtIGmtXMHLDIyGuQvhrFWM41JA+YWuhHK2i12AmPBKa5R+u4Na7Fe gFDAGwDQSTn6AUtU64/QgQlQD8WgwNf2M3QaEfDW1fTXkQd9FlHoUlRF6VVqnrR3iuNi iEC4kQgaacjBW1AkF3dEe4HxdK7cvTK3sLSKfFaO9lu14lUUShx3oAVKe4oP10624vsZ NCxw== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr25293370wiz.22.1341796937633; Sun, 08 Jul 2012 18:22:17 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 18:22:17 -0700 (PDT) Date: Sun, 8 Jul 2012 21:22:17 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 01:22:19 -0000 Hi folks, Ok, yet another Newbus' limitation. Assuming a device exports more than one interface, and one of its child has need to use more than one interface, each interfaces cannot register, concurrently, its own ivar. While I try to always have a single child per interface/resource, I need to keep some compatibility with the old way of doing thing (POLA wrt. drivers I cannot/will not convert and userland). So, it would have been nice if ivar had been per-interface, not global and unique to one device. Unless I am mistaken, ivar are the only way for a parent can transmit information to a child. I can not simply implement a new METHOD to get that ivar as the device implements multiple time the same function (actually, up to 4 time for one, 3 for the other, with possible crossovers...), each one physically distinct. Each child is being tied to a pair. Thus, I need to pass each child discriminator(s) for each interfaces right after having been *created*, which cannot be done later on. Of course, it is out-of-question to have crossover in the interfaces definitions. The best way I could achieve this currently is to pass the child's device to its parent, and do a lookup based on that pointer to get information I need, but erk.... my 1c, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 01:49:04 2012 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 40F84106564A; Mon, 9 Jul 2012 01:49:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28F598FC12; Mon, 9 Jul 2012 01:49:04 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q691n20m090882; Mon, 9 Jul 2012 01:49:03 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4FFA3890.5060207@freebsd.org> Date: Mon, 09 Jul 2012 09:49:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Chris Rees References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, pho@freebsd.org Subject: Re: port devel/doxygen failing to test on -CURRENT and -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 01:49:04 -0000 On 2012/07/08 18:21, Chris Rees wrote: > Hi all / David, > > doxygen has been failing for a while now on -CURRENT and apparently > -STABLE too. The current fix is disabling one of the tests in the > build, but obviously it points to a problem with our base system.... > > I've trussed [1] the failing code [2], and it looks as though it's > hanging on a _umtx call. I'm gratuitously ignorant of what goes on > there... but the timings of recent commits to umtx.h [3] could > indicate a link (hope it's not bogus...). > > Any pointers on what I should do next? > > Chris > > [1] http://www.bayofrum.net/~crees/scratch/doxygen-truss > _umtx_op(0x8012b0280,0x16,0x0,0x0,0x0,0x1) ERR#22 'Invalid argument' can you execute it in gdb and print its value ? print/x *(int *)0x8012b0280 print/x *(int *)(0x8012b0280+4) > [2] http://www.bayofrum.net/tb/index.php?action=display_markup_log&build=10-local&id=1037 > > [3] http://svnweb.freebsd.org/base/head/sys/sys/umtx.h?view=log > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 02:07:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C70031065672 for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 927C18FC0C for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19700680pbb.13 for ; Sun, 08 Jul 2012 19:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Qvwq/c+hjCJyYlYmS5vgdJVoqX3YK0aM5QlBryKHhCw=; b=jSoKYz9u/W0UXV45FUxDHkKq91MjNb4qxzFGkVj7C6XE9OoP1ZtcqTQ4pe9n73VlNi H+I4PTzHuYZ+419xgOfFLeeGuYvokCdvHhGIaY5hUkM1aJZFyFS2B6q2doUB2ZJkOBMX fq7VNIVOKFCgELyuLZZ7vWZ02Y8m93H/JDwTfGyv5FStu8SqMHv4SvccQZKbHyPHg6Kd 8hYSv7tnv1guP60NX15x6tSvuAN6rnMMkhC1SqgOJ2sIHVuNLZ2niOyukOZsgOfyUECV w21EqQn+NqX/P7nX+AoksV6Ude3EonjLc7jW5U7GhlbnhueZoaaNfo0Pi4vD85p25AY1 67ww== Received: by 10.68.236.129 with SMTP id uu1mr56103384pbc.77.1341799677392; Sun, 08 Jul 2012 19:07:57 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id or5sm7285160pbb.44.2012.07.08.19.07.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 19:07:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 20:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl1fANXmBhFUYoO0MhquE4ZXFNsI7/6kPFMmfa/UgbpVlE+Fe43dopYaMlJ5134hqtdY5JM Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 02:07:57 -0000 On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: > Ok, yet another Newbus' limitation. Assuming a device exports more > than one interface, and one of its child has need to use more than one > interface, each interfaces cannot register, concurrently, its own > ivar. While I try to always have a single child per > interface/resource, I need to keep some compatibility with the old way > of doing thing (POLA wrt. drivers I cannot/will not convert and > userland). So, it would have been nice if ivar had been per-interface, > not global and unique to one device. There's one pointer for the ivars. The bus code gets to determine what = the ivar looks like, because the interface is totally private to the = bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. So I'm not sure I understand what you are saying here. The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: enum pci_device_ivars { PCI_IVAR_SUBVENDOR, PCI_IVAR_SUBDEVICE, PCI_IVAR_VENDOR, .... }; We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't = scale too well. Given that there's only about a dozen or two in the = tree, that's right at the moment, it wouldn't be hard to do something = like: enum ivar_namespace { IVAR_PCI =3D 1, IVAR_PCCARD, IVAR_USB, etc }; #define IVAR_SHIFT 16 and the above could be changed to: enum pci_device_ivars { PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, PCI_IVAR_SUBDEVICE, PCI_IVAR_VENDOR, .... }; and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. > Unless I am mistaken, ivar are the only way for a parent can transmit > information to a child. I can not simply implement a new METHOD to get > that ivar as the device implements multiple time the same function > (actually, up to 4 time for one, 3 for the other, with possible > crossovers...), each one physically distinct. Each child is being tied > to a pair. Thus, I need to pass each child discriminator(s) for each > interfaces right after having been *created*, which cannot be done > later on. Of course, it is out-of-question to have crossover in the > interfaces definitions. ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. > The best way I could achieve this currently is to pass the child's > device to its parent, and do a lookup based on that pointer to get > information I need, but erk.... That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. Warner= From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 03:26:01 2012 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 DB2721065677; Mon, 9 Jul 2012 03:26:01 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4902A8FC0A; Mon, 9 Jul 2012 03:26:01 +0000 (UTC) Received: by werp13 with SMTP id p13so7439734wer.13 for ; Sun, 08 Jul 2012 20:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fJ27icMVKEL0eJOZFIhObd1y0nbMis9Ks6oAQn0CXPU=; b=SKycEEWZ9rbahqOE6ou1VDv92MdwoBPXCIuYki65u3IJaCcmGmmWGqoWwcy13I10PN pUpvCIv0qC49C5ruZP7P82dcczcv6mlMfwUZ9D+RkUadFvhmPLMFHQtnOCf/bQla8aKP grpSKcIp9Wun8Hh3VnxgOPp7nsDgMiCdriXCuN+OycYo8mq9W9I3NPnkS08f5AnWW7Uc Yo2hqmkpCgd9E1RNjFrqPJ5/hKIONIq8POJIv0jSPT1V2agXJl3APbBk4Og06ps5pBIx rm1ynOeA1IXvQ2vTdJQjPvgQqEjjFGGSo4Tr44LBYD1rsUnYy8iKknDDj3Ji68p6m0X3 DH6w== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr25853106wiz.22.1341804360296; Sun, 08 Jul 2012 20:26:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:26:00 -0700 (PDT) In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> Date: Sun, 8 Jul 2012 23:26:00 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 03:26:02 -0000 Hi, On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > > On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >> Ok, yet another Newbus' limitation. Assuming a device exports more >> than one interface, and one of its child has need to use more than one >> interface, each interfaces cannot register, concurrently, its own >> ivar. While I try to always have a single child per >> interface/resource, I need to keep some compatibility with the old way >> of doing thing (POLA wrt. drivers I cannot/will not convert and >> userland). So, it would have been nice if ivar had been per-interface, >> not global and unique to one device. > > There's one pointer for the ivars. The bus code gets to determine what t= he ivar looks like, because the interface is totally private to the bus. S= o long as it returns the right thing for any key that's presented, it doesn= 't matter quite how things are done. > > So I'm not sure I understand what you are saying here. > dev0 implements two interfaces: A and B. dev1, child of dev0, needs to use both interfaces. There is no generic way for dev0 to export independent ivars for both interface. For now, I restricted the function of the second interface not to need ivar, but that's kind of hackish. - Arnaud > The problem, more basically, is that the ivar keys are not unique. Curre= ntly, there's no bits used in the key to define the values to be non-overla= pping. For example: > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't sca= le too well. Given that there's only about a dozen or two in the tree, tha= t's right at the moment, it wouldn't be hard to do something like: > > enum ivar_namespace { > IVAR_PCI =3D 1, > IVAR_PCCARD, > IVAR_USB, > etc > }; > #define IVAR_SHIFT 16 > > and the above could be changed to: > > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > and then we'd have an unambiguous key, and the bus could easily implement= multiple interfaces. > > but then again, most of the existing interfaces in the kernel are mutuall= y exclusive, so you could implement this just for your new interfaces. > >> Unless I am mistaken, ivar are the only way for a parent can transmit >> information to a child. I can not simply implement a new METHOD to get >> that ivar as the device implements multiple time the same function >> (actually, up to 4 time for one, 3 for the other, with possible >> crossovers...), each one physically distinct. Each child is being tied >> to a pair. Thus, I need to pass each child discriminator(s) for each >> interfaces right after having been *created*, which cannot be done >> later on. Of course, it is out-of-question to have crossover in the >> interfaces definitions. > > ivars are but one way to communicate this. However, they are the generic= way to convert a key to a value and store a key on a value. I don't reall= y understand what you are trying to say here, perhaps an example would help= illustrate what you are trying to do, since I don't quite understand the p= roblem here. > >> The best way I could achieve this currently is to pass the child's >> device to its parent, and do a lookup based on that pointer to get >> information I need, but erk.... > > That doesn't make any sense. The child's parent already sets that child'= s ivar when the child is created. The child's parent already gets a pointe= r to the child when asked to do the key to value translation. Again, perha= ps an example would help here. > > Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 03:31:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 021791065674 for ; Mon, 9 Jul 2012 03:31:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF7788FC22 for ; Mon, 9 Jul 2012 03:31:46 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19804941pbb.13 for ; Sun, 08 Jul 2012 20:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=s0Nw9VUfRbX8IqJVyeJxrQ2ZD0MN1pqek1LCN5jPloU=; b=fnS1P2topoX5iGk0eXggXOU8g5Tphm1AZ+ZuXTac83ZiWBxiJfYSeGT9eMvq44pIBx pyc6+I7L+GlD7sJVhKC/kVepcdv+r21B5gX52JqeKVvU8Mejvf/QLg2tX3gtpsOxjRdi FGlo5ufdxgJ0CXwsm+RMNkK8WPE9euPpqsq0aCjOPh7dZ+zLerAsP/6PnTgmrSYbdMv7 GbyZtxUyj1hkaMN6VU7IeLRRSVZwdYiGfVtA1x+1haV+dbfSmXS/JjtX3chPGRn2CZqT GtBpIq90OOCNvAvSPNi8a87s2XwqQptjNItJx8h2g97HkbMOdNhDRyh2pcl0aHcNmotf E4UQ== Received: by 10.68.132.166 with SMTP id ov6mr57538341pbb.24.1341804706256; Sun, 08 Jul 2012 20:31:46 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pc6sm17677069pbc.47.2012.07.08.20.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 20:31:45 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 21:31:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnGaAK16HTABqG1aj7eFSJUFM25GymmRw5i4m5wxkNoCQlA//y+y4cFrFNMshFIVCqFuXzK Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 03:31:47 -0000 On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than = one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old = way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been = per-interface, >>> not global and unique to one device. >>=20 >> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>=20 >> So I'm not sure I understand what you are saying here. >>=20 > dev0 implements two interfaces: A and B. dev1, child of dev0, needs to > use both interfaces. There is no generic way for dev0 to export > independent ivars for both interface. For now, I restricted the > function of the second interface not to need ivar, but that's kind of > hackish. Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. Warner > - Arnaud >=20 >> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>=20 >> enum ivar_namespace { >> IVAR_PCI =3D 1, >> IVAR_PCCARD, >> IVAR_USB, >> etc >> }; >> #define IVAR_SHIFT 16 >>=20 >> and the above could be changed to: >>=20 >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>=20 >> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>=20 >>> Unless I am mistaken, ivar are the only way for a parent can = transmit >>> information to a child. I can not simply implement a new METHOD to = get >>> that ivar as the device implements multiple time the same function >>> (actually, up to 4 time for one, 3 for the other, with possible >>> crossovers...), each one physically distinct. Each child is being = tied >>> to a pair. Thus, I need to pass each child discriminator(s) for each >>> interfaces right after having been *created*, which cannot be done >>> later on. Of course, it is out-of-question to have crossover in the >>> interfaces definitions. >>=20 >> ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. >>=20 >>> The best way I could achieve this currently is to pass the child's >>> device to its parent, and do a lookup based on that pointer to get >>> information I need, but erk.... >>=20 >> That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. >>=20 >> Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 03:46:53 2012 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 73DB5106564A; Mon, 9 Jul 2012 03:46:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8E798FC0A; Mon, 9 Jul 2012 03:46:52 +0000 (UTC) Received: by werp13 with SMTP id p13so7447212wer.13 for ; Sun, 08 Jul 2012 20:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ALLlTh0eWvI4aHxdoIL83Z53L3zNOWvCsKlEW9UR30U=; b=fHSfS0XlH/2vRaCiEWmLtt5yBn/7SV26JYFLU4AAgEPf1gwS0m2ur4hN/pizZB162/ yCvFhK5jp8qdlUBESZj6Ljjs0FeSqkk/oxS8cjJS05pua3NjX8e+OsvyqsUe3RLc1HV8 DJgAZkEAwLdzgBIKEvQNzhyQvFUvqWsZAAWK3CZc/l2DecgI+wJyBzlYbdJCVDWd/J/H t4TIgtAtHAwXy15N577TBa/7wIkQ/v9dtywJ/e6QrsdD0Z6SxEDpmHnSzDEPC7jRCJ9w z3Gyp0zuf3AejNvEC4o2bvfK/HtjS1cAl0RLbDJ+x5XLm0UxIrAMv6ZS3OOEDjVcMcmH oeFQ== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr14189629wes.108.1341805611796; Sun, 08 Jul 2012 20:46:51 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:46:51 -0700 (PDT) In-Reply-To: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> Date: Sun, 8 Jul 2012 23:46:51 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 03:46:53 -0000 On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: > > On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>> than one interface, and one of its child has need to use more than one >>>> interface, each interfaces cannot register, concurrently, its own >>>> ivar. While I try to always have a single child per >>>> interface/resource, I need to keep some compatibility with the old way >>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>> userland). So, it would have been nice if ivar had been per-interface, >>>> not global and unique to one device. >>> >>> There's one pointer for the ivars. The bus code gets to determine what= the ivar looks like, because the interface is totally private to the bus. = So long as it returns the right thing for any key that's presented, it doe= sn't matter quite how things are done. >>> >>> So I'm not sure I understand what you are saying here. >>> >> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >> use both interfaces. There is no generic way for dev0 to export >> independent ivars for both interface. For now, I restricted the >> function of the second interface not to need ivar, but that's kind of >> hackish. > > Only if the IVARs for interface A and interface B have overlapping values= . If the Ivar keys don't overlap, then there's no problems at all. Certai= nly less hackish than not using them at all. Since dev0 knows the layout o= f the ivar that it set on its child, this presents no problems at all. It = would return the values from A from the right part of the ivar, and those f= rom B in the right part. Apart from the coordination of Ivar numbers, as I= outlined in my last post, there's no issue here. > I think we should not be talking about the same API here. I have no idea what you mean by "the key to value translation", nor "Ivar numbers". What I refer to is that device_set_ivars() / device_get_ivars() acts on a single instance variables from `struct device': `ivars'. In that case, I do not really see how to set that specific field to two distinct values for each interfaces. - Arnaud > Warner > >> - Arnaud >> >>> The problem, more basically, is that the ivar keys are not unique. Cur= rently, there's no bits used in the key to define the values to be non-over= lapping. For example: >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> We could easily reserve the upper 16-bits of this field to be that key.= This value could then be used to differentiate them. But this wouldn't s= cale too well. Given that there's only about a dozen or two in the tree, t= hat's right at the moment, it wouldn't be hard to do something like: >>> >>> enum ivar_namespace { >>> IVAR_PCI =3D 1, >>> IVAR_PCCARD, >>> IVAR_USB, >>> etc >>> }; >>> #define IVAR_SHIFT 16 >>> >>> and the above could be changed to: >>> >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> and then we'd have an unambiguous key, and the bus could easily impleme= nt multiple interfaces. >>> >>> but then again, most of the existing interfaces in the kernel are mutua= lly exclusive, so you could implement this just for your new interfaces. >>> >>>> Unless I am mistaken, ivar are the only way for a parent can transmit >>>> information to a child. I can not simply implement a new METHOD to get >>>> that ivar as the device implements multiple time the same function >>>> (actually, up to 4 time for one, 3 for the other, with possible >>>> crossovers...), each one physically distinct. Each child is being tied >>>> to a pair. Thus, I need to pass each child discriminator(s) for each >>>> interfaces right after having been *created*, which cannot be done >>>> later on. Of course, it is out-of-question to have crossover in the >>>> interfaces definitions. >>> >>> ivars are but one way to communicate this. However, they are the gener= ic way to convert a key to a value and store a key on a value. I don't rea= lly understand what you are trying to say here, perhaps an example would he= lp illustrate what you are trying to do, since I don't quite understand the= problem here. >>> >>>> The best way I could achieve this currently is to pass the child's >>>> device to its parent, and do a lookup based on that pointer to get >>>> information I need, but erk.... >>> >>> That doesn't make any sense. The child's parent already sets that chil= d's ivar when the child is created. The child's parent already gets a poin= ter to the child when asked to do the key to value translation. Again, per= haps an example would help here. >>> >>> Warner > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 03:59:13 2012 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 F311F1065670; Mon, 9 Jul 2012 03:59:12 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 616F68FC12; Mon, 9 Jul 2012 03:59:12 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so2289693wib.1 for ; Sun, 08 Jul 2012 20:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vuTa1iouTc9jB8ljAgnrc1sQ5y9CsDgdP2qoGAZPbw4=; b=vYSVByUD6emmo1ZGwNsWVHmynuv08ZoMhTIIrWBpgnXe5MN/VbCc5hXgCTMhfVdfqX pgUrv+lF5UU/pvBeftfsKtFkvx3+jTZHMzvnnnZDb8B77S12FPWZVKgOoOKkwLra160F Dqg1woO2HQiOmc+b8gkLckR2qYveagtcxlpIdNL32DKxrL7jhK2kehxvZAr87+xPa4Nn dCcmr5pzEu1YBANokMCT81+QD3FUF8txTmOdpXVAXtvdu4A7e5RFamlLXdu8cEl9jRG/ QWQskxgwGccVsu4wXHNpNLFlLyMgV85eF5gJmyYfYdXebRsBnxX74xpkHuSyIes/B22W YzXg== MIME-Version: 1.0 Received: by 10.180.14.34 with SMTP id m2mr26009127wic.22.1341806345314; Sun, 08 Jul 2012 20:59:05 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:59:05 -0700 (PDT) In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> Date: Sun, 8 Jul 2012 23:59:05 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 03:59:13 -0000 Hi, On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > > On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >> Ok, yet another Newbus' limitation. Assuming a device exports more >> than one interface, and one of its child has need to use more than one >> interface, each interfaces cannot register, concurrently, its own >> ivar. While I try to always have a single child per >> interface/resource, I need to keep some compatibility with the old way >> of doing thing (POLA wrt. drivers I cannot/will not convert and >> userland). So, it would have been nice if ivar had been per-interface, >> not global and unique to one device. > > There's one pointer for the ivars. The bus code gets to determine what t= he ivar looks like, because the interface is totally private to the bus. S= o long as it returns the right thing for any key that's presented, it doesn= 't matter quite how things are done. > > So I'm not sure I understand what you are saying here. > > The problem, more basically, is that the ivar keys are not unique. Curre= ntly, there's no bits used in the key to define the values to be non-overla= pping. For example: > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't sca= le too well. Given that there's only about a dozen or two in the tree, tha= t's right at the moment, it wouldn't be hard to do something like: > > enum ivar_namespace { > IVAR_PCI =3D 1, > IVAR_PCCARD, > IVAR_USB, > etc > }; > #define IVAR_SHIFT 16 > > and the above could be changed to: > > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > and then we'd have an unambiguous key, and the bus could easily implement= multiple interfaces. > > but then again, most of the existing interfaces in the kernel are mutuall= y exclusive, so you could implement this just for your new interfaces. > ok, I think I got it now. You and I are exactly saying the same thing, just in different terms; there is no way to currently specify multiple independent (/overlapping) ivars in a child... - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 04:37:12 2012 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 881A51065670 for ; Mon, 9 Jul 2012 04:37:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D02B8FC0A for ; Mon, 9 Jul 2012 04:37:12 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19888466pbb.13 for ; Sun, 08 Jul 2012 21:37:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jojy+TpzE3UZwtEJ/jX0QxlF/++XKd4pwlt2h/66jqk=; b=BN3mXZw1KT3W7f1uZkHDCZZCq1Qjl1K5VtPX65FMzT2Fsevevd1gBkgjoP1RDJpBcT Fku/f1H1TdpYU7JHLmrNO5REzJI9Jw0WP/4sNaT4OyCCUq3ECuuQHSAXI7j/sgVYTgEt E1AihStmbu+/pnif8g5GE1PRHgdHjwk+oJ/0LuX7xFByv0BKRI+wgHnSp8UaQOapqPV/ B7/8oXb7MQGx8HVOHpl9JebnOSwJexrpnS31w6wLMYnE9FozR4ZrSRz5JT/BBKiL/DSA tmcu9fElaxjm/kLJ9U1Ns3F4YzrN7Ggx4irwg+mgjvWxSmN2WFjqxH8WDBuzjAoOCq2N hbbA== Received: by 10.68.232.197 with SMTP id tq5mr56266726pbc.53.1341808631827; Sun, 08 Jul 2012 21:37:11 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nj4sm12980987pbc.5.2012.07.08.21.37.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:37:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 22:37:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlb6C92yxvcUlvqY1qXoYX1fQlTgyqnQishOfxeFY0PxUkUGNm9czYpoceCAF/kNaaBXgtB Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 04:37:12 -0000 On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: > On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>=20 >>> Hi, >>>=20 >>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>=20 >>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>> than one interface, and one of its child has need to use more than = one >>>>> interface, each interfaces cannot register, concurrently, its own >>>>> ivar. While I try to always have a single child per >>>>> interface/resource, I need to keep some compatibility with the old = way >>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>> userland). So, it would have been nice if ivar had been = per-interface, >>>>> not global and unique to one device. >>>>=20 >>>> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>>>=20 >>>> So I'm not sure I understand what you are saying here. >>>>=20 >>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs = to >>> use both interfaces. There is no generic way for dev0 to export >>> independent ivars for both interface. For now, I restricted the >>> function of the second interface not to need ivar, but that's kind = of >>> hackish. >>=20 >> Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. >>=20 > I think we should not be talking about the same API here. I have no > idea what you mean by "the key to value translation", nor "Ivar > numbers". What I refer to is that device_set_ivars() / > device_get_ivars() acts on a single instance variables from `struct > device': `ivars'. In that case, I do not really see how to set that > specific field to two distinct values for each interfaces. We are talking about the ivar interface. You are just misunderstanding = how it is used. Let us say that dev0 wants to implement interface A and B. The = interface it implements is the device_read _ivar method. That method = looks like: int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t = *result) { struct pci_ivar *iv =3D device_get_ivar(child); switch (which) { case PCI_IVAR_SUBVENDOR: *result =3D iv->subvendor; break; ... default: return EINVAL; } return 0; } So, if you wanted to implement interface A and interface B, you would = have to support reading and writing A_IVAR_* and B_IVAR_*. The above = routine would look like: struct mydev_ivar { int a_1; int a_2; int b_1; int b_2; }; int mydev_read_ivar(device_t dev, device child, int which, uintpr_t = *result) { struct mydev_ivar *iv =3D device_get_ivar(child); switch (which) { case A_IVAR_1: *result =3D iv->a_1; break; case A_IVAR_2: *result =3D iv->a_2; break; case B_IVAR_1: *result =3D iv->b_1; break; case B_IVAR_2: *result =3D iv->b_2; break; default: return EINVAL; } return 0; } and similar for the write routine. Now, there are some busses that = provide convenience structures and functions for dealing with the ivars. = In that case, you'd be able to use the wrapper structures and routines = like so: struct mdev_ivar { struct a_ivar a; struct b_ivar b; }; int mydev_read_ivar(device_t dev, device child, int which, uintpr_t = *result) { struct mydev_ivar *iv =3D device_get_ivar(child); switch (which) { case A_IVAR_1: case A_IVAR_2: return a_helper_read_ivar(&iv->a, which, result); case B_IVAR_1: case B_IVAR_2: return b_helper_read_ivar(&iv->b, which, result); default: return EINVAL; } return 0; } Both of these work only if the A_IVAR values are disjoint from the = B_IVAR values. Your mydev device is the one that sets the ivar on dev1, = in your example, so it would know how to malloc and create the = mydev_ivar structure, even if the interfaces it is implementing provide = helper functions, like I've outlined above. Warner > - Arnaud >=20 >> Warner >>=20 >>> - Arnaud >>>=20 >>>> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >>>> enum pci_device_ivars { >>>> PCI_IVAR_SUBVENDOR, >>>> PCI_IVAR_SUBDEVICE, >>>> PCI_IVAR_VENDOR, >>>> .... >>>> }; >>>>=20 >>>> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>>>=20 >>>> enum ivar_namespace { >>>> IVAR_PCI =3D 1, >>>> IVAR_PCCARD, >>>> IVAR_USB, >>>> etc >>>> }; >>>> #define IVAR_SHIFT 16 >>>>=20 >>>> and the above could be changed to: >>>>=20 >>>> enum pci_device_ivars { >>>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >>>> PCI_IVAR_SUBDEVICE, >>>> PCI_IVAR_VENDOR, >>>> .... >>>> }; >>>>=20 >>>> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>>>=20 >>>> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>>>=20 >>>>> Unless I am mistaken, ivar are the only way for a parent can = transmit >>>>> information to a child. I can not simply implement a new METHOD to = get >>>>> that ivar as the device implements multiple time the same function >>>>> (actually, up to 4 time for one, 3 for the other, with possible >>>>> crossovers...), each one physically distinct. Each child is being = tied >>>>> to a pair. Thus, I need to pass each child discriminator(s) for = each >>>>> interfaces right after having been *created*, which cannot be done >>>>> later on. Of course, it is out-of-question to have crossover in = the >>>>> interfaces definitions. >>>>=20 >>>> ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. >>>>=20 >>>>> The best way I could achieve this currently is to pass the child's >>>>> device to its parent, and do a lookup based on that pointer to get >>>>> information I need, but erk.... >>>>=20 >>>> That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. >>>>=20 >>>> Warner >>=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 04:39:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3D8F106564A for ; Mon, 9 Jul 2012 04:39:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECF48FC14 for ; Mon, 9 Jul 2012 04:39:09 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19890943pbb.13 for ; Sun, 08 Jul 2012 21:39:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2PU0KfHfGfWSG2xPJJRgEFUcsAIsKBa/gwQArzMPjPE=; b=c1FGI0Lu6mK3eszbHW3h4TpG5zANkZxVU2kqOgnHFYuArmnqLXroBjixEGfZxTF6ak vchEA07BaiqdtFkP36C0pNqBY+jQft1Vz3pgHrn+AWX/nj+1KpiTVA/FMDJnO5zfYvyo DPlkxWDgVFDe7wBqqi1l6Vg/Im5+tsnZ3+8K+F5wQbboSgeIXmcjUf5heDID/x3SIPkq v1VLsmdd8zYODV6xOq0qWHHqkYOumbva/Qb4I+Lkxaz5mGzF/ZU+D7TCLQ4uBcNwtfmZ PnRyZuImKcxVgsvLK5UUUHYyunPwIjpzIGpFv3uD0jBUIdsFWZdlHVQ4PI6+iL2WzznA qM5g== Received: by 10.66.74.97 with SMTP id s1mr62555882pav.11.1341808749146; Sun, 08 Jul 2012 21:39:09 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id jp10sm26913168pbb.16.2012.07.08.21.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:39:08 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 22:39:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnQ+xVzWFgwI1Ts02NyPFgDrpqz0lavNM993yppmzHOTo/aoPwZ756NqIiiDTHlgceByUdi Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 04:39:09 -0000 On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than = one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old = way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been = per-interface, >>> not global and unique to one device. >>=20 >> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>=20 >> So I'm not sure I understand what you are saying here. >>=20 >> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>=20 >> enum ivar_namespace { >> IVAR_PCI =3D 1, >> IVAR_PCCARD, >> IVAR_USB, >> etc >> }; >> #define IVAR_SHIFT 16 >>=20 >> and the above could be changed to: >>=20 >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>=20 >> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>=20 > ok, I think I got it now. You and I are exactly saying the same thing, > just in different terms; there is no way to currently specify multiple > independent (/overlapping) ivars in a child... There's no way to support overlapping IVAR keys, yes. However, if you = are designing the ivars for multiple inheritance, then you'll need to = make them non-overlapping. Thankfully, this is trivial to do. Warner Warner= From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 05:18:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3591A106564A; Mon, 9 Jul 2012 05:18:00 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 90E658FC08; Mon, 9 Jul 2012 05:17:59 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2069602wib.13 for ; Sun, 08 Jul 2012 22:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/Fgc51bagA4OIHukFXEdz+x40tkf/RC5w8RhoUsBCTE=; b=cTV3smi106Ka69hyE9BE8LW+dp+EQ8QU47IcgrAP+ptXMBwonco1PVD3N9hOhmNNej 2uJUVs6JEeTiXP8s9XFHEwZXuWSVvN31s52J8xIhPqFpKf/vu+dGB3ti3Wz6uq4/eKvC Vx9trLXww4UxoshkOoabz/NGe+5hAOpgR50QY2hGsbnOjY5LVxn+GoKY5W4EU/gmtsyV utNIuWrLdLD7Cyvr/eLFMv4df8K3o78jJ7EaM0pdfh4QnhviitKU0esWYeeG92j0IZQr GMgmHoZN6uau4HV+bDxRLRFPTd3rwl0zcpwJByF0KvF04sf312kCImFMDVrqbfDvQvtI HUBQ== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr26490361wib.3.1341811072926; Sun, 08 Jul 2012 22:17:52 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 22:17:52 -0700 (PDT) In-Reply-To: <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Mon, 9 Jul 2012 01:17:52 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 05:18:00 -0000 Hi, On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: > > On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: > >> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>> >>>> Hi, >>>> >>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>> >>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>>> than one interface, and one of its child has need to use more than o= ne >>>>>> interface, each interfaces cannot register, concurrently, its own >>>>>> ivar. While I try to always have a single child per >>>>>> interface/resource, I need to keep some compatibility with the old w= ay >>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>> userland). So, it would have been nice if ivar had been per-interfac= e, >>>>>> not global and unique to one device. >>>>> >>>>> There's one pointer for the ivars. The bus code gets to determine wh= at the ivar looks like, because the interface is totally private to the bus= . So long as it returns the right thing for any key that's presented, it d= oesn't matter quite how things are done. >>>>> >>>>> So I'm not sure I understand what you are saying here. >>>>> >>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >>>> use both interfaces. There is no generic way for dev0 to export >>>> independent ivars for both interface. For now, I restricted the >>>> function of the second interface not to need ivar, but that's kind of >>>> hackish. >>> >>> Only if the IVARs for interface A and interface B have overlapping valu= es. If the Ivar keys don't overlap, then there's no problems at all. Cert= ainly less hackish than not using them at all. Since dev0 knows the layout= of the ivar that it set on its child, this presents no problems at all. I= t would return the values from A from the right part of the ivar, and those= from B in the right part. Apart from the coordination of Ivar numbers, as= I outlined in my last post, there's no issue here. >>> >> I think we should not be talking about the same API here. I have no >> idea what you mean by "the key to value translation", nor "Ivar >> numbers". What I refer to is that device_set_ivars() / >> device_get_ivars() acts on a single instance variables from `struct >> device': `ivars'. In that case, I do not really see how to set that >> specific field to two distinct values for each interfaces. > > We are talking about the ivar interface. You are just misunderstanding h= ow it is used. > yes I indeed did... silly, silly me :-) - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 05:51:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 2FB4B106564A for ; Mon, 9 Jul 2012 05:51:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 756A314F187; Mon, 9 Jul 2012 05:51:49 +0000 (UTC) Message-ID: <4FFA7174.7050604@FreeBSD.org> Date: Sun, 08 Jul 2012 22:51:48 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Avleen Vig References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling?=, "Bjoern A. Zeeb" , =?ISO-8859-1?Q?_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 05:51:50 -0000 On 07/08/2012 22:43, Avleen Vig wrote: > It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 06:26:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id EB0501065673 for ; Mon, 9 Jul 2012 06:26:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 15451151096; Mon, 9 Jul 2012 06:26:08 +0000 (UTC) Message-ID: <4FFA7980.4000707@FreeBSD.org> Date: Sun, 08 Jul 2012 23:26:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Avleen Vig References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling?=, "Bjoern A. Zeeb" , =?ISO-8859-1?Q?_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 06:26:10 -0000 On 07/08/2012 23:16, Avleen Vig wrote: > On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote: >> On 07/08/2012 22:43, Avleen Vig wrote: >>> It would be silly not to keep bind-tools in base. >> >> Sounds easy, but not so much in practice. Keeping any of the code >> doesn't solve the problem of the release cycles not syncing up. And for >> the vast majority of users needs the tools we will import will be more >> than adequate. > > The question I keep asking myself is: > "Is this best for the users?" Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. > Linux has `nscd` which is a nice caching resolver, but most > distributions still carry bind-tools in the default install. A) You're wrong about "most." and B) The Linux distros have a default set of packages. There is no "base" like there is in FreeBSD. (Thus, your analogy is flawed.) That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 07:52:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id EE815106566B for ; Mon, 9 Jul 2012 07:52:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 623A61A8EF4; Mon, 9 Jul 2012 07:52:06 +0000 (UTC) Message-ID: <4FFA8DA5.6020300@FreeBSD.org> Date: Mon, 09 Jul 2012 00:52:05 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Avleen Vig References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling?=, "Bjoern A. Zeeb" , =?ISO-8859-1?Q?_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 07:52:07 -0000 On 07/09/2012 00:34, Avleen Vig wrote: > On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton wrote: >> On 07/08/2012 23:16, Avleen Vig wrote: >>> On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote: >>>> On 07/08/2012 22:43, Avleen Vig wrote: >>>>> It would be silly not to keep bind-tools in base. >>>> >>>> Sounds easy, but not so much in practice. Keeping any of the code >>>> doesn't solve the problem of the release cycles not syncing up. And for >>>> the vast majority of users needs the tools we will import will be more >>>> than adequate. >>> >>> The question I keep asking myself is: >>> "Is this best for the users?" >> >> Carrying BIND code in the base that is past EOL is not good for the >> users, period. Everything else we're discussing is an implementation >> detail. > > I think the "everything else we're discussing is an implementation > detail" is the part we'll have a problem with. No doubt there will be some bumps in the road. That's why it is going to be done in -current before 10-RELEASE, so that the bugs can be worked out. > Although Garrett's reply to my email makes sense too. > >> That said, I still believe that our idea of what should, and should not >> be, in the base system is seriously flawed, and needs to be completely >> redone. But that's never going to happen, so I'm trying to work with >> what we've got. > > Agreed. The idea of a "minimally functional system" itself might be > flawed. No, there are 2 questions. First, "What is a minimally functional system?" and second, "How do we provide it?" Answering those questions is beyond the scope of this thread. > Do you consider having `dig` and `host` essential in a > minimally functioning system? I do. > It's pretty f'king hard to resolve problems with installing the > bind-utils port, if you don't know how to test your DNS :-) No one has said that we're going to leave the base without any tools. Please actually read the entire thread before commenting further. > Yes, I'm going to be a stickler and say that having EOL code in base > isn't the end of the world. Yours is a minority opinion. > If there's a security vulnerability, sure, I understand that it might > suck without support from ISC to patch dig/host/nslookup, but when was > the last time that happened? Those binaries are just wrappers to the BIND libs, which are upgraded rather often when security vulnerabilities are found. Up to this point I've tried to respond to your questions in the hopes that answering them will serve to elucidate some of the details behind what's going on here. At this point though I'm starting to repeat myself. So if you have further questions I'd suggest that you read the entire thread so far, and then do some research on your own to try and understand the problem better. After that, if you still disagree, voicing your concerns when Dag-Erling has had a chance to get involved is probably your best bet. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 10:13:38 2012 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 7573B106566C for ; Mon, 9 Jul 2012 10:13:38 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id EEDFF8FC17 for ; Mon, 9 Jul 2012 10:13:37 +0000 (UTC) Received: by eeke49 with SMTP id e49so4435653eek.13 for ; Mon, 09 Jul 2012 03:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=TKs6rQJk5mrIHJ1p6OiJJyZJndSpZD1xB3wYskr9Uso=; b=O603hLg2hrupJzCjhV55xJ9SPz8cQczIYdCPQMZU4h2N/Qex3eQjuGfWc7+9fxBUdL sVc2qwPEDoY/euCwA2F2QPdvyqjBE+sgPCadFjQWjUSMuFPUBu56u+uf9BYiU0dwWjg0 idB1TdB4Z/eykzrExu9molCMrFg0D0l6vTN21EYhUexlDp1l6tiatO7FwkejfTscvEBu d/N2C5u3BKIaZKYjkfC9nFAugiK+qJL1unhT3MaJeme2INndvQTZmTX1SIdkfwF3839D ckY/u1oDABtrOmXwnBMMrJe8gbNxJ3NzGnLr6aPegklINRUk/WGbsjbw0EDa3YWwORAo JYEw== Received: by 10.14.185.137 with SMTP id u9mr9523247eem.219.1341828811170; Mon, 09 Jul 2012 03:13:31 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id s4sm92470534eef.2.2012.07.09.03.13.29 (version=SSLv3 cipher=OTHER); Mon, 09 Jul 2012 03:13:30 -0700 (PDT) Message-ID: <4FFAAEC7.1040407@my.gd> Date: Mon, 09 Jul 2012 12:13:27 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FF99C12.8070004@obluda.cz> <4FFA01D7.8090807@FreeBSD.org> <4FFA0D4E.3050507@obluda.cz> In-Reply-To: <4FFA0D4E.3050507@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmbhBv2hf11B7Lw5A5jhi+BDXmSn48GVGeIIhSp6rSSTjUGRUOUwhm0J+SW6qvmMonIc5sI Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 10:13:38 -0000 On 7/9/12 12:44 AM, Dan Lukes wrote: > On 07/08/12 23:55, Doug Barton: >> On 07/08/2012 07:41, Dan Lukes wrote: > ... >> Sorry, you're not understanding what is being proposed. Specifically >> you're confusing the system stub resolver (the bit that's compiled into >> libc, and used by binaries) and the resolving name server (BIND). No one >> is proposing to replace the stub. > > > libc stub resolver is BIND code based, so I assumed that arguments > against BIND apply to it as well. > > I'm happy it's not true. > > In my humble opinion, no resolving name server need to be part of base > at all. We have no DHCP, VPN, RADIUS, WWW, ... server in the base as well. > > > Thank you for clarifying. > > Dan > Whereas you don't need a DHCP, VPN, RADIUS or WWW server to do *anything at all* with your newly installed BSD machine, you sort of need a DNS resolver... I for one am not going to use a 3rd party resolver, even if only to download the ports' source code for BIND, so I'm happy it's provided in the base. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 10:21:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6F24106566C; Mon, 9 Jul 2012 10:21:55 +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 8FC628FC0C; Mon, 9 Jul 2012 10:21:55 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 89FDA664F; Mon, 9 Jul 2012 10:21:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3A4248742; Mon, 9 Jul 2012 12:21:54 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Avleen Vig References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> Date: Mon, 09 Jul 2012 12:21:53 +0200 In-Reply-To: (Avleen Vig's message of "Sun, 8 Jul 2012 22:43:20 -0700") Message-ID: <86eholnsji.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Doug Barton , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 10:21:55 -0000 Avleen Vig writes: > It would be silly not to keep bind-tools in base. `host` and `dig` are > very standard tools most people expect to be available in base, just > as they are in the base/core/whatever of other operating systems. We should definitely have an implementation of host(1), but dig(1) is not nearly as widely used, and ldns's drill(1) supports the same command-line syntax for the most common operations. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 10:29:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 785F1106566C; Mon, 9 Jul 2012 10:29:33 +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 2D85C8FC0A; Mon, 9 Jul 2012 10:29:33 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 859206655; Mon, 9 Jul 2012 10:29:32 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 46B268748; Mon, 9 Jul 2012 12:29:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Avleen Vig References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> <20120708171018.GA81070@DataIX.net> <4FF9FE2B.90800@FreeBSD.org> Date: Mon, 09 Jul 2012 12:29:31 +0200 In-Reply-To: (Avleen Vig's message of "Sun, 8 Jul 2012 22:50:08 -0700") Message-ID: <867gudns6s.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , FreeBSD Hackers , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 10:29:33 -0000 Avleen Vig writes: > As bind-tools and BIND (the resolver) as separate, why not just leave > bind-tools in base? They'll work happily with unbound. The bind-tools (host, dig, nslookup) are command-line frontends for the resolver. Perhaps what you are trying to say is that they are separate from the authoritative nameserver (named). Yes, they are, but they have a *lot* of code in common. In fact, *most* of the code in BIND is common code shared between named, dig etc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 10:39:39 2012 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 1DCC9106564A; Mon, 9 Jul 2012 10:39:39 +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 CC62D8FC12; Mon, 9 Jul 2012 10:39:38 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 2AAAE665E; Mon, 9 Jul 2012 10:39:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EA170874B; Mon, 9 Jul 2012 12:39:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor Kovesdan References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <4FF9ECB5.5090507@FreeBSD.org> Date: Mon, 09 Jul 2012 12:39:37 +0200 In-Reply-To: <4FF9ECB5.5090507@FreeBSD.org> (Gabor Kovesdan's message of "Sun, 08 Jul 2012 22:25:25 +0200") Message-ID: <863951nrpy.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Doug Barton , FreeBSD Hackers , freebsd-security@freebsd.org Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 10:39:39 -0000 Gabor Kovesdan writes: > Other than the functionality, when we replace something, it is also > important to do some benchmarks and assure that the performance is not > reasonably worse. Some time back I committed the error of not > carefully pass this requirement with BSD grep but so far it seems it > went fine with the recent BSD sort change. It would be nice to also > ensure this with the unbound change if it really happens. What sort of benchmarks do you envision? Unlike named, unbound is intended to serve only one client (localhost) or a small number of clients (a SOHO). With that kind of load, one could be ten times slower than the other and you wouldn't notice, because other factors, like network latency, completely dwarf the time the nameserver itself spends servicing a request. (note that I fully expect unbound to hold its own on corporate networks with thousands of clients, but I doubt my boss is going to let me run performance comparisons on the university's network) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 10:55:28 2012 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 475231065672 for ; Mon, 9 Jul 2012 10:55:28 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DF8A18FC20 for ; Mon, 9 Jul 2012 10:55:27 +0000 (UTC) Received: by yhfs35 with SMTP id s35so5186985yhf.13 for ; Mon, 09 Jul 2012 03:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=o4aXdEqovaTe3cUANHwX/PsS8Yl0v619U+HL8YCvmIE=; b=HUg/XYuB1iKFGygeyTc6Fb/WN+Da+YMS3hHw4al4YNyftfQ6gzj9DiOUxofVtzK2wx 84nl0t1En3n7YLh1mlmgY6MsDkg9hTyUuj1aeG5pb60FxT4XWTSPh5aENaZSqT12ciD3 IBO7+IW22l7H/dsvZH90llgm/ZX8v5S7orCII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=o4aXdEqovaTe3cUANHwX/PsS8Yl0v619U+HL8YCvmIE=; b=Jo7XSLRf5bCOvG9L3xVCOxyPrHWF1VQCY04dowPQnhGvGAduxB9Pynm0gfhwc3NapL JF8jThkVW1Ap64+OsuUKNGBrLaMxsnSw2vrTzTWxKpIczNxqyuedGwbq98ROl2yy/Yzq 9x9mvY4B0KlbCkiMJ6oMwuqxJ7qiyTIGNfD6JKuRmObnsw656V6bMomIpGvV9xB1SHnl 3/xqYiLznEUfFLxAS+HOcxOIlLw8xxf6xAdy+9VNjdyWcECVlqULEnbhAixhIGqIGClf IBAkZB8vS0UQztCPjs47JTH4t803BYkbJeB+ZBo6EOjtWSNig/qksz4ATlEJYWq0+y5J 1n5w== MIME-Version: 1.0 Received: by 10.42.148.196 with SMTP id s4mr20011186icv.19.1341831327299; Mon, 09 Jul 2012 03:55:27 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.64.18.206 with HTTP; Mon, 9 Jul 2012 03:55:27 -0700 (PDT) X-Originating-IP: [172.28.125.126] In-Reply-To: <4FF952FB.10200@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> Date: Mon, 9 Jul 2012 11:55:27 +0100 X-Google-Sender-Auth: g0yRvJ7WuSAqHvJ0qMzSARQLKaM Message-ID: From: "Simon L. B. Nielsen" To: Doug Barton , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmkNS2Tx2gp2Im6x9TXlU19jhiVRsfjWn2euvVqStEC4+oC5FyQF68NLShnqMKMnC4UrWrs Cc: freebsd-security@freebsd.org, Adam Vande More , FreeBSD Hackers , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 10:55:28 -0000 On Sun, Jul 8, 2012 at 10:29 AM, Doug Barton wrote: > Unbound has different policies and release schedules that are more in > line with ours. So in the short term (as in, the next few years) we're > better off with unbound in the base. Where is there information about this / what is their support? When I looked at their website I found nothing about security support, branch handling etc. and nobody has replied to that part in these threads (unless I missed it - I just rescanned thread without seeing a reply). -- Simon L. B. Nielsen From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 05:43:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EAB41065670; Mon, 9 Jul 2012 05:43:22 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A18C38FC20; Mon, 9 Jul 2012 05:43:21 +0000 (UTC) Received: by lbon10 with SMTP id n10so19359596lbo.13 for ; Sun, 08 Jul 2012 22:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6oWPDvD1OlXLVD8rS1XUdnzd/fZQQJSU1QSVb0K1ie0=; b=jH/x1BFPKRtBAcbiz4XnvIHuHbKzHUF+hd3Tex8BA0m3D/00honuJ0Cr8kQWFyFtOw 8513gczLCpfB3absbgEX65sntokHYn6ewmF0PaliRyZZL7F/i7fSHYy8l92nMg+L94+Y kmb4fSfueCHn1FFZiupX/WsdMllRF3nOx/PBUxnsNX/j/biMMfAiTttN9Tne/KzAVEWi zxqRYZtlB3nRPIIMMwweoPLc0LHEZOE+F9AJaWWAeKk0puMg25LdezQAZbkuvUWvTaYx D8niMtz7HboAAol+TsUyO38eoKypIPOQHMA4HMM/Em3LqTNcbF9gAqCPjkjWgOI63/R7 5tQw== MIME-Version: 1.0 Received: by 10.112.43.67 with SMTP id u3mr17516612lbl.16.1341812600386; Sun, 08 Jul 2012 22:43:20 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Sun, 8 Jul 2012 22:43:20 -0700 (PDT) In-Reply-To: <4FF8C890.9030408@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> Date: Sun, 8 Jul 2012 22:43:20 -0700 Message-ID: From: Avleen Vig To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 09 Jul 2012 11:38:33 +0000 Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 05:43:22 -0000 On Sat, Jul 7, 2012 at 4:38 PM, Doug Barton wrote: > > On 07/07/2012 16:33, Garrett Wollman wrote: > > < said: > > > >> BIND in the base today comes with a full-featured local resolver > >> configuration, which I'm confident that Dag-Erling can do for unbound > >> (and which I would be glad to assist with if needed). Other than that, > >> what integration are you concerned about? > > > > The utilities (specifically host(1) and dig(1)) are the only > > user-visible interfaces I care about. I don't see any need for there > > to be an authoritative name server in the base system. So long as the > > resolver works properly and does DNSsec validation.... > > I addressed the utils in a previous message, but once more ... > > ldns (a dependency of unbound) comes with drill, which is a dig-alike > tool. I'd like to see us produce a host-alike based on ldns as well, > which should be a pretty simple "junior hacker task" for a motivated group. > > If those don't do it for you, ports/dns/bind-tools already exists. It would be silly not to keep bind-tools in base. `host` and `dig` are very standard tools most people expect to be available in base, just as they are in the base/core/whatever of other operating systems. I'm all for writing other tools based on ldns, but now you're talking about doing things that create extra work for me, the end user, for something that gives me very little gain (if any). I either have to install bind-tools or rewrite scripts. And what do I get? Nothing I really care about. Think about the benefit to the end user before making such decisions. Especially if you're talking about taking away something that is already there and taken for granted. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 05:50:10 2012 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 02AFB106564A; Mon, 9 Jul 2012 05:50:10 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43B3D8FC15; Mon, 9 Jul 2012 05:50:09 +0000 (UTC) Received: by lbon10 with SMTP id n10so19366094lbo.13 for ; Sun, 08 Jul 2012 22:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jF8/KmRVf6WDmXa/hxx67V5qoJFCLQIsmPp53TXFTZA=; b=rsi69i+Tmmy9b3HvMM7f3f/gM2WlpxbvsqK4COKRyq6oTKgm61uOKCNdRvvlWKrCgq l9xOwS7TiAcytNzB3fpyvNGUpIzKZTbmVghjmvJ0lbHBR6WbR0DxgylNoegG5Bp5rUbs cBtuLzXzCPyDthD3LUww8s42vrmcIdUV/+jtdrS97L9KpRx6Td6WUMC71iu4ZY76O+9p A2qHujSyqW0pzf4KyY8AVSR2QemBF9A9+sYl3g9pIGD1h0MjkvCMbrmcc+ym9Z1xbPDl DDymI8dfGcfS3JnD/tC6347rHBtPPVtq48jBDBGVZwuBWa+oy8rN8rEQHP7B7iex6qUv 5N1A== MIME-Version: 1.0 Received: by 10.112.45.168 with SMTP id o8mr17495003lbm.88.1341813008152; Sun, 08 Jul 2012 22:50:08 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Sun, 8 Jul 2012 22:50:08 -0700 (PDT) In-Reply-To: <4FF9FE2B.90800@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> <20120708171018.GA81070@DataIX.net> <4FF9FE2B.90800@FreeBSD.org> Date: Sun, 8 Jul 2012 22:50:08 -0700 Message-ID: From: Avleen Vig To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 09 Jul 2012 11:38:41 +0000 Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , FreeBSD Hackers , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 05:50:10 -0000 On Sun, Jul 8, 2012 at 2:39 PM, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/08/2012 10:10, Jason Hellenthal wrote: >> From first impression it seems that drill(1) has a syntax that >> leaves something to be desired like the eased use of host or dig. > > So once again, if you need the exact capabilities of ISC host and dig, > install them from the port. As bind-tools and BIND (the resolver) as separate, why not just leave bind-tools in base? They'll work happily with unbound. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 06:16:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 047EE106566B; Mon, 9 Jul 2012 06:16:06 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43E7C8FC08; Mon, 9 Jul 2012 06:16:05 +0000 (UTC) Received: by lbon10 with SMTP id n10so19393193lbo.13 for ; Sun, 08 Jul 2012 23:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rbPWfH79jpvMn/X91GQdMolE2GN/10nec8RLCcoEfhI=; b=oE1jjjivmDqQMfMUjMhe5Fwta/9zMdhzDA0CIaMsRXntZQEZzKRWKrQdVfxx1D2kfy M16ZwtU9yzmVARGLVyURPepzeLxNcE7C9Mt+8YJNJ6hKzdkU6cAF37El6KaJV4F+7oOG sbwqRZk68ZgT+a57hEC/UmQWMHZisvPjgstdCFV3C/PhfXF9t+qjik/ai+puvZoMSUaL UFax0hR8c6S0DwBmwK9IRHDpInpylCekjMfDHHrINkE9EqHcLEq+8/nbtscoUoBX3uBh wTIYRiU0abKNeNDG2nFRL3kQESo+Mg3Eeea4qTmbGDH3Cwjkt/DQRPJ/xAf0WlBJADhw Oo+w== MIME-Version: 1.0 Received: by 10.152.48.37 with SMTP id i5mr38927371lan.36.1341814564128; Sun, 08 Jul 2012 23:16:04 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Sun, 8 Jul 2012 23:16:04 -0700 (PDT) In-Reply-To: <4FFA7174.7050604@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> Date: Sun, 8 Jul 2012 23:16:04 -0700 Message-ID: From: Avleen Vig To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 09 Jul 2012 11:38:50 +0000 Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 06:16:06 -0000 On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote: > On 07/08/2012 22:43, Avleen Vig wrote: >> It would be silly not to keep bind-tools in base. > > Sounds easy, but not so much in practice. Keeping any of the code > doesn't solve the problem of the release cycles not syncing up. And for > the vast majority of users needs the tools we will import will be more > than adequate. The question I keep asking myself is: "Is this best for the users?" I can't convince myself that it is, at the moment. While I completely agree with you reasons, and I do think that in an ideal way they'd be good, I'm just not sure they are the best thing to do for users. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. Enough people expect the tools to be there, that getting rid of them for almost any reason seems like a bad idea for low benefit. I could care less about the resolver daemon itself, I agree with what you're saying and I don't think most end users will care about that. But getting rid of dig and host in base would be bad. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 06:28:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F17106566C; Mon, 9 Jul 2012 06:28:54 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id C690F8FC15; Mon, 9 Jul 2012 06:28:53 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q696Sq9C047061; Mon, 9 Jul 2012 02:28:52 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id q696SqLQ047058; Mon, 9 Jul 2012 02:28:52 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20474.31268.853744.138344@hergotha.csail.mit.edu> Date: Mon, 9 Jul 2012 02:28:52 -0400 From: Garrett Wollman To: Avleen Vig In-Reply-To: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 09 Jul 2012 02:28:53 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Mon, 09 Jul 2012 11:39:09 +0000 Cc: FreeBSD Hackers , Doug Barton Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 06:28:54 -0000 < said: > I could care less about the resolver daemon itself, I agree with what > you're saying and I don't think most end users will care about that. > But getting rid of dig and host in base would be bad. I don't think it's as bad as you suggest, although I do think they we would likely get a few black eyes from just the same. After all, as Doug says, people can just install the bind-tools package. So long as there is *a* tool in the base, even if it's not the two we all are used to, that's sufficient for the purpose of doing enough troubleshooting to get package installs working. I think the embedded people have a better argument, but that's probably still not strong enough versus the benefits of making this change. (The black eyes will come from reviewers saying "WTF, FreeBSD! How can you not have host and dig?!" without bothering to read the release notes or investigate ports that they might want to have installed. The fact that this same crowd always installs sudo from ports will not prevent them from being astonished. I think there's a good case to be made for having a set of packages that are installed by default by the installer unless you disable it -- in my lab, we'll be wanting to install puppet -- and bind-tools is probably one of them.) -GAWollman From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 07:34:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39C5C106570D; Mon, 9 Jul 2012 07:34:37 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9668FC1D; Mon, 9 Jul 2012 07:34:36 +0000 (UTC) Received: by lbon10 with SMTP id n10so19486400lbo.13 for ; Mon, 09 Jul 2012 00:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6blQTjG/7PxcQxqmsmUNpW9fdGsSPfAVH9oZ94ecsNw=; b=vJZz0cQG4wWuluAU4G0W5MYS3QJJHUvZixAVb6uXpHGUpLa4MYnSMtmX4f1nhvOPsw 0lsXwl4NyxINIS2naKdA8oTzP6xDwTQhL7n7NFq29FjNp0rToLwsxM4D0o/cAp3ZiYfy AxScj/urHrRupKY20SZwx3HNDPrk/gZ21FeP1pkt2VI51sWb1aRsV7bqN0kFHzCQDAgi Rcl43Ia/QhGmn7M8Npq8nCQutKqIg/2GxCp67m7ZtfIAHRhZhaa3ZPehpDIoE7uLIpZb TqiD2/Tgh+YtnlJuYuo8yaDAfYqapQtLX5dSOvl1x1/5c4kAVxMKCaNnMqS2OEcH0OFW byJg== MIME-Version: 1.0 Received: by 10.112.43.67 with SMTP id u3mr17649818lbl.16.1341819275004; Mon, 09 Jul 2012 00:34:35 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Mon, 9 Jul 2012 00:34:34 -0700 (PDT) In-Reply-To: <4FFA7980.4000707@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> Date: Mon, 9 Jul 2012 00:34:34 -0700 Message-ID: From: Avleen Vig To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 09 Jul 2012 11:39:22 +0000 Cc: "Bjoern A. Zeeb" , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 07:34:37 -0000 On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton wrote: > On 07/08/2012 23:16, Avleen Vig wrote: >> On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote: >>> On 07/08/2012 22:43, Avleen Vig wrote: >>>> It would be silly not to keep bind-tools in base. >>> >>> Sounds easy, but not so much in practice. Keeping any of the code >>> doesn't solve the problem of the release cycles not syncing up. And for >>> the vast majority of users needs the tools we will import will be more >>> than adequate. >> >> The question I keep asking myself is: >> "Is this best for the users?" > > Carrying BIND code in the base that is past EOL is not good for the > users, period. Everything else we're discussing is an implementation > detail. I think the "everything else we're discussing is an implementation detail" is the part we'll have a problem with. Although Garrett's reply to my email makes sense too. >> Linux has `nscd` which is a nice caching resolver, but most >> distributions still carry bind-tools in the default install. > > A) You're wrong about "most." and B) The Linux distros have a default > set of packages. There is no "base" like there is in FreeBSD. (Thus, > your analogy is flawed.) That's not *really* true, there is a "base" like FreeBSD, but what we consider core userland tools like `ls`, come in a package (coreutils). > That said, I still believe that our idea of what should, and should not > be, in the base system is seriously flawed, and needs to be completely > redone. But that's never going to happen, so I'm trying to work with > what we've got. Agreed. The idea of a "minimally functional system" itself might be flawed. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes, I'm going to be a stickler and say that having EOL code in base isn't the end of the world. It's not ideal, but really.. what is it breaking? If there's a security vulnerability, sure, I understand that it might suck without support from ISC to patch dig/host/nslookup, but when was the last time that happened? From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 13:33:12 2012 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 9A7341065675 for ; Mon, 9 Jul 2012 13:33:12 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) by mx1.freebsd.org (Postfix) with ESMTP id B88508FC0C for ; Mon, 9 Jul 2012 13:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Message-Id:Content-Type:MIME-Version:Date:Subject:To:From; bh=DWVXqyflHIF4fhBLSAe14kTcNaTAlLQciadgVNd1IC0=; b=La0BCU4+eciKUrpxfSgC0TYm4ZhM8gqswK40nSCLjYHHO4DgL7dlM4G4yaw71NpD5bj0oKy90EBlyKxb5Oca96q7Ar97mMlaNm8fYIih9vHuHV+nzI5pZSYQIXdsedEE; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:51278) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SoE5N-000AH4-9F for freebsd-hackers@freebsd.org; Mon, 09 Jul 2012 15:33:09 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Mon, 9 Jul 2012 15:33:08 +0200 User-Agent: KMail/1.9.10 References: <4FFA7980.4000707@FreeBSD.org> In-Reply-To: X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: mail.ru.ac.za (2001:4200:1010:0:250:56ff:fe8d:5) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 13:33:12 -0000 On Monday 09 July 2012 09:34:34 Avleen Vig wrote: > The issue is also one of barrier-to-entry. By removing `dig` and > `host`, I think we're making things unnecessarily more difficult for > people who don't *know* FreeBSD. `dig` and `host` a universally > standard tools for doing DNS lookups. Taking them away in base to > replace them with something else just seems like something that won't > really *help* users. Yes. So we should change the base system so that by default it does a database lookup whenever you type an unrecognised command - to lower the barrier to entry. We should also change the base system to remove the most commonly used tools for doing DNS lookups, to.... what was the reason again? I suppose at least those arguing for both these changes can argue that one mitigates the non-POLA effect of the other.... Jonathan From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 14:08:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DB85106566B; Mon, 9 Jul 2012 14:08:08 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 37A458FC1A; Mon, 9 Jul 2012 14:08:08 +0000 (UTC) Received: from [172.16.0.142] (94-30-105-106.xdsl.murphx.net [94.30.105.106]) by relay0.exonetric.net (Postfix) with ESMTP id 6C0FA57012; Mon, 9 Jul 2012 14:46:03 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Blackman In-Reply-To: Date: Mon, 9 Jul 2012 14:45:14 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> To: Avleen Vig X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" , FreeBSD Hackers , Doug Barton , Garrett Wollman , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 14:08:08 -0000 On 9 Jul 2012, at 08:34, Avleen Vig wrote: > > Agreed. The idea of a "minimally functional system" itself might be > flawed. Do you consider having `dig` and `host` essential in a > minimally functioning system? I do. > It's pretty f'king hard to resolve problems with installing the > bind-utils port, if you don't know how to test your DNS :-) > > The issue is also one of barrier-to-entry. By removing `dig` and > `host`, I think we're making things unnecessarily more difficult for > people who don't *know* FreeBSD. `dig` and `host` a universally > standard tools for doing DNS lookups. Taking them away in base to > replace them with something else just seems like something that won't > really *help* users. Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. - Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 15:38:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4EA7106566B; Mon, 9 Jul 2012 15:38:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 607588FC08; Mon, 9 Jul 2012 15:38:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B4049B972; Mon, 9 Jul 2012 11:38:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:19:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1341601751.70246.7.camel@revolution.hippie.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091119.42549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:17 -0400 (EDT) Cc: Ian Lepore , Arnaud Lacombe , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 15:38:19 -0000 On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > wrote: > > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > >> > That's neither correct nor robust in a couple of way: > >> > 1) you have no guarantee a device unit will always give you the same resource. > >> this raises the following question: how can a device, today, figure > >> out which parent in a given devclass would give it access to resources > >> it needs. > >> > >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > >> attachment is conditional to some BIOS setting. How can you tell > >> gpioled(4) to attach on the chipset provided GPIO without hardcoding > >> unit number either way ? > >> > >> AFAIK, you can not. > >> > >> Even hints provided layout description is defeated. Each device in a > >> given devclass need to have a set of unique attribute to allow a child > >> to distinguish it from other potential parent in the same devclass... > >> > >> - Arnaud > > > > Talking about a child being unable to choose the correct parent seems to > > indicate that this whole problem is turned upside-down somehow; children > > don't choose their parents. > > > actually, I think I was wrong, I thought device were attached to a > devclass, but they are truly attached to a given device. My mistake. > > > Just blue-sky dreaming here on the fly... what we really have is a > > resource-management problem. A device comes along that needs a GPIO > > resource, how does it find and use that resource? > > > > Well, we have a resource manager, could that help somehow? Could a > > driver that provides access to GPIO somehow register its availability so > > that another driver can find and access it? The "resource" may be a > > callable interface, it doesn't really matter, I'm just wondering if the > > current rman stuff could be leveraged to help make the connection > > between unrelated devices. I think that implies that there would have > > to be something near the root of the hiearchy willing to be the > > owner/manager of dynamic resources. > > > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. > The more I think about it, the more FTD is the answer. The open > question now being "how to map a flexible device structure (FTD) to a > less flexible structure (Newbus)" :/ Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 15:38:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A96CF106564A; Mon, 9 Jul 2012 15:38:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D83E8FC17; Mon, 9 Jul 2012 15:38:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E2A7BB9B9; Mon, 9 Jul 2012 11:38:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:27:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> In-Reply-To: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091127.30289.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:22 -0400 (EDT) Cc: FreeBSD Hackers , Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 15:38:22 -0000 On Monday, July 09, 2012 12:39:03 am Warner Losh wrote: > > On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote: > > > Hi, > > > > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > >> > >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: > >>> Ok, yet another Newbus' limitation. Assuming a device exports more > >>> than one interface, and one of its child has need to use more than one > >>> interface, each interfaces cannot register, concurrently, its own > >>> ivar. While I try to always have a single child per > >>> interface/resource, I need to keep some compatibility with the old way > >>> of doing thing (POLA wrt. drivers I cannot/will not convert and > >>> userland). So, it would have been nice if ivar had been per-interface, > >>> not global and unique to one device. > >> > >> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done. > >> > >> So I'm not sure I understand what you are saying here. > >> > >> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non- overlapping. For example: > >> enum pci_device_ivars { > >> PCI_IVAR_SUBVENDOR, > >> PCI_IVAR_SUBDEVICE, > >> PCI_IVAR_VENDOR, > >> .... > >> }; > >> > >> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like: > >> > >> enum ivar_namespace { > >> IVAR_PCI = 1, > >> IVAR_PCCARD, > >> IVAR_USB, > >> etc > >> }; > >> #define IVAR_SHIFT 16 > >> > >> and the above could be changed to: > >> > >> enum pci_device_ivars { > >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT, > >> PCI_IVAR_SUBDEVICE, > >> PCI_IVAR_VENDOR, > >> .... > >> }; > >> > >> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces. > >> > >> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces. > >> > > ok, I think I got it now. You and I are exactly saying the same thing, > > just in different terms; there is no way to currently specify multiple > > independent (/overlapping) ivars in a child... > > There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do. Also, I think we should do this in general. We already have one example (e.g. ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can provide both ACPI and PCI IVARs to child devices). I think we should assign each bus it's own IVAR range. It would make it easier to determine if a specific IVAR is event supported. Certainly I think ISA and PCI at a minimum should be changed to start at, say, 200 and 300. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 16:42:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43BB71065673 for ; Mon, 9 Jul 2012 16:42:45 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5098FC1A for ; Mon, 9 Jul 2012 16:42:44 +0000 (UTC) Received: by eeke49 with SMTP id e49so4608102eek.13 for ; Mon, 09 Jul 2012 09:42:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=hCJI38Aryzbk08cAAeonl+VJ2S/z/SfxALGczxzTbpY=; b=mSdhaODgNF5nBREGq9+UAT6T98Dwql2FPi1APjBHcDttLgZA6QponUbtt/k+qSdYNf f4wdKBIQzF0aE4NvuWvKof7Lk51ksxknC+ishSFT8n0PNPOa+7/6/8UOLHowylR8ZNUP qfrT/lebwBQ5wm2GUszvwFQ449fvRLJ2Ejqw5nW1K5gCGkB95aWF69ow7oi5puHv6CMZ 9WDrGEDB2WykIKmOUS+g5z5QZ+TuvXf3QNgsqRKWopc7RBQs0h6DxsxzCADqC8jsOQko XeZID/jtEXPHRaoWi87WZ4c8PHxEk3UxMcKmws7ivPKiHkvFqlBJCUQV32L7s4bptlxX lfcA== MIME-Version: 1.0 Received: by 10.14.27.136 with SMTP id e8mr10048059eea.157.1341852163260; Mon, 09 Jul 2012 09:42:43 -0700 (PDT) Received: by 10.14.223.201 with HTTP; Mon, 9 Jul 2012 09:42:43 -0700 (PDT) In-Reply-To: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> Date: Mon, 9 Jul 2012 09:42:43 -0700 Message-ID: From: Jos Backus To: FreeBSD Hackers X-Gm-Message-State: ALoCoQmIj+6bsktrLIrhqRR5LyoQOFo0qTyCjjpGK9RJaNBx3X+sf3gKJzMWt26pf6hbI+RJc+4Z Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 16:42:45 -0000 On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig wrote: > [snip] > The issue is also one of barrier-to-entry. By removing `dig` and > `host`, I think we're making things unnecessarily more difficult for > people who don't *know* FreeBSD. `dig` and `host` a universally > standard tools for doing DNS lookups. Taking them away in base to > replace them with something else just seems like something that won't > really *help* users. > [snip] One reason I'd like to see these "standard tools" be replaced with something better is that their output sucks for use in any kind of automation (unlike e.g. some of the the tools that ship with djbdns). Jos -- Jos Backus jos at catnook.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 17:55:44 2012 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 1DAD81065676 for ; Mon, 9 Jul 2012 17:55:44 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B1E0E8FC25 for ; Mon, 9 Jul 2012 17:55:43 +0000 (UTC) Received: by yenl8 with SMTP id l8so12024044yen.13 for ; Mon, 09 Jul 2012 10:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=ZbfGi38INtoEq+ZibeDAiLUlnRk1P0qhpgrHKoLoEWI=; b=SxVKdwtaAbkeOrNkE0ga1v8Mf4XLrNtZlfuFgoYcWWDdvNXGU4Zc9fPUzlAXgwOEDg a2yO7Bgpzo1BckRwaF+q3oVRxUfYkkNjZ/V17foCpakrsCxXekIgdJRQ0vdrLa/O6ZCz N7kjTjyE0UBYIflXitIYc3bkxQ8Q58fNWX1IY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=ZbfGi38INtoEq+ZibeDAiLUlnRk1P0qhpgrHKoLoEWI=; b=IpMOZ3Kd+yCzRGdCYknAIcXRVOsE2RmwuQzFcu5hNix3jPc9Y2mPVTVUUdTV4R92A7 IwszZSMapVoQUiwEwax7ASlDlaobZ8SxpnziUPNKJ4LzehynUq6hthb2KfHBAb5qbH0M Fdnz6zpxoL/qgQVAmHCevIzx+dC8t4InBZM2DGpRaZnBMfNYUtmC7EAi2Zc0P2wCW09G HdaKo0BBsA453fQxsROSK9deePNduZaLYAqJicgKe26W4YxO9NdIZ70x7nClwWpDKVTm kwZhBx9/bsfnjXrIvHJyvSu8ttLMAVYlG9s2Xp8Cfva+N4ZBpBVvuFSbpkcloNiTfJEO 9viw== Received: by 10.50.34.200 with SMTP id b8mr9161064igj.50.1341856542723; Mon, 09 Jul 2012 10:55:42 -0700 (PDT) Received: from DataIX.net (adsl-99-112-213-189.dsl.klmzmi.sbcglobal.net. [99.112.213.189]) by mx.google.com with ESMTPS id zu2sm7447775igb.0.2012.07.09.10.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 10:55:42 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q69Htdcp056663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 13:55:39 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q69HtdYE056662; Mon, 9 Jul 2012 13:55:39 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Mon, 9 Jul 2012 13:55:39 -0400 From: Jason Hellenthal To: Jos Backus Message-ID: <20120709175538.GA56437@DataIX.net> References: <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQlBbtxK67nf9o3HIpp5NVT+lSepWKxfedc1CDiFa7zMcao+m93VYlcMhC9uXIszg9zG/Zde Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 17:55:44 -0000 On Mon, Jul 09, 2012 at 09:42:43AM -0700, Jos Backus wrote: > On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig wrote: > > > [snip] > > > The issue is also one of barrier-to-entry. By removing `dig` and > > `host`, I think we're making things unnecessarily more difficult for > > people who don't *know* FreeBSD. `dig` and `host` a universally > > standard tools for doing DNS lookups. Taking them away in base to > > replace them with something else just seems like something that won't > > really *help* users. > > > [snip] > > One reason I'd like to see these "standard tools" be replaced with > something better is that their output sucks for use in any kind of > automation (unlike e.g. some of the the tools that ship with djbdns). > Where there is a will there is a way... usually boils down to the administrators understanding and use of system utilities to get the results they want. -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 19:21:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82E64106575E for ; Mon, 9 Jul 2012 19:21:09 +0000 (UTC) (envelope-from ocean_grey@hotmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 58DEF8FC08 for ; Mon, 9 Jul 2012 19:21:09 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SoJW3-0006ks-5y for freebsd-hackers@freebsd.org; Mon, 09 Jul 2012 12:21:03 -0700 Date: Mon, 9 Jul 2012 12:21:03 -0700 (PDT) From: ping chen To: freebsd-hackers@freebsd.org Message-ID: <1341861663173-5725463.post@n5.nabble.com> In-Reply-To: <4FEC85F4.8010005@FreeBSD.org> References: <201206280958.13859.jhb@freebsd.org> <20120628144630.GA50099@dragon.genyosha.net> <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> <4FEC85F4.8010005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 Jul 2012 19:43:24 +0000 Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 19:21:09 -0000 Thanks Kim. That's very helpful. One more question, to get teh RAM of the system, is the way r190599 reliable? Could we trust env variable to get memory reading from bios? If I would like to calculate the RAM from totalmem = physmem << 12 + reserve_memory+ msgbuff_size How can I get size of reserve_memory, i belive msgbuff_size is 65536? THANKS -- View this message in context: http://freebsd.1045724.n5.nabble.com/distinguish-between-Maxmem-realmem-physmem-tp5722282p5725463.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 19:49:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98227106564A; Mon, 9 Jul 2012 19:49:41 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 522688FC18; Mon, 9 Jul 2012 19:49:41 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q69Jn1TQ054490; Mon, 9 Jul 2012 12:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1341863342; bh=AxtLJNvA0WVysac5Ib+9VPLStOupbO+JPaqOgLihJZ8=; h=Subject:From:Reply-To:To:Cc:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=qzMG2O85dpQ9eWN2o3b6koaRkT611WUSOqG/yjhiWegs0LuaNRhNQ/7QH9BKXc7uB Vt9d/M0/RmiG3UXOX80x/bDIE7lpAfgdeIW5BcqMRv0/f4dwsi2jU403KqgxhHOv9/ P7wKUkfeyHTWrPjAc8Fx9lOQdhgHU316Jn5QNOr4= From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 09 Jul 2012 12:49:01 -0700 Message-ID: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 863342000 Cc: rmacklem@freebsd.org Subject: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:49:41 -0000 Ran into some symbol errors with the dtraceall module when using the *old* nfs client. I think that this is more or less the right thing to do, but I'm not sure. --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.000000000 0000 +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.000000000 0000 @@ -66,8 +66,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#else /* defined (NFSCLIENT) */ MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 20:04:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE3EC106566B for ; Mon, 9 Jul 2012 20:04:47 +0000 (UTC) (envelope-from apeiron@isuckatdomains.net) Received: from isuckatdomains.net (unknown [IPv6:2600:3c01:e000:4::1]) by mx1.freebsd.org (Postfix) with ESMTP id AF98C8FC08 for ; Mon, 9 Jul 2012 20:04:47 +0000 (UTC) Received: from isuckatdomains.isuckatdomains.net (isuckatdomains.net [74.207.243.179]) by isuckatdomains.net (Postfix) with ESMTPSA id 26A5345C9F for ; Mon, 9 Jul 2012 16:04:50 -0400 (EDT) Date: Mon, 9 Jul 2012 16:04:49 -0400 From: Chris Nehren To: freebsd-hackers@freebsd.org Message-ID: <20120709200448.GK6569@isuckatdomains.isuckatdomains.net> Mail-Followup-To: freebsd-hackers@freebsd.org References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <07345CE5-EE3A-413D-84BC-C9DA63FCBB9E@bsdimp.com> <4FF9512A.8050803@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="acOuGx3oQeOcSZJu" Content-Disposition: inline In-Reply-To: <4FF9512A.8050803@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Better ldns docs? (Was: bikeshedding about BIND) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 20:04:47 -0000 --acOuGx3oQeOcSZJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 02:21:46 -0700 , Doug Barton wrote: > That's an implementation issue, and is easily handled with drill, or the > host-like program we all agree is a really-nice-to-have. About that: as I said elsewhere in one of these threads (I want my bikeshed clear and chartreuse at the same time, thank you), I decided to give this a try. However I'm finding the Doxygen autogenerated documentation to be less than useful. I'd really appreciate a task-oriented set of documentation. The design guide helps somewhat but I'm still missing a good set of docs for how things fit together. I suppose you could say "well volunteered" to that, too, but I'm not sure if the docs will get finished in time for a good CLI client for 10-RELEASE. --=20 Thanks and best regards, Chris Nehren --acOuGx3oQeOcSZJu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJP+zlgAAoJEB3ywRGrHAnQmR8QAKhARbKu+x44C97wG3PYbYdh 2VxspPzE2AduiyBKahHmOBsYCKgksaxDl+KJ4qPQrny4t8IA5D3EBf6zO91Z4fqZ WJtA981AskMvPeLLXlo6nzGUVaIb+OS7kZgeC8Up7BeRa9MzldhQLURJJGo4wkpv JHGS8R4NlyG1XqXGifn0Tky511DzsBFIXTkmn2GWaNeWVRaQsec/eWutjGm4qKEs 6LMLfn65dH+F/5ST60gFMtpM4KdrtVMZN3hd3X8gjU3MaaYImu7EK10shE+Ip1OY nBqWgmnTjDkfvYF0+qcv1Iggkn82l4nYNx9IoHEf1VL600+hrEoIbzn+Wz428dBC cOf7V8SNdbr3nFr7JZePPxRaRN9cwXVUtoOJtty1Vn3G/JaX+0yXl3baRhMjXfSy Zgorw2Xe+UcSIGoYx4U+lZvjWMJ6QytMnxrEVVj1u/TC/VoYTvxdz863mE8FEoB1 pgM40+8jeCA//YadFEBws2V+iyet6JjaEthxFVIid0n1LDv19HNXsUWek63Janog UAukkImoU7I5JRBv/SL5GTCqaconYjAxsIxLT4+z7cp16ntKKki8JjB5jJIwRI3e lhFC/6i7XdaYHNeqn4w9Hk3XVTsoPdiebUruzPGHhR+0yW10SSZk6lTki2eyLWzc 5kd4IvUMomYYopHAXeXM =svVQ -----END PGP SIGNATURE----- --acOuGx3oQeOcSZJu-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 20:48:04 2012 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 EB70F10656E9 for ; Mon, 9 Jul 2012 20:48:04 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 754FC8FC08 for ; Mon, 9 Jul 2012 20:48:03 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q69Kltvf058386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Jul 2012 06:47:56 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q69Kln6A088290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 06:47:50 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q69Klnei088289 for freebsd-hackers@freebsd.org; Tue, 10 Jul 2012 06:47:49 +1000 (EST) (envelope-from peter) Date: Tue, 10 Jul 2012 06:47:49 +1000 From: Peter Jeremy To: freebsd-hackers@freebsd.org Message-ID: <20120709204749.GA88274@server.rulingia.com> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <4FFACB51.90001@brodnik.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 20:48:05 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) Brodnik"= wrote: >Excuse my ignorance - but is there a how-to paper on transition from=20 >bind to unbound for SOHO? In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? --=20 Peter Jeremy --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/7Q3UACgkQ/opHv/APuIdA0wCgpMceJo1BHtHPOhX+KXQHFZPG EbMAoMO1HCj/+n/4ymdfMkEgdhQE3djp =ISvb -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 20:54:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 622EB106566B for ; Mon, 9 Jul 2012 20:54:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F2F7C203AEB; Mon, 9 Jul 2012 20:52:16 +0000 (UTC) Message-ID: <4FFB447F.9020001@FreeBSD.org> Date: Mon, 09 Jul 2012 13:52:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> <20120709204749.GA88274@server.rulingia.com> In-Reply-To: <20120709204749.GA88274@server.rulingia.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 20:54:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/09/2012 13:47, Peter Jeremy wrote: > On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) > Brodnik" wrote: >> Excuse my ignorance - but is there a how-to paper on transition >> from bind to unbound for SOHO? You don't need to transition if you don't want to. Just install BIND from the ports. > In particular, if unbound has no authoritative server capabilities, > what suggestions are there for handling the private hosts in a SOHO > environment? Stub and/or forward zones. The unbound docs have more information. Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+0R/AAoJEFzGhvEaGryECuQIAM2CtwjuYZPpQHYojU93mF7g ZLmTqmo8cdunpRUc66hHEirqnmnZ58LkosOugbuTgNvWAB9H2NOo25rFKkft3k0q S+5hSqS442NNvEYrsOlBhdPlP/cEpK36Mt24o3UlB1JVDjX0oj3BxXBc6BY08zHI 6/vCr74+SBHrg8k5yOhLpbgI5sEENhEAKNQY/6XSUmQlWzOPTMVEehp2Xon+llbf m/T5vkjitLBSveG7+xwFT4gCMgI1S2eJcFE/rmgmLYI9iqoUkp5uO/eSZQBi12Qa EIHKIPwp1eioSdrtPqZTuqLaPripJ+ewhveL126aXFVsKToskk9HaFRQr0TzMac= =Ojll -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 20:55:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2DFB9106568C for ; Mon, 9 Jul 2012 20:55:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 53DD81588EC; Mon, 9 Jul 2012 20:53:15 +0000 (UTC) Message-ID: <4FFB44BA.3040208@FreeBSD.org> Date: Mon, 09 Jul 2012 13:53:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jonathan McKeown References: <4FFA7980.4000707@FreeBSD.org> <201207091533.08963.j.mckeown@ru.ac.za> In-Reply-To: <201207091533.08963.j.mckeown@ru.ac.za> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 20:55:34 -0000 On 07/09/2012 06:33, Jonathan McKeown wrote: > On Monday 09 July 2012 09:34:34 Avleen Vig wrote: >> The issue is also one of barrier-to-entry. By removing `dig` and >> `host`, I think we're making things unnecessarily more difficult for >> people who don't *know* FreeBSD. `dig` and `host` a universally >> standard tools for doing DNS lookups. Taking them away in base to >> replace them with something else just seems like something that won't >> really *help* users. > > Yes. So we should change the base system so that by default it does a database > lookup whenever you type an unrecognised command - to lower the barrier to > entry. Right. > We should also change the base system to remove the most commonly used > tools for doing DNS lookups, to.... what was the reason again? It's been covered at length in this thread. We get it, change is hard. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 21:03:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 68FAE106567C for ; Mon, 9 Jul 2012 21:03:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E9F631A6AC7; Mon, 9 Jul 2012 21:01:24 +0000 (UTC) Message-ID: <4FFB46A4.5050504@FreeBSD.org> Date: Mon, 09 Jul 2012 14:01:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD Hackers , Garrett Wollman , Avleen Vig , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 21:03:55 -0000 On 07/09/2012 06:45, Mark Blackman wrote: > Indeed, 'dig' and 'host' must be present and working as expected > in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 21:04:55 2012 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 A7CEA106567F; Mon, 9 Jul 2012 21:04:55 +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 8E9598FC12; Mon, 9 Jul 2012 21:04:54 +0000 (UTC) Received: from porto.starpoint.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 AAA08077; Tue, 10 Jul 2012 00:04:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SoL8V-000L3Z-S0; Tue, 10 Jul 2012 00:04:51 +0300 Message-ID: <4FFB4770.7050209@FreeBSD.org> Date: Tue, 10 Jul 2012 00:04:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: sbruno@FreeBSD.org References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Sean Bruno , rmacklem@FreeBSD.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 21:04:55 -0000 on 09/07/2012 22:49 Sean Bruno said the following: > Ran into some symbol errors with the dtraceall module when using the > *old* nfs client. > > I think that this is more or less the right thing to do, but I'm not > sure. > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > 2011-11-02 23:46:55.000000000 0000 > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > 2011-11-02 23:46:55.000000000 0000 > @@ -66,8 +66,11 @@ > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > +#if defined (NFSCL) > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > +#else /* defined (NFSCLIENT) */ > MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); > +#endif > #if defined(__amd64__) || defined(__i386__) > MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); > MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); Just to add some noise to the signal - my personal opinion is that nfs support doesn't have to be in dtraceall. Maybe in something "all-er" :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 21:13:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB02D106566B; Mon, 9 Jul 2012 21:13:14 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 830A98FC0A; Mon, 9 Jul 2012 21:13:14 +0000 (UTC) Received: from [192.168.1.21] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id AF86757012; Mon, 9 Jul 2012 22:14:00 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Blackman In-Reply-To: <4FFB46A4.5050504@FreeBSD.org> Date: Mon, 9 Jul 2012 22:13:12 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" , FreeBSD Hackers , Garrett Wollman , Avleen Vig , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 21:13:14 -0000 On 9 Jul 2012, at 22:01, Doug Barton wrote: > On 07/09/2012 06:45, Mark Blackman wrote: > >> Indeed, 'dig' and 'host' must be present and working as expected >> in a minimally installed system. > > So if you don't like the versions that get imported, install bind-tools > from ports. my DNS resolution is broken, so my ports can't download any tarballs. In this case, I reach for dig to see which part of the DNS resolution chain is failing me. At the bare minimum, 'dig' should be an alias for 'drill', which I have to say isn't working brilliantly for me on OS X. It suggests I use '-t' and then keeps suggesting I use '-t' even when I do use it. drill feels a bit rough around the edges to me. - Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 21:37:13 2012 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 971B3106566C; Mon, 9 Jul 2012 21:37:13 +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 254068FC1C; Mon, 9 Jul 2012 21:37:13 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id B4C63685D; Mon, 9 Jul 2012 21:37:11 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 6A5B487D2; Mon, 9 Jul 2012 23:37:11 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> Date: Mon, 09 Jul 2012 23:37:10 +0200 In-Reply-To: <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> (Mark Blackman's message of "Mon, 9 Jul 2012 22:13:12 +0100") Message-ID: <86a9z8mxa1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Doug Barton , Garrett Wollman , Avleen Vig , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 21:37:13 -0000 Mark Blackman writes: > my DNS resolution is broken, so my ports can't download any tarballs.=20 > In this case, I reach for dig to see which part of the DNS resolution > chain is failing me.=20 > > At the bare minimum, 'dig' should be an alias for 'drill', which I have=20 > to say isn't working brilliantly for me on OS X. It suggests I use '-t'=20 > and then keeps suggesting I use '-t' even when I do use it. > > drill feels a bit rough around the edges to me. This reminds me of the (probably apocryphal) American grade school teacher who complained that the metric system was so inexact; for instance, a meter is _approximately_ a yard, a kilometer is _approximately_ two thirds of a kilometer, etc. By which I mean, of course, that you are blaming drill not for its own shortcomings, but for those of the wrapper you use to _approximate_ dig with drill. The -t option doesn't mean the same for drill as for dig. A proper dig wrapper for drill would have to translate one to the other. However, you should never need the -t option when using dig; I suspect that it exists only for people who are so used to host that they want to use the same command line except for s/host/dig/. Instead of 'dig -t soa des.no', you should use 'dig des.no soa'. The syntax is dig [@server] name [type] [class] I'm not sure why it supports a class argument, since as far as I know, the only class still in use is IN. In the most common case, dig and drill are nearly identical; the command line is exactly the same (except for s/dig/drill/), and the output nearly so - drill doesn't print a question section. If that's a problem for you, it's easily fixed. % dig @ns.des.no des.no soa=20=20 ; <<>> DiG 9.6.-ESV-R5-P1 <<>> @ns.des.no des.no soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47226 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;des.no. IN SOA ;; ANSWER SECTION: des.no. 3600 IN SOA ns.des.no. hostmaster.des.n= o. 2012042401 3600 900 3600000 3600 ;; AUTHORITY SECTION: des.no. 3600 IN NS ns.des.no. des.no. 3600 IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600 IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121#53(194.63.250.121) ;; WHEN: Mon Jul 9 23:22:05 2012 ;; MSG SIZE rcvd: 128 % drill @ns.des.no des.no soa ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 61642 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1=20 ;; QUESTION SECTION: ;; des.no. IN SOA ;; ANSWER SECTION: des.no. 3600 IN SOA ns.des.no. hostmaster.des.no. 2012042401 36= 00 900 3600000 3600 ;; AUTHORITY SECTION: des.no. 3600 IN NS ns.des.no. des.no. 3600 IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600 IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121 ;; WHEN: Mon Jul 9 23:22:23 2012 ;; MSG SIZE rcvd: 128 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 21:48:33 2012 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 938351065674; Mon, 9 Jul 2012 21:48:33 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8E78FC16; Mon, 9 Jul 2012 21:48:33 +0000 (UTC) Received: from [192.168.1.21] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id 95DF757012; Mon, 9 Jul 2012 22:49:20 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Blackman In-Reply-To: <86a9z8mxa1.fsf@ds4.des.no> Date: Mon, 9 Jul 2012 22:47:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" , Doug Barton , Garrett Wollman , Avleen Vig , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 21:48:33 -0000 On 9 Jul 2012, at 22:37, Dag-Erling Sm=F8rgrav wrote: > Mark Blackman writes: >> my DNS resolution is broken, so my ports can't download any tarballs.=20= >> In this case, I reach for dig to see which part of the DNS resolution >> chain is failing me.=20 >>=20 >> At the bare minimum, 'dig' should be an alias for 'drill', which I = have=20 >> to say isn't working brilliantly for me on OS X. It suggests I use = '-t'=20 >> and then keeps suggesting I use '-t' even when I do use it. >>=20 >> drill feels a bit rough around the edges to me. >=20 > This reminds me of the (probably apocryphal) American grade school > teacher who complained that the metric system was so inexact; for > instance, a meter is _approximately_ a yard, a kilometer is > _approximately_ two thirds of a kilometer, etc. >=20 > By which I mean, of course, that you are blaming drill not for its own > shortcomings, but for those of the wrapper you use to _approximate_ = dig > with drill. >=20 > The -t option doesn't mean the same for drill as for dig. A proper = dig > wrapper for drill would have to translate one to the other. However, > you should never need the -t option when using dig; I suspect that it > exists only for people who are so used to host that they want to use = the > same command line except for s/host/dig/. I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Marks-Macbook% drill -t www.google.com ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 14583 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0=20 ;; QUESTION SECTION: ;; www.google.com. IN A ;; ANSWER SECTION: www.google.com. 44089 IN CNAME www.l.google.com. www.l.google.com. 147 IN A 173.194.67.106 www.l.google.com. 147 IN A 173.194.67.147 www.l.google.com. 147 IN A 173.194.67.104 www.l.google.com. 147 IN A 173.194.67.105 www.l.google.com. 147 IN A 173.194.67.103 www.l.google.com. 147 IN A 173.194.67.99 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 34 msec ;; SERVER: 178.250.72.130 ;; WHEN: Mon Jul 9 22:46:13 2012 ;; MSG SIZE rcvd: 148 ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 22:01:45 2012 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 B4FA31065786; Mon, 9 Jul 2012 22:01:45 +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 685658FC12; Mon, 9 Jul 2012 22:01:45 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id BB8466869; Mon, 9 Jul 2012 22:01:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 96CB587E5; Tue, 10 Jul 2012 00:01:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> Date: Tue, 10 Jul 2012 00:01:44 +0200 In-Reply-To: <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> (Mark Blackman's message of "Mon, 9 Jul 2012 22:47:59 +0100") Message-ID: <863950mw53.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Doug Barton , Garrett Wollman , Avleen Vig , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 22:01:45 -0000 Mark Blackman writes: > I never use '-t' with dig. drill *told* me I should use '-t' then > completely failed to acknowledge I had done so. > > Marks-Macbook% drill -t www.google.com > [...] > ;; WARNING: The answer packet was truncated; you might want to > ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) So you got a truncated response and used -t, it didn't help, and drill printed the boilerplate warning message that it always prints when it gets a truncated response. I don't know about you, but I would call that a cosmetic nit. Unless, of course, you had tcpdump running while you did this and it turns out that drill sent a UDP request in spite of -t? It works fine (i.e. it uses UDP by default, and TCP when asked to) for me. I even tried the same nameserver you used, and was very surprised to get an answer. If you know the people who run it, you might let them know that it is inadvisable to process recursive queries from outside their own network. FWIW, the reply I got was not truncated. Perhaps there is a transparent DNS proxy somewhere between you and 178.250.72.130 - quite common with broadband CPE. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 22:23:08 2012 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 3FE101065670; Mon, 9 Jul 2012 22:23:08 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1E48FC14; Mon, 9 Jul 2012 22:23:07 +0000 (UTC) Received: from [192.168.1.21] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id AA10B57012; Mon, 9 Jul 2012 23:23:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) From: Mark Blackman In-Reply-To: <863950mw53.fsf@ds4.des.no> Date: Mon, 9 Jul 2012 23:23:05 +0100 Message-Id: <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <863950mw53.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1278) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Bjoern A. Zeeb" , Doug Barton , Avleen Vig , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 22:23:08 -0000 On 9 Jul 2012, at 23:01, Dag-Erling Sm=F8rgrav wrote: > Mark Blackman writes: >> I never use '-t' with dig. drill *told* me I should use '-t' then >> completely failed to acknowledge I had done so. >>=20 >> Marks-Macbook% drill -t www.google.com >> [...] >> ;; WARNING: The answer packet was truncated; you might want to >> ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) >=20 > So you got a truncated response and used -t, it didn't help, and drill > printed the boilerplate warning message that it always prints when it > gets a truncated response. I don't know about you, but I would call > that a cosmetic nit. >=20 > Unless, of course, you had tcpdump running while you did this and it > turns out that drill sent a UDP request in spite of -t? It works fine > (i.e. it uses UDP by default, and TCP when asked to) for me. Yes, I worked out it was boilerplate for the general condition. A = cosmetic nit that makes me do a double-take on my first usage strikes me as=20 rough around the edges. YMMV. drill certainly looks like a drop-in=20 replacement for the common case as you suggest. But if it's not called 'dig' and I've never heard of 'drill', I'm unlikely to reach for = 'drill', hence the alias suggestion. I *had* never heard of 'drill' until this thread came up. > FWIW, the reply I got was not truncated. Perhaps there is a = transparent > DNS proxy somewhere between you and 178.250.72.130 - quite common with > broadband CPE. I have detected there is some kind of stealth DNS interception at work in the past, although I think it's more central than the CPE. Mark= From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 22:40:09 2012 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 CC39D1065673; Mon, 9 Jul 2012 22:40:09 +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 7EFCC8FC1A; Mon, 9 Jul 2012 22:40:09 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 4F7A06887; Mon, 9 Jul 2012 22:40:08 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id F0E6687EB; Tue, 10 Jul 2012 00:40:07 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <863950mw53.fsf@ds4.des.no> <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> Date: Tue, 10 Jul 2012 00:40:07 +0200 In-Reply-To: <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> (Mark Blackman's message of "Mon, 9 Jul 2012 23:23:05 +0100") Message-ID: <86y5mslfso.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Doug Barton , Avleen Vig , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 22:40:09 -0000 Mark Blackman writes: > drill certainly looks like a drop-in replacement for the common case > as you suggest. But if it's not called 'dig' and I've never heard of > 'drill', I'm unlikely to reach for 'drill', hence the alias > suggestion. I *had* never heard of 'drill' until this thread came up. They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I'm not entirely convinced that it is really required, but considering how easy it would be to implement, there's no reason not to. A drop-in replacement for host is, of course, an absolute requirement. As for nslookup... it's been deprecated for a decade. Its only saving grace is that its interactive mode is useful for playing text adventures implemented with DNS TXT records :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 23:46:06 2012 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 72EC5106566B for ; Mon, 9 Jul 2012 23:46:06 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6B58FC12 for ; Mon, 9 Jul 2012 23:46:06 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q69Nk0nV054812 for ; Mon, 9 Jul 2012 19:46:05 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <4FFB6D37.1040300@m5p.com> Date: Mon, 09 Jul 2012 19:45:59 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> In-Reply-To: <4FFB46A4.5050504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 09 Jul 2012 19:46:05 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Jul 2012 23:46:06 -0000 On 07/09/12 17:01, Doug Barton wrote: > On 07/09/2012 06:45, Mark Blackman wrote: > >> Indeed, 'dig' and 'host' must be present and working as expected >> in a minimally installed system. > > So if you don't like the versions that get imported, install bind-tools > from ports. > > Doug > Doug, you are one of the people whose writings on the FreeBSD lists I most respect. But I think you are wrong about this one aspect of your proposed change. To discover that "dig" is suddenly not in the base FreeBSD system any more some day would be just about the worst violation of the Principle of Least Astonishment for me in many years. And discovering it just when I'm having trouble downloading packages would be salt in the wound. -- George Mitchell From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 02:46:15 2012 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 82B69106564A; Tue, 10 Jul 2012 02:46:15 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD338FC0C; Tue, 10 Jul 2012 02:46:14 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6A2kDwA059230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 12:46:13 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6A2k660091298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 12:46:06 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6A2k6gg091297; Tue, 10 Jul 2012 12:46:06 +1000 (EST) (envelope-from peter) Date: Tue, 10 Jul 2012 12:46:05 +1000 From: Peter Jeremy To: Doug Barton Message-ID: <20120710024605.GA90875@server.rulingia.com> References: <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> <20120709204749.GA88274@server.rulingia.com> <4FFB447F.9020001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <4FFB447F.9020001@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Replacing BIND with unbound 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 02:46:15 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Firstly, I should note that I'm not against removing bind from base. I'm merely saying that users are going to need some guidance during the transition. On 2012-Jul-09 13:52:15 -0700, Doug Barton wrote: >On 07/09/2012 13:47, Peter Jeremy wrote: >> On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) >> Brodnik" wrote: >>> Excuse my ignorance - but is there a how-to paper on transition >>> from bind to unbound for SOHO? > >You don't need to transition if you don't want to. Just install BIND >from the ports. IMHO, this is a copout. If the default response to anyone asking a question about transitioning is "install bind" then we might as well leave bind in the base system. As I see it, FreeBSD systems fall roughly into 3 categories: 1) Client systems that need to lookup external DNS servers only. 2) SOHO systems that primarily do external lookups but need to be internally authoritative about their local network. 3) Systems that are primarily DNS servers. The third category is clearly a "use ports" case - there's no need for the base system to include all the tools necessary to build one of the root nameservers. The base system _must_ handle the first category - and I'll accept advice from dougb@ & des@ that unbound is a good choice for this. The issues people seem to have with the change here are the user tools to interface with DNS - currently dig(1), host(1) and nslookup(1) - and des@ has now adequately covered this. I think the majority of the remaining unease in this thread comes from people who administer systems in the second category. I (and I expect lots of other people) use bind for this solely because it is in the base system, not because it is the best tool for the job. >> In particular, if unbound has no authoritative server capabilities, >> what suggestions are there for handling the private hosts in a SOHO >> environment? > >Stub and/or forward zones. The unbound docs have more information. But unfortunately no tutorial guides. Having looked at the online copy of unbound.conf(5), it appears that unbound _does_ have some limited server capabilities - this wasn't clear in the original proposal. It's not immediately clear to me whether it's adequate for my purposes and, if it isn't, what I should use. This is an area where I expect there will be community input - potentially via the FreeBSD wiki. --=20 Peter Jeremy --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/7l20ACgkQ/opHv/APuIfP6gCfVKFxrbCxy8OJUYh/mE8J6DdL 5SoAnR+fZatQNXvtSQvX6GQ01HJwoBNh =sQo0 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 02:56:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 467FD106566B for ; Tue, 10 Jul 2012 02:56:28 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id AAA5E8FC0A for ; Tue, 10 Jul 2012 02:56:27 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6A2uQkH059256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Jul 2012 12:56:26 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6A2uKFJ091395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 12:56:20 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6A2uKvs091394 for freebsd-hackers@freebsd.org; Tue, 10 Jul 2012 12:56:20 +1000 (EST) (envelope-from peter) Date: Tue, 10 Jul 2012 12:56:20 +1000 From: Peter Jeremy To: FreeBSD Hackers Message-ID: <20120710025619.GB90875@server.rulingia.com> References: <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <863950mw53.fsf@ds4.des.no> <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> <86y5mslfso.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <86y5mslfso.fsf@ds4.des.no> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 02:56:28 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-10 00:40:07 +0200, Dag-Erling Sm=F8rgrav wrote: >They are sufficiently similar that writing a wrapper that supports a >significant subset of dig's command-line option and uses drill as a >backend shouldn't take more than an afternoon for a reasonably >experienced programmer. I would further suggest that where a dig(1) option isn't emulated, the fallback error message should refer the user to drill(1). >As for nslookup... it's been deprecated for a decade. But old fogies might still use it. Can I suggest that something along the lines of the the following be installed as /usr/bin/nslookup: #!/bin/sh echo "nslookup is no longer supported. Please see drill(1) or host(1)" >&2 exit 1 --=20 Peter Jeremy --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/7mdMACgkQ/opHv/APuIeVeACgkSRqr3qRcXu76P+qQEZc3t/G 4ngAnjsvt4uIhVzbjiYtQl8fshpaSEpJ =Ff03 -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 03:10:19 2012 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 CB787106566C for ; Tue, 10 Jul 2012 03:10:19 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45A2E8FC15 for ; Tue, 10 Jul 2012 03:10:19 +0000 (UTC) Received: by lbon10 with SMTP id n10so21021699lbo.13 for ; Mon, 09 Jul 2012 20:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WpKlqKlhv+bG4MppV/Tp8Cx6QjOFsg1mtfszUKVNj6k=; b=ksekx/W/j3n75vmy7Vs4WgVcHL9FIXIJjxPIuQxinZTRCmagfid7KIm7CaG4aCBpYx WmLBrrzFmy27TS4xbdEnETVobDiGI6Ep+0jC9HUNutuLKB8KQIYkZWZ5z16UPGs5hK8N jOY3D9lfAWDaxb+N3RfJtOW86/uai26x0j1pZ9klhsVvgU34AxvFhBag/w4ZqOBekFeE HBHeC0A769m6Y9mmMObbMNo77ebb0UnwfkqlMY5PSg+xoaM8ibIhw6tmwH7pZYw07ONG S2ItlTvR1+TcpAEEj8aK/eWnPmacOCMrmarFr4GgXkJj9adVtI4AnIigOkCeLyy/8ogl /taQ== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr36996872lab.31.1341889818072; Mon, 09 Jul 2012 20:10:18 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Mon, 9 Jul 2012 20:10:18 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Mon, 9 Jul 2012 20:10:18 -0700 (PDT) In-Reply-To: <20120710025619.GB90875@server.rulingia.com> References: <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <863950mw53.fsf@ds4.des.no> <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> <86y5mslfso.fsf@ds4.des.no> <20120710025619.GB90875@server.rulingia.com> Date: Mon, 9 Jul 2012 20:10:18 -0700 Message-ID: From: Avleen Vig To: Peter Jeremy X-Mailman-Approved-At: Tue, 10 Jul 2012 04:26:50 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 03:10:20 -0000 On Jul 9, 2012 7:57 PM, "Peter Jeremy" wrote: > > On 2012-Jul-10 00:40:07 +0200, Dag-Erling Sm=F8rgrav wrote: > >They are sufficiently similar that writing a wrapper that supports a > >significant subset of dig's command-line option and uses drill as a > >backend shouldn't take more than an afternoon for a reasonably > >experienced programmer. > > I would further suggest that where a dig(1) option isn't emulated, the > fallback error message should refer the user to drill(1). > > >As for nslookup... it's been deprecated for a decade. > > But old fogies might still use it. Can I suggest that something along > the lines of the the following be installed as /usr/bin/nslookup: > > #!/bin/sh > echo "nslookup is no longer supported. Please see drill(1) or host(1)" >&2 > exit 1 This is a much better solution for users. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 06:50:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35DC91065674; Tue, 10 Jul 2012 06:50:49 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5511E8FC15; Tue, 10 Jul 2012 06:50:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Message-Id:Content-Type:MIME-Version:Date:Subject:To:From; bh=pYwDYnjFUmMo3lfdWwg74aAWkX2Oo4HwV8t75tXxta0=; b=bV9Vcx7mDJlJ28mI2nUnTeXOKnWzvA9NOQF4xI2OfvqZ3D5lbE9i9UH8OfSn1lk93/9YgdvnygpYSpcVNdLDkBrlYfcygiHvjWw5b+Q+EeTQTfPV746PXvfvah11k2nc; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:56203) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SoUHW-000C6f-36; Tue, 10 Jul 2012 08:50:46 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Tue, 10 Jul 2012 08:50:45 +0200 User-Agent: KMail/1.9.10 References: <201207091533.08963.j.mckeown@ru.ac.za> <4FFB44BA.3040208@FreeBSD.org> In-Reply-To: <4FFB44BA.3040208@FreeBSD.org> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: mail.ru.ac.za (2001:4200:1010:0:250:56ff:fe8d:5) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Cc: Doug Barton Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 06:50:49 -0000 On Monday 09 July 2012 22:53:14 Doug Barton wrote: > > We get it, change is hard. No, that isn't what I said at all. I was pointing out that there's some inconsistency between arguing that we need to make things more predictable for new users, while simultaneously arguing that we should remove the usual tools for doing dns lookups (note, I was talking about the BIND tools, not the whole of BIND, although I gather from other responses in the thread that they're inextricably linked). From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:12:18 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5491A1065672 for ; Tue, 10 Jul 2012 07:12:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7ECEA155919; Tue, 10 Jul 2012 07:12:16 +0000 (UTC) Message-ID: <4FFBD5D0.8020306@FreeBSD.org> Date: Tue, 10 Jul 2012 00:12:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> <20120709204749.GA88274@server.rulingia.com> <4FFB447F.9020001@FreeBSD.org> <20120710024605.GA90875@server.rulingia.com> In-Reply-To: <20120710024605.GA90875@server.rulingia.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Replacing BIND with unbound 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:12:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/09/2012 19:46, Peter Jeremy wrote: > Firstly, I should note that I'm not against removing bind from base. Thanks for clarifying. > I'm merely saying that users are going to need some guidance during > the transition. I've never argued against that. I think you misunderstood my flippant comment below. > On 2012-Jul-09 13:52:15 -0700, Doug Barton wrote: >> On 07/09/2012 13:47, Peter Jeremy wrote: >>> On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) >>> Brodnik" wrote: >>>> Excuse my ignorance - but is there a how-to paper on transition >>>> from bind to unbound for SOHO? >> >> You don't need to transition if you don't want to. Just install BIND >>from the ports. > > IMHO, this is a copout. If the default response to anyone asking a > question about transitioning is "install bind" then we might as well > leave bind in the base system. 3 things to keep in mind in response. 1. We cannot keep BIND in the base system. 2. As above, I didn't say we shouldn't have a transition guide. I said we don't need one. That may not seem like an important distinction, but it is. :) 3. People really don't have to transition if they don't want to. All 3 of these are important points, but 1 and 3 are critical for people to understand if they are going to participate in this discussion. > As I see it, FreeBSD systems fall roughly into 3 categories: > 1) Client systems that need to lookup external DNS servers only. > 2) SOHO systems that primarily do external lookups but need to > be internally authoritative about their local network. > 3) Systems that are primarily DNS servers. > > The third category is clearly a "use ports" case - there's no need > for the base system to include all the tools necessary to build one > of the root nameservers. > > The base system _must_ handle the first category - and I'll accept > advice from dougb@ & des@ that unbound is a good choice for this. The > issues people seem to have with the change here are the user tools > to interface with DNS - currently dig(1), host(1) and nslookup(1) - > and des@ has now adequately covered this. I think your analysis above is basically correct. > I think the majority of the remaining unease in this thread comes from > people who administer systems in the second category. I (and I expect > lots of other people) use bind for this solely because it is in the > base system, not because it is the best tool for the job. Well that's yet another reason to take it out of the base so that people can analyze this critically. :) Seriously though, "install BIND from ports" is still a good answer to this use case. I'd argue that BIND 9.[89] is actually the best tool for the purpose you outlined, but there's no reason you couldn't use a combination of unbound and nsd. It would just be different than what people are used to. >>> In particular, if unbound has no authoritative server capabilities, >>> what suggestions are there for handling the private hosts in a SOHO >>> environment? >> >> Stub and/or forward zones. The unbound docs have more information. > > But unfortunately no tutorial guides. https://unbound.net/documentation/index.html > Having looked at the online > copy of unbound.conf(5), it appears that unbound _does_ have some > limited server capabilities - this wasn't clear in the original > proposal. It's not immediately clear to me whether it's adequate for > my purposes and, if it isn't, what I should use. You're still stuck on "If it's in the base, it's the thing I have to use, so the fact that I don't know how to use it is causing me stress." Get over that, and realize that you can continue to use all the same stuff you already have, if you install BIND from ports. :) Doug - -- Change is hard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9XPAAoJEFzGhvEaGryENVkH/jWir7h8xI9CmdpMuXdMRZZT ulfoUs8KFt1BAwWvIQsXS1kwH+coe6i0rMd9ir9QCXgs9CqllJ8NhTcaY+OqxudA YcUWdzYIX6szfrgnocwxlZWIz2Xou63T3cRFdBQ9hzLDA7KzlJxgreTtLrEf3Fvg V1qv0ZigI3X50UtelOilROe/xqZLHwgOlUWpX6vuvYJhlw5s///Oe+13ZSQkqTa7 Roa9bz3r2PKaHSw3hTjKIuVDiCwJQMbx26IXmYf5SPIlJaBG28/LBGVFcxETMPPf c+fc1JYjDp2wZ1yBUmJ3gljtl7mGmGV40KF9WCie6dKrTSMgRGAvuTn+EMXD3rs= =RRzj -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:13:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D500E106564A for ; Tue, 10 Jul 2012 07:13:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E4A5A176492; Tue, 10 Jul 2012 07:12:49 +0000 (UTC) Message-ID: <4FFBD5F1.8090803@FreeBSD.org> Date: Tue, 10 Jul 2012 00:12:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> In-Reply-To: <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , Garrett Wollman , Avleen Vig , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:13:44 -0000 On 07/09/2012 14:47, Mark Blackman wrote: > I never use '-t' with dig. drill *told* me I should use '-t' > then completely failed to acknowledge I had done so. Have you reported this bug? -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:16:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 2C9A51065670 for ; Tue, 10 Jul 2012 07:16:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7B17A14E82B; Tue, 10 Jul 2012 07:16:23 +0000 (UTC) Message-ID: <4FFBD6C7.2080008@FreeBSD.org> Date: Tue, 10 Jul 2012 00:16:23 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <863950mw53.fsf@ds4.des.no> <86885338-37D1-47FE-8DC6-45E9B4B806D7@exonetric.com> <86y5mslfso.fsf@ds4.des.no> <20120710025619.GB90875@server.rulingia.com> In-Reply-To: <20120710025619.GB90875@server.rulingia.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:16:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/09/2012 19:56, Peter Jeremy wrote: > On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav > wrote: >> They are sufficiently similar that writing a wrapper that >> supports a significant subset of dig's command-line option and >> uses drill as a backend shouldn't take more than an afternoon for >> a reasonably experienced programmer. > > I would further suggest that where a dig(1) option isn't emulated, > the fallback error message should refer the user to drill(1). IMO we don't need a wrapper for drill. For most people, just substituting 'drill' for 'dig' is enough. For more complex stuff people really need to learn the new tool, or install bind-tools. >> As for nslookup... it's been deprecated for a decade. > > But old fogies might still use it. Can I suggest that something > along the lines of the the following be installed as > /usr/bin/nslookup: > > #!/bin/sh echo "nslookup is no longer supported. Please see > drill(1) or host(1)" >&2 exit 1 You have no idea how long I've wanted to do that. :) - -- Change is hard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9bHAAoJEFzGhvEaGryEd9YIAL/A71XjQUC2aXZV36m4nFJ6 sGqfpeVcP/AjaF67wld1WukcrKxqqjmIQATlUna3m6L5t0exNGy4y3Udqmr5eOeo U6p/qYyJ2xkaPz+GnmcO6ygi4uWa0CwzbH5/jfprRSrCQuk7PZzRC0FvNsqqQcyc PtwEBmxTHzURSE6CaB19EuYKYQe+hLecSZlwVlipG4IaEmqmczpdjHnE1EHWiGCU 2uIEkJRradqXknAUTxfomAfM8ARiK2AQGT3TKRJuG8ApcF2CpoJkCaFKn73yxvn8 DQ3ENpSKkkRn8n7t/a9rOUQ0gbl9GP3dXpX/1Kw0dlq21LsGn5aOIy+yvOUw3bw= =Yrv4 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:19:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 6A1121065672 for ; Tue, 10 Jul 2012 07:19:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3853E157DC7; Tue, 10 Jul 2012 07:18:44 +0000 (UTC) Message-ID: <4FFBD753.6050105@FreeBSD.org> Date: Tue, 10 Jul 2012 00:18:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Mitchell References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <4FFB6D37.1040300@m5p.com> In-Reply-To: <4FFB6D37.1040300@m5p.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:19:09 -0000 On 07/09/2012 16:45, George Mitchell wrote: > On 07/09/12 17:01, Doug Barton wrote: >> On 07/09/2012 06:45, Mark Blackman wrote: >> >>> Indeed, 'dig' and 'host' must be present and working as expected >>> in a minimally installed system. >> >> So if you don't like the versions that get imported, install bind-tools >> from ports. >> >> Doug >> > Doug, you are one of the people whose writings on the FreeBSD lists I > most respect. Thank you for the kind words. :) > But I think you are wrong about this one aspect of your > proposed change. To discover that "dig" is suddenly not in the base > FreeBSD system any more some day would be just about the worst > violation of the Principle of Least Astonishment for me in many > years. All flippancy aside, I understand what you're saying here. The problem is that we can't keep BIND in the base. Given that, we need to look at how best to handle the transition. Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:28:07 2012 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 60A79106567A for ; Tue, 10 Jul 2012 07:28:07 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01FE38FC12 for ; Tue, 10 Jul 2012 07:28:06 +0000 (UTC) Received: by qcsg15 with SMTP id g15so8113774qcs.13 for ; Tue, 10 Jul 2012 00:28:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:face:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=KzDVuOVMTj/BbIJ9trMOeBVYCMEC7iUHAoB3aiqfkYU=; b=SaM73NtNRPmXeh+FYhLBrcu8kQgr4+DzJX1EfWh2CzaBCiMxudEMormdVFRYahZ21V hE68hqYXOo23YaJLjftidw6EloUHyEXNguzaNKDEOAXvGZIY/Mj2BfqVa/4c8rdL0zly Fqac58pcioHRudnHmQlvNhh5S5kNemu9EyQ/Wp8o/ByXaMgicspSIyPF0yh9VpzDQASs gjZWoU2aFsdLykKxHFn2EUfLJmw2G6FpfQ0OALMEBcMYKEQa5AzEt1CmqW1JF5H5+dX3 W5npkuQ3Y9KY0m7BcfZufJQGjoLa+/g40xtUyNljurWMtSd6Fxy2YP+IuRMn+r+NNqKl mn5A== Received: by 10.229.115.12 with SMTP id g12mr22057300qcq.58.1341905286401; Tue, 10 Jul 2012 00:28:06 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id n2sm64662334qap.10.2012.07.10.00.28.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 00:28:06 -0700 (PDT) Date: Tue, 10 Jul 2012 03:28:03 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20120710032803.55d30a7d@bhuda.mired.org> In-Reply-To: <4FFBD5D0.8020306@FreeBSD.org> References: <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> <20120709204749.GA88274@server.rulingia.com> <4FFB447F.9020001@FreeBSD.org> <20120710024605.GA90875@server.rulingia.com> <4FFBD5D0.8020306@FreeBSD.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmZUGGAxw9QEcbkOuhsXTvyMLWJ5RrL/cc5vuK3f5byDWwvNdWaEQqHJdaoTI3akg9tsQfP Subject: Re: Replacing BIND with unbound 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:28:07 -0000 On Tue, 10 Jul 2012 00:12:16 -0700 Doug Barton wrote: > On 07/09/2012 19:46, Peter Jeremy wrote: > > As I see it, FreeBSD systems fall roughly into 3 categories: > > 1) Client systems that need to lookup external DNS servers only. > > 2) SOHO systems that primarily do external lookups but need to > > be internally authoritative about their local network. > > 3) Systems that are primarily DNS servers. > > > > I think the majority of the remaining unease in this thread comes from > > people who administer systems in the second category. I (and I expect > > lots of other people) use bind for this solely because it is in the > > base system, not because it is the best tool for the job. > > Well that's yet another reason to take it out of the base so that people > can analyze this critically. :) > > Seriously though, "install BIND from ports" is still a good answer to > this use case. I'd argue that BIND 9.[89] is actually the best tool for > the purpose you outlined, but there's no reason you couldn't use a > combination of unbound and nsd. It would just be different than what > people are used to. I suspect that dnsmasq is a lot better tool for that job than BIND, but see below. Unless you've got a really messy SOHO network, anyway. It's simpler to configure, and includes an integrated DHCP server so hosts that get their IP addresses via DHCP show show up in the dns server. I know bind and at least one DHCP server can be setup to do that, but I never could get it to work properly. dnsmasq did it the first time years ago, and I've never looked back. These days, I'm using it on a DDWRT router. I would have suggested it for the base system, but 1) it's still a bit more than case 1 needs, and 2) it's GPL'ed. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 07:35:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 79A97106566C for ; Tue, 10 Jul 2012 07:35:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 123D3155614; Tue, 10 Jul 2012 07:35:21 +0000 (UTC) Message-ID: <4FFBDB38.3010008@FreeBSD.org> Date: Tue, 10 Jul 2012 00:35:20 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Meyer References: <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> <4FF8CA35.7040209@FreeBSD.org> <4FF952FB.10200@FreeBSD.org> <4FFACB51.90001@brodnik.org> <20120709204749.GA88274@server.rulingia.com> <4FFB447F.9020001@FreeBSD.org> <20120710024605.GA90875@server.rulingia.com> <4FFBD5D0.8020306@FreeBSD.org> <20120710032803.55d30a7d@bhuda.mired.org> In-Reply-To: <20120710032803.55d30a7d@bhuda.mired.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Replacing BIND with unbound 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 07:35:21 -0000 On 07/10/2012 00:28, Mike Meyer wrote: > I suspect that dnsmasq is a lot better tool for that job than BIND I think "better" is in the eye of the beholder, particularly whether or not the "O" is either small or well-staffed enough to pre-enter hostnames into the zone files. That said, dnsmasq is a great tool, especially if you're relying on DDNS. OTOH, as anyone can see from the named.conf in the base, I believe rather strongly that a large'ish network should take responsibility for being authoritative for 1918 stuff (et al) so that they don't go out over the network. You can still do that with other solutions, but this is one area where the fact that BIND can do both is a feature. Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 10:10:54 2012 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 CC5A41065673 for ; Tue, 10 Jul 2012 10:10:54 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 396E28FC14 for ; Tue, 10 Jul 2012 10:10:53 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6AAAlqn046952 for ; Tue, 10 Jul 2012 12:10:47 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6AAAlwZ046949 for ; Tue, 10 Jul 2012 12:10:47 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 10 Jul 2012 12:10:47 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 10 Jul 2012 12:10:47 +0200 (CEST) Subject: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 10:10:54 -0000 this is what i've got from kernel (same visible after dmesg of course) Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn sosini ggnsnaalilg n1a1l Jul 9 08:56:53 .. kernel: 1 Jul 9 08:56:53 ... kernel: Jul 9 08:56:53 ... kernel: <<66>>11 Jul 9 08:56:53 ... kernel: 1 Jul 9 08:56:53 ... kernel: everything before and after seems usual. when reading every second letter it SEEMS to make more sense but still not much. What it is? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 08:30:16 2012 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 E4CD11065674; Tue, 10 Jul 2012 08:30:16 +0000 (UTC) (envelope-from avleen@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1558FC14; Tue, 10 Jul 2012 08:30:15 +0000 (UTC) Received: by lbon10 with SMTP id n10so21381471lbo.13 for ; Tue, 10 Jul 2012 01:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nts9DYM7KgDeDMwI1sIQ+GaXc8Mt64/nRCR0GE8H974=; b=M28dPCKO8gB5pL7JdjNquIBD7nw6oTBEtUiZytjiIjfSI4ZXvwo+Exiv6SeUu8vKJA ilutFdNiNXkBqn/a+04JTG5BaDGzuLF8Pl6cdBb+BK4p/CM/MaxTrQnw2naPq6RGe+mC EsN/9SL389aOaZKsd0Epqnst7PLgr70W1e3OBQo6oWCWrxERSg5ebaH6e5gMR83XqBPl g6rMNTlNgsib7/9oDKB3cqQnWtq98wquACUxIOA8iz5idXsLOGCgxQ06j6PqOe3d57iH aPkLcM4zOLWY6ZxTkcDlf7O7p0FT8n5/rkl1WnafhWhNN2RJP/stXFeOh1uXdS6ALEk0 lpoA== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr44025090lab.41.1341909014854; Tue, 10 Jul 2012 01:30:14 -0700 (PDT) Received: by 10.112.76.225 with HTTP; Tue, 10 Jul 2012 01:30:14 -0700 (PDT) In-Reply-To: <4FFBD753.6050105@FreeBSD.org> References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <4FFB6D37.1040300@m5p.com> <4FFBD753.6050105@FreeBSD.org> Date: Tue, 10 Jul 2012 01:30:14 -0700 Message-ID: From: Avleen Vig To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 10 Jul 2012 11:15:53 +0000 Cc: freebsd-hackers@freebsd.org, George Mitchell Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 08:30:17 -0000 On Tue, Jul 10, 2012 at 12:18 AM, Doug Barton wrote: >> But I think you are wrong about this one aspect of your >> proposed change. To discover that "dig" is suddenly not in the base >> FreeBSD system any more some day would be just about the worst >> violation of the Principle of Least Astonishment for me in many >> years. > > All flippancy aside, I understand what you're saying here. The problem > is that we can't keep BIND in the base. Given that, we need to look at > how best to handle the transition. This is essentially what I was trying to get at :-) The proposed solution of `dig` and `host` returning "These tools can be installed through the bind-utils port, or you can use `drill`" I think would be sufficient. Having them simply disappear would be terrible, but stubs would make this possibly the least painful thing. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 11:27:51 2012 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 D8F241065672; Tue, 10 Jul 2012 11:27:51 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6228FC24; Tue, 10 Jul 2012 11:27:51 +0000 (UTC) Received: from [192.168.1.21] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id B472157018; Tue, 10 Jul 2012 12:28:38 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Blackman In-Reply-To: <4FFBD5F1.8090803@FreeBSD.org> Date: Tue, 10 Jul 2012 12:27:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <4FFBD5F1.8090803@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , Garrett Wollman , Avleen Vig , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 11:27:51 -0000 On 10 Jul 2012, at 08:12, Doug Barton wrote: > On 07/09/2012 14:47, Mark Blackman wrote: >> I never use '-t' with dig. drill *told* me I should use '-t' >> then completely failed to acknowledge I had done so. > > Have you reported this bug? Nope, you? - Mark From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 12:16:51 2012 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 046841065670; Tue, 10 Jul 2012 12:16:51 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 55C168FC0C; Tue, 10 Jul 2012 12:16:50 +0000 (UTC) Received: by bkcje9 with SMTP id je9so6285352bkc.13 for ; Tue, 10 Jul 2012 05:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GIdrdY0Z/ZpK93YsN0XogYGWXOwSPdI/0Nz0qA70IWc=; b=iFA4pVsHUC6IrLVK1avvgS6TtwQEj6Pv2efjvHYQseo/XTi4Rap1RC4EliJUsx+jM/ auIhuwF/17WfUaKyC8cEqnB1lJqDXSpMhZVXCHOwlUrrRjB4f92LPnULp8WsqsBYGPQW dLzdr6e3ouIvz/Fml3nwsj0O0VAkjl9K2EvipefvpmaDiCzCryH+Big7mSXPNQCU8cg7 0koJ7+tJAdNquiQBDd8jk4o2n5jzM5s838gMdW1E6BA1D1f90G0pABkXHfEBx11zliIh Q4bO5vr1Wd5W5ZvW8jXvoIeu1FbPWdC3LGlpUzA5WdNEymfU0A8Vk4lZNsiHAVuDeGnt uehg== Received: by 10.204.157.18 with SMTP id z18mr21065836bkw.16.1341922609398; Tue, 10 Jul 2012 05:16:49 -0700 (PDT) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id t23sm20389050bks.4.2012.07.10.05.16.46 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 05:16:47 -0700 (PDT) Message-ID: <4FFC1D2D.4020405@gmail.com> Date: Tue, 10 Jul 2012 15:16:45 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120605 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-standards@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 12:16:51 -0000 Hi all. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857 This PR is rather old. I just had submitted new test case, now in plain c. It doesn't work exactly like python version, but the result is the same: > clang test.c > cat test.c | ./a.out -1 916 0 0 0 -1 0 32768 0 0 > ./a.out < test.c -1 916 0 0 0 <- and here we have a complete hang in [kqread]. -- Sphinx of black quartz judge my vow. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 12:40:21 2012 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 A073E1065673 for ; Tue, 10 Jul 2012 12:40:21 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC208FC08 for ; Tue, 10 Jul 2012 12:40:20 +0000 (UTC) Received: by weyx56 with SMTP id x56so1017198wey.13 for ; Tue, 10 Jul 2012 05:40:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=JowOtm290Cd2gEXjzD8xLSpOOJbC646n5k8COqdnzNA=; b=YF0VTZ8Pl6LTjVWOclTFS87oqh2ikHRZU7baafdov8ayDTCQAgeVgJQevoWE5hTpbf dqDPwuVTqllG3WTAri4wcf6wsoRw+O94+tJMJTc0qpyKmOjUXgk/uxK8m4BMuDcJF/9O FfaXVSiXdgAjb4pakGurny9gXmO5c6reGd+OsUAAhJiEBCcbRX3EI4yH0TNGXJpv4hyG Vte3ep3TT5Rl+zEpjVhNIppZdcokdeYcuy52r+ebOwgardpTLQIAIoa3pjnaVODwT/O5 FAYoqu48g/Fv5LsQYckzIGd8D1/DJA2MUqWT+8BzBSrh1XYN6G1Z16eFD2IPOIARKc+g kfqQ== Received: by 10.216.80.29 with SMTP id j29mr1743390wee.121.1341924020078; Tue, 10 Jul 2012 05:40:20 -0700 (PDT) Received: from [10.23.109.123] ([92.90.20.92]) by mx.google.com with ESMTPS id h9sm28707930wiz.1.2012.07.10.05.40.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 05:40:19 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Date: Tue, 10 Jul 2012 14:40:14 +0200 To: Wojciech Puchar X-Gm-Message-State: ALoCoQlJ0smfvmsTtIKsj0CTSmjv/fDFLIOSZra1bsjQB8dr9Ob9cnWrC5jyucWw0F3KjfqDcvy1 Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 12:40:21 -0000 On 10 Jul 2012, at 12:10, Wojciech Puchar w= rote: > this is what i've got from kernel (same visible after dmesg of course) >=20 >=20 > Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4= )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn s= osini ggnsnaalilg n1a1l > Jul 9 08:56:53 .. kernel: 1 > Jul 9 08:56:53 ... kernel: > Jul 9 08:56:53 ... kernel: <<66>>11 > Jul 9 08:56:53 ... kernel: 1 > Jul 9 08:56:53 ... kernel: >=20 > everything before and after seems usual. >=20 > when reading every second letter it SEEMS to make more sense but still not= much. >=20 > What it is? >=20 You're seeing several messages at jumbled together, or your message and othe= r parts of the buffer. Either way, you can see the word "signal" there ;)= From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 13:43:09 2012 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 38ADA1065670; Tue, 10 Jul 2012 13:43:09 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mx1.freebsd.org (Postfix) with ESMTP id B9B818FC12; Tue, 10 Jul 2012 13:43:08 +0000 (UTC) Received: from [78.35.154.206] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SoaiT-0005VQ-IH; Tue, 10 Jul 2012 15:43:01 +0200 Date: Tue, 10 Jul 2012 15:41:28 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20120710154128.192eb8d6@fabiankeil.de> In-Reply-To: <4FFB4770.7050209@FreeBSD.org> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/iioYr4df0X.XEcWMnzauWlK"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@FreeBSD.org, Sean Bruno , rmacklem@FreeBSD.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 13:43:09 -0000 --Sig_/iioYr4df0X.XEcWMnzauWlK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 09/07/2012 22:49 Sean Bruno said the following: > > Ran into some symbol errors with the dtraceall module when using the > > *old* nfs client. > >=20 > > I think that this is more or less the right thing to do, but I'm not > > sure. > >=20 > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > 2011-11-02 23:46:55.000000000 0000 > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > 2011-11-02 23:46:55.000000000 0000 > > @@ -66,8 +66,11 @@ > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > +#if defined (NFSCL) > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > +#else /* defined (NFSCLIENT) */ Any objections to changing this to #elif defined (NFSCLIENT) ? > > MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); > > +#endif > > #if defined(__amd64__) || defined(__i386__) > > MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); > > MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); >=20 > Just to add some noise to the signal - my personal opinion is that nfs su= pport > doesn't have to be in dtraceall. Maybe in something "all-er" :-) I have no opinion on whether or not dtraceall should depend on nfs modules if they are available, but I would prefer it if the dependency was optional. I do not use any nfs modules and the hard-coded dependency made dtraceall useless for me in the past. Unlike Sean I worked around it with a shell function and was too lazy to investigate the cause, though. Fabian --Sig_/iioYr4df0X.XEcWMnzauWlK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/8MQsACgkQBYqIVf93VJ1aoACfXUiqn2FDfrnaOwz1/OxGaw47 8CUAnAoLGJwMPVV0nhcjZWp/q4JpG+XK =a/qv -----END PGP SIGNATURE----- --Sig_/iioYr4df0X.XEcWMnzauWlK-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 14:03:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B185110656D2; Tue, 10 Jul 2012 14:03:17 +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 2A3F98FC16; Tue, 10 Jul 2012 14:03:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6AE2Gud020232; Tue, 10 Jul 2012 17:02:16 +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.5/8.14.5) with ESMTP id q6AE23Z7053140; Tue, 10 Jul 2012 17:02:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6AE23tg053139; Tue, 10 Jul 2012 17:02:03 +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: Tue, 10 Jul 2012 17:02:03 +0300 From: Konstantin Belousov To: Volodymyr Kostyrko Message-ID: <20120710140203.GA2338@deviant.kiev.zoral.com.ua> References: <4FFC1D2D.4020405@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dfOvyYudzT1RPUKx" Content-Disposition: inline In-Reply-To: <4FFC1D2D.4020405@gmail.com> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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-standards@freebsd.org Subject: Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 14:03:17 -0000 --dfOvyYudzT1RPUKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 03:16:45PM +0300, Volodymyr Kostyrko wrote: > Hi all. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/149857 >=20 > This PR is rather old. I just had submitted new test case, now in plain c. >=20 > It doesn't work exactly like python version, but the result is the same: >=20 > > clang test.c > > cat test.c | ./a.out > -1 916 0 0 0 > -1 0 32768 0 0 > > ./a.out < test.c > -1 916 0 0 0 > <- and here we have a complete hang in [kqread]. And what is your expectation ? The vnode filter never returns EOF when current file position at the end of file. It is documented that read filter returns when file offset if not at the end of file, thats all. In fact, EV_EOF is returned on forced unmoun= t. I do not see a bug in kqueue. On the other hand, your C code has at least two things that I cannot understand. First, EV_EOF is output flag, it makes absolutely no sense to set it in command. Second, it is mistery for me what do you check with if (kev.flags >> 15 =3D=3D 1) { test. --dfOvyYudzT1RPUKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/8NdsACgkQC3+MBN1Mb4iTxACgjIyAmfQzKZ1YJhjVqpcDeRtq cggAn1rOw71APAlZ1oyP+vvEyODsPtd2 =2fEs -----END PGP SIGNATURE----- --dfOvyYudzT1RPUKx-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 14:19:12 2012 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 442991065673; Tue, 10 Jul 2012 14:19:12 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8929D8FC08; Tue, 10 Jul 2012 14:19:11 +0000 (UTC) Received: by bkcje9 with SMTP id je9so27130bkc.13 for ; Tue, 10 Jul 2012 07:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7cl94lUV0C9EuGhkijqh6yxKuWV1HeaAx6GeJ2VLgZA=; b=r81FAZIXoHlVFT7bsuDxwRMf9WEV7G0LfTJY5bQ3xx4jDwUnAZYsxGY9p5NfvdXjun slztlJGxMMkQK2KxscmzjNjepEf3i5x0bNmjGBqqDOjxjGZH42Mkx/dPUw81oT/YP4Xd uK4wAS78YUAsAhilHH8HroE/vwD2h+KrYccU37P/9SLKLmKM8cBlvA/sWTx3LCi3iqkI 513xxT8LQsOjLmRPMFXiSQCYSp59g8itfwkxZb1BvAnrXYR345XfOax/PdX7rQSELiGh OxcubGbCI4mD2KDYCob6cHq5X4VwUXQPsb9MdoXumjqia0ckqcYaQ72zoBkwBX50dl5p Kd2w== Received: by 10.204.154.85 with SMTP id n21mr2982912bkw.48.1341929950342; Tue, 10 Jul 2012 07:19:10 -0700 (PDT) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id hs2sm28383879bkc.1.2012.07.10.07.19.07 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:19:08 -0700 (PDT) Message-ID: <4FFC39D9.6080809@gmail.com> Date: Tue, 10 Jul 2012 17:19:05 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120605 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FFC1D2D.4020405@gmail.com> <20120710140203.GA2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120710140203.GA2338@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-standards@FreeBSD.org Subject: Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 14:19:12 -0000 Konstantin Belousov wrote: >> This PR is rather old. I just had submitted new test case, now in plain c. >> >> It doesn't work exactly like python version, but the result is the same: >> >>> clang test.c >>> cat test.c | ./a.out >> -1 916 0 0 0 >> -1 0 32768 0 0 >>> ./a.out< test.c >> -1 916 0 0 0 >> <- and here we have a complete hang in [kqread]. > > And what is your expectation ? > > The vnode filter never returns EOF when current file position at the end > of file. It is documented that read filter returns when file offset if not > at the end of file, thats all. In fact, EV_EOF is returned on forced unmount. > I do not see a bug in kqueue. > > On the other hand, your C code has at least two things that I cannot > understand. First, EV_EOF is output flag, it makes absolutely no sense > to set it in command.Second, it is mistery for me what do you check with > if (kev.flags>> 15 == 1) { > test. EV_EOF on line 19 actually slipped by my fault, original source omits that one. It doesn't change anything. EV_EOF = 1 << 15 = 32768. And it _is_ returned when file is feed with the pipe. So you mean this is just my false assumption that EOF _should_ occur on stdin? And it actually occurs only if source is a process which can send EOF? -- Sphinx of black quartz judge my vow. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 14:27:54 2012 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 DE070106564A; Tue, 10 Jul 2012 14:27:53 +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 603488FC15; Tue, 10 Jul 2012 14:27:53 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6AERxKN021974; Tue, 10 Jul 2012 17:27:59 +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.5/8.14.5) with ESMTP id q6AERkmh053337; Tue, 10 Jul 2012 17:27:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6AERk6p053336; Tue, 10 Jul 2012 17:27: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: Tue, 10 Jul 2012 17:27:46 +0300 From: Konstantin Belousov To: Volodymyr Kostyrko Message-ID: <20120710142746.GD2338@deviant.kiev.zoral.com.ua> References: <4FFC1D2D.4020405@gmail.com> <20120710140203.GA2338@deviant.kiev.zoral.com.ua> <4FFC39D9.6080809@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YTqNa7If1bmePjLb" Content-Disposition: inline In-Reply-To: <4FFC39D9.6080809@gmail.com> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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-standards@freebsd.org Subject: Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 14:27:54 -0000 --YTqNa7If1bmePjLb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 05:19:05PM +0300, Volodymyr Kostyrko wrote: > Konstantin Belousov wrote: > >>This PR is rather old. I just had submitted new test case, now in plain= c. > >> > >>It doesn't work exactly like python version, but the result is the same: > >> > >>>clang test.c > >>>cat test.c | ./a.out > >>-1 916 0 0 0 > >>-1 0 32768 0 0 > >>>./a.out< test.c > >>-1 916 0 0 0 > >><- and here we have a complete hang in [kqread]. > > > >And what is your expectation ? > > > >The vnode filter never returns EOF when current file position at the end > >of file. It is documented that read filter returns when file offset if n= ot > >at the end of file, thats all. In fact, EV_EOF is returned on forced=20 > >unmount. > >I do not see a bug in kqueue. > > > >On the other hand, your C code has at least two things that I cannot > >understand. First, EV_EOF is output flag, it makes absolutely no sense > >to set it in command.Second, it is mistery for me what do you check with > > if (kev.flags>> 15 =3D=3D 1) { > >test. >=20 > EV_EOF on line 19 actually slipped by my fault, original source omits=20 > that one. It doesn't change anything. Yes. >=20 > EV_EOF =3D 1 << 15 =3D 32768. And it _is_ returned when file is feed with= =20 > the pipe. >=20 > So you mean this is just my false assumption that EOF _should_ occur on= =20 > stdin? And it actually occurs only if source is a process which can send= =20 > EOF? 'Source' cannot be a process. Read filter on pipes can return EV_EOF. Read filter on vnodes (read: regular files) does not return EV_EOF, except in situation that is created by manual intervention of administrator. It should have been clear from my previous response. --YTqNa7If1bmePjLb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/8O+IACgkQC3+MBN1Mb4ia3gCdFAvD2rv3oCQuQQJ+PyM7H4my YhQAoPKslmosOliJkgVQUOu1TgIJfULV =0aSI -----END PGP SIGNATURE----- --YTqNa7If1bmePjLb-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 14:36:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8A8D1065677 for ; Tue, 10 Jul 2012 14:36:51 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 1084B8FC19 for ; Tue, 10 Jul 2012 14:36:50 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6AEajY6001447; Tue, 10 Jul 2012 16:36:45 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6AEaj27001444; Tue, 10 Jul 2012 16:36:45 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 10 Jul 2012 16:36:44 +0200 (CEST) From: Wojciech Puchar To: Damien Fleuriot In-Reply-To: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> Message-ID: References: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 10 Jul 2012 16:36:45 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 14:36:51 -0000 On Tue, 10 Jul 2012, Damien Fleuriot wrote: > > On 10 Jul 2012, at 12:10, Wojciech Puchar wrote: > >> this is what i've got from kernel (same visible after dmesg of course) >> >> >> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn sosini ggnsnaalilg n1a1l >> Jul 9 08:56:53 .. kernel: 1 >> Jul 9 08:56:53 ... kernel: >> Jul 9 08:56:53 ... kernel: <<66>>11 >> Jul 9 08:56:53 ... kernel: 1 >> Jul 9 08:56:53 ... kernel: >> >> everything before and after seems usual. >> >> when reading every second letter it SEEMS to make more sense but still not much. >> >> What it is? >> > > You're seeing several messages at jumbled together, or your message and other parts of the buffer. > > Either way, you can see the word "signal" there ;) > i think it was httpd (probably PHP trash) crashed with sig11 but want to be sure. httpd rarely do crash... Strange i have ports rather up to date and no KNOWN vulnerabilities are according to portaudit output. how can i prevent mixing kernel messages? i have options PRINTF_BUFR_SIZE=256 # Prevent printf output being interspersed. in kernel config From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 14:59:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58EB01065674 for ; Tue, 10 Jul 2012 14:59:31 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id E8DF38FC19 for ; Tue, 10 Jul 2012 14:59:30 +0000 (UTC) Received: (qmail 1122 invoked from network); 10 Jul 2012 10:59:30 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 10 Jul 2012 10:59:30 -0400 Message-ID: <4FFC0B23.1010404@shadowsun.net> Date: Tue, 10 Jul 2012 10:59:47 +0000 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120704 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Clang, EFI and bad offsets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 14:59:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the process of the EFI on intel work, I ran across a strange issue. The procedure for creating loader.efi goes something like this: 1) compile to ELF object files 2) generate an ELF executable with -Bsymbolic and a custom linker script that puts everything starting at 0x1000, and also appends some kind of data to the end of symbols (you can find this in sys/boot/i386/efi) 3) use objcopy to convert to PE format (BFD is ia32-efi-app) However, using clang for any of this seems to result in bad jump offsets being generated, which will cause the resulting program to fail. I haven't done a thorough investigation of the issues yet, but I wanted to bring it up to see if anyone has seen something similar, or has any insights. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJP/AsiAAoJENSCzbQ+koZ72N8QAL8zA/0MaHXkLpwTlNiEOZ5m a+73QS2O/uVw/Tsfge/yEcrJdXjGT0YmfmvTEKQPVSmMiZRf8KbG4FQYBKgWTHlO I/Thkw2JRj0iJOlhgp7VyOFpcLHyEdWDsst1D4Y5332j9dEa+JkIqtVTjwefSBbY OcoRkQ9Zznu3vF98BKmn1JTxdKASPMrELs5HMQ3GZop6/FMV8+SBdTFst/gvO1Wg Loe6S2IDMkcaXGYNSBrdqjkJY06wg2oSivlb44/DsSRzQSfKTkSBZ2i3r+LIUv13 cu0XFejjLd2mSPUkSgPGMwTu+PuScGY8Xe8kskJPl+F9NFzxeEdCUbYbpv8HoTJG 3xCXSun5CbkPwfSIfprUS59mAN7sBqWIOzeI5HDeboZv0WL1+7PfUJB27nAINg/D 3MocooMAZHrqsCADlsdgKrodvGp0ccG0vwrfsajho+/69JhNzRbOgllGp2Meqwfy npVBToxVrs7LtcYXkBsyshN3I9GBIjjtR+Ryn5KLCG7xJTvLP0XuYrn4XcNNXjBI ewMRCgUgdlhoS1vPItnmDkYPiIrb5SgowJSZ6Nzd/es7pTdLzRKYXkWzlTNwqY3z TtJLhzebrjfHDArvL2kHvIempyGda+ED4k4W0Ubr8Owzd1WJhRGEhgwVAeJ0hFnO CJOy14wJK32mVr2KFEjG =y2ee -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 15:02:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22EFB1065781; Tue, 10 Jul 2012 15:02:56 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1058FC14; Tue, 10 Jul 2012 15:02:55 +0000 (UTC) Received: by bkcje9 with SMTP id je9so85958bkc.13 for ; Tue, 10 Jul 2012 08:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RZRfuKFOwkFeC+V3NRXnWkIWY8zwesP6dII6YQlflVQ=; b=pfOLyD2FV8tpn6Ye4y0Yx4Wz0zn/iJ1g3UtmGCc1Ag1aBTXebaNvJ7bo6BRaXa8bVX 7S3E84knOCv8OcEz/4GsDsInlllEGiZa0TrJiD7jol341WPRRSzokcygbk/PGK4mrHwq IhiW+zbLlDhz8O0TZP5F951M4O+TCXa7t2nr1t/ikN6SfzLHCtbHWStsSVSOJcRiftRl 8FPlknSWZI25GPBk9gjKfw8tGE9DuMnt1R7r0kceLwCFEyr6TPmyUQbhrK/TGyrDC1mj RWPjqLxRuT5i0BU97i0UKtNZ6wMHJQLJWteXoeMyqxdZHh71e/RZxl5V1HZu2UymZgxk /DTA== Received: by 10.205.128.141 with SMTP id he13mr15452938bkc.112.1341932574438; Tue, 10 Jul 2012 08:02:54 -0700 (PDT) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id t23sm20751813bks.4.2012.07.10.08.02.51 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 08:02:53 -0700 (PDT) Message-ID: <4FFC441A.2010500@gmail.com> Date: Tue, 10 Jul 2012 18:02:50 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120605 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FFC1D2D.4020405@gmail.com> <20120710140203.GA2338@deviant.kiev.zoral.com.ua> <4FFC39D9.6080809@gmail.com> <20120710142746.GD2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120710142746.GD2338@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-standards@freebsd.org Subject: Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 15:02:56 -0000 Konstantin Belousov wrote: >> So you mean this is just my false assumption that EOF _should_ occur on >> stdin? And it actually occurs only if source is a process which can send >> EOF? > > 'Source' cannot be a process. Read filter on pipes can return EV_EOF. > Read filter on vnodes (read: regular files) does not return EV_EOF, > except in situation that is created by manual intervention of > administrator. This keeps me puzzled. How then I can tell that file at stdin is already at EOF? You mean I should treat stdin like normal vnode-backed file? off_t pos = 0, endpos; lseek(fileno(stdin), 0, SEEK_END); endpos = ftell(stdin); lseek(fileno(stdin), 0, SEEK_SET); ... and then later check it with: if(endpos != -1) { pos += kev.data; if(pos >= endpos) { printf("end reached\n"); return(0); } } Is this a correct way to detect EOF? I'm letting besides that I should also detect vnode changes and update max file size accordingly. > It should have been clear from my previous response. Please excuse me, I'm a bit new to this things... -- Sphinx of black quartz judge my vow. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 15:06:42 2012 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 0B1D2106566B for ; Tue, 10 Jul 2012 15:06:42 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id CCF758FC0A for ; Tue, 10 Jul 2012 15:06:41 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Tue, 10 Jul 2012 09:54:12 -0500 From: Paul Albrecht To: freebsd-hackers@freebsd.org Content-Type: text/plain Date: Tue, 10 Jul 2012 10:03:08 -0500 Message-ID: <1341932588.6997.6.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 15:06:42 -0000 Hi, I have a question about the kqueue timer timeout period ... what's data supposed to be? I thought it was supposed to be the period in milliseconds, but I seem to off by one. For example, if I set date (the timeout period) to 20 milliseconds, I often wait 21 milliseconds which is very undesirable for my application. -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 15:07:44 2012 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 64D101065670 for ; Tue, 10 Jul 2012 15:07:44 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE62D8FC17 for ; Tue, 10 Jul 2012 15:07:43 +0000 (UTC) Received: by eeke49 with SMTP id e49so44409eek.13 for ; Tue, 10 Jul 2012 08:07:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=XRskkl+RaQQDNHSO/qNVj05vCKthVI8ltIkaC7rAEFU=; b=jepNusOJBTdqUuSObQFcYv9FoApKva8AM8DDcAS48lQAZ6XKCMLBkaHyPEnddXGzKY 5JY3HqGwOCn1XzgWCbSFaoWECxgLnoN0LoAdO7NPopdXOyoYA+U6DJorb0MfjgTwX3RW 7MfRn4CTS8igREvQzFFPBKQzSRETJko1jsZ2bUvmgbEvT0LQS1/bd2wJX1akWxBATUqC 2W5EprbhKsRQnhdSbcTqAWT8YIebuGJfEYV2K5OtJvqpbzBvdhAwEDuNWyR/eMgKBAUO uHStPnELCdJdL3cUIm4CobGHqhAsKZvFlUMbie3y14waw3OvtV+R7qNTBjElGcKOnQ0o TV4A== Received: by 10.14.22.69 with SMTP id s45mr11016183ees.82.1341932862850; Tue, 10 Jul 2012 08:07:42 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id a4sm96088564een.14.2012.07.10.08.07.41 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 08:07:41 -0700 (PDT) Message-ID: <4FFC453B.2080105@my.gd> Date: Tue, 10 Jul 2012 17:07:39 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Wojciech Puchar References: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl6NThgNNTjwNKBjyL7Jdb2N6+vdyQWJAuQM+sW4j2PkX+p3wn8Ewjl0ay5HvROBfrXdriK Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 15:07:44 -0000 On 7/10/12 4:36 PM, Wojciech Puchar wrote: > > > On Tue, 10 Jul 2012, Damien Fleuriot wrote: > >> >> On 10 Jul 2012, at 12:10, Wojciech Puchar >> wrote: >> >>> this is what i've got from kernel (same visible after dmesg of course) >>> >>> >>> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 >>> ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex >>> die txoiedtn eo dn sosini ggnsnaalilg n1a1l >>> Jul 9 08:56:53 .. kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> Jul 9 08:56:53 ... kernel: <<66>>11 >>> Jul 9 08:56:53 ... kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> >>> everything before and after seems usual. >>> >>> when reading every second letter it SEEMS to make more sense but >>> still not much. >>> >>> What it is? >>> >> >> You're seeing several messages at jumbled together, or your message >> and other parts of the buffer. >> >> Either way, you can see the word "signal" there ;) >> > i think it was httpd (probably PHP trash) crashed with sig11 but want to > be sure. > > httpd rarely do crash... Strange i have ports rather up to date and no > KNOWN vulnerabilities are according to portaudit output. > > how can i prevent mixing kernel messages? > > i have > > options PRINTF_BUFR_SIZE=256 # Prevent printf output being > interspersed. > > in kernel config Regarding the mixing of kernel messages I'm afraid I won't be able to help with that. Regarding your HTTPd dying, I've also experienced signal 11 quits when I was using apache and PHP as a module. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 15:22:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 562B9106566C; Tue, 10 Jul 2012 15:22:15 +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 CD1A48FC14; Tue, 10 Jul 2012 15:22:14 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6AFMLXA027827; Tue, 10 Jul 2012 18:22:21 +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.5/8.14.5) with ESMTP id q6AFM8r7053679; Tue, 10 Jul 2012 18:22:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6AFM8Hn053678; Tue, 10 Jul 2012 18:22:08 +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: Tue, 10 Jul 2012 18:22:08 +0300 From: Konstantin Belousov To: Volodymyr Kostyrko Message-ID: <20120710152208.GF2338@deviant.kiev.zoral.com.ua> References: <4FFC1D2D.4020405@gmail.com> <20120710140203.GA2338@deviant.kiev.zoral.com.ua> <4FFC39D9.6080809@gmail.com> <20120710142746.GD2338@deviant.kiev.zoral.com.ua> <4FFC441A.2010500@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZSoWtPk5XaIUnOQI" Content-Disposition: inline In-Reply-To: <4FFC441A.2010500@gmail.com> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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-standards@freebsd.org Subject: Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 15:22:15 -0000 --ZSoWtPk5XaIUnOQI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 06:02:50PM +0300, Volodymyr Kostyrko wrote: > Konstantin Belousov wrote: > >>So you mean this is just my false assumption that EOF _should_ occur on > >>stdin? And it actually occurs only if source is a process which can send > >>EOF? > > > >'Source' cannot be a process. Read filter on pipes can return EV_EOF. > >Read filter on vnodes (read: regular files) does not return EV_EOF, > >except in situation that is created by manual intervention of > >administrator. >=20 > This keeps me puzzled. How then I can tell that file at stdin is already= =20 > at EOF? You mean I should treat stdin like normal vnode-backed file? >=20 > off_t pos =3D 0, endpos; >=20 > lseek(fileno(stdin), 0, SEEK_END); > endpos =3D ftell(stdin); > lseek(fileno(stdin), 0, SEEK_SET); >=20 > ... and then later check it with: >=20 > if(endpos !=3D -1) { > pos +=3D kev.data; > if(pos >=3D endpos) { > printf("end reached\n"); > return(0); > } > } >=20 > Is this a correct way to detect EOF? I'm letting besides that I should=20 > also detect vnode changes and update max file size accordingly. >=20 > >It should have been clear from my previous response. >=20 > Please excuse me, I'm a bit new to this things... Why do you use kqueue there at all ? Just read from stdin, and decide that you hit EOF when read returned 0 bytes. If insisting on using kqueue, which may be ligitimate if you process other sources besides stdin, you should first investigate the nature of the fd 0 using fstat, and then use appropriate code for regular file, pipe and probably socket (e.g. for the case if code allows to run under inetd(8)). --ZSoWtPk5XaIUnOQI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/8SJwACgkQC3+MBN1Mb4jqSgCdHgVPqhHwmfHo6xP3bSVIj7LU OoIAnRa30uNLPclEEcXgk17m6VXbU7JG =c8s9 -----END PGP SIGNATURE----- --ZSoWtPk5XaIUnOQI-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 15:30:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF396106564A for ; Tue, 10 Jul 2012 15:30:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 678928FC12 for ; Tue, 10 Jul 2012 15:30:57 +0000 (UTC) Received: by ghbz22 with SMTP id z22so121679ghb.13 for ; Tue, 10 Jul 2012 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rLgijPU9LIhPLwu7n1km3eBP8FWv/pgCO3fEEY4jc8=; b=OdQXZWxhqZ2mZyDgI4onSJY3DE5OjDZi6MzsO/4WDUfuCCmakaLwACK0FmNZu9ebWb 3iA3aNhn3lrs9ekxUuicanOp1UlK9yorDJNAXSuFf7TU0p6Q0JpgyVfiCqgfz3e4X/yG 1Ocz2s4fT9oWOa6bE39JwVaZEktkaUKjMSYCtBYcKdjPt7KiF1prTmS6fapIKn3mClJU mQX+GjJmU456tHJqQxxxHia1kjvQRIJs2fWQoyZJAI7s79s7rUXXiPHqQ4kB7prndqKP cIt90ZY3YBIJEkMfe3BmFf8mM1yg/H1De6BAXi6VXj9lpfVOxtCQtg19jKuGpVKmJGNP KkWQ== MIME-Version: 1.0 Received: by 10.60.3.102 with SMTP id b6mr46492488oeb.35.1341934250784; Tue, 10 Jul 2012 08:30:50 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 08:30:50 -0700 (PDT) In-Reply-To: References: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> Date: Tue, 10 Jul 2012 08:30:50 -0700 Message-ID: From: Garrett Cooper To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 15:30:57 -0000 On Tue, Jul 10, 2012 at 7:36 AM, Wojciech Puchar wrote: > > > On Tue, 10 Jul 2012, Damien Fleuriot wrote: > >> >> On 10 Jul 2012, at 12:10, Wojciech Puchar >> wrote: >> >>> this is what i've got from kernel (same visible after dmesg of course) >>> >>> >>> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 >>> ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die >>> txoiedtn eo dn sosini ggnsnaalilg n1a1l >>> Jul 9 08:56:53 .. kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> Jul 9 08:56:53 ... kernel: <<66>>11 >>> Jul 9 08:56:53 ... kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> >>> everything before and after seems usual. >>> >>> when reading every second letter it SEEMS to make more sense but still >>> not much. >>> >>> What it is? >>> >> >> You're seeing several messages at jumbled together, or your message and >> other parts of the buffer. >> >> Either way, you can see the word "signal" there ;) >> > i think it was httpd (probably PHP trash) crashed with sig11 but want to be > sure. > > httpd rarely do crash... Strange i have ports rather up to date and no KNOWN > vulnerabilities are according to portaudit output. > > how can i prevent mixing kernel messages? > > i have > > options PRINTF_BUFR_SIZE=256 # Prevent printf output being > interspersed. > > in kernel config Increasing that value [to 1k, 2k, etc] will help at the cost of some more memory usage, but it won't fix the problem. The issue should be less prominent in 9.x+. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 16:22:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CC92E1065673 for ; Tue, 10 Jul 2012 16:22:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0AF3315826E; Tue, 10 Jul 2012 16:22:50 +0000 (UTC) Message-ID: <4FFC56DA.3090208@FreeBSD.org> Date: Tue, 10 Jul 2012 09:22:50 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Blackman References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <20472.51031.308284.775990@hergotha.csail.mit.edu> <4FF8C890.9030408@FreeBSD.org> <4FFA7174.7050604@FreeBSD.org> <4FFA7980.4000707@FreeBSD.org> <4FFB46A4.5050504@FreeBSD.org> <1E29121E-62B1-4929-BB7B-4FCA5D893F51@exonetric.com> <86a9z8mxa1.fsf@ds4.des.no> <8D942592-3662-4FBA-BA61-2A010452BF70@exonetric.com> <4FFBD5F1.8090803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers , Garrett Wollman , Avleen Vig , "Bjoern A. Zeeb" Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 16:22:51 -0000 On 7/10/2012 4:27 AM, Mark Blackman wrote: > On 10 Jul 2012, at 08:12, Doug Barton wrote: > >> On 07/09/2012 14:47, Mark Blackman wrote: >>> I never use '-t' with dig. drill *told* me I should use '-t' >>> then completely failed to acknowledge I had done so. >> >> Have you reported this bug? > > Nope, you? I'm not the one bothered by it. :) -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 17:02:09 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 407E3106564A; Tue, 10 Jul 2012 17:02:09 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id E9DA08FC0C; Tue, 10 Jul 2012 17:02:08 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6AH0un7009786; Tue, 10 Jul 2012 10:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1341939658; bh=SefkWQ+qssDMfaF/s2AWGWcW2JeI68oq1zkOALIpvGc=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=emWve+pg8NxcS+xxixSICI4nT/pQqW7xQWVsF7d6wkSKezkqzBXA0EaFkdlLCCMSZ su1uSu5SXJ97fcBdBVME5TMIzeUoqkuVtBIRQ7gjP7evqafV2lKwb4z+Vepw06Tmym Mvli0f3QDEBy7+IKivBewaGYdL5Og4vFNo7wNE8E= From: Sean Bruno To: Fabian Keil In-Reply-To: <20120710154128.192eb8d6@fabiankeil.de> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Jul 2012 09:52:35 -0700 Message-ID: <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 939657002 Cc: "freebsd-hackers@FreeBSD.org" , Sean Bruno , Andriy Gapon , "rmacklem@FreeBSD.org" Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 17:02:09 -0000 On Tue, 2012-07-10 at 06:41 -0700, Fabian Keil wrote: > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.000000000 0000 > > > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.000000000 0000 > > > @@ -66,8 +66,11 @@ > > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > > +#if defined (NFSCL) > > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > > +#else /* defined (NFSCLIENT) */ > > Any objections to changing this to > #elif defined (NFSCLIENT) > ? No objections here. I suspect that this is the more correct thing regardless. I mean, it keeps the nfs dtrace objects loading in the event someone is running a non-nfs kernel... right? Sean From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 18:23:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8745D1065672 for ; Tue, 10 Jul 2012 18:23:35 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id E801F8FC0C for ; Tue, 10 Jul 2012 18:23:34 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6AINTpO044219; Tue, 10 Jul 2012 20:23:29 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6AINSLa044216; Tue, 10 Jul 2012 20:23:29 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 10 Jul 2012 20:23:28 +0200 (CEST) From: Wojciech Puchar To: Damien Fleuriot In-Reply-To: <4FFC453B.2080105@my.gd> Message-ID: References: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> <4FFC453B.2080105@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 10 Jul 2012 20:23:29 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 18:23:35 -0000 > > Regarding your HTTPd dying, I've also experienced signal 11 quits when I > was using apache and PHP as a module. > yes they are rare and just apache serving process dies, not master process. All works fine but i am concerned about security... Oh well i wasn't the one that chose PHP, it is needed to run already written program... And any error would not hit any more than WWW server, but still i am quite concerned From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 18:25:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC24C1065672 for ; Tue, 10 Jul 2012 18:25:59 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 26FC48FC15 for ; Tue, 10 Jul 2012 18:25:58 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6AIPs0p044233; Tue, 10 Jul 2012 20:25:54 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6AIPsrP044230; Tue, 10 Jul 2012 20:25:54 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 10 Jul 2012 20:25:53 +0200 (CEST) From: Wojciech Puchar To: Garrett Cooper In-Reply-To: Message-ID: References: <2E148ED4-F2E6-4B3D-99D8-C84E4E11F0F4@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 10 Jul 2012 20:25:54 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: kernel: abra-kadabra X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 18:25:59 -0000 >> interspersed. >> >> in kernel config > > Increasing that value [to 1k, 2k, etc] will help at the cost of changed to 4K thanks > some more memory usage, but it won't fix the problem. The issue should > be less prominent in 9.x+. > HTH, > -Garrett > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 18:57:58 2012 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 67FDB106564A; Tue, 10 Jul 2012 18:57:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by mx1.freebsd.org (Postfix) with ESMTP id E8DA58FC1B; Tue, 10 Jul 2012 18:57:57 +0000 (UTC) Received: from [78.35.154.206] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Sofch-0002ML-Jh; Tue, 10 Jul 2012 20:57:23 +0200 Date: Tue, 10 Jul 2012 20:57:02 +0200 From: Fabian Keil To: Sean Bruno Message-ID: <20120710205702.5e57168b@fabiankeil.de> In-Reply-To: <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/uZuc8esXT5IFMib.zSl9_Cl"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon , rmacklem@FreeBSD.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 18:57:58 -0000 --Sig_/uZuc8esXT5IFMib.zSl9_Cl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sean Bruno wrote: > On Tue, 2012-07-10 at 06:41 -0700, Fabian Keil wrote: > > > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > > 2011-11-02 23:46:55.000000000 0000 > > > > > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > > 2011-11-02 23:46:55.000000000 0000 > > > > @@ -66,8 +66,11 @@ > > > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > > > +#if defined (NFSCL) > > > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > > > +#else /* defined (NFSCLIENT) */ > >=20 > > Any objections to changing this to > > #elif defined (NFSCLIENT) > > ?=20 >=20 > No objections here. I suspect that this is the more correct thing > regardless. I mean, it keeps the nfs dtrace objects loading in the > event someone is running a non-nfs kernel... right? I do not use a completely NFS-free kernel, but I don't build any NFS-related modules. Trying to load an unpatched dtraceall results in: Jul 9 21:58:48 r500 sudo: fk : TTY=3Dpts/16 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD dtnfsclient.ko: depends on oldnfs -= not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclien= t - not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type My assumption was that your patch and the "#elif defined (NFSCLIENT)" would fix that, and indeed it does, but I later on realized that I actually do have NFSCL in the kernel: fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL My impression is that the patch is missing an opt_nfs.h inclusion combined with the Makefile voodoo to create the file. The dtraceall module already has an opt_compat.h, even though the Makefile logic to create it seems a bit dubious to me. It blindly assumes that COMPAT_FREEBSD32 is available on amd64. Fabian --Sig_/uZuc8esXT5IFMib.zSl9_Cl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/8ewIACgkQBYqIVf93VJ3NOQCePiqna0WCGP5D19bJyLfjjhMX 8N0Ani1xB5WcjwiRy1DcsZ7ZtAG3xHrn =W44H -----END PGP SIGNATURE----- --Sig_/uZuc8esXT5IFMib.zSl9_Cl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 10 19:37:41 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 726FC106566C; Tue, 10 Jul 2012 19:37:41 +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 565C98FC0A; Tue, 10 Jul 2012 19:37:40 +0000 (UTC) Received: from porto.starpoint.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 WAA23514; Tue, 10 Jul 2012 22:37:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SogFX-000P5q-ET; Tue, 10 Jul 2012 22:37:31 +0300 Message-ID: <4FFC8479.9080608@FreeBSD.org> Date: Tue, 10 Jul 2012 22:37:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> In-Reply-To: <20120710205702.5e57168b@fabiankeil.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Sean Bruno , rmacklem@FreeBSD.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Jul 2012 19:37:41 -0000 on 10/07/2012 21:57 Fabian Keil said the following: > I do not use a completely NFS-free kernel, but I don't build any > NFS-related modules. Trying to load an unpatched dtraceall results in: > > Jul 9 21:58:48 r500 sudo: fk : TTY=pts/16 ; PWD=/home/fk ; USER=root > ; COMMAND=/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD > dtnfsclient.ko: depends on oldnfs - not available or version mismatch Jul > 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul > 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient - > not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] > linker_load_file: Unsupported file type > > My assumption was that your patch and the "#elif defined (NFSCLIENT)" would > fix that, and indeed it does, but I later on realized that I actually do > have NFSCL in the kernel: > > fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options > NFSLOCKD options NFSD options NFSCL > > My impression is that the patch is missing an opt_nfs.h inclusion combined > with the Makefile voodoo to create the file. > > The dtraceall module already has an opt_compat.h, even though the Makefile > logic to create it seems a bit dubious to me. It blindly assumes that > COMPAT_FREEBSD32 is available on amd64. Not sure if I got correctly what the (perceived) problem actually is, but I have this to say: the proper way of building a module is either via buildkernel (MODULES_OVERRIDE, etc) or by using KERNBUILDDIR for "independent" module build if the module has any dependency on kernel options in effect. This could be a little bit sad (for third-party module providers), but this seems to be true. Sometimes Makefile-s fake kernel options for truly independent module build (no KERNBUILDDIR) to provide the widest and/or safest feature set. But this has to be done very carefully to ensure that module<->kernel*s* compatibility actually occurs. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 01:53:34 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEE411065670; Wed, 11 Jul 2012 01:53:34 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 74B9F8FC0C; Wed, 11 Jul 2012 01:53:34 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q6B1rSD2066245; Tue, 10 Jul 2012 21:53:33 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <4FFCDC98.5070704@m5p.com> Date: Tue, 10 Jul 2012 21:53:28 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <4FF18216.3070207@m5p.com> <4FF204B8.7020804@FreeBSD.org> In-Reply-To: <4FF204B8.7020804@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 10 Jul 2012 21:53:33 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Browsing over IPv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 01:53:34 -0000 On 07/02/12 16:29, Doug Barton wrote: > On 07/02/2012 04:12, George Mitchell wrote: > >> I've been using IPv6 for quite a few years without problems and I've >> had no difficulty browsing > > Many more sites are actually putting, or have put, IPv6 into production > since the latest world IPv6 day last month. Some growing pains are > inevitable. > > Doug > This problem may be here in FreeBSD. Here's my setup: Me <--ethernet, MTU1500, native IPv6--> mattapan <-| | World <-- v6 in v4 tunnel, gif0, MTU1280-----------| (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts working again. Should this be necessary? -- George From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 02:07:29 2012 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 3A9191065670 for ; Wed, 11 Jul 2012 02:07:29 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id E2D968FC16 for ; Wed, 11 Jul 2012 02:07:28 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q6B27MfZ066372 for ; Tue, 10 Jul 2012 22:07:27 -0400 (EDT) (envelope-from george@m5p.com) Message-ID: <4FFCDFDA.60704@m5p.com> Date: Tue, 10 Jul 2012 22:07:22 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FF18216.3070207@m5p.com> <4FF204B8.7020804@FreeBSD.org> <4FFCDC98.5070704@m5p.com> In-Reply-To: <4FFCDC98.5070704@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 10 Jul 2012 22:07:28 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 X-Mailman-Approved-At: Wed, 11 Jul 2012 02:15:43 +0000 Subject: Re: Browsing over IPv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 02:07:29 -0000 On 07/10/12 21:53, George Mitchell wrote: > On 07/02/12 16:29, Doug Barton wrote: >> On 07/02/2012 04:12, George Mitchell wrote: >> >>> I've been using IPv6 for quite a few years without problems and I've >>> had no difficulty browsing >> >> Many more sites are actually putting, or have put, IPv6 into production >> since the latest world IPv6 day last month. Some growing pains are >> inevitable. >> >> Doug >> > > This problem may be here in FreeBSD. Here's my setup: > > Me <--ethernet, MTU1500, native IPv6--> mattapan <-| > | > World <-- v6 in v4 tunnel, gif0, MTU1280-----------| > > (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) > If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts > working again. Should this be necessary? -- George It turns out I can change /etc/rc.conf from: ipv6_defaultrouter="2001:418:3fd::fd" to: ipv6_defaultrouter="2001:418:3fd::fd -mtu 1280" and "fix" the problem. -- George From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 06:03:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9834D106566C; Wed, 11 Jul 2012 06:03:02 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 09B728FC16; Wed, 11 Jul 2012 06:03:00 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6B62tOr062174; Wed, 11 Jul 2012 08:02:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6B62tkx062171; Wed, 11 Jul 2012 08:02:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 11 Jul 2012 08:02:55 +0200 (CEST) From: Wojciech Puchar To: George Mitchell In-Reply-To: <4FFCDC98.5070704@m5p.com> Message-ID: References: <4FF18216.3070207@m5p.com> <4FF204B8.7020804@FreeBSD.org> <4FFCDC98.5070704@m5p.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 11 Jul 2012 08:02:55 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: Browsing over IPv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 06:03:02 -0000 > > Me <--ethernet, MTU1500, native IPv6--> mattapan <-| > | > World <-- v6 in v4 tunnel, gif0, MTU1280-----------| > > (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) > If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts > working again. Should this be necessary? -- George ICMP6 control packets aren't blocked? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 07:50:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75E26106568A for ; Wed, 11 Jul 2012 07:50:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id ED3AD8FC08 for ; Wed, 11 Jul 2012 07:50:53 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6B7opWk064931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 17:50:51 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6B7ojX9010521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 17:50:45 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6B7ojeb010520; Wed, 11 Jul 2012 17:50:45 +1000 (EST) (envelope-from peter) Date: Wed, 11 Jul 2012 17:50:45 +1000 From: Peter Jeremy To: Paul Albrecht Message-ID: <20120711075044.GA10224@server.rulingia.com> References: <1341932588.6997.6.camel@albrecht-desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <1341932588.6997.6.camel@albrecht-desktop> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 07:50:54 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: >I have a question about the kqueue timer timeout period ... what's data >supposed to be? I thought it was supposed to be the period in >milliseconds, but I seem to off by one. > >For example, if I set date (the timeout period) to 20 milliseconds, I >often wait 21 milliseconds which is very undesirable for my application. FreeBSD is not a real-time OS. The timeouts specified in various syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) specify minimum timeouts. Once the timeout (rounded up to the next tick) has expired, the process will be placed back into the queue of processes eligible to be run by the scheduler - which may impose a further arbitrary delay. Periodic timers are somewhat better behaved: Scheduler delays only impact process scheduling after the timeout expires and the average rate should be very close to that requested. --=20 Peter Jeremy --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/9MFQACgkQ/opHv/APuIcVHwCgjd94NxaR1o1bJvKuZWPx9rMe 6ZQAoI/xS6s6NFGtbFLYmtfWjkDK79ml =quLt -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 08:38:01 2012 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 C43AD1065670 for ; Wed, 11 Jul 2012 08:38:01 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5640D8FC18 for ; Wed, 11 Jul 2012 08:38:01 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 10:36:05 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 10:36:06 +0200 Date: Wed, 11 Jul 2012 10:36:27 +0200 From: Harti Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Peter Jeremy In-Reply-To: <20120711075044.GA10224@server.rulingia.com> Message-ID: References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 08:38:01 -0000 On Wed, 11 Jul 2012, Peter Jeremy wrote: PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: PJ>>I have a question about the kqueue timer timeout period ... what's data PJ>>supposed to be? I thought it was supposed to be the period in PJ>>milliseconds, but I seem to off by one. PJ>> PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I PJ>>often wait 21 milliseconds which is very undesirable for my application. PJ> PJ>FreeBSD is not a real-time OS. The timeouts specified in various PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) PJ>specify minimum timeouts. Once the timeout (rounded up to the next PJ>tick) has expired, the process will be placed back into the queue PJ>of processes eligible to be run by the scheduler - which may impose PJ>a further arbitrary delay. PJ> PJ>Periodic timers are somewhat better behaved: Scheduler delays only PJ>impact process scheduling after the timeout expires and the average PJ>rate should be very close to that requested. While it is certainly true that FreeBSD is not a real-time OS, this does not explain the timer problems. 2 or 3 month ago I did a simple test with select and poll: I observed a systematic error of about 3-5% of the waiting time. So when you wait for 20ms, you may get 21ms (if running with a low HZ value) because of rounding. But if you wait for 100s, you get 103 or even 105s on a completly idle machine (all services disabled). I think that this is not a problem with beeing non-realtime, but a problem with time-keeping. Shouldn't it be possible to do this better? harti From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 09:42:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A41C81065691; Wed, 11 Jul 2012 09:42:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0335F8FC14; Wed, 11 Jul 2012 09:42:29 +0000 (UTC) Received: by bkcje9 with SMTP id je9so816257bkc.13 for ; Wed, 11 Jul 2012 02:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=UsLRH6SFe7wP7jV+9OVdq720971gc/4yFgxcE3o1giE=; b=JcWxZJRCmqsWkQxRfJa4ZH1I3xg928rlt81mb0kwD9vibzbB4PQvzi6D0bsB3PLheA KHuIhEV4XM1lUmrvdvgakEFx5qFWDDZDJNM+1WUQk00/s7IAnNI15cJOZwRW4SD9XzZ9 9mIWGR1/eGIPdJtmRsrujp1P+MKumPnCrug4HsbHl6G/MAwSVJZ+XYBp8F1dlxp2zecJ 3J+FNk3hZIQAzj24euNtDGkV0Pzv0PYdZoZz+BmLpjx3UvhIZrCQxZlGGVFiXGxL6pDQ z2GgEh+ncypE9pz3bmb5wEr6ThE+WkArMqzwtbH3RNIElRjPb05RO8pz+8vcVe5VgK9O evIg== Received: by 10.204.156.217 with SMTP id y25mr23401319bkw.65.1341999748846; Wed, 11 Jul 2012 02:42:28 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id hg13sm669894bkc.7.2012.07.11.02.42.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 02:42:27 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FFD4A7F.9060103@FreeBSD.org> Date: Wed, 11 Jul 2012 12:42:23 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Harti Brandt Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: davide@FreeBSD.org, freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 09:42:30 -0000 Hi. Historically FreeBSD used completely different hardware time sources for time keeping and time events. Not sure about 5%, but the last could be less precise in some cases. FreeBSD 9.0, depending on hardware, can be more precise because of using same time source in both cases. Also there is ongoing GSoC project now by Davide Italiano to handle sub-HZ resolution for time events. Present tests show reaching 20 microseconds precision; and I think it can be improved further. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 10:30:49 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA2E1106564A; Wed, 11 Jul 2012 10:30:49 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA6A8FC18; Wed, 11 Jul 2012 10:30:49 +0000 (UTC) Received: from [78.35.173.77] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SouBC-0006vx-W7; Wed, 11 Jul 2012 12:29:59 +0200 Date: Wed, 11 Jul 2012 12:29:35 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20120711122935.1382e76d@fabiankeil.de> In-Reply-To: <4FFC8479.9080608@FreeBSD.org> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/9sIycTmw_0p6QYzm37pBrn/"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@FreeBSD.org, Sean Bruno , rmacklem@FreeBSD.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 10:30:50 -0000 --Sig_/9sIycTmw_0p6QYzm37pBrn/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 10/07/2012 21:57 Fabian Keil said the following: > > I do not use a completely NFS-free kernel, but I don't build any=20 > > NFS-related modules. Trying to load an unpatched dtraceall results in: > >=20 > > Jul 9 21:58:48 r500 sudo: fk : TTY=3Dpts/16 ; PWD=3D/home/fk ; U= SER=3Droot > > ; COMMAND=3D/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922]= KLD > > dtnfsclient.ko: depends on oldnfs - not available or version mismatch J= ul > > 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type = Jul > > 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient= - > > not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] > > linker_load_file: Unsupported file type > >=20 > > My assumption was that your patch and the "#elif defined (NFSCLIENT)" w= ould > > fix that, and indeed it does, but I later on realized that I actually do > > have NFSCL in the kernel: > >=20 > > fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT optio= ns > > NFSLOCKD options NFSD options NFSCL > >=20 > > My impression is that the patch is missing an opt_nfs.h inclusion combi= ned > > with the Makefile voodoo to create the file. > >=20 > > The dtraceall module already has an opt_compat.h, even though the Makef= ile > > logic to create it seems a bit dubious to me. It blindly assumes that > > COMPAT_FREEBSD32 is available on amd64. >=20 > Not sure if I got correctly what the (perceived) problem actually is, but= I > have this to say: the proper way of building a module is either via > buildkernel (MODULES_OVERRIDE, etc) or by using KERNBUILDDIR for "indepen= dent" > module build if the module has any dependency on kernel options in effect. > This could be a little bit sad (for third-party module providers), but th= is > seems to be true. >=20 > Sometimes Makefile-s fake kernel options for truly independent module bui= ld > (no KERNBUILDDIR) to provide the widest and/or safest feature set. But t= his > has to be done very carefully to ensure that module<->kernel*s* compatibi= lity > actually occurs. I'm using the following modification of Sean's patch: diff --git a/sys/modules/dtrace/dtraceall/dtraceall.c b/sys/modules/dtrace/= dtraceall/dtraceall.c index c57f590..d50b1e5 100644 --- a/sys/modules/dtrace/dtraceall/dtraceall.c +++ b/sys/modules/dtrace/dtraceall/dtraceall.c @@ -67,8 +67,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtio, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#elif defined (NFSCLIENT) MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); The perceived problem is that after compiling dtraceall with "make buildkernel", installing it with "make installkernel" and rebooting, loading it results in:=20 fk@r500 ~ $kldstat Id Refs Address Size Name 1 73 0xffffffff80200000 e492c0 kernel 2 1 0xffffffff8104a000 226928 zfs.ko 3 14 0xffffffff81271000 82b8 opensolaris.ko 4 1 0xffffffff8127a000 23a48 geom_eli.ko 5 2 0xffffffff8129e000 34380 crypto.ko 7 1 0xffffffff812fe000 8640 acpi_video.ko 8 1 0xffffffff81307000 7d00 acpi_ibm.ko 9 4 0xffffffff81412000 29e31 usb.ko 10 1 0xffffffff8143c000 32ec usb_quirk.ko 11 1 0xffffffff81440000 bded ehci.ko 12 1 0xffffffff8144c000 8d02 umass.ko 13 1 0xffffffff81455000 5c2a nullfs.ko 14 1 0xffffffff8145b000 51ac fdescfs.ko 15 1 0xffffffff81461000 beb4 i915.ko 16 1 0xffffffff8146d000 173cc drm.ko 17 1 0xffffffff81485000 b25 dtraceall.ko 18 1 0xffffffff81486000 4e00 profile.ko 19 3 0xffffffff8148b000 4073 cyclic.ko 20 10 0xffffffff81490000 23b931 dtrace.ko 21 1 0xffffffff816cc000 125da systrace_freebsd32.ko 22 1 0xffffffff816df000 13797 systrace.ko 23 1 0xffffffff816f3000 44be sdt.ko 24 1 0xffffffff816f8000 484d lockstat.ko 25 1 0xffffffff816fd000 bce5 fasttrap.ko 26 1 0xffffffff81709000 6553 fbt.ko 27 1 0xffffffff81710000 448b dtmalloc.ko 28 1 0xffffffff81715000 43d9 dtio.ko Note that dtnfscl.ko is not loaded even though loading it manually works and I have NFSCL in the kernel. Fabian --Sig_/9sIycTmw_0p6QYzm37pBrn/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/9VaEACgkQBYqIVf93VJ18rgCeID+tIXTceHLE8cwOtnUm/rVd V24AmgOtMjwBXve8X7lHyskr+tKEjVbr =Re94 -----END PGP SIGNATURE----- --Sig_/9sIycTmw_0p6QYzm37pBrn/-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 04:50:35 2012 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 C9FE5106566B for ; Wed, 11 Jul 2012 04:50:35 +0000 (UTC) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD3C8FC12 for ; Wed, 11 Jul 2012 04:50:35 +0000 (UTC) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.11/8.12.11) with ESMTP id q6B4VBSC014473 for ; Wed, 11 Jul 2012 00:31:11 -0400 (EDT) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.11/8.12.11/Submit) id q6B4VBbU014472 for freebsd-hackers@freebsd.org; Wed, 11 Jul 2012 00:31:11 -0400 (EDT) (envelope-from wayne) Date: Wed, 11 Jul 2012 00:31:11 -0400 From: "Michael R. Wayne" To: freebsd-hackers@freebsd.org Message-ID: <20120711043110.GR42080@manor.msen.com> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 11 Jul 2012 11:01:33 +0000 Subject: kernel ignores default route? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 04:50:36 -0000 One of my machines is doing something I can not understand and may have uncovered some form of bug. The kernel appears to be ignoring the default route. Had several people look this over, we can't determine where the route is being hidden. This is 7.4-RELEASE-p2. I suspect that rebooting the box will clear the problem but I would REALLY like to figure out why the routing table is not being followed. I have two routers, on the same ethernet at: 148.59.4.1 (default) 148.59.4.3 & 139.171.192.26 148.59.4.2 (FreeBSD box) This is correct (see routing table below): > traceroute -n 148.59.48.1 traceroute to 148.59.48.1 (148.59.48.1), 64 hops max, 40 byte packets 1 139.171.192.26 7.366 ms 4.748 ms 6.879 ms 2 148.59.48.1 3.357 ms 5.130 ms 3.006 ms And "route" agrees: > route -n get 148.59.48.1 route to: 148.59.48.1 destination: 148.59.48.0 mask: 255.255.255.192 gateway: 148.59.4.3 interface: fxp0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 This is not, it should go out 148.59.4.1: > traceroute -n 148.59.80.1 traceroute to 148.59.80.1 (148.59.80.1), 64 hops max, 40 byte packets 1 139.171.192.26 6.874 ms 6.496 ms 4.288 ms 2 139.171.198.139 5.907 ms 8.251 ms 4.156 ms 3 198.22.65.217 5.246 ms 4.961 ms 4.719 ms 4 198.22.65.222 14.096 ms 4.760 ms 6.545 ms 5 148.59.80.1 5.753 ms 5.813 ms 5.952 ms "route" says it should: > route -n get 148.59.80.1 route to: 148.59.80.1 destination: default mask: default gateway: 148.59.4.1 interface: fxp0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 netstat -rn (minus a few 148.59.4.x machines that can be ignored) Internet: Destination Gateway Flags Refs Use Netif Expire default 148.59.4.1 UGS 0 667619000 fxp0 10.151.89.0/24 link#1 UC 0 0 em0 10.151.89.49 00:c0:9f:21:b2:31 UHLW 1 14 lo0 127.0.0.1 127.0.0.1 UH 2 23811 lo0 148.59.4.0/27 link#2 UC 0 0 fxp0 148.59.4.1 00:a0:c8:2c:5f:38 UHLW 2 602 fxp0 47 148.59.4.3 00:a0:c8:2c:5f:38 UHLW 5 0 fxp0 23 148.59.4.64 ff:ff:ff:ff:ff:ff UHLWb 1 14991 em0 => 148.59.4.64/26 link#1 UC 0 0 em0 148.59.4.66 00:02:b3:e9:0e:c0 UHLW 1 8098 em0 903 148.59.4.130 148.59.4.129 UH 0 2073 tun0 148.59.48.0/26 148.59.4.3 UG1 0 1158 fxp0 148.59.50.0/24 148.59.4.3 UG1 0 194507 fxp0 148.59.80.39 148.59.4.3 UGH1 0 0 fxp0 198.11.50.21 148.59.4.3 UGH1 0 0 fxp0 224.0.0.5 127.0.0.1 UGH1 0 0 lo0 224.0.0.6 127.0.0.1 UGH1 0 0 lo0 From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 11:25:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4E3B106564A for ; Wed, 11 Jul 2012 11:25:13 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5A58FC0C for ; Wed, 11 Jul 2012 11:25:13 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q6BBPCW8011452 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2012 13:25:12 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6BBPCEp003410 for freebsd-hackers@freebsd.org; Wed, 11 Jul 2012 13:25:12 +0200 (MEST) Date: Wed, 11 Jul 2012 13:25:12 +0200 From: Daniel Hartmeier To: freebsd-hackers@freebsd.org Message-ID: <20120711112512.GF9145@insomnia.benzedrine.cx> References: <20120711043110.GR42080@manor.msen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120711043110.GR42080@manor.msen.com> User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: kernel ignores default route? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 11:25:13 -0000 On Wed, Jul 11, 2012 at 12:31:11AM -0400, Michael R. Wayne wrote: > I have two routers, on the same ethernet at: > 148.59.4.1 (default) > 148.59.4.3 & 139.171.192.26 > 148.59.4.2 (FreeBSD box) > 148.59.4.0/27 link#2 UC 0 0 fxp0 > 148.59.4.1 00:a0:c8:2c:5f:38 UHLW 2 602 fxp0 47 > 148.59.4.3 00:a0:c8:2c:5f:38 UHLW 5 0 fxp0 23 Which router has MAC 00:a0:c8:2c:5f:38 (00:a0:c8 is Adtrans Inc.)? Is arp -na showing the same MAC for both routers, even though their all in the same segment? Your routing table can distinguish between next-hops .1 and .3 all you want, if ARP for both goes to the same MAC... Daniel From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 14:36:54 2012 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 B4563106566B; Wed, 11 Jul 2012 14:36:54 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDC48FC18; Wed, 11 Jul 2012 14:36:54 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Wed, 11 Jul 2012 09:27:40 -0500 From: Paul Albrecht To: Harti Brandt , Peter Jeremy , "freebsd-hackers@freebsd.org" In-Reply-To: References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com> Content-Type: text/plain Date: Wed, 11 Jul 2012 09:36:38 -0500 Message-ID: <1342017398.5984.18.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 14:36:54 -0000 On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote: > On Wed, 11 Jul 2012, Peter Jeremy wrote: > > PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: > PJ>>I have a question about the kqueue timer timeout period ... what's data > PJ>>supposed to be? I thought it was supposed to be the period in > PJ>>milliseconds, but I seem to off by one. > PJ>> > PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I > PJ>>often wait 21 milliseconds which is very undesirable for my application. > PJ> > PJ>FreeBSD is not a real-time OS. The timeouts specified in various > PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) > PJ>specify minimum timeouts. Once the timeout (rounded up to the next > PJ>tick) has expired, the process will be placed back into the queue > PJ>of processes eligible to be run by the scheduler - which may impose > PJ>a further arbitrary delay. > PJ> > PJ>Periodic timers are somewhat better behaved: Scheduler delays only > PJ>impact process scheduling after the timeout expires and the average > PJ>rate should be very close to that requested. > > While it is certainly true that FreeBSD is not a real-time OS, this does > not explain the timer problems. 2 or 3 month ago I did a simple test with > select and poll: I observed a systematic error of about 3-5% of the > waiting time. So when you wait for 20ms, you may get 21ms (if running with > a low HZ value) because of rounding. But if you wait for 100s, you get 103 > or even 105s on a completly idle machine (all services disabled). > > I think that this is not a problem with beeing non-realtime, but a problem > with time-keeping. Shouldn't it be possible to do this better? > I don't think it has anything to do with realtime either. I've been using gentoo linux to run my application using timerfd_create/read for 20 millisecond timing without any problems. > harti -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 14:44:45 2012 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 5922F106564A; Wed, 11 Jul 2012 14:44:45 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 213B28FC0A; Wed, 11 Jul 2012 14:44:45 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Wed, 11 Jul 2012 09:35:46 -0500 From: Paul Albrecht To: Alexander Motin In-Reply-To: <4FFD4A7F.9060103@FreeBSD.org> References: <4FFD4A7F.9060103@FreeBSD.org> Content-Type: text/plain Date: Wed, 11 Jul 2012 09:44:44 -0500 Message-ID: <1342017884.5984.24.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: "davide@FreeBSD.org" , "freebsd-hackers@freebsd.org" , Harti Brandt Subject: Re: [[SPAM]] Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 14:44:45 -0000 On Wed, 2012-07-11 at 04:42 -0500, Alexander Motin wrote: > Hi. > > Historically FreeBSD used completely different hardware time sources for > time keeping and time events. Not sure about 5%, but the last could be > less precise in some cases. FreeBSD 9.0, depending on hardware, can be > more precise because of using same time source in both cases. Also there > is ongoing GSoC project now by Davide Italiano to handle sub-HZ > resolution for time events. Present tests show reaching 20 microseconds > precision; and I think it can be improved further. > I'm definitely not getting getting 20 millisecond timing with freebsd kqueue which surprised me because I get it with linux linuxfd_create/read using the same hardware. -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 19:52:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6B83106566B for ; Wed, 11 Jul 2012 19:52:24 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 73C0B8FC14 for ; Wed, 11 Jul 2012 19:52:24 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Wed, 11 Jul 2012 14:43:12 -0500 From: Paul Albrecht To: freebsd-hackers@freebsd.org Content-Type: text/plain Date: Wed, 11 Jul 2012 14:52:12 -0500 Message-ID: <1342036332.8313.8.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 19:52:24 -0000 Hi, Sorry about this repost but I'm confused about the responses I received in my last post so I'm looking for some clarification. Specifically, I though I could use the kqueue timer as essentially a "drop in" replacement for linuxfd_create/read, but was surprised that the accuracy of the kqueue timer is much less than what I need for my application. So my confusion at this point is whether this is consider to be a bug or "feature"? Here's some test code if you want to verify the problem: #include #include #include #include #include #include #include #include int main(void) { int i,msec; int kq,nev; struct kevent inqueue; struct kevent outqueue; struct timeval start,end; if ((kq = kqueue()) == -1) { fprintf(stderr, "kqueue error!? errno = %s", strerror(errno)); exit(EXIT_FAILURE); } EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); gettimeofday(&start, 0); for (i = 0; i < 50; i++) { if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) { fprintf(stderr, "kevent error!? errno = %s", strerror(errno)); exit(EXIT_FAILURE); } else if (outqueue.flags & EV_ERROR) { fprintf(stderr, "EV_ERROR: %s\n", strerror(outqueue.data)); exit(EXIT_FAILURE); } } gettimeofday(&end, 0); msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + end.tv_usec - start.tv_usec) / 1000) - 1000); printf("msec = %d\n", msec); close(kq); return EXIT_SUCCESS; } -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 21:00:56 2012 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 71104106566B for ; Wed, 11 Jul 2012 21:00:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 539E28FC0C for ; Wed, 11 Jul 2012 21:00:56 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Z9041j00R0x6nqcAC90q4Y; Wed, 11 Jul 2012 21:00:50 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta12.emeryville.ca.mail.comcast.net with comcast id Z90p1j00H4NgCEG8Y90pfL; Wed, 11 Jul 2012 21:00:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6BL0l1m014495; Wed, 11 Jul 2012 15:00:47 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Paul Albrecht In-Reply-To: <1342036332.8313.8.camel@albrecht-desktop> References: <1342036332.8313.8.camel@albrecht-desktop> Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jul 2012 15:00:47 -0600 Message-ID: <1342040447.1123.31.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 21:00:56 -0000 On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > Hi, > > Sorry about this repost but I'm confused about the responses I received > in my last post so I'm looking for some clarification. > > Specifically, I though I could use the kqueue timer as essentially a > "drop in" replacement for linuxfd_create/read, but was surprised that > the accuracy of the kqueue timer is much less than what I need for my > application. > > So my confusion at this point is whether this is consider to be a bug or > "feature"? > > Here's some test code if you want to verify the problem: > > #include > #include > #include > #include > #include > #include > #include > #include > > int > main(void) > { > int i,msec; > int kq,nev; > struct kevent inqueue; > struct kevent outqueue; > struct timeval start,end; > > if ((kq = kqueue()) == -1) { > fprintf(stderr, "kqueue error!? errno = %s", strerror(errno)); > exit(EXIT_FAILURE); > } > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > gettimeofday(&start, 0); > for (i = 0; i < 50; i++) { > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) { > fprintf(stderr, "kevent error!? errno = %s", strerror(errno)); > exit(EXIT_FAILURE); > } else if (outqueue.flags & EV_ERROR) { > fprintf(stderr, "EV_ERROR: %s\n", strerror(outqueue.data)); > exit(EXIT_FAILURE); > } > } > gettimeofday(&end, 0); > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + end.tv_usec - start.tv_usec) / 1000) - 1000); > > printf("msec = %d\n", msec); > > close(kq); > return EXIT_SUCCESS; > } > > What you are seeing is "just the way FreeBSD currently works." Sleeping (in most all of its various forms, and I've just looked at the kevent code to verify this is true there) is handled by converting the amount of time to sleep (usually specified in a timeval or timespec struct) to a count of timer ticks, using an internal routine called tvtohz() in kern/kern_time.c. That routine rounds up by one tick to account for the current tick. Whether that's a good idea or not (it probably was once, and probably not anymore) it's how things currently work, and could explain the fairly consistant +1ms you're seeing. Another source of oversleeping is that the length of a tick in microseconds is simplisticly calculated as 1000000 / hz on most hardware, so for HZ=1000, tick=1000. Unless the clock producing the tick interrupts is running at a frequency exactly divisible by 1000, that tick-length calculation has some rounding error in it, and it results in systematic oversleeping. On modern hardware with high-frequency clocks it's typically less than 1%. The routines for sleeping in the kernel take a count of ticks for how long to sleep, so when tvtohz() converts some number of microseconds to the corresponding number of ticks, any rounding error in the value for the length of a tick results in oversleeping by some small percentage of the time you wanted to sleep. Note that this rounding error in calculating the length of a tick does not result in a systematic skew in system timekeeping, because when each tick interrupt happens, the system reads a clock counter register that may or may not be related to the clock producing tick interrupts; the value in the register is full precision without the rounding error you get when counting ticks. It might be an interesting experiment to add kern.hz=10000 to your /boot/loader.conf and see how that affects your test. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 22:39:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 819031065670 for ; Wed, 11 Jul 2012 22:39:52 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 571FF8FC0C for ; Wed, 11 Jul 2012 22:39:52 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2998446pbb.13 for ; Wed, 11 Jul 2012 15:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MizMswMzsptw/QOCrXxSXLWh/jK8bCWWsDVJwUPuYMM=; b=F6BS1WxM78ZGDfsEWMM3akTVC+OJ1XrxnHNPfVVmHw/f+ElwfuVHushEHYIt22Og64 G+O9JoWVUZJhc9cvzXtQiD8ugxS8l5dPd/CbyspzGexmik+Gz90CBHnpKu3Rg9XT35rc s5M98VZfyzUZ+xFK8juqqt1gzzLi8aiY/G9hnMwDX8FInlVvM/t8E+xXSJpSIB9kEwUL noanyMl4gBy+HnpRPJjiW247ybpsQRHfrNbaL0lHYDOjqxRA+n5OT3dl4FpJDNEqpdGD Ehbxmd0ToAYcHek7dUyhVMu+ItIFMRn/E4T10ueeHBbAPT1tz3cN/HjPxmM33J3MRaqO G2hA== MIME-Version: 1.0 Received: by 10.66.83.69 with SMTP id o5mr85231460pay.34.1342046391899; Wed, 11 Jul 2012 15:39:51 -0700 (PDT) Received: by 10.66.82.201 with HTTP; Wed, 11 Jul 2012 15:39:51 -0700 (PDT) In-Reply-To: <1342036332.8313.8.camel@albrecht-desktop> References: <1342036332.8313.8.camel@albrecht-desktop> Date: Thu, 12 Jul 2012 00:39:51 +0200 Message-ID: From: Davide Italiano To: Paul Albrecht Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Jul 2012 22:39:52 -0000 On Wed, Jul 11, 2012 at 9:52 PM, Paul Albrecht wrote: > > Hi, > > Sorry about this repost but I'm confused about the responses I received > in my last post so I'm looking for some clarification. > > Specifically, I though I could use the kqueue timer as essentially a > "drop in" replacement for linuxfd_create/read, but was surprised that > the accuracy of the kqueue timer is much less than what I need for my > application. > > So my confusion at this point is whether this is consider to be a bug or > "feature"? > > Here's some test code if you want to verify the problem: > > #include > #include > #include > #include > #include > #include > #include > #include > > int > main(void) > { > int i,msec; > int kq,nev; > struct kevent inqueue; > struct kevent outqueue; > struct timeval start,end; > > if ((kq = kqueue()) == -1) { > fprintf(stderr, "kqueue error!? errno = %s", strerror(errno)); > exit(EXIT_FAILURE); > } > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > gettimeofday(&start, 0); > for (i = 0; i < 50; i++) { > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) { > fprintf(stderr, "kevent error!? errno = %s", strerror(errno)); > exit(EXIT_FAILURE); > } else if (outqueue.flags & EV_ERROR) { > fprintf(stderr, "EV_ERROR: %s\n", strerror(outqueue.data)); > exit(EXIT_FAILURE); > } > } > gettimeofday(&end, 0); > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + end.tv_usec - start.tv_usec) / 1000) - 1000); > > printf("msec = %d\n", msec); > > close(kq); > return EXIT_SUCCESS; > } > > > -- > Paul Albrecht > > _______________________________________________ > 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" Hi. As I told you before I'm currently working on this problem. I wrote a testcase myself, you can find it here: http://people.freebsd.org/~davide/kqueue/kevent_test.c As part of my callout(9) rewriting work I've recently converted kqueue(9) in order to exploit the precision allowed by the new backend and exposed to consumers via the new interface (callout_reset_bt_on()). I ran my testcase and these are the results over 100 iterations: http://people.freebsd.org/~davide/kqueue/kqueue_res.png (red line-> old, green line -> new). It seems there's some improvement, at least for now. If you want to give it a try checkout the projects/calloutng branch and apply the following patch http://people.freebsd.org/~davide/kqueue/kqueue_calloutng.diff (still in an early stage, if there are some issues, feel free to report them). Davide From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 00:10:45 2012 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 6CB6B106566C; Thu, 12 Jul 2012 00:10:45 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id E4DA08FC08; Thu, 12 Jul 2012 00:10:44 +0000 (UTC) X-AuditID: 12074425-b7f9b6d0000008c4-9e-4ffe1603037b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 79.7D.02244.3061EFF4; Wed, 11 Jul 2012 20:10:43 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q6C0AgHj020760; Wed, 11 Jul 2012 20:10:42 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q6C0AeLM023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 20:10:41 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q6C0Aeew019895; Wed, 11 Jul 2012 20:10:40 -0400 (EDT) Date: Wed, 11 Jul 2012 20:10:40 -0400 (EDT) From: Benjamin Kaduk To: Fabian Keil In-Reply-To: <20120711122935.1382e76d@fabiankeil.de> Message-ID: References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrcss9s/f4PdTTovtm/8xWny6fp7J Yu7f/YwOzB5Htm5k9JjxaT5LAFMUl01Kak5mWWqRvl0CV8aV8xdYCtrFK05sncDUwPhPsIuR k0NCwESifeo1ZghbTOLCvfVsXYxcHEIC+xglWue1QTkbGCWaTixhhHAOMEkcv3idFcJpYJS4 eX8WUIaDg0VAW2LxCy6QUWwCKhIz32xkA7FFBPQkphxpBVvBLGAq8X3dZnYQW1hAR+LM1ZWs IDYn0BmdL24wg4zhFXCUWLDTCWL8OiaJmZO/MIHUiALVr94/hQXE5hUQlDg58wkLxExLiX9r f7FOYBSchSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0LvdzMEr3UlNJNjKCgZXdR 3cE44ZDSIUYBDkYlHt6d6/76C7EmlhVX5h5ilORgUhLl/SHyz1+ILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO/Bl0DlvCmJlVWpRfkwKWkOFiVx3hspN/2FBNITS1KzU1MLUotgsjIcHEoSvF9A hgoWpaanVqRl5pQgpJk4OEGG8wAN3wNSw1tckJhbnJkOkT/FqMsx99KJG4xCLHn5ealS4rzK okBFAiBFGaV5cHNgyeYVozjQW8K87CBVPMBEBTfpFdASJqAlC5b+AVlSkoiQkmpgXCmxtOnF 0hthhlZzD2fsPPSnw/G8sYEf75el6UYKn3PE2eov1n3MshDYz9Q58Zs4x57LEvc+zhG+fTxb XPRkWHu+cIjbInmLJjv5OrXPf+c8Y825d3KvcIvOuROfnCdsCQ92F7TxE1zvdvZX6dP4Qzf5 fqz4v+TBA9t92akLGiye7eq72vtztRJLcUaioRZzUXEiAEPUN0kRAwAA Cc: rmacklem@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 00:10:45 -0000 On Wed, 11 Jul 2012, Fabian Keil wrote: > I'm using the following modification of Sean's patch: > > diff --git a/sys/modules/dtrace/dtraceall/dtraceall.c b/sys/modules/dtrace/dtraceall/dtraceall.c > index c57f590..d50b1e5 100644 > --- a/sys/modules/dtrace/dtraceall/dtraceall.c > +++ b/sys/modules/dtrace/dtraceall/dtraceall.c > @@ -67,8 +67,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > MODULE_DEPEND(dtraceall, dtio, 1, 1, 1); > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > +#if defined (NFSCL) > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > +#elif defined (NFSCLIENT) > MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); > +#endif > #if defined(__amd64__) || defined(__i386__) > MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); > MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); > > The perceived problem is that after compiling dtraceall with > "make buildkernel", installing it with "make installkernel" > and rebooting, loading it results in: > > fk@r500 ~ $kldstat > Id Refs Address Size Name > 1 73 0xffffffff80200000 e492c0 kernel > 2 1 0xffffffff8104a000 226928 zfs.ko > 3 14 0xffffffff81271000 82b8 opensolaris.ko > 4 1 0xffffffff8127a000 23a48 geom_eli.ko > 5 2 0xffffffff8129e000 34380 crypto.ko > 7 1 0xffffffff812fe000 8640 acpi_video.ko > 8 1 0xffffffff81307000 7d00 acpi_ibm.ko > 9 4 0xffffffff81412000 29e31 usb.ko > 10 1 0xffffffff8143c000 32ec usb_quirk.ko > 11 1 0xffffffff81440000 bded ehci.ko > 12 1 0xffffffff8144c000 8d02 umass.ko > 13 1 0xffffffff81455000 5c2a nullfs.ko > 14 1 0xffffffff8145b000 51ac fdescfs.ko > 15 1 0xffffffff81461000 beb4 i915.ko > 16 1 0xffffffff8146d000 173cc drm.ko > 17 1 0xffffffff81485000 b25 dtraceall.ko > 18 1 0xffffffff81486000 4e00 profile.ko > 19 3 0xffffffff8148b000 4073 cyclic.ko > 20 10 0xffffffff81490000 23b931 dtrace.ko > 21 1 0xffffffff816cc000 125da systrace_freebsd32.ko > 22 1 0xffffffff816df000 13797 systrace.ko > 23 1 0xffffffff816f3000 44be sdt.ko > 24 1 0xffffffff816f8000 484d lockstat.ko > 25 1 0xffffffff816fd000 bce5 fasttrap.ko > 26 1 0xffffffff81709000 6553 fbt.ko > 27 1 0xffffffff81710000 448b dtmalloc.ko > 28 1 0xffffffff81715000 43d9 dtio.ko > > Note that dtnfscl.ko is not loaded even though loading > it manually works and I have NFSCL in the kernel. This is because dtraceall.c only #includes opt_compat.h, and the kernel build system only passes -include opt_global.h, so the dtraceall module build has no way of knowing about the NFSCL{IENT,} options defined in opt_nfs.h. (As you noted earlier in the thread?) You would still need to address Andriy's comments in order to ensure that the configuration seen by the module matches the kernel. -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 03:47:52 2012 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 C1C48106566B; Thu, 12 Jul 2012 03:47:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6158FC0A; Thu, 12 Jul 2012 03:47:51 +0000 (UTC) Received: by lbon10 with SMTP id n10so3307323lbo.13 for ; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ykhiy4BXcrqg714iHPrnFmeaf2/wIiragN6AFheEyV0=; b=l4vLuz8Kl4iBK4NMEn+ZryNvZ5cJMmAeah7WRf9oVxVqofUyxnJHrgGxJeixY02a3o Pi1xb3DfElMay7DrKrb/dIsBjlDBLNAlkaTVfwGKLHz6AnFMoqfYVohEYzVMXRQGAWL0 +yDrzZrydLtOo7SwSlW2gyk6X1JGhQkqnXV5copY7Ae9Y8ILs4Zy6T0Awc4NTQKa3Jv3 27DzZYA6N2FtKCRpsfD4FI4o1dOjJvWzCod2sJ3NiZHg6Reebkh6g1FMXdG4HCeVqlR0 BPQK3/5P+4l3pVEy0yGwaLQ4fkyQVjCfWKhDE2zQvUF82aG85xa13wFrsInCgug48EkY cSjw== MIME-Version: 1.0 Received: by 10.152.132.40 with SMTP id or8mr51802446lab.24.1342064870717; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) In-Reply-To: References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Wed, 11 Jul 2012 23:47:50 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 03:47:52 -0000 Hi, On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >> >> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >> >>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>>> >>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>> >>>>> Hi, >>>>> >>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>>> >>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>>>> than one interface, and one of its child has need to use more than = one >>>>>>> interface, each interfaces cannot register, concurrently, its own >>>>>>> ivar. While I try to always have a single child per >>>>>>> interface/resource, I need to keep some compatibility with the old = way >>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>>> userland). So, it would have been nice if ivar had been per-interfa= ce, >>>>>>> not global and unique to one device. >>>>>> >>>>>> There's one pointer for the ivars. The bus code gets to determine w= hat the ivar looks like, because the interface is totally private to the bu= s. So long as it returns the right thing for any key that's presented, it = doesn't matter quite how things are done. >>>>>> >>>>>> So I'm not sure I understand what you are saying here. >>>>>> >>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs t= o >>>>> use both interfaces. There is no generic way for dev0 to export >>>>> independent ivars for both interface. For now, I restricted the >>>>> function of the second interface not to need ivar, but that's kind of >>>>> hackish. >>>> >>>> Only if the IVARs for interface A and interface B have overlapping val= ues. If the Ivar keys don't overlap, then there's no problems at all. Cer= tainly less hackish than not using them at all. Since dev0 knows the layou= t of the ivar that it set on its child, this presents no problems at all. = It would return the values from A from the right part of the ivar, and thos= e from B in the right part. Apart from the coordination of Ivar numbers, a= s I outlined in my last post, there's no issue here. >>>> >>> I think we should not be talking about the same API here. I have no >>> idea what you mean by "the key to value translation", nor "Ivar >>> numbers". What I refer to is that device_set_ivars() / >>> device_get_ivars() acts on a single instance variables from `struct >>> device': `ivars'. In that case, I do not really see how to set that >>> specific field to two distinct values for each interfaces. >> >> We are talking about the ivar interface. You are just misunderstanding = how it is used. >> > yes I indeed did... silly, silly me :-) > Actually, no. I wasn't that silly, neither was I misunderstanding anything beside how *you* wanted it to be used, which is, I sorry to say, unacceptable. The last thing I want is to pollute an interface with a single-purpose, hand-crafted, bus. I was to just throw away all that ivar stuff and go into hinted child configuration for now, waiting for FDT... but of course, I figured out after a few hours that hinted child attachment requires `bus_hinted_child' to be set in the parent, as does bus_enumerate_hinted_children() / bus_generic_attach() to explicitly pollute my code. All this stuff should be done implicitly to support N:1 interfaces/client relationship. N *independent* interfaces being provided by a single driver; of course, I'm not even going back to require those interface being provided by multiple drivers, it is already a dead end. I am not even sure any driver in the tree provides more than one interface.= .. For whatever reason, I am more and more thinking that this all new-bus[0] stuff is *way* overkill, static, bloated at will, and missing critical features; a huge PITA to use, for the intended purpose. /me pissed. - Arnaud [0]: damn, why is it even called "newbus", this stuff is 14 years old. It really belongs to a museum, not production code... From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 03:51:07 2012 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 8EC3D106566C; Thu, 12 Jul 2012 03:51:07 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 978B88FC0C; Thu, 12 Jul 2012 03:51:06 +0000 (UTC) Received: by lbon10 with SMTP id n10so3310776lbo.13 for ; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ld4EQ0vVtcIYE4PJWTr+vZeGtinJ1zcOqM1qyRqgms8=; b=QUChQv8D1lKm9y/Si+SacNnAMbw2Fnbfjgr8B54Esm69Ks2bBE9sOgKTU7lel2WWB0 Lu+6J2kC1K9qkTCpMN6GcX16m71AXqOTedkyZy/8un4madZIl1dRV+/xzvJIsnGpCGUQ fvflu2O/rxQh3d05pPRwwLMPchgGi8JnavnuwhQa6ZUwlvAJB/chcu22hbJK0nCz0HGk ZIhS4HDvOB/h6tb4IM0M+HZIFoysK+JdvZz9Yh21xUrFk5xLueDbgFbYWiDplaLCj9tm IsbdxCSxRN76tU1b1+gTwQav6uexxyHS3pR/XMOew+OpoIWNPmwj9/3F4nvA14APAXv2 bJYA== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr51660627lab.20.1342065065417; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) In-Reply-To: <201207091127.30289.jhb@freebsd.org> References: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> <201207091127.30289.jhb@freebsd.org> Date: Wed, 11 Jul 2012 23:51:05 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 03:51:07 -0000 Hi, On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin wrote: > Also, I think we should do this in general. We already have one example (e.g. > ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can > provide both ACPI and PCI IVARs to child devices). I think we should assign > each bus it's own IVAR range. It would make it easier to determine if a > specific IVAR is event supported. Certainly I think ISA and PCI at a minimum > should be changed to start at, say, 200 and 300. > What's the point doing that ? Let's just resign to the conclusion that FreeBSD devices' subsystem provides no dynamic way for a client device to deals with multiple bus driver. Instead all possible combination have to be harcoded and hand-crafted, when at all possible, to look like they're coming from a single bus... But again, newbus is 14 years old... - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 05:20:13 2012 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 3B42E1065672 for ; Thu, 12 Jul 2012 05:20:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D659F8FC1A for ; Thu, 12 Jul 2012 05:20:12 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2320609ggn.13 for ; Wed, 11 Jul 2012 22:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gQj15LefXJAW00EkiFPzDQ1KcGKgEl1c2SqZv3ONKC4=; b=aMY0er12SwFSJNT+RtrrtUKlIbRWIhMZ8crCVOmBQ8YGxsUuVyCvJBk031oM/IZK8c pC48gUlTolpJjndq0jq0QHd1NOhYCb+FCGc1AwzUfBQSWklqYk7+hfHRrGDdHgS7LzRE 2Zh8EHthtY0Hw7XtWZQuqQ75RUDfIVkXRBFaswhgik1KkB+tJj6f64jsg8rA5LstDfgH 2iPi+f4El2AzQW+8gTMvbw1e5KymHkP8A0DZT+xBV4Qw7QKm94Ybaxl2GVisrkUC5oAi z+/T8KiNvs2e+jp6RmSCKXm0uSeNTcl4JCobWvY1cysroiTn2stX4RLunKcHXYAn9KzB XXjg== Received: by 10.66.83.33 with SMTP id n1mr87325444pay.7.1342070411875; Wed, 11 Jul 2012 22:20:11 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id se9sm3120525pbc.25.2012.07.11.22.20.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 22:20:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 11 Jul 2012 23:20:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkBZU28qLBfTMgMEy6eh8zKkzo9UARhcKsw3UAgY1IgVXGALvwXSeCEvWtM6wOpCrOjBGjr Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 05:20:13 -0000 On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe = wrote: >> Hi, >>=20 >> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >>>=20 >>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >>>=20 >>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh = wrote: >>>>>=20 >>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh = wrote: >>>>>>>=20 >>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports = more >>>>>>>> than one interface, and one of its child has need to use more = than one >>>>>>>> interface, each interfaces cannot register, concurrently, its = own >>>>>>>> ivar. While I try to always have a single child per >>>>>>>> interface/resource, I need to keep some compatibility with the = old way >>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>>>> userland). So, it would have been nice if ivar had been = per-interface, >>>>>>>> not global and unique to one device. >>>>>>>=20 >>>>>>> There's one pointer for the ivars. The bus code gets to = determine what the ivar looks like, because the interface is totally = private to the bus. So long as it returns the right thing for any key = that's presented, it doesn't matter quite how things are done. >>>>>>>=20 >>>>>>> So I'm not sure I understand what you are saying here. >>>>>>>=20 >>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, = needs to >>>>>> use both interfaces. There is no generic way for dev0 to export >>>>>> independent ivars for both interface. For now, I restricted the >>>>>> function of the second interface not to need ivar, but that's = kind of >>>>>> hackish. >>>>>=20 >>>>> Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. >>>>>=20 >>>> I think we should not be talking about the same API here. I have no >>>> idea what you mean by "the key to value translation", nor "Ivar >>>> numbers". What I refer to is that device_set_ivars() / >>>> device_get_ivars() acts on a single instance variables from `struct >>>> device': `ivars'. In that case, I do not really see how to set that >>>> specific field to two distinct values for each interfaces. >>>=20 >>> We are talking about the ivar interface. You are just = misunderstanding how it is used. >>>=20 >> yes I indeed did... silly, silly me :-) >>=20 > Actually, no. I wasn't that silly, neither was I misunderstanding > anything beside how *you* wanted it to be used, which is, I sorry to > say, unacceptable. The last thing I want is to pollute an interface > with a single-purpose, hand-crafted, bus. I was to just throw away all > that ivar stuff and go into hinted child configuration for now, > waiting for FDT... but of course, I figured out after a few hours that > hinted child attachment requires `bus_hinted_child' to be set in the > parent, as does bus_enumerate_hinted_children() / bus_generic_attach() > to explicitly pollute my code. All this stuff should be done > implicitly to support N:1 interfaces/client relationship. N > *independent* interfaces being provided by a single driver; of course, > I'm not even going back to require those interface being provided by > multiple drivers, it is already a dead end. >=20 > I am not even sure any driver in the tree provides more than one = interface... >=20 > For whatever reason, I am more and more thinking that this all > new-bus[0] stuff is *way* overkill, static, bloated at will, and > missing critical features; a huge PITA to use, for the intended > purpose. >=20 > /me pissed. >=20 > - Arnaud >=20 > [0]: damn, why is it even called "newbus", this stuff is 14 years old. > It really belongs to a museum, not production code... I'm sorry you feel that way. Honestly, though, I think you'll be more pissed when you find out that = the N:1 interface that you want is being done in the wrong domain. But = I've been wrong before and look forward to seeing your replacement. acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI = interfaces. Warner= From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 07:01:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3BFA1065670; Thu, 12 Jul 2012 07:01:40 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6FF8FC12; Thu, 12 Jul 2012 07:01:40 +0000 (UTC) Received: by weyx56 with SMTP id x56so1877601wey.13 for ; Thu, 12 Jul 2012 00:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hg1ixnKhpS5GFnhza6la6hVviiJFKEM77Pbl6oNpOEc=; b=X70qm9UGDLuxesowOKAi2+G6UFBgNiK+CLf4Lnwz2kmsk+wkdLtDVcKmWqbX11RmCO y1F8iXlJ8+2Jgr2ZhrjTX2aB7+aBEbuf4bxZYg7bVrryENtBFKAY2nW6QQjVpMIOZkps cB3JfWsxStroNJWQeL1aos744ykfMyXUj6eL0dcidX7vAU300DroVxxXo66Ugo3QEki1 VNUSsnzuWixVS3aMFZFFdoT1gquw7yZnxZ2CogoqDCXfrxm3BeV7aDrloTEI8fSee3s+ TCFmhKUY/URGZe7ERrr2GZ1ho8OZGuk0aDz1omNrGS9zXApVAOeWjfjRutFYAonj7ZmB 4i2w== MIME-Version: 1.0 Received: by 10.216.29.10 with SMTP id h10mr2475824wea.126.1342076497225; Thu, 12 Jul 2012 00:01:37 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Thu, 12 Jul 2012 00:01:36 -0700 (PDT) In-Reply-To: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Thu, 12 Jul 2012 03:01:36 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 07:01:40 -0000 Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > I'm sorry you feel that way. > > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > > acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. > Does it ? From the definition of `acpi_pcib_acpi_methods', I can only see a single pcib(4) interface being exported. Moreover, I do not seem to be able to find any clue that would led any ACPI devices to attach on acpi_pcib_acpi(4), neither to find how could acpi_get_flags() ends up in acpi_pcib_read_ivar() ? Thks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 12:35:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 290541065670; Thu, 12 Jul 2012 12:35:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C0BE88FC18; Thu, 12 Jul 2012 12:35:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06565B93A; Thu, 12 Jul 2012 08:35:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 12 Jul 2012 08:01:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207120801.25810.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 08:35:05 -0400 (EDT) Cc: FreeBSD Hackers , Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 12:35:06 -0000 On Thursday, July 12, 2012 3:01:36 am Arnaud Lacombe wrote: > Hi, > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > > I'm sorry you feel that way. > > > > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > > > > acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. > > > Does it ? From the definition of `acpi_pcib_acpi_methods', I can only > see a single pcib(4) interface being exported. Moreover, I do not seem > to be able to find any clue that would led any ACPI devices to attach > on acpi_pcib_acpi(4), neither to find how could acpi_get_flags() ends > up in acpi_pcib_read_ivar() ? acpi_get_handle() is certainly supported. Relevant code snippets: sys/dev/acpica/acpivar.h: /* * Note that the low ivar values are reserved to provide * interface compatibility with ISA drivers which can also * attach to ACPI. */ #define ACPI_IVAR_HANDLE 0x100 #define ACPI_IVAR_UNUSED 0x101 /* Unused/reserved. */ #define ACPI_IVAR_PRIVATE 0x102 #define ACPI_IVAR_FLAGS 0x103 /* * Accessor functions for our ivars. Default value for BUS_READ_IVAR is * (type) 0. The accessor functions don't check return values. */ #define __ACPI_BUS_ACCESSOR(varp, var, ivarp, ivar, type) \ \ static __inline type varp ## _get_ ## var(device_t dev) \ { \ uintptr_t v = 0; \ BUS_READ_IVAR(device_get_parent(dev), dev, \ ivarp ## _IVAR_ ## ivar, &v); \ return ((type) v); \ } \ \ static __inline void varp ## _set_ ## var(device_t dev, type t) \ { \ uintptr_t v = (uintptr_t) t; \ BUS_WRITE_IVAR(device_get_parent(dev), dev, \ ivarp ## _IVAR_ ## ivar, v); \ } __ACPI_BUS_ACCESSOR(acpi, handle, ACPI, HANDLE, ACPI_HANDLE) __ACPI_BUS_ACCESSOR(acpi, private, ACPI, PRIVATE, void *) __ACPI_BUS_ACCESSOR(acpi, flags, ACPI, FLAGS, int) sys/dev/acpica/acpi_pcib_acpi.c: /* * Support for standard PCI bridge ivars. */ static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_hpcib_softc *sc = device_get_softc(dev); switch (which) { case PCIB_IVAR_DOMAIN: *result = sc->ap_segment; return (0); case PCIB_IVAR_BUS: *result = sc->ap_bus; return (0); case ACPI_IVAR_HANDLE: *result = (uintptr_t)sc->ap_handle; return (0); case ACPI_IVAR_FLAGS: *result = (uintptr_t)sc->ap_flags; return (0); } return (ENOENT); } sys/dev/acpica/acpi_pcib_pci.c: static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_pcib_softc *sc = device_get_softc(dev); switch (which) { case ACPI_IVAR_HANDLE: *result = (uintptr_t)sc->ap_handle; return (0); } return (pcib_read_ivar(dev, child, which, result)); } This is used by the ACPI PCI bus driver to detect buses that are enumerated via ACPI and to then provide the ACPI_IVAR_HANDLE for all such PCI devices. Note that ACPI PCI uses its own ivars structure (acpi_pci_devinfo) that extends the base PCI ivars to add ACPI handle and flags. sys/dev/acpi/acpi_pci.c: struct acpi_pci_devinfo { struct pci_devinfo ap_dinfo; ACPI_HANDLE ap_handle; int ap_flags; }; ... static int acpi_pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_pci_devinfo *dinfo; dinfo = device_get_ivars(child); switch (which) { case ACPI_IVAR_HANDLE: *result = (uintptr_t)dinfo->ap_handle; return (0); case ACPI_IVAR_FLAGS: *result = (uintptr_t)dinfo->ap_flags; return (0); } return (pci_read_ivar(dev, child, which, result)); } ... static int acpi_pci_attach(device_t dev) { ... /* * First, PCI devices are added as in the normal PCI bus driver. * Afterwards, the ACPI namespace under the bridge driver is * walked to save ACPI handles to all the devices that appear in * the ACPI namespace as immediate descendants of the bridge. * * XXX: Sometimes PCI devices show up in the ACPI namespace that * pci_add_children() doesn't find. We currently just ignore * these devices. */ pci_add_children(dev, domain, busno, sizeof(struct acpi_pci_devinfo)); AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, acpi_pci_save_handle, NULL, dev, NULL); ... } The main use of this feature is to get PCI interrupt routing to work correctly for ACPI bridges (i.e. using ACPI's _PRT method to route interrupts for all ACPI-enumerated bridges). The first way this is accomplished is by having each ACPI PCI bridge driver export it's own handle as the handle for it's child. This allows the ACPI PCI bus driver to detect a bus that is enumerated via ACPI and export ACPI handle ivars for each PCI device: sys/dev/acpica/acpi_pci.c: static int acpi_pci_probe(device_t dev) { if (acpi_get_handle(dev) == NULL) return (ENXIO); device_set_desc(dev, "ACPI PCI bus"); return (0); } (Note: it is calling acpi_get_handle() on a pcib device!) Secondly, to handle PCI-PCI bridges the ACPI PCI-PCI bridge driver checks for a valid ACPI handle on each PCI-PCI bridge device and returns a higher priority to claim that bridge (rather than the generic PCI-PCI bridge driver). Note again that it is calling acpi_get_handle() on a PCI device: sys/dev/acpica/acpi_pcib_pci.c: static int acpi_pcib_pci_probe(device_t dev) { if (pci_get_class(dev) != PCIC_BRIDGE || pci_get_subclass(dev) != PCIS_BRIDGE_PCI || acpi_disabled("pci")) return (ENXIO); if (acpi_get_handle(dev) == NULL) return (ENXIO); if (pci_cfgregopen() == 0) return (ENXIO); device_set_desc(dev, "ACPI PCI-PCI bridge"); return (-1000); } New-bus is certainly not the only way to organize a device hierarchy and is not perfect, but in your case I suggest you tone down your language until you have enough information to develop an informed opinion. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 12:35:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 868F71065674; Thu, 12 Jul 2012 12:35:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 560828FC0C; Thu, 12 Jul 2012 12:35:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8373DB91E; Thu, 12 Jul 2012 08:35:08 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 12 Jul 2012 08:15:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FC25A5F.4020401@rawbw.com> <20120527200850.GA63911@FreeBSD.org> <4FF3B691.5090206@rawbw.com> In-Reply-To: <4FF3B691.5090206@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201207120815.18827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 08:35:08 -0400 (EDT) Cc: Yuri , Alexey Dokuchaev Subject: Re: nvidia-driver-295.49 is highly unstable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 12:35:09 -0000 On Tuesday, July 03, 2012 11:20:49 pm Yuri wrote: > On 05/27/2012 13:08, Alexey Dokuchaev wrote: > > Perhaps you can try asking on official nVidia FreeBSD forum: > > > > http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 > > I reported there 05-28-12, but got no response. > Do you know if there is a way to report a problem with NVidia? For > example, is there a for example bugzilla or other bug reporting system > for this? > In addition, I observe system hangup for a few seconds when running > glxinfo. Also I observe Xorg freeze when I run nvidia-settings. > So I have to run 285.05.09 from cvs instead. If you read the README that comes with the driver there are notes on how to submit a bug report. You need to run a script that collects debug information and then submit an e-mail to the e-mail address in the README. It sometimes takes a few days for them to respond, but I've always had them respond. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 12:35:11 2012 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 3CA6C10656F7; Thu, 12 Jul 2012 12:35:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 483548FC14; Thu, 12 Jul 2012 12:35:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9862BB926; Thu, 12 Jul 2012 08:35:09 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 12 Jul 2012 08:26:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> In-Reply-To: <20120708110516.GA38312@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207120826.05577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 08:35:09 -0400 (EDT) Cc: Alan Cox , Warner Losh Subject: Re: contigmalloc() breaking Xorg X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 12:35:11 -0000 [ Adding alc@ for VM stuff, Warner for arm/mips bus dma brokenness ] On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > On 2012-Jul-03 21:17:53 +1000, Peter Jeremy wrote: > >I have a reasonably recent 8-stable/amd64 system (r237444) with a "ATI > >Radeon HD 2400 Pro", xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1 > >8GB RAM and ZFS. I'm seeing fairly consistent problems with Xorg > ... > >How difficult would it be to modify bus_dmamem_alloc() [at least on > >x86] to handle multi-segment allocations? > > I think I've managed to create an amd64 bus_dmamem_alloc() that allows > page-sized allocations as long as no boundary condition is specified > and no more than page-sized alignment is required (porting it to other > architectures would be trivial). I've given it a quick whirl inside a > VBox and no smoke came out but I'd appreciate someone with a better > understanding of bus_dma(9) and vm/vm_contig.c giving > http://www.rulingia.com/bugs/patch-wiredmalloc a once-over. Note that > this patch is against 8.x but there's only a trivial difference to head. > > BTW, the comment in busdma_machdep.c:bus_dmamem_alloc() > * XXX Use Contigmalloc until it is merged into this facility > * and handles multi-seg allocations. Nobody is doing > * multi-seg allocations yet though. > * XXX Certain AGP hardware does. > does not appear to be accurate. Apart from drm, quite a few drivers > call bus_dma_tag_create(9) with multiple segments and also call > bus_dmamem_alloc(9) [though I haven't verified that the calls share > the same bus_dma_tag, so I can't be absolutely certain]. I do think that all tags currently used with bus_dmamem_alloc() only use a single segment. It's a bit of an unfortunate part of the bus_dmamem API that the size of the allocate is determined by the tag (the tag should be used for determining the features and constraints of a DMA engine, not really the amount of memory to allocate). However, rather add a wiredmalloc(), I think you should just have bus_dmamem_alloc() call kmem_alloc_attr() directly in this case. One of the things I've been meaning to add to bus_dma is a way to allocate other memory types (e.g. WC memory), and in that case it would be best to just call kmem_alloc_attr() directly instead. > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > noticed they appear to potentially allocate substantial kernel stack > under some conditions as several bus_dma(9) functions include: > bus_dma_segment_t dm_segments[dmat->nsegments]; > What prevents this overflowing the kernel stack? That does seem dubious. x86 stores the array in the tag instead. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 12:35:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFBCF10657A8 for ; Thu, 12 Jul 2012 12:35:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3178B8FC15 for ; Thu, 12 Jul 2012 12:35:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7FD96B93A; Thu, 12 Jul 2012 08:35:10 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 12 Jul 2012 08:34:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342036332.8313.8.camel@albrecht-desktop> <1342040447.1123.31.camel@revolution.hippie.lan> In-Reply-To: <1342040447.1123.31.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207120834.40745.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 08:35:10 -0400 (EDT) Cc: Ian Lepore , Paul Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 12:35:18 -0000 On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > Hi, > > > > Sorry about this repost but I'm confused about the responses I received > > in my last post so I'm looking for some clarification. > > > > Specifically, I though I could use the kqueue timer as essentially a > > "drop in" replacement for linuxfd_create/read, but was surprised that > > the accuracy of the kqueue timer is much less than what I need for my > > application. > > > > So my confusion at this point is whether this is consider to be a bug or > > "feature"? > > > > Here's some test code if you want to verify the problem: > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > int > > main(void) > > { > > int i,msec; > > int kq,nev; > > struct kevent inqueue; > > struct kevent outqueue; > > struct timeval start,end; > > > > if ((kq = kqueue()) == -1) { > > fprintf(stderr, "kqueue error!? errno = %s", strerror(errno)); > > exit(EXIT_FAILURE); > > } > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > > > gettimeofday(&start, 0); > > for (i = 0; i < 50; i++) { > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) { > > fprintf(stderr, "kevent error!? errno = %s", strerror(errno)); > > exit(EXIT_FAILURE); > > } else if (outqueue.flags & EV_ERROR) { > > fprintf(stderr, "EV_ERROR: %s\n", strerror(outqueue.data)); > > exit(EXIT_FAILURE); > > } > > } > > gettimeofday(&end, 0); > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + end.tv_usec - start.tv_usec) / 1000) - 1000); > > > > printf("msec = %d\n", msec); > > > > close(kq); > > return EXIT_SUCCESS; > > } > > > > > > What you are seeing is "just the way FreeBSD currently works." > > Sleeping (in most all of its various forms, and I've just looked at the > kevent code to verify this is true there) is handled by converting the > amount of time to sleep (usually specified in a timeval or timespec > struct) to a count of timer ticks, using an internal routine called > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > account for the current tick. Whether that's a good idea or not (it > probably was once, and probably not anymore) it's how things currently > work, and could explain the fairly consistant +1ms you're seeing. This is all true, but mostly irrelevant for his case. EVFILT_TIMER installs a periodic callout that executes KNOTE() and then resets itself (via callout_reset()) each time it runs. This should generally be closer to regulary spaced intervals than something that does: for (;;) { usleep(20 * 1000); } Which should be subject to the problem you are describing. It would be interesting to see if the callout routine itself is running at the right interval or if it is being delayed. If the latter, then that should be fixed if at all possible. You could investigate that by adding KTR traces to the relevant callout routine (so recording the TSC timestamp each time the callout runs), and then parsing the ktrdump output to compute TSC deltas and examining that distribution to see if it is noisy or incorrect, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 13:21:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3A9A106566B for ; Thu, 12 Jul 2012 13:21:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 644C68FC12 for ; Thu, 12 Jul 2012 13:21:05 +0000 (UTC) Received: by yhfs35 with SMTP id s35so2969296yhf.13 for ; Thu, 12 Jul 2012 06:21:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Bg654VVqjMWN+VjKSmVNGjVxSOY4jJKrne9NDuPlQ/Y=; b=H0aFlvYadDs+2aWBzllYVc3QdaHpUSkh+QCi3P5TKELR5DjacfT/Aq3VasaeFpyB7H +mMYPx/4ZgHpRD63KtBuWMi8DtBNNNw5UFyXQbc2M5WMA5jPlQ4ssAA6gIg+yH+kHCor IoUTLUwr10FVvOYf28JkyFZ0lCMRKV3vuoImD/R1jSV8JRsW4hFBn79qryRNoKsqcZRQ iE+Ga0mAMJtU6iPTGP84fLsDgyljYZqOwb/aYLBrmIWUz0+TlI+f+wGasBNWuqwNMXcN bwBX9YMN1ubIJE1gxV6rAaOIv7fip6aonIJWV66CR2Ofaw5Ni1i98Hcpku5TXJwGPPH/ TOGg== Received: by 10.68.227.198 with SMTP id sc6mr5423759pbc.138.1342099262621; Thu, 12 Jul 2012 06:21:02 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id gh9sm3865763pbc.20.2012.07.12.06.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 06:21:01 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201207120801.25810.jhb@freebsd.org> Date: Thu, 12 Jul 2012 07:20:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <40098958-831C-49AE-8A7A-BE0B8EE15C34@bsdimp.com> References: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> <201207120801.25810.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlg0PS38WoZ9HYyh9RhjxQiEqQgbgr9f5VnYGQhlbPIIHcEEWFZVeVhNBkWNcjSmaMHYtbf Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 13:21:05 -0000 On Jul 12, 2012, at 6:01 AM, John Baldwin wrote: > New-bus is certainly not the only way to organize a device hierarchy = and is=20 > not perfect, but in your case I suggest you tone down your language = until you=20 > have enough information to develop an informed opinion. It is also not the only way to represent relationships between objects, = or to export services to the rest of the kernel. =46rom earlier = descriptions, it seems like some of these relationships aren't very = newbus-y. =46rom what I know about FDT, many of them are 'this device's = interrupt pin is tied to GPIO 12 on controller 3' which isn't a = parent/child relationship, but rather some kind of interrupt cookie = you'll need to implement bus_setup_intr. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 13:57:25 2012 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 6195D106566B for ; Thu, 12 Jul 2012 13:57:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) 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 4208E8FC0C for ; Thu, 12 Jul 2012 13:57:25 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ZR9L1j0071zF43QA3RxK03; Thu, 12 Jul 2012 13:57:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id ZRxJ1j00F4NgCEG8kRxKtz; Thu, 12 Jul 2012 13:57:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6CDvG4H015599; Thu, 12 Jul 2012 07:57:16 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201207120834.40745.jhb@freebsd.org> References: <1342036332.8313.8.camel@albrecht-desktop> <1342040447.1123.31.camel@revolution.hippie.lan> <201207120834.40745.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jul 2012 07:57:16 -0600 Message-ID: <1342101436.1123.52.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 13:57:25 -0000 On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > > Hi, > > > > > > Sorry about this repost but I'm confused about the responses I received > > > in my last post so I'm looking for some clarification. > > > > > > Specifically, I though I could use the kqueue timer as essentially a > > > "drop in" replacement for linuxfd_create/read, but was surprised that > > > the accuracy of the kqueue timer is much less than what I need for my > > > application. > > > > > > So my confusion at this point is whether this is consider to be a bug or > > > "feature"? > > > > > > Here's some test code if you want to verify the problem: > > > > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > > > > int > > > main(void) > > > { > > > int i,msec; > > > int kq,nev; > > > struct kevent inqueue; > > > struct kevent outqueue; > > > struct timeval start,end; > > > > > > if ((kq = kqueue()) == -1) { > > > fprintf(stderr, "kqueue error!? errno = %s", > strerror(errno)); > > > exit(EXIT_FAILURE); > > > } > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > > > > > gettimeofday(&start, 0); > > > for (i = 0; i < 50; i++) { > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > -1) { > > > fprintf(stderr, "kevent error!? errno = %s", > strerror(errno)); > > > exit(EXIT_FAILURE); > > > } else if (outqueue.flags & EV_ERROR) { > > > fprintf(stderr, "EV_ERROR: %s\n", > strerror(outqueue.data)); > > > exit(EXIT_FAILURE); > > > } > > > } > > > gettimeofday(&end, 0); > > > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > end.tv_usec - start.tv_usec) / 1000) - 1000); > > > > > > printf("msec = %d\n", msec); > > > > > > close(kq); > > > return EXIT_SUCCESS; > > > } > > > > > > > > > > What you are seeing is "just the way FreeBSD currently works." > > > > Sleeping (in most all of its various forms, and I've just looked at the > > kevent code to verify this is true there) is handled by converting the > > amount of time to sleep (usually specified in a timeval or timespec > > struct) to a count of timer ticks, using an internal routine called > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > > account for the current tick. Whether that's a good idea or not (it > > probably was once, and probably not anymore) it's how things currently > > work, and could explain the fairly consistant +1ms you're seeing. > > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > installs a periodic callout that executes KNOTE() and then resets itself (via > callout_reset()) each time it runs. This should generally be closer to > regulary spaced intervals than something that does: > In what way is it irrelevant? That is, what did I miss? It appears to me that the next callout is scheduled by calling timertoticks() passing a count of milliseconds, that count is converted to a struct timeval and passed to tvtohz() which is where the +1 adjustment happens. If you ask for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. There is some time, likely a small number of microseconds, that you've consumed of the current tick, and that's what the +1 in tvtohz() is supposed to account for according to the comments. The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick and then adds one tick on top of that. That seems not quite right to me, except that it is a way to g'tee that you don't return early, and that is the one promise made by sleep routines on any OS; those magical "at least" words always appear in the docs. Actually what I'm missing (that I know of) is how the scheduler works. Maybe the +1 adjustment to account for the fraction of the current tick you've already consumed is the right thing to do, even when that fraction is 1uS or less of a 1mS tick. That would depend on scheduler behavior that I know nothing about. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 14:26:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 653901065672 for ; Thu, 12 Jul 2012 14:26:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20B218FC17 for ; Thu, 12 Jul 2012 14:26:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6DD63B960; Thu, 12 Jul 2012 10:26:39 -0400 (EDT) From: John Baldwin To: Ian Lepore Date: Thu, 12 Jul 2012 10:26:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342036332.8313.8.camel@albrecht-desktop> <201207120834.40745.jhb@freebsd.org> <1342101436.1123.52.camel@revolution.hippie.lan> In-Reply-To: <1342101436.1123.52.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207121026.37849.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 10:26:39 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 14:26:40 -0000 On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > > > Hi, > > > > > > > > Sorry about this repost but I'm confused about the responses I received > > > > in my last post so I'm looking for some clarification. > > > > > > > > Specifically, I though I could use the kqueue timer as essentially a > > > > "drop in" replacement for linuxfd_create/read, but was surprised that > > > > the accuracy of the kqueue timer is much less than what I need for my > > > > application. > > > > > > > > So my confusion at this point is whether this is consider to be a bug or > > > > "feature"? > > > > > > > > Here's some test code if you want to verify the problem: > > > > > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > > > > > int > > > > main(void) > > > > { > > > > int i,msec; > > > > int kq,nev; > > > > struct kevent inqueue; > > > > struct kevent outqueue; > > > > struct timeval start,end; > > > > > > > > if ((kq = kqueue()) == -1) { > > > > fprintf(stderr, "kqueue error!? errno = %s", > > strerror(errno)); > > > > exit(EXIT_FAILURE); > > > > } > > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > > > > > > > gettimeofday(&start, 0); > > > > for (i = 0; i < 50; i++) { > > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > > -1) { > > > > fprintf(stderr, "kevent error!? errno = %s", > > strerror(errno)); > > > > exit(EXIT_FAILURE); > > > > } else if (outqueue.flags & EV_ERROR) { > > > > fprintf(stderr, "EV_ERROR: %s\n", > > strerror(outqueue.data)); > > > > exit(EXIT_FAILURE); > > > > } > > > > } > > > > gettimeofday(&end, 0); > > > > > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > > end.tv_usec - start.tv_usec) / 1000) - 1000); > > > > > > > > printf("msec = %d\n", msec); > > > > > > > > close(kq); > > > > return EXIT_SUCCESS; > > > > } > > > > > > > > > > > > > > What you are seeing is "just the way FreeBSD currently works." > > > > > > Sleeping (in most all of its various forms, and I've just looked at the > > > kevent code to verify this is true there) is handled by converting the > > > amount of time to sleep (usually specified in a timeval or timespec > > > struct) to a count of timer ticks, using an internal routine called > > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > > > account for the current tick. Whether that's a good idea or not (it > > > probably was once, and probably not anymore) it's how things currently > > > work, and could explain the fairly consistant +1ms you're seeing. > > > > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > > installs a periodic callout that executes KNOTE() and then resets itself (via > > callout_reset()) each time it runs. This should generally be closer to > > regulary spaced intervals than something that does: > > > > In what way is it irrelevant? That is, what did I miss? It appears to > me that the next callout is scheduled by calling timertoticks() passing > a count of milliseconds, that count is converted to a struct timeval and > passed to tvtohz() which is where the +1 adjustment happens. If you ask > for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > There is some time, likely a small number of microseconds, that you've > consumed of the current tick, and that's what the +1 in tvtohz() is > supposed to account for according to the comments. > > The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > and then adds one tick on top of that. That seems not quite right to > me, except that it is a way to g'tee that you don't return early, and > that is the one promise made by sleep routines on any OS; those magical > "at least" words always appear in the docs. > > Actually what I'm missing (that I know of) is how the scheduler works. > Maybe the +1 adjustment to account for the fraction of the current tick > you've already consumed is the right thing to do, even when that > fraction is 1uS or less of a 1mS tick. That would depend on scheduler > behavior that I know nothing about. Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this case. That is, the +1 makes sense when you are computing a one-time delta for things like nanosleep(). It is incorrect when computing a periodic delta such as for computing the interval for an itimer (setitimer) or EVFILT_TIMER(). Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: sys/kern/kern_time.c: /* * Real interval timer expired: * send process whose timer expired an alarm signal. * If time is not set up to reload, then just return. * Else compute next time timer should go off which is > current time. * This is where delay in processing this timeout causes multiple * SIGALRM calls to be compressed into one. * tvtohz() always adds 1 to allow for the time until the next clock * interrupt being strictly less than 1 clock tick, but we don't want * that here since we want to appear to be in sync with the clock * interrupt even when we're delayed. */ void realitexpire(void *arg) { struct proc *p; struct timeval ctv, ntv; p = (struct proc *)arg; PROC_LOCK(p); kern_psignal(p, SIGALRM); if (!timevalisset(&p->p_realtimer.it_interval)) { timevalclear(&p->p_realtimer.it_value); if (p->p_flag & P_WEXIT) wakeup(&p->p_itcallout); PROC_UNLOCK(p); return; } for (;;) { timevaladd(&p->p_realtimer.it_value, &p->p_realtimer.it_interval); getmicrouptime(&ctv); if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { ntv = p->p_realtimer.it_value; timevalsub(&ntv, &ctv); callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, realitexpire, p); PROC_UNLOCK(p); return; } } /*NOTREACHED*/ } Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as seitimer() above: Index: kern_event.c =================================================================== --- kern_event.c (revision 238365) +++ kern_event.c (working copy) @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { calloutp = (struct callout *)kn->kn_hook; - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, filt_timerexpire, kn); } } -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 15:08:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2733A106564A; Thu, 12 Jul 2012 15:08:48 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E599A8FC0C; Thu, 12 Jul 2012 15:08:47 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so4298578pbb.13 for ; Thu, 12 Jul 2012 08:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4AaFI4QS6ERpZZSYCxcuExDXaY5WkuWs7JkhkBFtLTo=; b=wUEv9FpULNgphLctDhqNR5ajaPjWT7c+TnmIrugqpiX7viwumojYQRBuGJbzZNtUfC 7HegM0Y4MAhe+ercSDyVhELJP1wwlmOPiQsKhu5oMnkJHrupMZlqSs8+iFmNYuwmNI0O 8LtXPyPtIqn8yzqpGrOAFgRfvWwshm8B+qHqp6+hw2ffkvDUQ2XPZhDDuSrFj8RgUoPM ohCtlnHPqPYTzy2XTaHbAPR/1JNHD6Whmlzpk/1JjDUSV0konM+qdQJw8S9ENIebC92t WeJYhHSX55iHMKsOo+SgxxU4CceXJJL7lpGEOHQoHysXNfH0ZihYiXLMwbW+JZoEHlB0 mLcw== MIME-Version: 1.0 Received: by 10.68.191.8 with SMTP id gu8mr6059526pbc.158.1342105727336; Thu, 12 Jul 2012 08:08:47 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.66.82.201 with HTTP; Thu, 12 Jul 2012 08:08:47 -0700 (PDT) In-Reply-To: <201207121026.37849.jhb@freebsd.org> References: <1342036332.8313.8.camel@albrecht-desktop> <201207120834.40745.jhb@freebsd.org> <1342101436.1123.52.camel@revolution.hippie.lan> <201207121026.37849.jhb@freebsd.org> Date: Thu, 12 Jul 2012 17:08:47 +0200 X-Google-Sender-Auth: Xl1_P-7sPxWeempwNv3QCLiW1ao Message-ID: From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Paul Albrecht , freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 15:08:48 -0000 On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: >> > > > Hi, >> > > > >> > > > Sorry about this repost but I'm confused about the responses I received >> > > > in my last post so I'm looking for some clarification. >> > > > >> > > > Specifically, I though I could use the kqueue timer as essentially a >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that >> > > > the accuracy of the kqueue timer is much less than what I need for my >> > > > application. >> > > > >> > > > So my confusion at this point is whether this is consider to be a bug or >> > > > "feature"? >> > > > >> > > > Here's some test code if you want to verify the problem: >> > > > >> > > > #include >> > > > #include >> > > > #include >> > > > #include >> > > > #include >> > > > #include >> > > > #include >> > > > #include >> > > > >> > > > int >> > > > main(void) >> > > > { >> > > > int i,msec; >> > > > int kq,nev; >> > > > struct kevent inqueue; >> > > > struct kevent outqueue; >> > > > struct timeval start,end; >> > > > >> > > > if ((kq = kqueue()) == -1) { >> > > > fprintf(stderr, "kqueue error!? errno = %s", >> > strerror(errno)); >> > > > exit(EXIT_FAILURE); >> > > > } >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); >> > > > >> > > > gettimeofday(&start, 0); >> > > > for (i = 0; i < 50; i++) { >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == >> > -1) { >> > > > fprintf(stderr, "kevent error!? errno = %s", >> > strerror(errno)); >> > > > exit(EXIT_FAILURE); >> > > > } else if (outqueue.flags & EV_ERROR) { >> > > > fprintf(stderr, "EV_ERROR: %s\n", >> > strerror(outqueue.data)); >> > > > exit(EXIT_FAILURE); >> > > > } >> > > > } >> > > > gettimeofday(&end, 0); >> > > > >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + >> > end.tv_usec - start.tv_usec) / 1000) - 1000); >> > > > >> > > > printf("msec = %d\n", msec); >> > > > >> > > > close(kq); >> > > > return EXIT_SUCCESS; >> > > > } >> > > > >> > > > >> > > >> > > What you are seeing is "just the way FreeBSD currently works." >> > > >> > > Sleeping (in most all of its various forms, and I've just looked at the >> > > kevent code to verify this is true there) is handled by converting the >> > > amount of time to sleep (usually specified in a timeval or timespec >> > > struct) to a count of timer ticks, using an internal routine called >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to >> > > account for the current tick. Whether that's a good idea or not (it >> > > probably was once, and probably not anymore) it's how things currently >> > > work, and could explain the fairly consistant +1ms you're seeing. >> > >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER >> > installs a periodic callout that executes KNOTE() and then resets itself (via >> > callout_reset()) each time it runs. This should generally be closer to >> > regulary spaced intervals than something that does: >> > >> >> In what way is it irrelevant? That is, what did I miss? It appears to >> me that the next callout is scheduled by calling timertoticks() passing >> a count of milliseconds, that count is converted to a struct timeval and >> passed to tvtohz() which is where the +1 adjustment happens. If you ask >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. >> There is some time, likely a small number of microseconds, that you've >> consumed of the current tick, and that's what the +1 in tvtohz() is >> supposed to account for according to the comments. >> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick >> and then adds one tick on top of that. That seems not quite right to >> me, except that it is a way to g'tee that you don't return early, and >> that is the one promise made by sleep routines on any OS; those magical >> "at least" words always appear in the docs. >> >> Actually what I'm missing (that I know of) is how the scheduler works. >> Maybe the +1 adjustment to account for the fraction of the current tick >> you've already consumed is the right thing to do, even when that >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler >> behavior that I know nothing about. > > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > case. That is, the +1 makes sense when you are computing a one-time delta > for things like nanosleep(). It is incorrect when computing a periodic > delta such as for computing the interval for an itimer (setitimer) or > EVFILT_TIMER(). > > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > > sys/kern/kern_time.c: > > /* > * Real interval timer expired: > * send process whose timer expired an alarm signal. > * If time is not set up to reload, then just return. > * Else compute next time timer should go off which is > current time. > * This is where delay in processing this timeout causes multiple > * SIGALRM calls to be compressed into one. > * tvtohz() always adds 1 to allow for the time until the next clock > * interrupt being strictly less than 1 clock tick, but we don't want > * that here since we want to appear to be in sync with the clock > * interrupt even when we're delayed. > */ > void > realitexpire(void *arg) > { > struct proc *p; > struct timeval ctv, ntv; > > p = (struct proc *)arg; > PROC_LOCK(p); > kern_psignal(p, SIGALRM); > if (!timevalisset(&p->p_realtimer.it_interval)) { > timevalclear(&p->p_realtimer.it_value); > if (p->p_flag & P_WEXIT) > wakeup(&p->p_itcallout); > PROC_UNLOCK(p); > return; > } > for (;;) { > timevaladd(&p->p_realtimer.it_value, > &p->p_realtimer.it_interval); > getmicrouptime(&ctv); > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > ntv = p->p_realtimer.it_value; > timevalsub(&ntv, &ctv); > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > realitexpire, p); > PROC_UNLOCK(p); > return; > } > } > /*NOTREACHED*/ > } > > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > seitimer() above: > > Index: kern_event.c > =================================================================== > --- kern_event.c (revision 238365) > +++ kern_event.c (working copy) > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > calloutp = (struct callout *)kn->kn_hook; > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > filt_timerexpire, kn); > } > } > > -- > John Baldwin > _______________________________________________ > 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, I don't think it's good to decrease by a unit the 'ticks' you pass to callout_reset_* KPI. If this have to be fixed it should be fixed at the callout level and not at the consumer level. In other words, subsystems that makes use of callout_reset_* should not deal with the inherent limitations of callout precision, as it is right now. Davide From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 15:36:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D77B91065670; Thu, 12 Jul 2012 15:36:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98E838FC1C; Thu, 12 Jul 2012 15:36:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 04404B94E; Thu, 12 Jul 2012 11:36:17 -0400 (EDT) From: John Baldwin To: Davide Italiano Date: Thu, 12 Jul 2012 11:25:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342036332.8313.8.camel@albrecht-desktop> <201207121026.37849.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207121125.01228.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 11:36:17 -0400 (EDT) Cc: Ian Lepore , Paul Albrecht , freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 15:36:17 -0000 On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: > On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > >> > > > Hi, > >> > > > > >> > > > Sorry about this repost but I'm confused about the responses I received > >> > > > in my last post so I'm looking for some clarification. > >> > > > > >> > > > Specifically, I though I could use the kqueue timer as essentially a > >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that > >> > > > the accuracy of the kqueue timer is much less than what I need for my > >> > > > application. > >> > > > > >> > > > So my confusion at this point is whether this is consider to be a bug or > >> > > > "feature"? > >> > > > > >> > > > Here's some test code if you want to verify the problem: > >> > > > > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > > >> > > > int > >> > > > main(void) > >> > > > { > >> > > > int i,msec; > >> > > > int kq,nev; > >> > > > struct kevent inqueue; > >> > > > struct kevent outqueue; > >> > > > struct timeval start,end; > >> > > > > >> > > > if ((kq = kqueue()) == -1) { > >> > > > fprintf(stderr, "kqueue error!? errno = %s", > >> > strerror(errno)); > >> > > > exit(EXIT_FAILURE); > >> > > > } > >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > >> > > > > >> > > > gettimeofday(&start, 0); > >> > > > for (i = 0; i < 50; i++) { > >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > >> > -1) { > >> > > > fprintf(stderr, "kevent error!? errno = %s", > >> > strerror(errno)); > >> > > > exit(EXIT_FAILURE); > >> > > > } else if (outqueue.flags & EV_ERROR) { > >> > > > fprintf(stderr, "EV_ERROR: %s\n", > >> > strerror(outqueue.data)); > >> > > > exit(EXIT_FAILURE); > >> > > > } > >> > > > } > >> > > > gettimeofday(&end, 0); > >> > > > > >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > >> > end.tv_usec - start.tv_usec) / 1000) - 1000); > >> > > > > >> > > > printf("msec = %d\n", msec); > >> > > > > >> > > > close(kq); > >> > > > return EXIT_SUCCESS; > >> > > > } > >> > > > > >> > > > > >> > > > >> > > What you are seeing is "just the way FreeBSD currently works." > >> > > > >> > > Sleeping (in most all of its various forms, and I've just looked at the > >> > > kevent code to verify this is true there) is handled by converting the > >> > > amount of time to sleep (usually specified in a timeval or timespec > >> > > struct) to a count of timer ticks, using an internal routine called > >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > >> > > account for the current tick. Whether that's a good idea or not (it > >> > > probably was once, and probably not anymore) it's how things currently > >> > > work, and could explain the fairly consistant +1ms you're seeing. > >> > > >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > >> > installs a periodic callout that executes KNOTE() and then resets itself (via > >> > callout_reset()) each time it runs. This should generally be closer to > >> > regulary spaced intervals than something that does: > >> > > >> > >> In what way is it irrelevant? That is, what did I miss? It appears to > >> me that the next callout is scheduled by calling timertoticks() passing > >> a count of milliseconds, that count is converted to a struct timeval and > >> passed to tvtohz() which is where the +1 adjustment happens. If you ask > >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > >> There is some time, likely a small number of microseconds, that you've > >> consumed of the current tick, and that's what the +1 in tvtohz() is > >> supposed to account for according to the comments. > >> > >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > >> and then adds one tick on top of that. That seems not quite right to > >> me, except that it is a way to g'tee that you don't return early, and > >> that is the one promise made by sleep routines on any OS; those magical > >> "at least" words always appear in the docs. > >> > >> Actually what I'm missing (that I know of) is how the scheduler works. > >> Maybe the +1 adjustment to account for the fraction of the current tick > >> you've already consumed is the right thing to do, even when that > >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler > >> behavior that I know nothing about. > > > > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > > case. That is, the +1 makes sense when you are computing a one-time delta > > for things like nanosleep(). It is incorrect when computing a periodic > > delta such as for computing the interval for an itimer (setitimer) or > > EVFILT_TIMER(). > > > > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > > > > sys/kern/kern_time.c: > > > > /* > > * Real interval timer expired: > > * send process whose timer expired an alarm signal. > > * If time is not set up to reload, then just return. > > * Else compute next time timer should go off which is > current time. > > * This is where delay in processing this timeout causes multiple > > * SIGALRM calls to be compressed into one. > > * tvtohz() always adds 1 to allow for the time until the next clock > > * interrupt being strictly less than 1 clock tick, but we don't want > > * that here since we want to appear to be in sync with the clock > > * interrupt even when we're delayed. > > */ > > void > > realitexpire(void *arg) > > { > > struct proc *p; > > struct timeval ctv, ntv; > > > > p = (struct proc *)arg; > > PROC_LOCK(p); > > kern_psignal(p, SIGALRM); > > if (!timevalisset(&p->p_realtimer.it_interval)) { > > timevalclear(&p->p_realtimer.it_value); > > if (p->p_flag & P_WEXIT) > > wakeup(&p->p_itcallout); > > PROC_UNLOCK(p); > > return; > > } > > for (;;) { > > timevaladd(&p->p_realtimer.it_value, > > &p->p_realtimer.it_interval); > > getmicrouptime(&ctv); > > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > > ntv = p->p_realtimer.it_value; > > timevalsub(&ntv, &ctv); > > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > > realitexpire, p); > > PROC_UNLOCK(p); > > return; > > } > > } > > /*NOTREACHED*/ > > } > > > > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > > seitimer() above: > > > > Index: kern_event.c > > =================================================================== > > --- kern_event.c (revision 238365) > > +++ kern_event.c (working copy) > > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > > > > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > > calloutp = (struct callout *)kn->kn_hook; > > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > > filt_timerexpire, kn); > > } > > } > > > > -- > > John Baldwin > > _______________________________________________ > > 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, > I don't think it's good to decrease by a unit the 'ticks' you pass to > callout_reset_* KPI. > If this have to be fixed it should be fixed at the callout level and > not at the consumer level. In other words, subsystems that makes use > of callout_reset_* should not deal with the inherent limitations of > callout precision, as it is right now. Given that you are reworking callout already, it would seem a bit odd to rework callout a separate time just to fix this bug. A simple fix like this (which follows the same pattern we already use for setitimer()) is something we can easily merge back to 8 and 9. Reworking callout in a different way than you are already doing, OTOH, is not something we can merge trivially. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 15:40:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BD581065674 for ; Thu, 12 Jul 2012 15:40:43 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 694348FC14 for ; Thu, 12 Jul 2012 15:40:43 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta12.emeryville.ca.mail.comcast.net with comcast id ZTcM1j00A0EPchoACTgjQZ; Thu, 12 Jul 2012 15:40:43 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta01.emeryville.ca.mail.comcast.net with comcast id ZTgh1j0154NgCEG8MTgiz3; Thu, 12 Jul 2012 15:40:43 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6CFee5J015714; Thu, 12 Jul 2012 09:40:40 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Davide Italiano In-Reply-To: References: <1342036332.8313.8.camel@albrecht-desktop> <201207120834.40745.jhb@freebsd.org> <1342101436.1123.52.camel@revolution.hippie.lan> <201207121026.37849.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jul 2012 09:40:40 -0600 Message-ID: <1342107640.1123.70.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 15:40:43 -0000 On Thu, 2012-07-12 at 17:08 +0200, Davide Italiano wrote: > On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > >> > > > Hi, > >> > > > > >> > > > Sorry about this repost but I'm confused about the responses I received > >> > > > in my last post so I'm looking for some clarification. > >> > > > > >> > > > Specifically, I though I could use the kqueue timer as essentially a > >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that > >> > > > the accuracy of the kqueue timer is much less than what I need for my > >> > > > application. > >> > > > > >> > > > So my confusion at this point is whether this is consider to be a bug or > >> > > > "feature"? > >> > > > > >> > > > Here's some test code if you want to verify the problem: > >> > > > > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > #include > >> > > > > >> > > > int > >> > > > main(void) > >> > > > { > >> > > > int i,msec; > >> > > > int kq,nev; > >> > > > struct kevent inqueue; > >> > > > struct kevent outqueue; > >> > > > struct timeval start,end; > >> > > > > >> > > > if ((kq = kqueue()) == -1) { > >> > > > fprintf(stderr, "kqueue error!? errno = %s", > >> > strerror(errno)); > >> > > > exit(EXIT_FAILURE); > >> > > > } > >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > >> > > > > >> > > > gettimeofday(&start, 0); > >> > > > for (i = 0; i < 50; i++) { > >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > >> > -1) { > >> > > > fprintf(stderr, "kevent error!? errno = %s", > >> > strerror(errno)); > >> > > > exit(EXIT_FAILURE); > >> > > > } else if (outqueue.flags & EV_ERROR) { > >> > > > fprintf(stderr, "EV_ERROR: %s\n", > >> > strerror(outqueue.data)); > >> > > > exit(EXIT_FAILURE); > >> > > > } > >> > > > } > >> > > > gettimeofday(&end, 0); > >> > > > > >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > >> > end.tv_usec - start.tv_usec) / 1000) - 1000); > >> > > > > >> > > > printf("msec = %d\n", msec); > >> > > > > >> > > > close(kq); > >> > > > return EXIT_SUCCESS; > >> > > > } > >> > > > > >> > > > > >> > > > >> > > What you are seeing is "just the way FreeBSD currently works." > >> > > > >> > > Sleeping (in most all of its various forms, and I've just looked at the > >> > > kevent code to verify this is true there) is handled by converting the > >> > > amount of time to sleep (usually specified in a timeval or timespec > >> > > struct) to a count of timer ticks, using an internal routine called > >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > >> > > account for the current tick. Whether that's a good idea or not (it > >> > > probably was once, and probably not anymore) it's how things currently > >> > > work, and could explain the fairly consistant +1ms you're seeing. > >> > > >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > >> > installs a periodic callout that executes KNOTE() and then resets itself (via > >> > callout_reset()) each time it runs. This should generally be closer to > >> > regulary spaced intervals than something that does: > >> > > >> > >> In what way is it irrelevant? That is, what did I miss? It appears to > >> me that the next callout is scheduled by calling timertoticks() passing > >> a count of milliseconds, that count is converted to a struct timeval and > >> passed to tvtohz() which is where the +1 adjustment happens. If you ask > >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > >> There is some time, likely a small number of microseconds, that you've > >> consumed of the current tick, and that's what the +1 in tvtohz() is > >> supposed to account for according to the comments. > >> > >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > >> and then adds one tick on top of that. That seems not quite right to > >> me, except that it is a way to g'tee that you don't return early, and > >> that is the one promise made by sleep routines on any OS; those magical > >> "at least" words always appear in the docs. > >> > >> Actually what I'm missing (that I know of) is how the scheduler works. > >> Maybe the +1 adjustment to account for the fraction of the current tick > >> you've already consumed is the right thing to do, even when that > >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler > >> behavior that I know nothing about. > > > > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > > case. That is, the +1 makes sense when you are computing a one-time delta > > for things like nanosleep(). It is incorrect when computing a periodic > > delta such as for computing the interval for an itimer (setitimer) or > > EVFILT_TIMER(). > > > > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > > > > sys/kern/kern_time.c: > > > > /* > > * Real interval timer expired: > > * send process whose timer expired an alarm signal. > > * If time is not set up to reload, then just return. > > * Else compute next time timer should go off which is > current time. > > * This is where delay in processing this timeout causes multiple > > * SIGALRM calls to be compressed into one. > > * tvtohz() always adds 1 to allow for the time until the next clock > > * interrupt being strictly less than 1 clock tick, but we don't want > > * that here since we want to appear to be in sync with the clock > > * interrupt even when we're delayed. > > */ > > void > > realitexpire(void *arg) > > { > > struct proc *p; > > struct timeval ctv, ntv; > > > > p = (struct proc *)arg; > > PROC_LOCK(p); > > kern_psignal(p, SIGALRM); > > if (!timevalisset(&p->p_realtimer.it_interval)) { > > timevalclear(&p->p_realtimer.it_value); > > if (p->p_flag & P_WEXIT) > > wakeup(&p->p_itcallout); > > PROC_UNLOCK(p); > > return; > > } > > for (;;) { > > timevaladd(&p->p_realtimer.it_value, > > &p->p_realtimer.it_interval); > > getmicrouptime(&ctv); > > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > > ntv = p->p_realtimer.it_value; > > timevalsub(&ntv, &ctv); > > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > > realitexpire, p); > > PROC_UNLOCK(p); > > return; > > } > > } > > /*NOTREACHED*/ > > } > > > > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > > seitimer() above: > > > > Index: kern_event.c > > =================================================================== > > --- kern_event.c (revision 238365) > > +++ kern_event.c (working copy) > > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > > > > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > > calloutp = (struct callout *)kn->kn_hook; > > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > > filt_timerexpire, kn); > > } > > } > > > > -- > > John Baldwin > > _______________________________________________ > > 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, > I don't think it's good to decrease by a unit the 'ticks' you pass to > callout_reset_* KPI. > If this have to be fixed it should be fixed at the callout level and > not at the consumer level. In other words, subsystems that makes use > of callout_reset_* should not deal with the inherent limitations of > callout precision, as it is right now. > > Davide I'm not sure it can be fixed in the callout_reset_* routines because those routines have no idea whether the passed-in tick count came from tvtohz() where the +1 gets applied. Either tvtohz() has to stop adding a tick, then other code that needs the adjustment has to be changed to add it, or code that doesn't need the adjustment has to subtract it back out. Neither prospect is very appealing, really. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 16:30:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE8FB106564A; Thu, 12 Jul 2012 16:30:53 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 852C68FC12; Thu, 12 Jul 2012 16:30:53 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Thu, 12 Jul 2012 11:19:46 -0500 From: Paul Albrecht To: John Baldwin In-Reply-To: <201207121026.37849.jhb@freebsd.org> References: <1342036332.8313.8.camel@albrecht-desktop> <201207120834.40745.jhb@freebsd.org> <1342101436.1123.52.camel@revolution.hippie.lan> <201207121026.37849.jhb@freebsd.org> Content-Type: text/plain Date: Thu, 12 Jul 2012 11:28:48 -0500 Message-ID: <1342110528.7071.3.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Paul Albrecht , "freebsd-hackers@freebsd.org" Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 16:30:53 -0000 On Thu, 2012-07-12 at 09:26 -0500, John Baldwin wrote: > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > > On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > > > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > > > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > > > > Hi, > > > > > > > > > > Sorry about this repost but I'm confused about the responses I received > > > > > in my last post so I'm looking for some clarification. > > > > > > > > > > Specifically, I though I could use the kqueue timer as essentially a > > > > > "drop in" replacement for linuxfd_create/read, but was surprised that > > > > > the accuracy of the kqueue timer is much less than what I need for my > > > > > application. > > > > > > > > > > So my confusion at this point is whether this is consider to be a bug or > > > > > "feature"? > > > > > > > > > > Here's some test code if you want to verify the problem: > > > > > > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > > > > > > int > > > > > main(void) > > > > > { > > > > > int i,msec; > > > > > int kq,nev; > > > > > struct kevent inqueue; > > > > > struct kevent outqueue; > > > > > struct timeval start,end; > > > > > > > > > > if ((kq = kqueue()) == -1) { > > > > > fprintf(stderr, "kqueue error!? errno = %s", > > > strerror(errno)); > > > > > exit(EXIT_FAILURE); > > > > > } > > > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > > > > > > > > > gettimeofday(&start, 0); > > > > > for (i = 0; i < 50; i++) { > > > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > > > -1) { > > > > > fprintf(stderr, "kevent error!? errno = %s", > > > strerror(errno)); > > > > > exit(EXIT_FAILURE); > > > > > } else if (outqueue.flags & EV_ERROR) { > > > > > fprintf(stderr, "EV_ERROR: %s\n", > > > strerror(outqueue.data)); > > > > > exit(EXIT_FAILURE); > > > > > } > > > > > } > > > > > gettimeofday(&end, 0); > > > > > > > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > > > end.tv_usec - start.tv_usec) / 1000) - 1000); > > > > > > > > > > printf("msec = %d\n", msec); > > > > > > > > > > close(kq); > > > > > return EXIT_SUCCESS; > > > > > } > > > > > > > > > > > > > > > > > > What you are seeing is "just the way FreeBSD currently works." > > > > > > > > Sleeping (in most all of its various forms, and I've just looked at the > > > > kevent code to verify this is true there) is handled by converting the > > > > amount of time to sleep (usually specified in a timeval or timespec > > > > struct) to a count of timer ticks, using an internal routine called > > > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > > > > account for the current tick. Whether that's a good idea or not (it > > > > probably was once, and probably not anymore) it's how things currently > > > > work, and could explain the fairly consistant +1ms you're seeing. > > > > > > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > > > installs a periodic callout that executes KNOTE() and then resets itself (via > > > callout_reset()) each time it runs. This should generally be closer to > > > regulary spaced intervals than something that does: > > > > > > > In what way is it irrelevant? That is, what did I miss? It appears to > > me that the next callout is scheduled by calling timertoticks() passing > > a count of milliseconds, that count is converted to a struct timeval and > > passed to tvtohz() which is where the +1 adjustment happens. If you ask > > for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > > There is some time, likely a small number of microseconds, that you've > > consumed of the current tick, and that's what the +1 in tvtohz() is > > supposed to account for according to the comments. > > > > The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > > and then adds one tick on top of that. That seems not quite right to > > me, except that it is a way to g'tee that you don't return early, and > > that is the one promise made by sleep routines on any OS; those magical > > "at least" words always appear in the docs. > > > > Actually what I'm missing (that I know of) is how the scheduler works. > > Maybe the +1 adjustment to account for the fraction of the current tick > > you've already consumed is the right thing to do, even when that > > fraction is 1uS or less of a 1mS tick. That would depend on scheduler > > behavior that I know nothing about. > > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > case. That is, the +1 makes sense when you are computing a one-time delta > for things like nanosleep(). It is incorrect when computing a periodic > delta such as for computing the interval for an itimer (setitimer) or > EVFILT_TIMER(). > > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > > sys/kern/kern_time.c: > > /* > * Real interval timer expired: > * send process whose timer expired an alarm signal. > * If time is not set up to reload, then just return. > * Else compute next time timer should go off which is > current time. > * This is where delay in processing this timeout causes multiple > * SIGALRM calls to be compressed into one. > * tvtohz() always adds 1 to allow for the time until the next clock > * interrupt being strictly less than 1 clock tick, but we don't want > * that here since we want to appear to be in sync with the clock > * interrupt even when we're delayed. > */ > void > realitexpire(void *arg) > { > struct proc *p; > struct timeval ctv, ntv; > > p = (struct proc *)arg; > PROC_LOCK(p); > kern_psignal(p, SIGALRM); > if (!timevalisset(&p->p_realtimer.it_interval)) { > timevalclear(&p->p_realtimer.it_value); > if (p->p_flag & P_WEXIT) > wakeup(&p->p_itcallout); > PROC_UNLOCK(p); > return; > } > for (;;) { > timevaladd(&p->p_realtimer.it_value, > &p->p_realtimer.it_interval); > getmicrouptime(&ctv); > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > ntv = p->p_realtimer.it_value; > timevalsub(&ntv, &ctv); > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > realitexpire, p); > PROC_UNLOCK(p); > return; > } > } > /*NOTREACHED*/ > } > > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > seitimer() above: > > Index: kern_event.c > =================================================================== > --- kern_event.c (revision 238365) > +++ kern_event.c (working copy) > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > calloutp = (struct callout *)kn->kn_hook; > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > filt_timerexpire, kn); > } > } > I tested your fix this morning and it works perfectly. Thanks!! When will your fix be available for current? -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 16:36:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 200D2106566C for ; Thu, 12 Jul 2012 16:36:08 +0000 (UTC) (envelope-from bcrisp@crispernetworks.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C72BE8FC14 for ; Thu, 12 Jul 2012 16:36:07 +0000 (UTC) Received: by vcbf1 with SMTP id f1so1942785vcb.13 for ; Thu, 12 Jul 2012 09:36:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=3d3FTxIiz3laFgUmzT9chtPi169n0nZUiK0ZuapXDgA=; b=ZrI8LEjXpS6f32Vm5Yn6ETpIEOCYQM0ThiB+34k7yFVi0FLAWjZ0uCkMtxN/d22xMf 4tekuFATfJtnEdKG9Nt6ouUH5tt8fswmLTOQnkuTvYPAyA8qlHmKh/k56MRqvf9PgPZX FONZsTdPuiL5J528+Gao2LtxMJ6RPvzn60Nl9zfy1XmnKX7ux/49FcsSqEAmocq74xpj uiKlUyPA/Dg5CGcO/BsuZMzWVvJFCas0p8APWr8luoCSd4BkeBh7SDzxl0A1/VbFfoVX hM1vUe6mGIM0ljPHFpmjlWcJksxMooICufJx6ef6UQG+6B+mwWDATInh2GxRA/QWJqYu L8cA== MIME-Version: 1.0 Received: by 10.52.92.70 with SMTP id ck6mr22270442vdb.16.1342110967202; Thu, 12 Jul 2012 09:36:07 -0700 (PDT) Received: by 10.58.216.6 with HTTP; Thu, 12 Jul 2012 09:36:07 -0700 (PDT) Date: Thu, 12 Jul 2012 12:36:07 -0400 Message-ID: From: Bill Crisp To: freebsd-hackers@freebsd.org X-Gm-Message-State: ALoCoQnMbHO8ZZLnqLSqDQobbznZAufVFHMhYQzoDA7k91Y/erVB4Cxfskf/BkPfNSSm/f8AawiK Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:36:08 -0000 Good Morning! This was also posted to the FreeBSD forums: I have been researching CVE-2012-0217 and while I have patched the kernels on servers with 7.3/8.2 that I have, I would like to see if anyone knows for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are out of support from looking at the documentation. I have looked at the code in trap.c to see if the current patch would work with 6.3 source but it won't based on what I saw. I am also aware of upgrading as an option to resolve this unfortunately in some cases I have this is not possible right now. Any help would be greatly appreciated, and I can of course test anything that might need it. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 17:53:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B08D106566C; Thu, 12 Jul 2012 17:53:17 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7097E8FC16; Thu, 12 Jul 2012 17:53:16 +0000 (UTC) Received: by bkcje9 with SMTP id je9so2603896bkc.13 for ; Thu, 12 Jul 2012 10:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jb5PuemlQ3wFqLlM+GjsoI3Ie823Pu5zb/fAKULk9sA=; b=Id5Lpt4hS1W3UbhAIu/wDmdPg5G3jeFW+ZuwFU6teGqOwKi78Bgl4QwuBV2SOjVPfO c8TDWsaolXjUuR5w7lIANbxF06Rey9TTIGMGaHMRpcELECXYCT3eWzEqTBLUwhPzmAVO FtDekevqaE4PAPxOypIyIPXozU4X+c0M1Cqx2urkMibtU75rjwi8kHITEJulw3s94uHj loQdfyrjTLonFxA3bmVTKw07izLARu29dD0h+UGYoPGpqacv8eugiodvJGkaTJLMSMfZ +8SQP7kEiHPxQdSnJJux0K88kq0cOSlDjXbP5f+8m9VT7A+TbiVkWBwnOCEeMUBmXgOB N6cA== Received: by 10.205.134.137 with SMTP id ic9mr12549803bkc.57.1342115595245; Thu, 12 Jul 2012 10:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.49.87 with HTTP; Thu, 12 Jul 2012 10:52:44 -0700 (PDT) In-Reply-To: <4FFA3890.5060207@freebsd.org> References: <4FFA3890.5060207@freebsd.org> From: Chris Rees Date: Thu, 12 Jul 2012 18:52:44 +0100 Message-ID: To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, pho@freebsd.org Subject: Re: port devel/doxygen failing to test on -CURRENT and -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 17:53:17 -0000 On 9 July 2012 02:49, David Xu wrote: > On 2012/07/08 18:21, Chris Rees wrote: >> >> Hi all / David, >> >> doxygen has been failing for a while now on -CURRENT and apparently >> -STABLE too. The current fix is disabling one of the tests in the >> build, but obviously it points to a problem with our base system.... >> >> I've trussed [1] the failing code [2], and it looks as though it's >> hanging on a _umtx call. I'm gratuitously ignorant of what goes on >> there... but the timings of recent commits to umtx.h [3] could >> indicate a link (hope it's not bogus...). >> >> Any pointers on what I should do next? >> >> Chris >> >> [1] http://www.bayofrum.net/~crees/scratch/doxygen-truss >> > _umtx_op(0x8012b0280,0x16,0x0,0x0,0x0,0x1) ERR#22 'Invalid argument' > > can you execute it in gdb and print its value ? > > print/x *(int *)0x8012b0280 > print/x *(int *)(0x8012b0280+4) I've been having trouble debugging it since it's threaded, and so I ran a binary search over the last few days of revisions from 1/Apr to 1/May. Unfortunately I discovered to my horror today that all but the first test was useless, because the patch I committed to disable the test was of course readded to my ports tree, so none of the tests ran :/ I'll hopefully have it narrowed down to the offending commit over the next few days. Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 18:31:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 378511065670 for ; Thu, 12 Jul 2012 18:31:55 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by mx1.freebsd.org (Postfix) with ESMTP id B94DF8FC12 for ; Thu, 12 Jul 2012 18:31:54 +0000 (UTC) Received: from [84.44.178.238] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SpO51-0006sG-81; Thu, 12 Jul 2012 20:25:35 +0200 Date: Thu, 12 Jul 2012 20:17:41 +0200 From: Fabian Keil To: Benjamin Kaduk Message-ID: <20120712201741.34573af4@fabiankeil.de> In-Reply-To: References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/_EgWdIF1caHraz.QSKIGnRZ"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@freebsd.org, Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 18:31:55 -0000 --Sig_/_EgWdIF1caHraz.QSKIGnRZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: > On Wed, 11 Jul 2012, Fabian Keil wrote: >=20 > > I'm using the following modification of Sean's patch: This way it seems to work as expected: diff --git a/sys/modules/dtrace/dtraceall/Makefile b/sys/modules/dtrace/dtr= aceall/Makefile index 456efd1..628583b 100644 --- a/sys/modules/dtrace/dtraceall/Makefile +++ b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:= 07:31 uqs Exp $ KMOD=3D dtraceall -SRCS=3D dtraceall.c opt_compat.h +SRCS=3D dtraceall.c opt_compat.h opt_nfs.h CFLAGS+=3D -I${.CURDIR}/../../.. diff --git a/sys/modules/dtrace/dtraceall/dtraceall.c b/sys/modules/dtrace/= dtraceall/dtraceall.c index d256489..0672556 100644 --- a/sys/modules/dtrace/dtraceall/dtraceall.c +++ b/sys/modules/dtrace/dtraceall/dtraceall.c @@ -33,6 +33,7 @@ #include #include #include "opt_compat.h" +#include "opt_nfs.h" static int dtraceall_modevent(module_t mod __unused, int type, void *data __unused) @@ -67,8 +68,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtio, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#elif defined (NFSCLIENT) MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); > > Note that dtnfscl.ko is not loaded even though loading > > it manually works and I have NFSCL in the kernel. I wasn't entirely clear here, what I meant was that the KERNCONF used when compiling the module included "options NFSCL". I didn't expect run-time detection. > This is because dtraceall.c only #includes opt_compat.h, and the kernel=20 > build system only passes -include opt_global.h, so the dtraceall module=20 > build has no way of knowing about the NFSCL{IENT,} options defined in=20 > opt_nfs.h. (As you noted earlier in the thread?) Yes. > You would still need to address Andriy's comments in order to ensure that= =20 > the configuration seen by the module matches the kernel. Sure. Fabian --Sig_/_EgWdIF1caHraz.QSKIGnRZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//FMcACgkQBYqIVf93VJ2yTwCdGKuZD+8+fzB/V0rNGGSn/x/G +zEAoMclL8F9/52dQgi+V4tQjf+Pu0Br =1cUD -----END PGP SIGNATURE----- --Sig_/_EgWdIF1caHraz.QSKIGnRZ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 18:52:30 2012 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 54B9C1065673; Thu, 12 Jul 2012 18:52:30 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 063968FC08; Thu, 12 Jul 2012 18:52:30 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Thu, 12 Jul 2012 13:41:27 -0500 From: Paul Albrecht To: Ian Lepore In-Reply-To: <1342107640.1123.70.camel@revolution.hippie.lan> References: <1342036332.8313.8.camel@albrecht-desktop> <201207120834.40745.jhb@freebsd.org> <1342101436.1123.52.camel@revolution.hippie.lan> <201207121026.37849.jhb@freebsd.org> <1342107640.1123.70.camel@revolution.hippie.lan> Content-Type: text/plain Date: Thu, 12 Jul 2012 13:50:26 -0500 Message-ID: <1342119026.7631.8.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , "freebsd-hackers@freebsd.org" , Paul, Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 18:52:30 -0000 On Thu, 2012-07-12 at 10:40 -0500, Ian Lepore wrote: > On Thu, 2012-07-12 at 17:08 +0200, Davide Italiano wrote: > > On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > > > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > > >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > > >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > > >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > >> > > > Hi, > > >> > > > > > >> > > > Sorry about this repost but I'm confused about the responses I received > > >> > > > in my last post so I'm looking for some clarification. > > >> > > > > > >> > > > Specifically, I though I could use the kqueue timer as essentially a > > >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that > > >> > > > the accuracy of the kqueue timer is much less than what I need for my > > >> > > > application. > > >> > > > > > >> > > > So my confusion at this point is whether this is consider to be a bug or > > >> > > > "feature"? > > >> > > > > > >> > > > Here's some test code if you want to verify the problem: > > >> > > > > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > #include > > >> > > > > > >> > > > int > > >> > > > main(void) > > >> > > > { > > >> > > > int i,msec; > > >> > > > int kq,nev; > > >> > > > struct kevent inqueue; > > >> > > > struct kevent outqueue; > > >> > > > struct timeval start,end; > > >> > > > > > >> > > > if ((kq = kqueue()) == -1) { > > >> > > > fprintf(stderr, "kqueue error!? errno = %s", > > >> > strerror(errno)); > > >> > > > exit(EXIT_FAILURE); > > >> > > > } > > >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > >> > > > > > >> > > > gettimeofday(&start, 0); > > >> > > > for (i = 0; i < 50; i++) { > > >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > > >> > -1) { > > >> > > > fprintf(stderr, "kevent error!? errno = %s", > > >> > strerror(errno)); > > >> > > > exit(EXIT_FAILURE); > > >> > > > } else if (outqueue.flags & EV_ERROR) { > > >> > > > fprintf(stderr, "EV_ERROR: %s\n", > > >> > strerror(outqueue.data)); > > >> > > > exit(EXIT_FAILURE); > > >> > > > } > > >> > > > } > > >> > > > gettimeofday(&end, 0); > > >> > > > > > >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > > >> > end.tv_usec - start.tv_usec) / 1000) - 1000); > > >> > > > > > >> > > > printf("msec = %d\n", msec); > > >> > > > > > >> > > > close(kq); > > >> > > > return EXIT_SUCCESS; > > >> > > > } > > >> > > > > > >> > > > > > >> > > > > >> > > What you are seeing is "just the way FreeBSD currently works." > > >> > > > > >> > > Sleeping (in most all of its various forms, and I've just looked at the > > >> > > kevent code to verify this is true there) is handled by converting the > > >> > > amount of time to sleep (usually specified in a timeval or timespec > > >> > > struct) to a count of timer ticks, using an internal routine called > > >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > > >> > > account for the current tick. Whether that's a good idea or not (it > > >> > > probably was once, and probably not anymore) it's how things currently > > >> > > work, and could explain the fairly consistant +1ms you're seeing. > > >> > > > >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > > >> > installs a periodic callout that executes KNOTE() and then resets itself (via > > >> > callout_reset()) each time it runs. This should generally be closer to > > >> > regulary spaced intervals than something that does: > > >> > > > >> > > >> In what way is it irrelevant? That is, what did I miss? It appears to > > >> me that the next callout is scheduled by calling timertoticks() passing > > >> a count of milliseconds, that count is converted to a struct timeval and > > >> passed to tvtohz() which is where the +1 adjustment happens. If you ask > > >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > > >> There is some time, likely a small number of microseconds, that you've > > >> consumed of the current tick, and that's what the +1 in tvtohz() is > > >> supposed to account for according to the comments. > > >> > > >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > > >> and then adds one tick on top of that. That seems not quite right to > > >> me, except that it is a way to g'tee that you don't return early, and > > >> that is the one promise made by sleep routines on any OS; those magical > > >> "at least" words always appear in the docs. > > >> > > >> Actually what I'm missing (that I know of) is how the scheduler works. > > >> Maybe the +1 adjustment to account for the fraction of the current tick > > >> you've already consumed is the right thing to do, even when that > > >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler > > >> behavior that I know nothing about. > > > > > > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > > > case. That is, the +1 makes sense when you are computing a one-time delta > > > for things like nanosleep(). It is incorrect when computing a periodic > > > delta such as for computing the interval for an itimer (setitimer) or > > > EVFILT_TIMER(). > > > > > > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > > > > > > sys/kern/kern_time.c: > > > > > > /* > > > * Real interval timer expired: > > > * send process whose timer expired an alarm signal. > > > * If time is not set up to reload, then just return. > > > * Else compute next time timer should go off which is > current time. > > > * This is where delay in processing this timeout causes multiple > > > * SIGALRM calls to be compressed into one. > > > * tvtohz() always adds 1 to allow for the time until the next clock > > > * interrupt being strictly less than 1 clock tick, but we don't want > > > * that here since we want to appear to be in sync with the clock > > > * interrupt even when we're delayed. > > > */ > > > void > > > realitexpire(void *arg) > > > { > > > struct proc *p; > > > struct timeval ctv, ntv; > > > > > > p = (struct proc *)arg; > > > PROC_LOCK(p); > > > kern_psignal(p, SIGALRM); > > > if (!timevalisset(&p->p_realtimer.it_interval)) { > > > timevalclear(&p->p_realtimer.it_value); > > > if (p->p_flag & P_WEXIT) > > > wakeup(&p->p_itcallout); > > > PROC_UNLOCK(p); > > > return; > > > } > > > for (;;) { > > > timevaladd(&p->p_realtimer.it_value, > > > &p->p_realtimer.it_interval); > > > getmicrouptime(&ctv); > > > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > > > ntv = p->p_realtimer.it_value; > > > timevalsub(&ntv, &ctv); > > > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > > > realitexpire, p); > > > PROC_UNLOCK(p); > > > return; > > > } > > > } > > > /*NOTREACHED*/ > > > } > > > > > > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > > > seitimer() above: > > > > > > Index: kern_event.c > > > =================================================================== > > > --- kern_event.c (revision 238365) > > > +++ kern_event.c (working copy) > > > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > > > > > > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > > > calloutp = (struct callout *)kn->kn_hook; > > > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), > > > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, > > > filt_timerexpire, kn); > > > } > > > } > > > > > > -- > > > John Baldwin > > > _______________________________________________ > > > 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, > > I don't think it's good to decrease by a unit the 'ticks' you pass to > > callout_reset_* KPI. > > If this have to be fixed it should be fixed at the callout level and > > not at the consumer level. In other words, subsystems that makes use > > of callout_reset_* should not deal with the inherent limitations of > > callout precision, as it is right now. > > > > Davide > > I'm not sure it can be fixed in the callout_reset_* routines because > those routines have no idea whether the passed-in tick count came from > tvtohz() where the +1 gets applied. Either tvtohz() has to stop adding > a tick, then other code that needs the adjustment has to be changed to > add it, or code that doesn't need the adjustment has to subtract it back > out. Neither prospect is very appealing, really. > One other thing to note that is that mac os has the same problem. Does that make any difference in determining how to do the fix? > -- Ian > -- Paul Albrecht From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 19:11:57 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD44F1065786 for ; Thu, 12 Jul 2012 19:11:57 +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 2E23E8FC12 for ; Thu, 12 Jul 2012 19:11:56 +0000 (UTC) Received: from porto.starpoint.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 WAA25825; Thu, 12 Jul 2012 22:11:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SpOni-000726-H8; Thu, 12 Jul 2012 22:11:46 +0300 Message-ID: <4FFF2171.1030800@FreeBSD.org> Date: Thu, 12 Jul 2012 22:11:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> In-Reply-To: <20120712201741.34573af4@fabiankeil.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Benjamin Kaduk , Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 19:11:58 -0000 on 12/07/2012 21:17 Fabian Keil said the following: > Benjamin Kaduk wrote: > >> On Wed, 11 Jul 2012, Fabian Keil wrote: >> >>> I'm using the following modification of Sean's patch: > > This way it seems to work as expected: > > diff --git a/sys/modules/dtrace/dtraceall/Makefile > b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644 --- > a/sys/modules/dtrace/dtraceall/Makefile +++ > b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: > src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs Exp > $ > > KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h +SRCS= > dtraceall.c opt_compat.h opt_nfs.h > > CFLAGS+= -I${.CURDIR}/../../.. > If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does it compile OK with the above change? I am hinting at the case where KERNBUILDDIR is not set. This is not the proper way of building modules, but traditionally we keep it working. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 19:37:33 2012 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 11E5D106566B; Thu, 12 Jul 2012 19:37:33 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by mx1.freebsd.org (Postfix) with ESMTP id BCD638FC12; Thu, 12 Jul 2012 19:37:32 +0000 (UTC) Received: from [84.44.178.238] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SpPCX-0005Rg-6h; Thu, 12 Jul 2012 21:37:25 +0200 Date: Thu, 12 Jul 2012 21:36:15 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20120712213615.39640d1f@fabiankeil.de> In-Reply-To: <4FFF2171.1030800@FreeBSD.org> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Cr+.3sgsUdJACFeXgOhJ0_t"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@FreeBSD.org, Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 19:37:33 -0000 --Sig_/Cr+.3sgsUdJACFeXgOhJ0_t Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 12/07/2012 21:17 Fabian Keil said the following: > > Benjamin Kaduk wrote: > >=20 > >> On Wed, 11 Jul 2012, Fabian Keil wrote: > >>=20 > >>> I'm using the following modification of Sean's patch: > >=20 > > This way it seems to work as expected: > >=20 > > diff --git a/sys/modules/dtrace/dtraceall/Makefile > > b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644 -= -- > > a/sys/modules/dtrace/dtraceall/Makefile +++ > > b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: > > src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs= Exp > > $ > >=20 > > KMOD=3D dtraceall -SRCS=3D dtraceall.c opt_compat.h += SRCS=3D > > dtraceall.c opt_compat.h opt_nfs.h > >=20 > > CFLAGS+=3D -I${.CURDIR}/../../.. > >=20 >=20 > If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does = it > compile OK with the above change? Depends on your expectations I guess. As neither NFS-related option gets defined, no dependency on either NFS module is registered. The compiler has no complaints, though. Fabian --Sig_/Cr+.3sgsUdJACFeXgOhJ0_t Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//JzwACgkQBYqIVf93VJ0EOgCgu0TRofeJ3JiqvgQjz37mECep qfsAnRp5tFtDyabVJ9JekjibcPOdGtd2 =2L52 -----END PGP SIGNATURE----- --Sig_/Cr+.3sgsUdJACFeXgOhJ0_t-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 19:39:30 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE01A1065677 for ; Thu, 12 Jul 2012 19:39:30 +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 2BA718FC12 for ; Thu, 12 Jul 2012 19:39:29 +0000 (UTC) Received: from porto.starpoint.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 WAA26252; Thu, 12 Jul 2012 22:39:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SpPEV-00075D-JS; Thu, 12 Jul 2012 22:39:27 +0300 Message-ID: <4FFF27F0.4000106@FreeBSD.org> Date: Thu, 12 Jul 2012 22:39:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> <20120712213615.39640d1f@fabiankeil.de> In-Reply-To: <20120712213615.39640d1f@fabiankeil.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 19:39:30 -0000 on 12/07/2012 22:36 Fabian Keil said the following: > Andriy Gapon wrote: > >> on 12/07/2012 21:17 Fabian Keil said the following: >>> Benjamin Kaduk wrote: >>> >>>> On Wed, 11 Jul 2012, Fabian Keil wrote: >>>> >>>>> I'm using the following modification of Sean's patch: >>> >>> This way it seems to work as expected: >>> >>> diff --git a/sys/modules/dtrace/dtraceall/Makefile >>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644 >>> --- a/sys/modules/dtrace/dtraceall/Makefile +++ >>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: >>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs >>> Exp $ >>> >>> KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h >>> +SRCS= dtraceall.c opt_compat.h opt_nfs.h >>> >>> CFLAGS+= -I${.CURDIR}/../../.. >>> >> >> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does >> it compile OK with the above change? > > Depends on your expectations I guess. As neither NFS-related option gets > defined, no dependency on either NFS module is registered. The compiler has > no complaints, though. Interesting. Could you repeat after sufficient cleaning up? I am not sure where from opt_nfs.h file could come. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 19:46:00 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37C91106566C; Thu, 12 Jul 2012 19:46:00 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by mx1.freebsd.org (Postfix) with ESMTP id B62988FC16; Thu, 12 Jul 2012 19:45:59 +0000 (UTC) Received: from [84.44.178.238] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SpPJc-0003ty-FH; Thu, 12 Jul 2012 21:44:44 +0200 Date: Thu, 12 Jul 2012 21:44:30 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20120712214430.02451df7@fabiankeil.de> In-Reply-To: <4FFF27F0.4000106@FreeBSD.org> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> <20120712213615.39640d1f@fabiankeil.de> <4FFF27F0.4000106@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Z/ksMZsAI3ndvRbkTUKpQrZ"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@FreeBSD.org, Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 19:46:00 -0000 --Sig_/Z/ksMZsAI3ndvRbkTUKpQrZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 12/07/2012 22:36 Fabian Keil said the following: > > Andriy Gapon wrote: > >=20 > >> on 12/07/2012 21:17 Fabian Keil said the following: > >>> Benjamin Kaduk wrote: > >>>=20 > >>>> On Wed, 11 Jul 2012, Fabian Keil wrote: > >>>>=20 > >>>>> I'm using the following modification of Sean's patch: > >>>=20 > >>> This way it seems to work as expected: > >>>=20 > >>> diff --git a/sys/modules/dtrace/dtraceall/Makefile=20 > >>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644 > >>> --- a/sys/modules/dtrace/dtraceall/Makefile +++=20 > >>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD:=20 > >>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 u= qs > >>> Exp $ > >>>=20 > >>> KMOD=3D dtraceall -SRCS=3D dtraceall.c opt_compat.h > >>> +SRCS=3D dtraceall.c opt_compat.h opt_nfs.h > >>>=20 > >>> CFLAGS+=3D -I${.CURDIR}/../../.. > >>>=20 > >>=20 > >> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, do= es > >> it compile OK with the above change? > >=20 > > Depends on your expectations I guess. As neither NFS-related option gets > > defined, no dependency on either NFS module is registered. The compiler= has > > no complaints, though. >=20 > Interesting. Could you repeat after sufficient cleaning up? > I am not sure where from opt_nfs.h file could come. The Makefile seems to create an empty one: =20 fk@r500 /usr/src/sys/modules/dtrace/dtraceall $make clean rm -f export_syms dtraceall.ko dtraceall.kld dtraceall.o dtraceall.ko.debug= dtraceall.ko.symbols opt_compat.h opt_nfs.h fk@r500 /usr/src/sys/modules/dtrace/dtraceall $make echo "#define COMPAT_FREEBSD32 1" >> opt_compat.h :> opt_nfs.h cc -O2 -pipe [...] -c /usr/src/sys/modules/dtrace/dtraceall/dtraceall.c ld -d -warn-common -r -d -o dtraceall.ko.debug dtraceall.o :> export_syms awk -f /usr/src/sys/modules/dtrace/dtraceall/../../../conf/kmod_syms.awk dt= raceall.ko.debug export_syms | xargs -J% objcopy % dtraceall.ko.debug objcopy --only-keep-debug dtraceall.ko.debug dtraceall.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Ddtraceall.ko.symbols dtraceall.= ko.debug dtraceall.ko Fabian --Sig_/Z/ksMZsAI3ndvRbkTUKpQrZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//KSsACgkQBYqIVf93VJ1LTgCgtm17ryTK9TMzX0+3dlfzwJ0P rxoAoK3gT3SlCrmWRvHUe0a2/GZvThsl =eJpo -----END PGP SIGNATURE----- --Sig_/Z/ksMZsAI3ndvRbkTUKpQrZ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 19:47:06 2012 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 8F28E106566B; Thu, 12 Jul 2012 19:47:06 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id 526548FC15; Thu, 12 Jul 2012 19:47:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 910244806DD; Thu, 12 Jul 2012 15:47:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfkVCR-tv5hO; Thu, 12 Jul 2012 15:47:08 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id B42FF4806CA; Thu, 12 Jul 2012 15:47:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Andrew Boyer In-Reply-To: <4FFF27F0.4000106@FreeBSD.org> Date: Thu, 12 Jul 2012 15:47:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <742407DF-8026-4976-A1F9-A170A62EF87A@averesystems.com> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> <20120712213615.39640d1f@fabiankeil.de> <4FFF27F0.4000106@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@FreeBSD.org, Sean Bruno , Fabian Keil Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 19:47:06 -0000 On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote: > on 12/07/2012 22:36 Fabian Keil said the following: >> Andriy Gapon wrote: >>=20 >>> on 12/07/2012 21:17 Fabian Keil said the following: >>>> Benjamin Kaduk wrote: >>>>=20 >>>>> On Wed, 11 Jul 2012, Fabian Keil wrote: >>>>>=20 >>>>>> I'm using the following modification of Sean's patch: >>>>=20 >>>> This way it seems to work as expected: >>>>=20 >>>> diff --git a/sys/modules/dtrace/dtraceall/Makefile=20 >>>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b = 100644 >>>> --- a/sys/modules/dtrace/dtraceall/Makefile +++=20 >>>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD:=20= >>>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 = uqs >>>> Exp $ >>>>=20 >>>> KMOD=3D dtraceall -SRCS=3D dtraceall.c = opt_compat.h >>>> +SRCS=3D dtraceall.c opt_compat.h opt_nfs.h >>>>=20 >>>> CFLAGS+=3D -I${.CURDIR}/../../.. >>>>=20 >>>=20 >>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, = does >>> it compile OK with the above change? >>=20 >> Depends on your expectations I guess. As neither NFS-related option = gets >> defined, no dependency on either NFS module is registered. The = compiler has >> no complaints, though. >=20 > Interesting. Could you repeat after sufficient cleaning up? > I am not sure where from opt_nfs.h file could come. >=20 Maybe related: check out sys/modules/ipfw/Makefile. It makes its own = option headers for INET and INET6. -A -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 20:36:07 2012 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 B541B106566B for ; Thu, 12 Jul 2012 20:36:07 +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 0333B8FC18 for ; Thu, 12 Jul 2012 20:36:06 +0000 (UTC) Received: from porto.starpoint.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 XAA26879; Thu, 12 Jul 2012 23:36:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SpQ7I-00079I-8S; Thu, 12 Jul 2012 23:36:04 +0300 Message-ID: <4FFF3533.3030006@FreeBSD.org> Date: Thu, 12 Jul 2012 23:36:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> <20120712213615.39640d1f@fabiankeil.de> <4FFF27F0.4000106@FreeBSD.org> <20120712214430.02451df7@fabiankeil.de> In-Reply-To: <20120712214430.02451df7@fabiankeil.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Sean Bruno Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 20:36:07 -0000 on 12/07/2012 22:44 Fabian Keil said the following: > Andriy Gapon wrote: > >> on 12/07/2012 22:36 Fabian Keil said the following: >>> Andriy Gapon wrote: >>> >>>> on 12/07/2012 21:17 Fabian Keil said the following: >>>>> Benjamin Kaduk wrote: >>>>> >>>>>> On Wed, 11 Jul 2012, Fabian Keil wrote: >>>>>> >>>>>>> I'm using the following modification of Sean's patch: >>>>> >>>>> This way it seems to work as expected: >>>>> >>>>> diff --git a/sys/modules/dtrace/dtraceall/Makefile >>>>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b >>>>> 100644 --- a/sys/modules/dtrace/dtraceall/Makefile +++ >>>>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: >>>>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 >>>>> 09:07:31 uqs Exp $ >>>>> >>>>> KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h >>>>> +SRCS= dtraceall.c opt_compat.h opt_nfs.h >>>>> >>>>> CFLAGS+= -I${.CURDIR}/../../.. >>>>> >>>> >>>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, >>>> does it compile OK with the above change? >>> >>> Depends on your expectations I guess. As neither NFS-related option >>> gets defined, no dependency on either NFS module is registered. The >>> compiler has no complaints, though. >> >> Interesting. Could you repeat after sufficient cleaning up? I am not >> sure where from opt_nfs.h file could come. > > The Makefile seems to create an empty one: > > fk@r500 /usr/src/sys/modules/dtrace/dtraceall $make clean rm -f export_syms > dtraceall.ko dtraceall.kld dtraceall.o dtraceall.ko.debug > dtraceall.ko.symbols opt_compat.h opt_nfs.h fk@r500 > /usr/src/sys/modules/dtrace/dtraceall $make echo "#define COMPAT_FREEBSD32 > 1" >> opt_compat.h :> opt_nfs.h cc -O2 -pipe [...] -c > /usr/src/sys/modules/dtrace/dtraceall/dtraceall.c ld -d -warn-common -r -d > -o dtraceall.ko.debug dtraceall.o :> export_syms awk -f > /usr/src/sys/modules/dtrace/dtraceall/../../../conf/kmod_syms.awk > dtraceall.ko.debug export_syms | xargs -J% objcopy % dtraceall.ko.debug > objcopy --only-keep-debug dtraceall.ko.debug dtraceall.ko.symbols objcopy > --strip-debug --add-gnu-debuglink=dtraceall.ko.symbols dtraceall.ko.debug > dtraceall.ko Ah, correct. I now even see the relevant snippet in kmod.mk: .for _src in ${SRCS:Mopt_*.h} CLEANFILES+= ${_src} .if !target(${_src}) ${_src}: :> ${.TARGET} .endif .endfor It's only when we want those file to be not empty (have some options) that we define any targets for them (like COMPAT_FREEBSD32 in the dtraceall Makefile). Sorry for the noise. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 22:11:41 2012 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 4EDA4106566C for ; Thu, 12 Jul 2012 22:11:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3038B8FC18 for ; Thu, 12 Jul 2012 22:11:41 +0000 (UTC) Received: from planet.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0DBC311D52; Thu, 12 Jul 2012 15:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1342131095; bh=/X45ft0cUnfsCaWfuG2c3JA6KnYfAkL1Ge4goyvg+cA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ZnylTZDsrccK/SGrUA7R0u+2cmw2qWqXA9FB+/dN2mX7Wny7FS/REANhe370FxziX sPS0U6BAQmFHlthhBzkIGvDkHAjvvuBu4A4yPXBFIr96xpWlaC1uCOL+8qKmXjNbQG AGddJDgsre30f0htTBvq9A4rkTqbAF6rKP9cDIOo= Message-ID: <4FFF4B95.9080105@delphij.net> Date: Thu, 12 Jul 2012 15:11:33 -0700 From: Xin Li User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120320 Thunderbird/10.0.3 MIME-Version: 1.0 To: Bill Crisp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:11:41 -0000 On 07/12/12 09:36, Bill Crisp wrote: > Good Morning! > > This was also posted to the FreeBSD forums: > > I have been researching CVE-2012-0217 and while I have patched the kernels > on servers with 7.3/8.2 that I have, I would like to see if anyone knows > for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are > out of support from looking at the documentation. I have looked at the code > in trap.c to see if the current patch would work with 6.3 source but it > won't based on what I saw. I am also aware of upgrading as an option to > resolve this unfortunately in some cases I have this is not possible right > now. I believe that 6.x are vulnerable. You will have to backport the change (something like this against sys/amd64/amd64/trap.c, in syscall() right after PTRACESTOP_SC(p, td, S_PT_SCX); Add: + /* + * If the user-supplied value of %rip is not a canonical + * address, then some CPUs will trigger a ring 0 #GP during + * the sysret instruction. However, the fault handler would + * execute with the user's %gs and %rsp in ring 0 which would + * not be safe. Instead, preemptively kill the thread with a + * SIGBUS. + */ + if (td->td_frame->tf_rip>= VM_MAXUSER_ADDRESS) { + ksiginfo_init_trap(&ksi); + ksi.ksi_signo = SIGBUS; + ksi.ksi_code = BUS_OBJERR; + ksi.ksi_trapno = T_PROTFLT; + ksi.ksi_addr = (void *)td->td_frame->tf_rip; + trapsignal(td,&ksi); + } Right before: WITNESS_WARN(...) Cheers, From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 22:43:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D25D1065686 for ; Thu, 12 Jul 2012 22:43:09 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD978FC12 for ; Thu, 12 Jul 2012 22:43:09 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta07.emeryville.ca.mail.comcast.net with comcast id ZaY61j0061ZMdJ4A7ai3uy; Thu, 12 Jul 2012 22:42:03 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta16.emeryville.ca.mail.comcast.net with comcast id Zai21j0034NgCEG8cai2KM; Thu, 12 Jul 2012 22:42:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6CMfx5f015964; Thu, 12 Jul 2012 16:42:00 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: <4FDF8FF1.7020202@zonov.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jul 2012 16:41:58 -0600 Message-ID: <1342132918.1123.140.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /proc filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 22:43:09 -0000 On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote: > that is what i need. > > but still need some explanation after using it and reading manual > > say: > PID START END PRT RES PRES REF SHD FL TP PATH > 1378 0x400000 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg > 1378 0x7ab000 0x7bc000 rw- 17 0 1 0 C-- vn /usr/local/bin/Xorg > 1378 0x7bc000 0x800000 rw- 14 0 1 0 C-- df > 1378 0x8007ab000 0x8007c3000 r-x 24 0 32 0 CN- vn /libexec/ld-elf.so.1 > 1378 0x8007c3000 0x8007f0000 rw- 43 0 1 0 C-- df > 1378 0x8007f0000 0x8007f2000 rw- 1 0 4 0 --- dv > 1378 0x8007f2000 0x8007f4000 rw- 2 0 4 0 --- dv > 1378 0x8007f4000 0x800874000 rw- 11 0 4 0 --- dv > 1378 0x800874000 0x800884000 rw- 16 0 4 0 --- dv > 1378 0x800884000 0x800895000 rw- 10 0 1 0 CN- df > 1378 0x8009c2000 0x8009c5000 rw- 3 0 1 0 C-- df > > > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But > what "REF" really means here and why it is 2 once and 1 second. > > 2) what really PRES ("private resident") means? df (default) mappings are > IMHO anonymous maps==private data of process. so why RES is nonzero while > PRES is zero, while on shared code PRES is nonzero and large. what does it > really means? > > thanks. > I'm catching up on threads I was following before I went on vacation, and it looks like there was never a response to this. I'm interested in the answers to these questions too, so today I did some spelunking in the code to see what I could figure out. I don't think I really understand things too well, but I'll just say what I think I found and hopefully the experts will correct anything I get wrong. I think you're right about the first two mappings in that procstat output. The REF value is the reference count on the vm object (the vnode for the exe file, I presume). I think the reason the reference count is 2 is that one reference is the open file itself, and the other is the shadow object. I've always been a bit confused about the concept of shadow objects in freebsd's vm, but I think it's somehow related to the running processes that are based on that executable vnode. For example, if another copy of Xorg were running, I think REF would be 3, and SHD would be 2. I don't know why there is no shadow object for the writable data mapping and why the refcount is only 1 for that. The PRES thing seemed simple when I first looked at the code, but the more I think about it in relation to other numbers the more confused I get. The logic in the code is "if the shadow count is 1 then PRES is the resident size of the shadow object." This seems to be a measure of shared-code usage... any object which could be shared but isn't gets counted as private resident. The part that confuses me is how PRES can be larger than RES. The value for PRES is taken from the resident_page_count field of the shadow object. The RES value is calculated by walking each page of the map entry and calling pmap_mincore() to see if it's resident. So the number of resident pages is calculated to be fewer than the resident_page_count of the object the entry maps. I don't understand. Oh hmmm, wait a sec... could it be that read-ahead or relocation fixup or various other things caused lots of pages to be faulted in for the vnode object (so they're resident) but not all of those pages are mapped into the process because the path of execution has never referenced them and caused faults to map them into the process' vmspace? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 22:51:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC949106564A for ; Thu, 12 Jul 2012 22:51:30 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF628FC0C for ; Thu, 12 Jul 2012 22:51:20 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT/9U5yn2MLQDEZqaN/iKkctHsQ4Bv76d@postini.com; Thu, 12 Jul 2012 15:51:30 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 12 Jul 2012 15:51:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 12 Jul 2012 18:51:06 -0400 From: Andrew Duane To: Ian Lepore , Wojciech Puchar Date: Thu, 12 Jul 2012 18:51:04 -0400 Thread-Topic: /proc filesystem Thread-Index: Ac1gf+ScxQ0oGO8ASfOfq5PhVOiqUQAAJ7lg Message-ID: References: <4FDF8FF1.7020202@zonov.org> <1342132918.1123.140.camel@revolution.hippie.lan> In-Reply-To: <1342132918.1123.140.camel@revolution.hippie.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" Subject: RE: /proc filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 22:51:30 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Ian Lepore > Sent: Thursday, July 12, 2012 6:42 PM > To: Wojciech Puchar > Cc: freebsd-hackers@freebsd.org > Subject: Re: /proc filesystem >=20 > On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote: > > that is what i need. > > > > but still need some explanation after using it and reading manual > > > > say: > > PID START END PRT RES PRES REF SHD FL > TP PATH > > 1378 0x400000 0x5ac000 r-x 385 415 2 1 CN- = vn /usr/local/bin/Xorg > > 1378 0x7ab000 0x7bc000 rw- 17 0 1 0 C-- = vn /usr/local/bin/Xorg > > 1378 0x7bc000 0x800000 rw- 14 0 1 0 C-- = df > > 1378 0x8007ab000 0x8007c3000 r-x 24 0 32 0 CN- = vn /libexec/ld-elf.so.1 > > 1378 0x8007c3000 0x8007f0000 rw- 43 0 1 0 C-- = df > > 1378 0x8007f0000 0x8007f2000 rw- 1 0 4 0 --- = dv > > 1378 0x8007f2000 0x8007f4000 rw- 2 0 4 0 --- = dv > > 1378 0x8007f4000 0x800874000 rw- 11 0 4 0 --- = dv > > 1378 0x800874000 0x800884000 rw- 16 0 4 0 --- = dv > > 1378 0x800884000 0x800895000 rw- 10 0 1 0 CN- = df > > 1378 0x8009c2000 0x8009c5000 rw- 3 0 1 0 C-- = df > > > > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But > > what "REF" really means here and why it is 2 once and 1 second. > > > > 2) what really PRES ("private resident") means? df (default) mappings a= re > > IMHO anonymous maps=3D=3Dprivate data of process. so why RES is nonzero= while > > PRES is zero, while on shared code PRES is nonzero and large. what does= it > > really means? > > > > thanks. > > >=20 > I'm catching up on threads I was following before I went on vacation, > and it looks like there was never a response to this. I'm interested in > the answers to these questions too, so today I did some spelunking in > the code to see what I could figure out. I don't think I really > understand things too well, but I'll just say what I think I found and > hopefully the experts will correct anything I get wrong. >=20 > I think you're right about the first two mappings in that procstat > output. The REF value is the reference count on the vm object (the > vnode for the exe file, I presume). I think the reason the reference > count is 2 is that one reference is the open file itself, and the other > is the shadow object. I've always been a bit confused about the concept > of shadow objects in freebsd's vm, but I think it's somehow related to > the running processes that are based on that executable vnode. For > example, if another copy of Xorg were running, I think REF would be 3, > and SHD would be 2. >=20 > I don't know why there is no shadow object for the writable data mapping > and why the refcount is only 1 for that. BSS that doesn't exist in the file? =A0................................... Andrew Duane Juniper Networks +1 978-589-0551 (o) +1 603-770-7088 (m) aduane@juniper.net =A0 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 23:08:26 2012 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 6EED9106564A for ; Thu, 12 Jul 2012 23:08:26 +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 B3DDA8FC08 for ; Thu, 12 Jul 2012 23:08:25 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6CN8B93081974; Fri, 13 Jul 2012 02:08: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.5/8.14.5) with ESMTP id q6CN7wZe072274; Fri, 13 Jul 2012 02:07:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6CN7wdp072273; Fri, 13 Jul 2012 02:07:58 +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: Fri, 13 Jul 2012 02:07:58 +0300 From: Konstantin Belousov To: Ian Lepore Message-ID: <20120712230758.GM2338@deviant.kiev.zoral.com.ua> References: <4FDF8FF1.7020202@zonov.org> <1342132918.1123.140.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S/ewHz4E8nbJzUsO" Content-Disposition: inline In-Reply-To: <1342132918.1123.140.camel@revolution.hippie.lan> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: /proc filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Jul 2012 23:08:26 -0000 --S/ewHz4E8nbJzUsO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 04:41:58PM -0600, Ian Lepore wrote: > On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote: > > that is what i need. > >=20 > > but still need some explanation after using it and reading manual > >=20 > > say: > > PID START END PRT RES PRES REF SHD FL = TP PATH > > 1378 0x400000 0x5ac000 r-x 385 415 2 1 CN- = vn /usr/local/bin/Xorg > > 1378 0x7ab000 0x7bc000 rw- 17 0 1 0 C-- = vn /usr/local/bin/Xorg > > 1378 0x7bc000 0x800000 rw- 14 0 1 0 C-- = df > > 1378 0x8007ab000 0x8007c3000 r-x 24 0 32 0 CN- = vn /libexec/ld-elf.so.1 > > 1378 0x8007c3000 0x8007f0000 rw- 43 0 1 0 C-- = df > > 1378 0x8007f0000 0x8007f2000 rw- 1 0 4 0 --- = dv > > 1378 0x8007f2000 0x8007f4000 rw- 2 0 4 0 --- = dv > > 1378 0x8007f4000 0x800874000 rw- 11 0 4 0 --- = dv > > 1378 0x800874000 0x800884000 rw- 16 0 4 0 --- = dv > > 1378 0x800884000 0x800895000 rw- 10 0 1 0 CN- = df > > 1378 0x8009c2000 0x8009c5000 rw- 3 0 1 0 C-- = df > >=20 > >=20 > > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But= =20 > > what "REF" really means here and why it is 2 once and 1 second. ref shows the reference count on the top of the shadow chain. The Xorg text is mapped read-only private and flags indicate that there were no writes to the text (e.g. from debuggers to set breakpoints), so no COW were performed, and no shadows to contain the COW pages were inserted. You see the reference count 2 because text and data mappings are separate vm map entries, and both reference the same vm object. For the Xorg data, there were writes into private writeable mapping, so you can see in flags that COW was performed, and shadow object installed over the vnode vm object. Since the shadow object has a single user, namely the data mapping in the Xorg process, the ref count is 1. > >=20 > > 2) what really PRES ("private resident") means? df (default) mappings a= re=20 > > IMHO anonymous maps=3D=3Dprivate data of process. so why RES is nonzero= while=20 > > PRES is zero, while on shared code PRES is nonzero and large. what does= it=20 > > really means? > >=20 > > thanks. > >=20 >=20 > I'm catching up on threads I was following before I went on vacation, > and it looks like there was never a response to this. I'm interested in > the answers to these questions too, so today I did some spelunking in > the code to see what I could figure out. I don't think I really > understand things too well, but I'll just say what I think I found and > hopefully the experts will correct anything I get wrong. >=20 > I think you're right about the first two mappings in that procstat > output. The REF value is the reference count on the vm object (the > vnode for the exe file, I presume). I think the reason the reference > count is 2 is that one reference is the open file itself, and the other > is the shadow object. I've always been a bit confused about the concept This is wrong, see above for explanation. Vnode ownership of the vm object does not end in the vm object reference count increase. Instead, filesystems manually manage vm object creation and destruction, since it fits with the vnode lifecycle management. > of shadow objects in freebsd's vm, but I think it's somehow related to > the running processes that are based on that executable vnode. For > example, if another copy of Xorg were running, I think REF would be 3, > and SHD would be 2. >=20 > I don't know why there is no shadow object for the writable data mapping > and why the refcount is only 1 for that. There _is_ shadow object, as indicated by flags showing that entry no longer 'needs copy'. >=20 > The PRES thing seemed simple when I first looked at the code, but the > more I think about it in relation to other numbers the more confused I > get. The logic in the code is "if the shadow count is 1 then PRES is > the resident size of the shadow object." This seems to be a measure of > shared-code usage... any object which could be shared but isn't gets > counted as private resident. >=20 > The part that confuses me is how PRES can be larger than RES. The value > for PRES is taken from the resident_page_count field of the shadow > object. The RES value is calculated by walking each page of the map > entry and calling pmap_mincore() to see if it's resident. So the number > of resident pages is calculated to be fewer than the resident_page_count > of the object the entry maps. I don't understand. >=20 > Oh hmmm, wait a sec... could it be that read-ahead or relocation fixup > or various other things caused lots of pages to be faulted in for the > vnode object (so they're resident) but not all of those pages are mapped > into the process because the path of execution has never referenced them > and caused faults to map them into the process' vmspace? This is mostly right, except the note that established mappings might be removed from page tables at any moment, except for wired mappings. Main point to take is that page residency is different from mapping. --S/ewHz4E8nbJzUsO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk//WM4ACgkQC3+MBN1Mb4gcJgCgkniJ1LFjaR0dNINcJEtmhDXE YRQAmwf7MbvJ+mu4yFXFZmH3+Qd5rBLe =hCEJ -----END PGP SIGNATURE----- --S/ewHz4E8nbJzUsO-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 06:11:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42D62106564A; Fri, 13 Jul 2012 06:11:56 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 120FB8FC0A; Fri, 13 Jul 2012 06:11:56 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 91AD2606F1; Fri, 13 Jul 2012 01:11:53 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 76E1F606FF; Fri, 13 Jul 2012 01:11:53 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 6J4bJ5Jog9XJ; Fri, 13 Jul 2012 01:11:53 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id DA997606F1; Fri, 13 Jul 2012 01:11:52 -0500 (CDT) Message-ID: <4FFFBC27.3090402@rice.edu> Date: Fri, 13 Jul 2012 01:11:51 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> In-Reply-To: <201207120826.05577.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-hackers@freebsd.org, Warner Losh Subject: Re: contigmalloc() breaking Xorg X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Jul 2012 06:11:56 -0000 On 07/12/2012 07:26, John Baldwin wrote: > [ Adding alc@ for VM stuff, Warner for arm/mips bus dma brokenness ] When the code underlying contigmalloc() fails in its initial attempt to allocate memory and proceeds to launder and reclaim pages, it should almost certainly do as the page daemon does and invoke the vm_lowmem handlers. In particular, this should coax the ZFS ARC into releasing some of its hoard of wired memory. Try this: Index: vm/vm_contig.c =================================================================== --- vm/vm_contig.c (revision 238372) +++ vm/vm_contig.c (working copy) @@ -192,6 +192,18 @@ vm_contig_grow_cache(int tries, vm_paddr_t low, vm { int actl, actmax, inactl, inactmax; + if (tries > 0) { + /* + * Decrease registered cache sizes. + */ + EVENTHANDLER_INVOKE(vm_lowmem, 0); + + /* + * We do this explicitly after the caches have been drained + * above. + */ + uma_reclaim(); + } vm_page_lock_queues(); inactl = 0; inactmax = tries < 1 ? 0 : cnt.v_inactive_count; From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 12:22:20 2012 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 7101F106566C; Fri, 13 Jul 2012 12:22:20 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB318FC12; Fri, 13 Jul 2012 12:22:20 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5959272pbb.13 for ; Fri, 13 Jul 2012 05:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7TcbJCHRDfoUyF3X26Ab8WxG2/TzmAUoXaDH1zIjUc=; b=ZzhcRXUp0Cv2WyNABJpHfg6U+TsmzG3srujxHxdkG3U7s8S7H4woBdKmL1H5Rwo5/n gB/ITqZxwt6h5Gcl+cAaY83HhWt7AGSF3sjYlXa3/uzhYGwWpfBQEjpem3kFuA1ZdSXz wD58Rx2yPTNC0ERWiWBuEbZpBSK/SJ7+WEnjWawraE+1bM05liK/wQxo1cGXYICxHm7w 6ShXXwvY9J9sKU+Db1EwjoOlPDW/PKqqnUP0tYmN3ZApro8RWpfCsYQk1ya60ORkuskq WM90jutZr9qMDh6MPIQSBdiiz1ljk0DMusGYAs8ZG8nU5EsrLFs5GZ0wHJRPUZvHa59L BK4A== MIME-Version: 1.0 Received: by 10.68.191.8 with SMTP id gu8mr3216977pbc.158.1342182134024; Fri, 13 Jul 2012 05:22:14 -0700 (PDT) Received: by 10.66.82.201 with HTTP; Fri, 13 Jul 2012 05:22:13 -0700 (PDT) In-Reply-To: <201207121125.01228.jhb@freebsd.org> References: <1342036332.8313.8.camel@albrecht-desktop> <201207121026.37849.jhb@freebsd.org> <201207121125.01228.jhb@freebsd.org> Date: Fri, 13 Jul 2012 14:22:13 +0200 Message-ID: From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Paul Albrecht , freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Jul 2012 12:22:20 -0000 On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote: > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: >> >> > > > Hi, >> >> > > > >> >> > > > Sorry about this repost but I'm confused about the responses I received >> >> > > > in my last post so I'm looking for some clarification. >> >> > > > >> >> > > > Specifically, I though I could use the kqueue timer as essentially a >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that >> >> > > > the accuracy of the kqueue timer is much less than what I need for my >> >> > > > application. >> >> > > > >> >> > > > So my confusion at this point is whether this is consider to be a bug or >> >> > > > "feature"? >> >> > > > >> >> > > > Here's some test code if you want to verify the problem: >> >> > > > >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > #include >> >> > > > >> >> > > > int >> >> > > > main(void) >> >> > > > { >> >> > > > int i,msec; >> >> > > > int kq,nev; >> >> > > > struct kevent inqueue; >> >> > > > struct kevent outqueue; >> >> > > > struct timeval start,end; >> >> > > > >> >> > > > if ((kq = kqueue()) == -1) { >> >> > > > fprintf(stderr, "kqueue error!? errno = %s", >> >> > strerror(errno)); >> >> > > > exit(EXIT_FAILURE); >> >> > > > } >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); >> >> > > > >> >> > > > gettimeofday(&start, 0); >> >> > > > for (i = 0; i < 50; i++) { >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == >> >> > -1) { >> >> > > > fprintf(stderr, "kevent error!? errno = %s", >> >> > strerror(errno)); >> >> > > > exit(EXIT_FAILURE); >> >> > > > } else if (outqueue.flags & EV_ERROR) { >> >> > > > fprintf(stderr, "EV_ERROR: %s\n", >> >> > strerror(outqueue.data)); >> >> > > > exit(EXIT_FAILURE); >> >> > > > } >> >> > > > } >> >> > > > gettimeofday(&end, 0); >> >> > > > >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000); >> >> > > > >> >> > > > printf("msec = %d\n", msec); >> >> > > > >> >> > > > close(kq); >> >> > > > return EXIT_SUCCESS; >> >> > > > } >> >> > > > >> >> > > > >> >> > > >> >> > > What you are seeing is "just the way FreeBSD currently works." >> >> > > >> >> > > Sleeping (in most all of its various forms, and I've just looked at the >> >> > > kevent code to verify this is true there) is handled by converting the >> >> > > amount of time to sleep (usually specified in a timeval or timespec >> >> > > struct) to a count of timer ticks, using an internal routine called >> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to >> >> > > account for the current tick. Whether that's a good idea or not (it >> >> > > probably was once, and probably not anymore) it's how things currently >> >> > > work, and could explain the fairly consistant +1ms you're seeing. >> >> > >> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER >> >> > installs a periodic callout that executes KNOTE() and then resets itself (via >> >> > callout_reset()) each time it runs. This should generally be closer to >> >> > regulary spaced intervals than something that does: >> >> > >> >> >> >> In what way is it irrelevant? That is, what did I miss? It appears to >> >> me that the next callout is scheduled by calling timertoticks() passing >> >> a count of milliseconds, that count is converted to a struct timeval and >> >> passed to tvtohz() which is where the +1 adjustment happens. If you ask >> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. >> >> There is some time, likely a small number of microseconds, that you've >> >> consumed of the current tick, and that's what the +1 in tvtohz() is >> >> supposed to account for according to the comments. >> >> >> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick >> >> and then adds one tick on top of that. That seems not quite right to >> >> me, except that it is a way to g'tee that you don't return early, and >> >> that is the one promise made by sleep routines on any OS; those magical >> >> "at least" words always appear in the docs. >> >> >> >> Actually what I'm missing (that I know of) is how the scheduler works. >> >> Maybe the +1 adjustment to account for the fraction of the current tick >> >> you've already consumed is the right thing to do, even when that >> >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler >> >> behavior that I know nothing about. >> > >> > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this >> > case. That is, the +1 makes sense when you are computing a one-time delta >> > for things like nanosleep(). It is incorrect when computing a periodic >> > delta such as for computing the interval for an itimer (setitimer) or >> > EVFILT_TIMER(). >> > >> > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: >> > >> > sys/kern/kern_time.c: >> > >> > /* >> > * Real interval timer expired: >> > * send process whose timer expired an alarm signal. >> > * If time is not set up to reload, then just return. >> > * Else compute next time timer should go off which is > current time. >> > * This is where delay in processing this timeout causes multiple >> > * SIGALRM calls to be compressed into one. >> > * tvtohz() always adds 1 to allow for the time until the next clock >> > * interrupt being strictly less than 1 clock tick, but we don't want >> > * that here since we want to appear to be in sync with the clock >> > * interrupt even when we're delayed. >> > */ >> > void >> > realitexpire(void *arg) >> > { >> > struct proc *p; >> > struct timeval ctv, ntv; >> > >> > p = (struct proc *)arg; >> > PROC_LOCK(p); >> > kern_psignal(p, SIGALRM); >> > if (!timevalisset(&p->p_realtimer.it_interval)) { >> > timevalclear(&p->p_realtimer.it_value); >> > if (p->p_flag & P_WEXIT) >> > wakeup(&p->p_itcallout); >> > PROC_UNLOCK(p); >> > return; >> > } >> > for (;;) { >> > timevaladd(&p->p_realtimer.it_value, >> > &p->p_realtimer.it_interval); >> > getmicrouptime(&ctv); >> > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { >> > ntv = p->p_realtimer.it_value; >> > timevalsub(&ntv, &ctv); >> > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, >> > realitexpire, p); >> > PROC_UNLOCK(p); >> > return; >> > } >> > } >> > /*NOTREACHED*/ >> > } >> > >> > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as >> > seitimer() above: >> > >> > Index: kern_event.c >> > =================================================================== >> > --- kern_event.c (revision 238365) >> > +++ kern_event.c (working copy) >> > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) >> > >> > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { >> > calloutp = (struct callout *)kn->kn_hook; >> > - callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata), >> > + callout_reset_curcpu(calloutp, timertoticks(kn->kn_sdata) - 1, >> > filt_timerexpire, kn); >> > } >> > } >> > >> > -- >> > John Baldwin >> > _______________________________________________ >> > 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, >> I don't think it's good to decrease by a unit the 'ticks' you pass to >> callout_reset_* KPI. >> If this have to be fixed it should be fixed at the callout level and >> not at the consumer level. In other words, subsystems that makes use >> of callout_reset_* should not deal with the inherent limitations of >> callout precision, as it is right now. > > Given that you are reworking callout already, it would seem a bit odd > to rework callout a separate time just to fix this bug. A simple fix > like this (which follows the same pattern we already use for setitimer()) > is something we can easily merge back to 8 and 9. Reworking callout in > a different way than you are already doing, OTOH, is not something we can > merge trivially. > > -- > John Baldwin I understand what you mean. Indeed I hadn't thought about the difficulties of merging that work back. Only a thing: if I'd were you before committing I'd add a comment explaining the reasons of the negative correction in the timeout value passed. Davide From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 12:44:20 2012 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 F2D57106566C for ; Fri, 13 Jul 2012 12:44:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C87718FC16 for ; Fri, 13 Jul 2012 12:44:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D935B944; Fri, 13 Jul 2012 08:44:19 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 13 Jul 2012 08:31:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207130831.59211.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 08:44:19 -0400 (EDT) Cc: Bill Crisp Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:44:20 -0000 On Thursday, July 12, 2012 12:36:07 pm Bill Crisp wrote: > Good Morning! > > This was also posted to the FreeBSD forums: > > I have been researching CVE-2012-0217 and while I have patched the kernels > on servers with 7.3/8.2 that I have, I would like to see if anyone knows > for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are > out of support from looking at the documentation. I have looked at the code > in trap.c to see if the current patch would work with 6.3 source but it > won't based on what I saw. I am also aware of upgrading as an option to > resolve this unfortunately in some cases I have this is not possible right > now. > > Any help would be greatly appreciated, and I can of course test anything > that might need it. Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal opinion is that Intel screwed up their implementation of that instruction whereas AMD got it right, and we are merely working around Intel's CPU bug. :( -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 14:42:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD297106564A for ; Fri, 13 Jul 2012 14:42:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8518FC14 for ; Fri, 13 Jul 2012 14:42:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E41C2B93A; Fri, 13 Jul 2012 10:42:06 -0400 (EDT) From: John Baldwin To: Davide Italiano Date: Fri, 13 Jul 2012 08:45:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342036332.8313.8.camel@albrecht-desktop> <201207121125.01228.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207130845.32470.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 10:42:07 -0400 (EDT) Cc: Ian Lepore , Paul Albrecht , freebsd-hackers@freebsd.org Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Jul 2012 14:42:07 -0000 On Friday, July 13, 2012 8:22:13 am Davide Italiano wrote: > On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote: > > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote: > >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote: > >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote: > >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > >> >> > > > Hi, > >> >> > > > > >> >> > > > Sorry about this repost but I'm confused about the responses I received > >> >> > > > in my last post so I'm looking for some clarification. > >> >> > > > > >> >> > > > Specifically, I though I could use the kqueue timer as essentially a > >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised that > >> >> > > > the accuracy of the kqueue timer is much less than what I need for my > >> >> > > > application. > >> >> > > > > >> >> > > > So my confusion at this point is whether this is consider to be a bug or > >> >> > > > "feature"? > >> >> > > > > >> >> > > > Here's some test code if you want to verify the problem: > >> >> > > > > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > #include > >> >> > > > > >> >> > > > int > >> >> > > > main(void) > >> >> > > > { > >> >> > > > int i,msec; > >> >> > > > int kq,nev; > >> >> > > > struct kevent inqueue; > >> >> > > > struct kevent outqueue; > >> >> > > > struct timeval start,end; > >> >> > > > > >> >> > > > if ((kq = kqueue()) == -1) { > >> >> > > > fprintf(stderr, "kqueue error!? errno = %s", > >> >> > strerror(errno)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } > >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > >> >> > > > > >> >> > > > gettimeofday(&start, 0); > >> >> > > > for (i = 0; i < 50; i++) { > >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > >> >> > -1) { > >> >> > > > fprintf(stderr, "kevent error!? errno = %s", > >> >> > strerror(errno)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } else if (outqueue.flags & EV_ERROR) { > >> >> > > > fprintf(stderr, "EV_ERROR: %s\n", > >> >> > strerror(outqueue.data)); > >> >> > > > exit(EXIT_FAILURE); > >> >> > > > } > >> >> > > > } > >> >> > > > gettimeofday(&end, 0); > >> >> > > > > >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000); > >> >> > > > > >> >> > > > printf("msec = %d\n", msec); > >> >> > > > > >> >> > > > close(kq); > >> >> > > > return EXIT_SUCCESS; > >> >> > > > } > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > What you are seeing is "just the way FreeBSD currently works." > >> >> > > > >> >> > > Sleeping (in most all of its various forms, and I've just looked at the > >> >> > > kevent code to verify this is true there) is handled by converting the > >> >> > > amount of time to sleep (usually specified in a timeval or timespec > >> >> > > struct) to a count of timer ticks, using an internal routine called > >> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > >> >> > > account for the current tick. Whether that's a good idea or not (it > >> >> > > probably was once, and probably not anymore) it's how things currently > >> >> > > work, and could explain the fairly consistant +1ms you're seeing. > >> >> > > >> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > >> >> > installs a periodic callout that executes KNOTE() and then resets itself (via > >> >> > callout_reset()) each time it runs. This should generally be closer to > >> >> > regulary spaced intervals than something that does: > >> >> > > >> >> > >> >> In what way is it irrelevant? That is, what did I miss? It appears to > >> >> me that the next callout is scheduled by calling timertoticks() passing > >> >> a count of milliseconds, that count is converted to a struct timeval and > >> >> passed to tvtohz() which is where the +1 adjustment happens. If you ask > >> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. > >> >> There is some time, likely a small number of microseconds, that you've > >> >> consumed of the current tick, and that's what the +1 in tvtohz() is > >> >> supposed to account for according to the comments. > >> >> > >> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick > >> >> and then adds one tick on top of that. That seems not quite right to > >> >> me, except that it is a way to g'tee that you don't return early, and > >> >> that is the one promise made by sleep routines on any OS; those magical > >> >> "at least" words always appear in the docs. > >> >> > >> >> Actually what I'm missing (that I know of) is how the scheduler works. > >> >> Maybe the +1 adjustment to account for the fraction of the current tick > >> >> you've already consumed is the right thing to do, even when that > >> >> fraction is 1uS or less of a 1mS tick. That would depend on scheduler > >> >> behavior that I know nothing about. > >> > > >> > Ohhhhh. My bad, sorry. You are correct. It is a bug to use +1 in this > >> > case. That is, the +1 makes sense when you are computing a one-time delta > >> > for things like nanosleep(). It is incorrect when computing a periodic > >> > delta such as for computing the interval for an itimer (setitimer) or > >> > EVFILT_TIMER(). > >> > > >> > Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1: > >> > > >> > sys/kern/kern_time.c: > >> > > >> > /* > >> > * Real interval timer expired: > >> > * send process whose timer expired an alarm signal. > >> > * If time is not set up to reload, then just return. > >> > * Else compute next time timer should go off which is > current time. > >> > * This is where delay in processing this timeout causes multiple > >> > * SIGALRM calls to be compressed into one. > >> > * tvtohz() always adds 1 to allow for the time until the next clock > >> > * interrupt being strictly less than 1 clock tick, but we don't want > >> > * that here since we want to appear to be in sync with the clock > >> > * interrupt even when we're delayed. > >> > */ > >> > void > >> > realitexpire(void *arg) > >> > { > >> > struct proc *p; > >> > struct timeval ctv, ntv; > >> > > >> > p = (struct proc *)arg; > >> > PROC_LOCK(p); > >> > kern_psignal(p, SIGALRM); > >> > if (!timevalisset(&p->p_realtimer.it_interval)) { > >> > timevalclear(&p->p_realtimer.it_value); > >> > if (p->p_flag & P_WEXIT) > >> > wakeup(&p->p_itcallout); > >> > PROC_UNLOCK(p); > >> > return; > >> > } > >> > for (;;) { > >> > timevaladd(&p->p_realtimer.it_value, > >> > &p->p_realtimer.it_interval); > >> > getmicrouptime(&ctv); > >> > if (timevalcmp(&p->p_realtimer.it_value, &ctv, >)) { > >> > ntv = p->p_realtimer.it_value; > >> > timevalsub(&ntv, &ctv); > >> > callout_reset(&p->p_itcallout, tvtohz(&ntv) - 1, > >> > realitexpire, p); > >> > PROC_UNLOCK(p); > >> > return; > >> > } > >> > } > >> > /*NOTREACHED*/ > >> > } > >> > > >> > Paul, try this patch for sys/kern/kern_event.c. It uses the same approach as > >> > seitimer() above: > >> > > >> > Index: kern_event.c > >> > =================================================================== > >> > --- kern_event.c (revision 238365) > >> > +++ kern_event.c (working copy) > >> > @@ -538,7 +538,7 @@ filt_timerexpire(void *knx) > >> > > >> > if ((kn->kn_flags & EV_ONESHOT) != EV_ONESHOT) { > >> > calloutp = (struct callout *)kn->kn_hook; > >> > - callout_reset_curcpu(calloutp, timertoticks(kn- >kn_sdata), > >> > + callout_reset_curcpu(calloutp, timertoticks(kn- >kn_sdata) - 1, > >> > filt_timerexpire, kn); > >> > } > >> > } > >> > > >> > -- > >> > John Baldwin > >> > _______________________________________________ > >> > 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, > >> I don't think it's good to decrease by a unit the 'ticks' you pass to > >> callout_reset_* KPI. > >> If this have to be fixed it should be fixed at the callout level and > >> not at the consumer level. In other words, subsystems that makes use > >> of callout_reset_* should not deal with the inherent limitations of > >> callout precision, as it is right now. > > > > Given that you are reworking callout already, it would seem a bit odd > > to rework callout a separate time just to fix this bug. A simple fix > > like this (which follows the same pattern we already use for setitimer()) > > is something we can easily merge back to 8 and 9. Reworking callout in > > a different way than you are already doing, OTOH, is not something we can > > merge trivially. > > > > -- > > John Baldwin > > I understand what you mean. Indeed I hadn't thought about the > difficulties of merging that work back. Only a thing: if I'd were you > before committing I'd add a comment explaining the reasons of the > negative correction in the timeout value passed. Ok. Likely what I will do is just point the reader at the comments for realitexpire() which already cover this case in detail. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 15:09:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBFA3106564A for ; Fri, 13 Jul 2012 15:09:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0B5F8FC0C for ; Fri, 13 Jul 2012 15:09:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F92FB93A; Fri, 13 Jul 2012 11:09:15 -0400 (EDT) From: John Baldwin To: "Poul-Henning Kamp" Date: Fri, 13 Jul 2012 11:02:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <44644.1342190524@critter.freebsd.dk> In-Reply-To: <44644.1342190524@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207131102.14379.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 11:09:15 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Bill Crisp Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:09:16 -0000 On Friday, July 13, 2012 10:42:04 am Poul-Henning Kamp wrote: > In message <201207130831.59211.jhb@freebsd.org>, John Baldwin writes: > > >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal > >opinion is that Intel screwed up their implementation of that instruction > >whereas AMD got it right, and we are merely working around Intel's CPU bug. :( > > Given that the instruction set of AMD64 is defined by AMD originally, > while Intel was trying very hard to ram Itanic down everybodys > throat, that diagnosis is a given: Intel copied AMD, and difference > in functionality is a screwup on Intels part, even if they documented > their screwup in their manual. > > TL;DR: Which part of "compatible" doesn't Intel get ? In this case, I believe they were just lazy and reused some existing block to manage this exception case without properly thinking through the security implications of using a user-supplied stack pointer to handle a fault. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 14:42:13 2012 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 909AE106564A; Fri, 13 Jul 2012 14:42:13 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4A74D8FC1A; Fri, 13 Jul 2012 14:42:13 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 4970E3B758; Fri, 13 Jul 2012 14:42:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q6DEg46A044645; Fri, 13 Jul 2012 14:42:04 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 Jul 2012 08:31:59 -0400." <201207130831.59211.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 13 Jul 2012 14:42:04 +0000 Message-ID: <44644.1342190524@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 13 Jul 2012 15:46:54 +0000 Cc: freebsd-hackers@freebsd.org, Bill Crisp Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 14:42:13 -0000 In message <201207130831.59211.jhb@freebsd.org>, John Baldwin writes: >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal >opinion is that Intel screwed up their implementation of that instruction >whereas AMD got it right, and we are merely working around Intel's CPU bug. :( Given that the instruction set of AMD64 is defined by AMD originally, while Intel was trying very hard to ram Itanic down everybodys throat, that diagnosis is a given: Intel copied AMD, and difference in functionality is a screwup on Intels part, even if they documented their screwup in their manual. TL;DR: Which part of "compatible" doesn't Intel get ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 17:26:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39AFB1065670; Fri, 13 Jul 2012 17:26:25 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97E768FC0C; Fri, 13 Jul 2012 17:26:24 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so763211wgb.1 for ; Fri, 13 Jul 2012 10:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pOPRXGNhfSK6Aj50SumfEL2hKZTdRJ6XeMxBWXeIxWI=; b=qqt5mkQmPeZ5yj/HEWYi1ADClmuU3z3aT+EFy6SRzIujD9IerA7UEwzBZW/YEfs28p TpmR6Aw5vVW1kb0V8ZXXi4dI9H9d1/lBUYYnOJJ2HMlCVR/rtcQ8IZse0gamtSAwqJav oKkmh1j952s71eTUxmTAoskISY+T24uXfmqYkQDqtV2t6yEjf/LDNGnlqbZwII3Q/snX KCDeR5apjDESJb4ErKOjuJhOozEKXC3FfuncW38bBZxNd3zvk5kDS7iOhfCrWOrlv1YU iVmDgh5PFD7BJrrFhY9NYkcFTnEgTF7OyjxAXGCKMk0dG1JHzDYjpUSL0lWj/lhert/V kkcA== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr1025259wes.108.1342200378516; Fri, 13 Jul 2012 10:26:18 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 13 Jul 2012 10:26:18 -0700 (PDT) In-Reply-To: <201207131102.14379.jhb@freebsd.org> References: <44644.1342190524@critter.freebsd.dk> <201207131102.14379.jhb@freebsd.org> Date: Fri, 13 Jul 2012 13:26:18 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Poul-Henning Kamp , Bill Crisp Subject: Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:26:25 -0000 Hi, On Fri, Jul 13, 2012 at 11:02 AM, John Baldwin wrote: > On Friday, July 13, 2012 10:42:04 am Poul-Henning Kamp wrote: >> In message <201207130831.59211.jhb@freebsd.org>, John Baldwin writes: >> >> >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my > personal >> >opinion is that Intel screwed up their implementation of that instruction >> >whereas AMD got it right, and we are merely working around Intel's CPU bug. > :( >> >> Given that the instruction set of AMD64 is defined by AMD originally, >> while Intel was trying very hard to ram Itanic down everybodys >> throat, that diagnosis is a given: Intel copied AMD, and difference >> in functionality is a screwup on Intels part, even if they documented >> their screwup in their manual. >> >> TL;DR: Which part of "compatible" doesn't Intel get ? > > In this case, I believe they were just lazy and reused some existing block to > manage this exception case without properly thinking through the security > implications of using a user-supplied stack pointer to handle a fault. > Just as FreeBSD's developers were lazy when new-bus was designed ? Honestly, what's the point of this rock throwing and ad-hominem attacks ? I could start throwing a few more CVE-2009-2936 or CVE-2009-4488; just to point out nobody's perfect... - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 17:56:59 2012 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 B48651065673; Fri, 13 Jul 2012 17:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19B6F8FC14; Fri, 13 Jul 2012 17:56:58 +0000 (UTC) Received: by weyx56 with SMTP id x56so3552896wey.13 for ; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ni6wES3hVOMhStcZoBcASbqzS5yXiXojkyav9c/BjY=; b=Gym12y7kMzTE6ihNNtGei0GwVJIs5U8ebe1IJ9FGYfb+De9FgJR/BGVwKveD34q2OC xshl0SfRuLwonxFr8PlNagrp3xXk/QM5lJlv2XxC0PWk95508BhqMnCQyUJNIiAoUYiy MaLd2dbPg1ejfDCuqXpvAAiQ5BvGebNiSNSl1gsxL1oXTHvy08bwDajGlodor8Wpn0Vk vRGGj7HCL3oiRBE5hfQfYNvTgfKLL0zdTVT1rIoFAYjh95B0KnsjGgybIwBMk9I0I5Yk KF2wCcwILbO6M4qtNpzej0rkYEJTh9R2BibhEMBGErbk7kxU+t+cinhFfAGQE1Y+5oMb p5Dw== MIME-Version: 1.0 Received: by 10.180.102.136 with SMTP id fo8mr4440898wib.19.1342202218019; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 13 Jul 2012 10:56:57 -0700 (PDT) In-Reply-To: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Fri, 13 Jul 2012 13:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Jul 2012 17:56:59 -0000 Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > [..] > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > I will just pass function pointers for now, if things should be done dirty, let's be explicit about it. Now, the hinted device attachment did work quite smoothly, however, I would have a few suggestion: 1) add a call to bus_enumerate_hinted_children() before the call DEVICE_IDENTIFY() call in bus_generic_driver_added() this is required to be able to support dynamic loading and attachment of hinted children. 2) have a generic bus_hinted_child method which would just add a new child to the bus. 3) have bus_enumerate_hinted_children() and bus_generic_attach() always ran on device attachment. There is current +100 explicit call to bus_generic_attach() in the sys/dev/ tree. This should be done always and implicitly. 4) have bus_generic_detach() always ran prior to device detachment If not already the case. There is still the same +100 direct call to bus_generic_detach is the tree. 5) have the bus_generic_* method be the default of their respective method 6) have device_delete_child() called upon device detachment. As a rule of thumb, when a kld is unloaded there should not be any remains of anything built previously. Without device_delete_child() or proper singleton implementation, multiple load/unload sequence of bus will attempt to attach multiple version of a child, even if the single child was added prior to the bus_generic_attach() call. Also, as a rule of thumb, if the same logic is implemented in more than a few buses, it should be made generic and implicit. I am lazy, I hate doing the same things over and over, not to say it raised the likelihood of bugs' introduction... - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 10:11:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96733106566B for ; Sat, 14 Jul 2012 10:11:45 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 417AF8FC14 for ; Sat, 14 Jul 2012 10:11:45 +0000 (UTC) Received: by qabg1 with SMTP id g1so795545qab.13 for ; Sat, 14 Jul 2012 03:11:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:organization:x-mailer:face :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=vK2YFvLe5rNayx0khIYd5YphD+K2Jqe153mc+0/T2iw=; b=HO5dQ3kwTC5yC/15qmUIlPtaVJP5AEnS2y49jyD+3vOzrGCpfeA7S5DqkFPhGZBXsz knu7z5V++g0uBVr23hZrYOXmesUKlxvken3A5ZBBGhS884+8g1kuf5yh1I9FD7LdQTmO /nLd3nfv7Zl74MrNsjT2Ng/VjNql5zTPB2vPgQ084nD5NLvUE3b+XQUJrkpC29mSbiz6 AijBjxLDPAUYsV42ZhDTGHE1q2AE08TnkTvpcEO4fw0PZrsvrYJEP6GhFpHSqkQycgKb zfAAv3Zadp0zpdxy3+MJ8IUBuwZI+T054TciX1wdVAZKt66uvArOC7iXZFD5SPjvfyZD FpuA== Received: by 10.229.137.72 with SMTP id v8mr2350846qct.79.1342260704391; Sat, 14 Jul 2012 03:11:44 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id z9sm14422610qae.15.2012.07.14.03.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 03:11:44 -0700 (PDT) Date: Sat, 14 Jul 2012 06:11:41 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20120714061141.473cc8ee@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQntTr9RPQYxzNTbn5sbQ/hnfEkM5VTFOXazhPK3zgYDzdrhZwVtzgbrdarXFVbqmvMonkFP Subject: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 10:11:45 -0000 I just set up a system designed to handle lots of VBox VM's: a 6-core SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. Unfortunately, once I got it set up, I found that VBox guest performance simply sucks. The *mouse* isn't responsive. Linux guests see lots of "CPU Locked" errors. Googling turns up lots of problems with VBox on SandyBridge: Mac's running on 64 bit kernels have this problem - running on 32 bit kernels helps. Turning off Intel's SpeedStep has been reported to help. Turning off VT-X in the guest - if it's a 32-bit guest - helps. The last one is the only one that actually helped me. I was wondering if anyone here had run into and solved similar problems? Or if they were running a similar system, and didn't run into that problem? Especially anyone running 9.0 instead of 8.X! Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 17:56:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B95A9106566C for ; Sat, 14 Jul 2012 17:56:36 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 159BA8FC08 for ; Sat, 14 Jul 2012 17:56:35 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6EHuNaN001637; Sat, 14 Jul 2012 19:56:23 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6EHuMQT001634; Sat, 14 Jul 2012 19:56:23 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 14 Jul 2012 19:56:22 +0200 (CEST) From: Wojciech Puchar To: Mike Meyer In-Reply-To: <20120714061141.473cc8ee@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 14 Jul 2012 19:56:24 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:56:36 -0000 > SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. i am using virtualbox but no linux guest, only windows. the newest CPU i have is CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3100.03-MHz K8-class CPU) > Unfortunately, once I got it set up, I found that VBox guest > performance simply sucks. The *mouse* isn't responsive. Linux guests > see lots of "CPU Locked" errors. FreeBSD have linux emulation. i think you should use it instead of VBox if you need to run linux environments under FreeBSD. jails are your friend too. Windows runs great (as for windows of course) under VBox. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 18:16:33 2012 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 ABB1D106566C for ; Sat, 14 Jul 2012 18:16:33 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 51C7F8FC0C for ; Sat, 14 Jul 2012 18:16:33 +0000 (UTC) Received: by qabg1 with SMTP id g1so916868qab.13 for ; Sat, 14 Jul 2012 11:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:face:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=kz5KBIghDJIjAtBUS3W6VJgYB6uxs0GzHo9H/Q8mE3k=; b=aKroWl5noevF6At37iVCYaFP2iaRRw2VARNM2HwkVjmc5y0IUSkHdPiD7jJPVPTpPZ RcMuRvXHEAwD3iQ3PWXDcR2dmBGPYqvdCwLKpFqJKPZNwZRjKnBEQz/DQFnGwUfbS1r4 zOh90m0Qw87nDgpVUmj9GltonQpGxacV+hdSTuyjfaoSX1jD0skCyOutE3RLCysk3FIZ iBiSaBEuuazdqwwhzPSjZqiYAhNMXp4X15lyCqukpGqSZcFskGoV9hdiEcP5G9Z+bxmJ NkWLale/EMd4CuiRpW+2/Yq1rw5DToMLY+zD+bQW6/fs+j+4x2omq5QZEPNJ5aetZIGQ Uo2g== Received: by 10.224.217.9 with SMTP id hk9mr11061893qab.58.1342289792738; Sat, 14 Jul 2012 11:16:32 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id cz12sm15787509qab.5.2012.07.14.11.16.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 11:16:32 -0700 (PDT) Date: Sat, 14 Jul 2012 14:16:29 -0400 From: Mike Meyer To: Wojciech Puchar Message-ID: <20120714141629.7d968e4e@bhuda.mired.org> In-Reply-To: References: <20120714061141.473cc8ee@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmjG+Rs59ACQWmdnzfoLnyT0hDj3NbjeAJXXAmA84U7xaf3Cxy2ZBuNoV/GG3iJ8f1Wv0LB Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:16:33 -0000 On Sat, 14 Jul 2012 19:56:22 +0200 (CEST) Wojciech Puchar wrote: > CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3100.03-MHz K8-class CPU) If that the one normally listed as E3-1220? If so, it's a Sandy Bridge processor. If not, then I have not idea what it is. > > Unfortunately, once I got it set up, I found that VBox guest > > performance simply sucks. The *mouse* isn't responsive. Linux guests > > see lots of "CPU Locked" errors. > FreeBSD have linux emulation. i think you should use it instead of VBox if > you need to run linux environments under FreeBSD. Yes, it does. And I use it when I can. However, there are applications that it won't run, because of missing kernel features. And of course, it does absolutely not good at all if you need to run something other than Linux. Sucky Linux emulation performance is not my problem. If it were, I would have asked about that. My problem is sucky virtualbox performance, on any guest that has VT-X emulation enabled (which means all 64 bit guests). > Windows runs great (as for windows of course) under VBox. Not for me. *Every* 64-bit guest OS has sucky performance. Linux, Windows, and others. The only one that reports any problems is Linux - it reports the "CPU Locked" errors. The others just suck. If I cut the memory size down and create 32-bit guests, they all seem to run OK. But I want to run systems for which there aren't 32-bit distributions. Are you only running 32-bit guests? Are you running on 9.x or 8.x? Thanx, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 18:19:46 2012 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 7689D106566B for ; Sat, 14 Jul 2012 18:19:46 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7198FC0C for ; Sat, 14 Jul 2012 18:19:46 +0000 (UTC) Received: by ghbz22 with SMTP id z22so5009105ghb.13 for ; Sat, 14 Jul 2012 11:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=epLUvPaC8vYvkFPL3AWkcwDkscz7ayq8J36krELSuss=; b=g2RJe61DCBJIe+BeNhI4kEo2GwXZBCEsMgYeMzwB+8TIV7mbyeywePgyQNv6GTcZfQ sOOkXhKMYNsVkd+M4cPKwaMNq4w6wt8C/f4hDK3k3aPGfsVfCTbsr/GypnO2iBklf5mK cXH8Mur2nt0EA3HGZOP/lGm/mP37ad/oehc0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=epLUvPaC8vYvkFPL3AWkcwDkscz7ayq8J36krELSuss=; b=QA6g8rPL3b/zQ1gPhzrPTauJcJ0JWCHigPLMRNK9AirMCMH/oIhndqVuLyXPQrBVml s3v5pNaaAeRVDA6kNGnGnPEczgYIjRChSIYrNppqIFKYgRSZ9/Vl41pBUrbM8SHF/jhv Pr/YNjROq3El3/2KZhVpHGqH/ttx2vd8DH1jkR0LevZu8IhQB2uop0N6CW9eVF1zh30R IZVQVM6ZcoVNTmA+d3xYM2NhZvs7+w49ugjqdBECRfCfN5pMEG7/OLwjDy1trUo2xxmi RSDDclE3kRLt8W4B/Rh+Jz6t16RlsWlf3wLdJK6N+iLXcvcOc8uVZtns9z+Pf2KDixyA RbQw== Received: by 10.50.173.5 with SMTP id bg5mr1876717igc.35.1342289985109; Sat, 14 Jul 2012 11:19:45 -0700 (PDT) Received: from DataIX.net (adsl-99-109-124-107.dsl.klmzmi.sbcglobal.net. [99.109.124.107]) by mx.google.com with ESMTPS id k6sm9457494igw.14.2012.07.14.11.19.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 11:19:44 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6EIJfWf067103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 14:19:41 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6EIJd8N067102; Sat, 14 Jul 2012 14:19:39 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 14 Jul 2012 14:19:39 -0400 From: Jason Hellenthal To: Mike Meyer Message-ID: <20120714181939.GA34209@DataIX.net> References: <20120714061141.473cc8ee@bhuda.mired.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120714061141.473cc8ee@bhuda.mired.org> X-Gm-Message-State: ALoCoQkgBrlvCnuz8l8CXzCL02eKqM87RvwE9TODysmYYwmsczHWmnPei2GfsC7C4tlF87kPHp1Z Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:19:46 -0000 On Sat, Jul 14, 2012 at 06:11:41AM -0400, Mike Meyer wrote: > I just set up a system designed to handle lots of VBox VM's: a 6-core > SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. > > Unfortunately, once I got it set up, I found that VBox guest > performance simply sucks. The *mouse* isn't responsive. Linux guests > see lots of "CPU Locked" errors. Try booting the linux VBox with HZ=100. This should greatly improve your performance. > > Googling turns up lots of problems with VBox on SandyBridge: Mac's > running on 64 bit kernels have this problem - running on 32 bit > kernels helps. Turning off Intel's SpeedStep has been reported to > help. Turning off VT-X in the guest - if it's a 32-bit guest - > helps. The last one is the only one that actually helped me. > > I was wondering if anyone here had run into and solved similar > problems? Or if they were running a similar system, and didn't run > into that problem? Especially anyone running 9.0 instead of 8.X! > > > > Thanks, > > -- > Mike Meyer http://www.mired.org/ > Independent Software developer/SCM consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.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" -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 18:27:18 2012 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 22013106564A for ; Sat, 14 Jul 2012 18:27:18 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD178FC0A for ; Sat, 14 Jul 2012 18:27:17 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6EIRBfQ001827; Sat, 14 Jul 2012 20:27:11 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6EIRB0m001824; Sat, 14 Jul 2012 20:27:11 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 14 Jul 2012 20:27:11 +0200 (CEST) From: Wojciech Puchar To: Mike Meyer In-Reply-To: <20120714141629.7d968e4e@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714141629.7d968e4e@bhuda.mired.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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 14 Jul 2012 20:27:12 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:27:18 -0000 > Wojciech Puchar wrote: > >> CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3100.03-MHz K8-class CPU) > > If that the one normally listed as E3-1220? If so, it's a Sandy Bridge yes. > processor. If not, then I have not idea what it is. so it is. it have working AES-NI. I am such a kind of person that i am completely not on-time with marketing, namings, etc.. I just asked what CPUs will support AES-NI which is important for me (geli speedup) and got that in Dell Server ;) Virtualbox works great with windoze on that machine. >> FreeBSD have linux emulation. i think you should use it instead of VBox if >> you need to run linux environments under FreeBSD. > > Yes, it does. And I use it when I can. However, there are applications > that it won't run, because of missing kernel features. And of course, > it does absolutely not good at all if you need to run something other > than Linux. > would have asked about that. My problem is sucky virtualbox > performance, on any guest that has VT-X emulation enabled (which means > all 64 bit guests). > i would rather bet on linux addon kernel modules you have to install. In windows you have to install "guest additions" without this it is plain terrible. >> Windows runs great (as for windows of course) under VBox. > > Not for me. *Every* 64-bit guest OS has sucky performance. Linux, Are you sure with two level pagetables featured in modern CPUs including sandy bridge? > Are you only running 32-bit guests? Are you running on 9.x or 8.x? for production - yes (6 instances of windows XP). Virtualbox does never make main workload for me, it is just addon. On FreeBSD 8.3. But i've tried Windows 7 64-bit and it worked fine. didn't see any problems with latency you describe From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 18:43:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26149106566C for ; Sat, 14 Jul 2012 18:43:46 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id BEC178FC08 for ; Sat, 14 Jul 2012 18:43:45 +0000 (UTC) Received: by qabg1 with SMTP id g1so922928qab.13 for ; Sat, 14 Jul 2012 11:43:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:face:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=mOIpd78ph4BBLCOsVaDc3EJP/B4a0KbjZalgPsNfzoQ=; b=hTZRdPF8/1fSOdb+JBWD3yRpecjEgc7LzR/jIsS6J2/bppJZZeGbPk1HdtWL7Z56J0 KjS09k1N+yEMwN/QUXDG49exFxLufjiZln2FhI+iNz+MY3e7bLg0ehGiEy7/AigXLgU7 C11AyHTDZSxAbi+mKtglt4oL5XKnvXnTTtqEEkI/uzpduUlPpOvFfIGDu4RqMDlk70tD rayMvo396SeKj950rMG/kakXArhzqH5ApYGUZiT33zBnKYh/mrCxsifl7h05QEUJ1qyx Jyj86nPciORmbNTONCO5H0/oaqw7kfS3KhNUYxQGn2maBvQEumFYv2TQS4y2dQSJxW7L edgg== Received: by 10.224.30.212 with SMTP id v20mr11126210qac.52.1342291425033; Sat, 14 Jul 2012 11:43:45 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id z9sm15852236qae.15.2012.07.14.11.43.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 11:43:44 -0700 (PDT) Date: Sat, 14 Jul 2012 14:43:42 -0400 From: Mike Meyer To: Wojciech Puchar Message-ID: <20120714144342.4c2141c8@bhuda.mired.org> In-Reply-To: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714141629.7d968e4e@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkY9LJcQ66nnoB/pqMKU3i66QXTltppV7dYHtw/NJRKUBoBCvLVTnfNyFxp5kA1EKLs0k9H Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:43:46 -0000 On Sat, 14 Jul 2012 20:27:11 +0200 (CEST) Wojciech Puchar wrote: > > would have asked about that. My problem is sucky virtualbox > > performance, on any guest that has VT-X emulation enabled (which means > > all 64 bit guests). > i would rather bet on linux addon kernel modules you have to install. Are you talking about the guest additions? They're already installed (on a VM that was running on an older Core 2 CPU). Performance sucks. > In windows you have to install "guest additions" without this it is plain > terrible. I haven't managed to get through an install on a 64-bit windows system yet to try that. However, that Linux doesn't Linux, or for the 32-bit > >> Windows runs great (as for windows of course) under VBox. > > Not for me. *Every* 64-bit guest OS has sucky performance. Linux, > Are you sure with two level pagetables featured in modern CPUs including > sandy bridge? Yes, I'm sure that every guest OS I've tried on a 64 bit guest sucks. I'm busy recreating 32-bit versions of the 64-bit guests where I can. > > Are you only running 32-bit guests? Are you running on 9.x or 8.x? > for production - yes (6 instances of windows XP). Virtualbox does never > make main workload for me, it is just addon. On FreeBSD 8.3. Could you tell me if they all have VT-X disabled? > But i've tried Windows 7 64-bit and it worked fine. didn't see any > problems with latency you describe Could you send me the system settings (VT-X, PAE, etc.) you used for this? Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 19:13:51 2012 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 A87F2106566B for ; Sat, 14 Jul 2012 19:13:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 65B248FC0C for ; Sat, 14 Jul 2012 19:13:51 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q6EJDocs060839; Sat, 14 Jul 2012 13:13:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q6EJDoQK060836; Sat, 14 Jul 2012 13:13:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 14 Jul 2012 13:13:50 -0600 (MDT) From: Warren Block To: Mike Meyer In-Reply-To: <20120714061141.473cc8ee@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 14 Jul 2012 13:13:50 -0600 (MDT) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 19:13:51 -0000 On Sat, 14 Jul 2012, Mike Meyer wrote: > I just set up a system designed to handle lots of VBox VM's: a 6-core > SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. > > Unfortunately, once I got it set up, I found that VBox guest > performance simply sucks. The *mouse* isn't responsive. Linux guests > see lots of "CPU Locked" errors. Can you give a specific Linux version that has problems? I'm willing to download and test it on this i5/9-stable/amd64 system. Haven't noticed any problems, but I only occasionally boot Ubuntu in a VM for a little bit. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 19:27:53 2012 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 B5188106566B for ; Sat, 14 Jul 2012 19:27:53 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 571BD8FC0A for ; Sat, 14 Jul 2012 19:27:53 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3151894qcs.13 for ; Sat, 14 Jul 2012 12:27:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:face:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=iHjw1eSxw1RtDSl/TROAFAVAOqOiNP0SZqvbSg/UwZg=; b=Bh1kO+7G35MPma+1cqToZ06XlC9EDsz4u+xSjJiB5gELyinbM0e5cUOh6ZC2WUoX4P w2E/CDKrQijLcNuDPMm9GXKocTgdBXj/SLJTyrj+QDZHVezMT1HDdAtbwmYCUZbJWQnc 5QM+jIiMPiVVKZQkPlBQ/j8sOo7BUJrdQH4/pBDuh+3nVj2pNXyni4TT8UEeX4a3hgfU lStSI5h7ovpnY0f4dR/krGt+tcQLgE1qukWGRYuDdfhpZeug/Gtkqwm0aPNNuL/zolLR TWZ908qTcH+yFi8AXyEnEufWCyLmXhTI+fUeuAABBb31L9SW/vqZVPOj2QPwpDprAV6N uWDg== Received: by 10.229.173.40 with SMTP id n40mr3216522qcz.28.1342294072514; Sat, 14 Jul 2012 12:27:52 -0700 (PDT) Received: from bhuda.mired.org (74-140-201-117.dhcp.insightbb.com. [74.140.201.117]) by mx.google.com with ESMTPS id ea5sm16005499qab.2.2012.07.14.12.27.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 12:27:52 -0700 (PDT) Date: Sat, 14 Jul 2012 15:27:45 -0400 From: Mike Meyer To: Warren Block , "freebsd-hackers@freebsd.org" Message-ID: <20120714152745.1fe15238@bhuda.mired.org> In-Reply-To: References: <20120714061141.473cc8ee@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlkkLRR4nxUeYwuJJAzBF64JiVIBAJF7XQRND9sF6dg1r8arvaa2Rbey+g6s1PvjxpccwmY Cc: Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 19:27:53 -0000 On Sat, 14 Jul 2012 13:13:50 -0600 (MDT) Warren Block wrote: > On Sat, 14 Jul 2012, Mike Meyer wrote: > Can you give a specific Linux version that has problems? I'm willing to > download and test it on this i5/9-stable/amd64 system. Haven't noticed > any problems, but I only occasionally boot Ubuntu in a VM for a little > bit. 64-bit Ubuntu LTS 12.04. I moved a VM from the previous system, where it worked fine (same build of FreeBSD, same build of VirtualBox). The OS seems to be irrelevant. Windows XP and 7 and mumble all have this problem, *if* I have VT-X enabled in VirtualBox. If I disable VT-X, the ones I have tested so far worked fine. I'm still getting 32-bit builds of some of them, as you can't turn VT-X off in a 64-bit guest. Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 20:15:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83A171065673 for ; Sat, 14 Jul 2012 20:15:05 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 38AA18FC1C for ; Sat, 14 Jul 2012 20:15:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q6EKF4VA061084; Sat, 14 Jul 2012 14:15:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q6EKF3wf061081; Sat, 14 Jul 2012 14:15:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 14 Jul 2012 14:15:03 -0600 (MDT) From: Warren Block To: Mike Meyer In-Reply-To: <20120714152745.1fe15238@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 14 Jul 2012 14:15:04 -0600 (MDT) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:15:05 -0000 On Sat, 14 Jul 2012, Mike Meyer wrote: > On Sat, 14 Jul 2012 13:13:50 -0600 (MDT) > Warren Block wrote: >> On Sat, 14 Jul 2012, Mike Meyer wrote: >> Can you give a specific Linux version that has problems? I'm willing to >> download and test it on this i5/9-stable/amd64 system. Haven't noticed >> any problems, but I only occasionally boot Ubuntu in a VM for a little >> bit. > > 64-bit Ubuntu LTS 12.04. I moved a VM from the previous system, where > it worked fine (same build of FreeBSD, same build of VirtualBox). The > OS seems to be irrelevant. Windows XP and 7 and mumble all have this > problem, *if* I have VT-X enabled in VirtualBox. If I disable VT-X, > the ones I have tested so far worked fine. I'm still getting 32-bit > builds of some of them, as you can't turn VT-X off in a 64-bit guest. In a VM with stock settings (Linux 64-bit), Ubuntu 12.04 LTS Desktop Live CD works okay, installed also seems to work okay. The mouse is a little draggy but usable, like using a wireless mouse. kern.hz is set to 100 on the host (9-stable, er 9.1-BETA1, amd64). This is without guest additions. Trying the VirtualBox menu "install guest additions" made it crash. The only mouse problem I saw was the mouse pointer disappearing when over some preferences icons. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 20:25:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DEDA1065670 for ; Sat, 14 Jul 2012 20:25:28 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7228FC21 for ; Sat, 14 Jul 2012 20:25:28 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8259039pbb.13 for ; Sat, 14 Jul 2012 13:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BfSvoyUczypvEyy2QDLEW2JjGVI8rG6cgwsBkt43eZ8=; b=MW71ggbnUBiM5NmAly0eyQsiByXHuztIdC2t+McrN9Gx9unCtllXHqluezM9mvum/k bdknVi84YvEiiOLcPaf2lrufukAVkPc6WWdG9UpcRbnf6SssOabKLi/q3dqMqSCI6v5t ZaLCaITVZeNKapzu84Odd9BAERKBGSRq2D7MfG3w6aBP7fVQ52q4VQ+DtFwNsVABMpaJ 7vw7bGLKTgHjE3rJx//cOlnj6E/lMXPolF0kwHIqTbbXap/pm85yyEcbnEmt7QYOTmEH Qv0GinYObHBSXnEvcRZ/5zwmIQwQ0t9lqC1SbgG9YqgxlnRVwY73jg5HBICB+YxSn7Ki dGnw== MIME-Version: 1.0 Received: by 10.66.76.130 with SMTP id k2mr11253083paw.19.1342297527837; Sat, 14 Jul 2012 13:25:27 -0700 (PDT) Received: by 10.68.227.132 with HTTP; Sat, 14 Jul 2012 13:25:27 -0700 (PDT) In-Reply-To: <20120714152745.1fe15238@bhuda.mired.org> References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> Date: Sat, 14 Jul 2012 15:25:27 -0500 Message-ID: From: Adam Vande More To: Mike Meyer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:25:28 -0000 On Sat, Jul 14, 2012 at 2:27 PM, Mike Meyer wrote: > > 64-bit Ubuntu LTS 12.04. I moved a VM from the previous system, where > it worked fine (same build of FreeBSD, same build of VirtualBox). The > OS seems to be irrelevant. Windows XP and 7 and mumble all have this > problem, *if* I have VT-X enabled in VirtualBox. If I disable VT-X, > the ones I have tested so far worked fine. I'm still getting 32-bit > builds of some of them, as you can't turn VT-X off in a 64-bit guest. If possible, set VM to single cpu. Also not sure how you migrated machines. Occasionally the VM export/import functionality has produced silliness. Try creating new VM from scratch then attaching existing VM disk(s) to it. -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 20:30:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 684671065670 for ; Sat, 14 Jul 2012 20:30:00 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EE1AF14F9DA; Sat, 14 Jul 2012 20:29:59 +0000 (UTC) Message-ID: <5001D6C7.4070103@FreeBSD.org> Date: Sat, 14 Jul 2012 13:29:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adam Vande More References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Mike Meyer Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:30:00 -0000 For the OP, make sure you have the latest BIOS. I had a similar problem with vt-x and it was solved by a later BIOS upgrade. hth, Doug -- Change is hard. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 21:26:56 2012 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 66E061065670 for ; Sat, 14 Jul 2012 21:26:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2150F8FC0C for ; Sat, 14 Jul 2012 21:26:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q6ELQtKs061425; Sat, 14 Jul 2012 15:26:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q6ELQtul061422; Sat, 14 Jul 2012 15:26:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 14 Jul 2012 15:26:55 -0600 (MDT) From: Warren Block To: Mike Meyer In-Reply-To: Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714152745.1fe15238@bhuda.mired.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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 14 Jul 2012 15:26:55 -0600 (MDT) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:26:56 -0000 On Sat, 14 Jul 2012, Warren Block wrote: > In a VM with stock settings (Linux 64-bit), Ubuntu 12.04 LTS Desktop Live CD > works okay, installed also seems to work okay. The mouse is a little draggy > but usable, like using a wireless mouse. kern.hz is set to 100 on the host > (9-stable, er 9.1-BETA1, amd64). This is without guest additions. Trying > the VirtualBox menu "install guest additions" made it crash. > > The only mouse problem I saw was the mouse pointer disappearing when over > some preferences icons. Switched to XUbuntu because the menus were irritating in plain Ubuntu. No serious problems there either, and at least the package manager is locatable. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 21:51:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F12DD1065672 for ; Sat, 14 Jul 2012 21:51:01 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0AA8FC0A for ; Sat, 14 Jul 2012 21:51:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6ELotRF002783; Sat, 14 Jul 2012 23:50:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6ELotKL002780; Sat, 14 Jul 2012 23:50:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 14 Jul 2012 23:50:54 +0200 (CEST) From: Wojciech Puchar To: Mike Meyer In-Reply-To: <20120714144342.4c2141c8@bhuda.mired.org> Message-ID: References: <20120714061141.473cc8ee@bhuda.mired.org> <20120714141629.7d968e4e@bhuda.mired.org> <20120714144342.4c2141c8@bhuda.mired.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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 14 Jul 2012 23:50:55 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:51:02 -0000 >> i would rather bet on linux addon kernel modules you have to install. > > Are you talking about the guest additions? They're already installed > (on a VM that was running on an older Core 2 CPU). Performance sucks. something must be wrong with linux interacting with virtualbox. Won't help you as i never used linux on it, and actually at all for long time. >> In windows you have to install "guest additions" without this it is >> plain terrible. > > I haven't managed to get through an install on a 64-bit windows system Windows 7 64-bit installs fine. FreeBSD 8.3, vbox 4.0.12 >> sandy bridge? > > Yes, I'm sure that every guest OS I've tried on a 64 bit guest > sucks. I'm busy recreating 32-bit versions of the 64-bit guests where > I can. maybe. i didn't do very detailed tests. and don't use 64-bit guest in production. >> problems with latency you describe > > Could you send me the system settings (VT-X, PAE, etc.) you used for > this? Everything that is possible enable in BIOS, FreeBSD/amd64 8.3-stable (like month old or so), virtualbox 4.0.12 no fancy tricks, custom kernel but nothing special. If you need more ask on priv. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 22:23:43 2012 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 860151065672 for ; Sat, 14 Jul 2012 22:23:43 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 022238FC12 for ; Sat, 14 Jul 2012 22:23:42 +0000 (UTC) Received: by weyx56 with SMTP id x56so4358658wey.13 for ; Sat, 14 Jul 2012 15:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=from:reply-to:to:subject:x-mailer:references:in-reply-to :content-type:content-id:date:message-id:mime-version :content-transfer-encoding; bh=SqZPdQv1ZQODNQZewIgtDq5jylA+tJR8/B6iKgFQFvs=; b=ef4wDfGbeYDcLJ/js/lY5eGEyt4zFQ8osfzx76kWLj97zWVilI9p3Xsg39CNEoxrVG tMrIKlE7rtGs73Odqu8uG1+7Lm1IZZLOH7ezDuZ6y2w1tPQsZmgHdIxTnG+ZvV7XqCqf Zc9XjrHZBXDUzrn0dXqqdmeLO/VozaezPBnYk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:reply-to:to:subject:x-mailer:references:in-reply-to :content-type:content-id:date:message-id:mime-version :content-transfer-encoding:x-gm-message-state; bh=SqZPdQv1ZQODNQZewIgtDq5jylA+tJR8/B6iKgFQFvs=; b=V/GL3E4TJhgVR6sF5iJf0yAdDDhcPGbdvCz/axQmc7n0BSxytRXVUinxyhBslYtEGA KH6JkD0E3jn2SUlK6kO7w2McUVCbOuOWl1W8p+bqaGIAck2mztqvJAiA30FPcT/s0eql DE4yHMXGI1nGxLPmd+WuBLMKHIdBpN5CSZHnvxMuas1IuS/lwFLcY9vqpPFXqaZoVEGE YEAMFS9vwAwiqYVgER874HRBhHUM2iIXN5veC2jv/E1Wfp49bG6LOMC6xnWhEvwn/pli aG2H/ArWE/EGzN/ljv2fEayKpGkJ4DEuQecosWOSYMfqSaWYqrD2cwJx40Pd4d0EbeGK p29Q== Received: by 10.180.92.7 with SMTP id ci7mr9043053wib.1.1342304621781; Sat, 14 Jul 2012 15:23:41 -0700 (PDT) Received: from [10.37.82.177] (089144192238.atnat0001.highway.a1.net. [89.144.192.238]) by mx.google.com with ESMTPS id fr4sm17821231wib.8.2012.07.14.15.23.39 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 15:23:41 -0700 (PDT) From: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= To: Mike Meyer , freebsd-hackers@freebsd.org X-Mailer: Modest 3.90.7 References: <20120714061141.473cc8ee@bhuda.mired.org> In-Reply-To: <20120714061141.473cc8ee@bhuda.mired.org> Content-Type: text/plain; charset=utf-8 Content-ID: <1342304614.3162.1.camel@Nokia-N900-42-11> Date: Sun, 15 Jul 2012 00:23:35 +0200 Message-Id: <1342304615.3162.2.camel@Nokia-N900-42-11> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnFQLMIABt2SFhGaaU/QkL0zwmLqpYm8YSAqYNSZMl0oqCUqS4edZ+NzGdOVR7DFAop6UI0 X-Mailman-Approved-At: Sat, 14 Jul 2012 22:29:55 +0000 Cc: Subject: Re: FreeBSD 8.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 22:23:43 -0000 On Sa., 14. Jul. 2012 12:11:41 CEST, Mike Meyer wrote: > I just set up a system designed to handle lots of VBox VM's: a 6-core > SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. > > Unfortunately, once I got it set up, I found that VBox guest > performance simply sucks. The *mouse* isn't responsive. Linux guests > see lots of "CPU Locked" errors. Does the VM use multiple vCPUs? Does reducing to one vcpu help? I have seen a lot of instabilities and problems in the past when using more than one vcpu. Where is that cpu locked reported? You could also try to build the vbox port with debug option enabled and look at VBox.log which gives probably useful information in case there are soft errors that cause the slowdown or if some of the vt-x features were incorrectly detected and vbox had to fallback to the recompiler (=slow). > Googling turns up lots of problems with VBox on SandyBridge: Mac's > running on 64 bit kernels have this problem - running on 32 bit > kernels helps. Turning off Intel's SpeedStep has been reported to > help. Turning off VT-X in the guest - if it's a 32-bit guest - > helps. The last one is the only one that actually helped me. Just to be sure which vbox version are we talking about? You could try emulators/virtualbox-ose-legacy to verify if it is a regression of 4.1.x. > I was wondering if anyone here had run into and solved similar > problems? Or if they were running a similar system, and didn't run > into that problem? Especially anyone running 9.0 instead of 8.X I've not heard about that before so it wasn't reported at least. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 14 23:49:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 213DF106564A for ; Sat, 14 Jul 2012 23:49:52 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DEC528FC17 for ; Sat, 14 Jul 2012 23:49:51 +0000 (UTC) Received: by obbun3 with SMTP id un3so8822363obb.13 for ; Sat, 14 Jul 2012 16:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F134qe6cOu9CP+1Hmw9810ZCkC+aornvtDzoHnJJUZA=; b=QtmeghteLDfSmA457sHy+gwW6tf19Ar1QJYLE3vXz0Rqlv5tXAHj6bd8thFYRDklR0 Mm/n7dk9fq6m11uwIh0HQrq0691Ylu2wqaJ2s5UrfyvV3bQdyygoKUPb8+yOns7oCcPZ WL7sBG/EcyvnAmYDEt65Uam7GLxeRFunaBTDnedNJKYi0Se5vEdW+Vh6vipQLxihC4am I9V/Y8zjcW2iCKcUujfS3DNOqj3GlIAJ2Np1V3zybIgt7UtqoJgo2Q7iGsepzh2FL6kU rYknIfmPC7aCtkeyVG1PTe9FaMk/doX/LlTziS5R630yZuFtRcpnrKtC7/lIPGIW682e ZZpA== MIME-Version: 1.0 Received: by 10.50.213.1 with SMTP id no1mr2154933igc.71.1342309791167; Sat, 14 Jul 2012 16:49:51 -0700 (PDT) Received: by 10.231.72.133 with HTTP; Sat, 14 Jul 2012 16:49:51 -0700 (PDT) Date: Sat, 14 Jul 2012 18:49:51 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Interesting facts about AI_ADDRCONFIG X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Jul 2012 23:49:52 -0000 Hi, hackers: FreeBSD's AI_ADDRCONFIG flag used by getaddrinfo(3) is regarded as broken: https://wikispaces.psu.edu/display/ipv6/IPv6+programming#IPv6programming-AIADDRCONFIGflag The short reason is that it still queries for both A and AAAA even one of them is not configured. The details are interesting: In rfc2553, AI_ADDRCONFIG is described as: - The AI_ADDRCONFIG flag specifies that a query for AAAA records should occur only if the node has at least one IPv6 source address configured and a query for A records should occur only if the node has at least one IPv4 source address configured. Note that the description applies to getipnodebyname() actually, but we can expect that it also applies to getaddrinfo(). And compare the above with the description from POSIX.1-2008: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. See the difference? POSIX does not care whether the addresses are "queried"; it only says that it should be not returned. Hence, you can query them first and filter them latter... However, this is not the biggest problem. The main chaos is about whether a loopback IP address can be considered "configured": An embarrassing workaround by Mozilla: https://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#2013 In 2003, rfc3493 responded the problem as: - If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The loopback address is not considered for this case as valid as a configured address. For example, when using the DNS, a query for AAAA records should occur only if the node has at least one IPv6 address configured (other than IPv6 loopback) and a query for A records should occur only if the node has at least one IPv4 address configured (other than the IPv4 loopback). Now I think things becomes clear: To support AI_ADDRCONFIG in a POSIX+RFC way, getaddrinfo(3) should detect outbound address availability first, then query. Let's go back to the code in FreeBSD: In lib/libc/net/getaddrinfo.c and lib/libc/net/name6.c , AI_ADDRCONFIG is implemented as "filter out the unsupported AFs in kernel, then query". Obviously it's a misinterpretation of the word "configured", and the implementation does not confirm with any standards. A better impl may be bind9's lwres_getipnodebyname() (in contrib/bind9/lib/lwres/getipnode.c). It carefully uses ioctl(2) to obtain the addr info on interfaces, then do query. I'm not sure whether it handles the loopback problem, but it's much better then what we have in libc. So... What we going to do? -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/