From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 00:58:12 2010 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 4C503106566B for ; Sun, 2 May 2010 00:58:12 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7488FC18 for ; Sun, 2 May 2010 00:58:11 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o420wBfn049943 for ; Sat, 1 May 2010 17:58:11 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BDCCE48.4070900@feral.com> Date: Sat, 01 May 2010 17:58:48 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20100501223524.GU36233@elvis.mu.org> In-Reply-To: <20100501223524.GU36233@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Sat, 01 May 2010 17:58:11 -0700 (PDT) Subject: Re: Coverity warning: strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 00:58:12 -0000 On 5/1/2010 3:35 PM, Alfred Perlstein wrote: > I notice this code sprinkled through the sources: > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > > This trips up coverity because it does not know for sure > that the string returned by cam_sim_name() is going to > be DEV_IDLEN-1 characters long. > > Should we switch these calls to strlcpy? Is there a smarter > thing to do to code more defensively? > > strlcpy seems right. From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 07:25:23 2010 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 E470A106566B for ; Sun, 2 May 2010 07:25:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id D21998FC15 for ; Sun, 2 May 2010 07:25:23 +0000 (UTC) Received: from eagle.syrec.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id o427PN9V043039; Sun, 2 May 2010 00:25:23 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4BDD28E2.8010201@rawbw.com> Date: Sun, 02 May 2010 00:25:22 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.24 (X11/20100331) MIME-Version: 1.0 To: =?UTF-8?B?QW5kcml1cyBNb3JrxatuYXM=?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 07:25:24 -0000 Andrius MorkÅ«nas wrote: > Hi, > > I'm Andrius MorkÅ«nas from Lithuania. My Summer of Code proposal was > accepted > this year and be working on my project, which is to make clang and > ports to > be friendly with each other. > My main goals are: > * Create an easy way to set ports compiler to either clang or gcc (and > no, > CC=clang is not a good way to do that). > * Write a tool to detect common problems with individual ports not > respecting > environment variables like CC/CXX or doing other horrible things > that break > compilation with clang. > * Make Gnome, KDE, Xorg and other widely used things to work with clang. Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. It crashes a lot, fails on many quite simple c++ patterns. Very immature. Don't you feel it's too early to start project like you are going to given the state of clang with c++? You will just keep stumbling upon various problems with various ports and maybe will make 30% of c++ ports build with it at best. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 10:21:48 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03FFB106564A for ; Sun, 2 May 2010 10:21:48 +0000 (UTC) (envelope-from matthias.andree@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6EE8FC12 for ; Sun, 2 May 2010 10:21:47 +0000 (UTC) Received: from [192.168.0.3] (p4FE32DA6.dip.t-dialin.net [79.227.45.166]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id o42A6tXB023958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 May 2010 12:07:13 +0200 (CEST) Message-ID: <4BDD4EBF.5040807@tu-dortmund.de> Date: Sun, 02 May 2010 12:06:55 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Alfred Perlstein References: <20100501223524.GU36233@elvis.mu.org> In-Reply-To: <20100501223524.GU36233@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 02 May 2010 12:00:52 +0000 Cc: hackers@freebsd.org Subject: Re: Coverity warning: strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 10:21:48 -0000 Alfred Perlstein schrieb: > I notice this code sprinkled through the sources: > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > > This trips up coverity because it does not know for sure > that the string returned by cam_sim_name() is going to > be DEV_IDLEN-1 characters long. Right. strncpy/strncat are examples for features that the C standards libc had better not ever had, similar to [f]gets... > Should we switch these calls to strlcpy? Is there a smarter > thing to do to code more defensively? if dev_name is a vector of char or equally sized types: (cpi->dev_name)[DEV_IDLEN-1] = '\0'; However, rather than relying on implicit assumptions and inefficiencies, I'd still prefer memset + strlcpy. -- Matthias Andree From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 20:17:31 2010 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 096DE1065673; Sun, 2 May 2010 20:17:31 +0000 (UTC) (envelope-from eitanadlerlist@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5FEF58FC23; Sun, 2 May 2010 20:17:29 +0000 (UTC) Received: by fxm15 with SMTP id 15so1818471fxm.13 for ; Sun, 02 May 2010 13:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=oOV/NJbp4++nuKOi3WES+QfyYESwcTdaIKUGOj/QiP8=; b=EUqQCXOngOrazyL4b04xbSSsop0kS42q9TTbcbcfDN59NeqMVbuIkL1iSmcZ2ZRoq3 9rJvkYhQ7Gokaic6frU3A9hIHC5+nmiAF+viG5nBJjKZ4o7FXlMznqoxxGDFYOnl3ZHr CY3eqBtTyEtQhXjwxc9uJyGjvCYfQctASlmns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=LbnxzvRBLWE4cJi5FvPDQ/ly8DaMr7aM9ewHGSBGbcSJAp+8fudtVavmYwAlKQImNR Y1DUeiYdqGw/8sQ7UpCGgLVmqBKnw+tVPiiwxrfcvLcDqMLifdNbov+rvxDp9rNZwOi2 TYll2OEhFzSwbcXR7bLnc0TV/gSJEDwqlJV1c= Received: by 10.239.183.145 with SMTP id u17mr34259hbg.209.1272831440196; Sun, 02 May 2010 13:17:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.193.77 with HTTP; Sun, 2 May 2010 13:17:00 -0700 (PDT) In-Reply-To: <4BDD28E2.8010201@rawbw.com> References: <4BDD28E2.8010201@rawbw.com> From: Eitan Adler Date: Sun, 2 May 2010 23:17:00 +0300 Message-ID: To: yuri@rawbw.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org, =?UTF-8?Q?Andrius_Mork=C5=ABnas?= Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 20:17:31 -0000 > Having tried clang++ I have a feeling that it's not quite ready to be a > generic c++ compiler. > It crashes a lot, fails on many quite simple c++ patterns. Very immature. > Don't you feel it's too early to start project like you are going to given > the state of clang with c++? > You will just keep stumbling upon various problems with various ports and > maybe will make 30% of c++ ports build with it at best. Good - and those 30% of ports will help improve clang++ even more. Hopefully over time that number will increase to 100% and we will be able to say goodbye to gcc for good. From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 20:52:02 2010 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 AE3021065670; Sun, 2 May 2010 20:52:02 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 14C838FC08; Sun, 2 May 2010 20:52:01 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so594044fgb.13 for ; Sun, 02 May 2010 13:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=vkh3u8F204jJG7Eguejku322J5UpV73K2Bdsx6/2Q60=; b=UypLTZtwBwpG+3/cL/YBxrEgtrJ7IwD0OAGDjeApjdsce8zu6SUc7xHbGa3IRFtpUR IozTbBf6wfLePNHolBcqWNtQlUDj9PKne7CCHtOxLv975xmwIxwF+G5a4xzj0u4qC6Zm C84sxZeF21VdZSyyekT4TMdqs6MU1dE7mjyZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=vkAWQVIYgaAsbDYMgrudNcimwDhzQ1ZznEeBYa+2S2kmMkTU6oFK96M5AGhjkZuE24 POtWmGtJlegfjPLHqJD/DLJ3fMu48OfbxON7J2qGPkUP+ll/D4nQd2hsGkZ8vMfq/I6X BQu+cv52kEsg1C0gN+ycI/u0ADjG6JdoDE78s= Received: by 10.86.126.20 with SMTP id y20mr8893707fgc.10.1272833515744; Sun, 02 May 2010 13:51:55 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id d4sm8599273fga.5.2010.05.02.13.51.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 May 2010 13:51:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: yuri@rawbw.com References: <4BDD28E2.8010201@rawbw.com> Date: Sun, 02 May 2010 23:51:52 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <4BDD28E2.8010201@rawbw.com> User-Agent: Opera Mail/10.10 (FreeBSD) Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 20:52:02 -0000 On Sun, 02 May 2010 10:25:22 +0300, Yuri wrote: > Having tried clang++ I have a feeling that it's not quite ready to be a > generic c++ compiler. > It crashes a lot, fails on many quite simple c++ patterns. The current state of clang doesn't bother me too much. I'm aware of its limitations, but I'm also aware of the pace of clang/llvm development. Trying clang at any given time is quite different than actually seeing it get better and better every week, for months. When llvm 2.6 was released, clang didn't compile C++ at all, and compared to that, what we have now is definitely better. I'm sure that by the end of the summer I'm going to call current version of clang/llvm "horribly outdated", just like I've been calling any clang version which is over a month old. It will get better. > Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. > Don't you feel it's too early to start project like you are going to > given the state of clang with c++? No I don't. My project doesn't rely on clang supporting all of C++. I just want to prepare ports tree for clang. I don't intend to make 21645+ ports work with clang over the summer, that may be slightly too much work even for me. So if I can't get KDE working, too bad, but let's wait until clang supports all the fancy C++ KDE needs and I'll just get it working then, even if that's after the summer is long over. You could say that the goal of this project is to make fixing ports+clang easier in the future. > You will just keep stumbling upon various problems with various ports I've mentioned that I've been involved with ports+clang since last October. "Stumbling upon various problems" is what I do. I'm still here, even doing a GSoC project, so it doesn't look like "various problems" will scare me off. And as I've mentioned above, just because some ports don't compile, it doesn't affect this project too much. > and maybe will make 30% of c++ ports build with it at best. [citation needed] -- Andrius From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 21:03:16 2010 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 2BFE7106566C; Sun, 2 May 2010 21:03:16 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 85D1F8FC12; Sun, 2 May 2010 21:03:15 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so437193fge.13 for ; Sun, 02 May 2010 14:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=JrnGgljk58IaeREk0YMT6kavSmQdalrRlDFzAp1FBkE=; b=ELEPuWNQxDQLjK2JZMbgH8c9Vv+x7gzl4UFe/VYennJf9R8ZZXAoeMvbHRppYNtioO PuNxiUYmB07brzIDT+EV4KrsBX8yBy6vWX3cOsrYR4RO5v1oyfcLmi9eEzlTfEXNKplE jLsSANWPxNhN2DFLe1WZe38hrwhthioLIoYdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=mfw9XOH0WN0zFeW/A0uv0RX6D5cVe7Pyn2zNJZcBeHLVr/XlNH1njnIhzeA0vx0ZoE J9QyDJtQ9n9azkb2qtIRrll+5qG3yRQ97UNOv7UhiWU/e0h9b8cbD+D9z45C9D7VDH7r bmS1yrZvyUaNcW7/mYVd/zWjvo5d/6DuzY5eE= Received: by 10.87.62.28 with SMTP id p28mr8717803fgk.16.1272834189090; Sun, 02 May 2010 14:03:09 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id 4sm8986793fgg.17.2010.05.02.14.03.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 May 2010 14:03:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Eitan Adler" , yuri@rawbw.com References: <4BDD28E2.8010201@rawbw.com> Date: Mon, 03 May 2010 00:03:06 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (FreeBSD) Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 21:03:16 -0000 On Sun, 02 May 2010 23:17:00 +0300, Eitan Adler wrote: > Good - and those 30% of ports will help improve clang++ even more. Some probably will, we submit a lot of bug reports for clang/llvm. > Hopefully over time that number will increase to 100% and we will be > able to say goodbye to gcc for good. That won't happen, at least not anytime soon and not until we get rid of [old] poorly written ports from the ports tree. Another problem is ports using horrible or less horrible GNU extensions for C or C++, clang will not support all of them. So we will still need gcc for some things, just like we need USE_GCC=whatever now, because some ports don't compile with gcc42 from base. I just hope we can get the majority of ports working with clang and keep the number of ports that need gcc as low as possible. -- Andrius From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 22:29:54 2010 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 D2DC6106564A for ; Sun, 2 May 2010 22:29:54 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 93EFB8FC1A for ; Sun, 2 May 2010 22:29:54 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id ClQM1e0041ZXKqc58mGfUY; Sun, 02 May 2010 22:16:39 +0000 Received: from comcast.net ([98.203.142.76]) by omta21.westchester.pa.mail.comcast.net with comcast id CmGd1e0091f6R9u3hmGd71; Sun, 02 May 2010 22:16:39 +0000 Received: by comcast.net (sSMTP sendmail emulation); Sun, 02 May 2010 15:16:35 -0700 Date: Sun, 2 May 2010 15:16:35 -0700 From: Charlie Kester To: freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20100502221635.GB326@comcast.net> Mail-Followup-To: freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org References: <4BDD28E2.8010201@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 22:29:54 -0000 On Sun 02 May 2010 at 14:03:06 PDT Andrius Mork??nas wrote: >On Sun, 02 May 2010 23:17:00 +0300, Eitan Adler wrote: >>Good - and those 30% of ports will help improve clang++ even more. >Some probably will, we submit a lot of bug reports for clang/llvm. > >>Hopefully over time that number will increase to 100% and we will be >>able to say goodbye to gcc for good. >That won't happen, at least not anytime soon and not until we get rid of >[old] poorly written ports from the ports tree. Another problem is ports >using horrible or less horrible GNU extensions for C or C++, clang will >not support all of them. So we will still need gcc for some things, just >like we need USE_GCC=whatever now, because some ports don't compile with >gcc42 from base. I just hope we can get the majority of ports working >with clang and keep the number of ports that need gcc as low as possible. > As things stand today, we don't know exactly which ports have the kind of dependency on gcc that you describe. If this project gets us closer to that list, it will have been worthwhile. Once we know which ports are unavoidably dependent on gcc, we can start exploring alternatives to them. More projects for GSOC and others looking for ways to contribute! Sounds like fun! From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 22:44:37 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3F6E1065670; Sun, 2 May 2010 22:44:37 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9758FC1E; Sun, 2 May 2010 22:44:37 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o42MXRUY047015; Sun, 2 May 2010 15:33:28 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BDDFDDD.6060208@feral.com> Date: Sun, 02 May 2010 15:34:05 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Sun, 02 May 2010 15:33:28 -0700 (PDT) Cc: ed@freebsd.org Subject: making consmsgbuf_size a tunable? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 02 May 2010 22:44:37 -0000 Any thoughts about this? diff -r 5308a7cebc7d sys/kern/kern_cons.c --- a/sys/kern/kern_cons.c Thu Apr 29 19:55:46 2010 -0700 +++ b/sys/kern/kern_cons.c Sun May 02 15:32:24 2010 -0700 @@ -428,6 +428,7 @@ } static int consmsgbuf_size = 8192; +TUNABLE_INT("kern.consmsgbuf_size", &consmsgbuf_size); SYSCTL_INT(_kern, OID_AUTO, consmsgbuf_size, CTLFLAG_RW, &consmsgbuf_size, 0, ""); From owner-freebsd-hackers@FreeBSD.ORG Sun May 2 23:33:27 2010 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 DA5421065670 for ; Sun, 2 May 2010 23:33:27 +0000 (UTC) (envelope-from pebu3op@googlemail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 640B48FC14 for ; Sun, 2 May 2010 23:33:27 +0000 (UTC) Received: by bwz8 with SMTP id 8so1132272bwz.3 for ; Sun, 02 May 2010 16:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:reply-to:mail-followup-to:mime-version:content-type :content-disposition:user-agent; bh=hYk218Edt+oqRcG7ySa9K4zincDXczeFc6fI+dCmX4Y=; b=KRB0iPPvvxyra/O1ZeZclGwe4xTJTabu+Wq7osaIGHn7s0txDIGSSwSSOajRha2KLi PNrMd3Q03I7WtdicNFUxVla0NPwWphswLfW7Qb2juWU7HtReBfD9p4PxKxXjhVZwHyUO BzWlEuAS3oSBPUgmLAz7iqviwRjUB+hH69FZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent; b=HvdIEmKviRpT0SybIw4diYi8bdhiLJu7oVHmr4RYgWHL64vKbjcNup62I5qcub8IIm AqyfjGzs42jDF87dQZRENNWZIYTwxeWPeHXkPs1fAfzUsqFKsN4YbWfss7SH1miM4Gmn TTeHOkdlz9GJMQMTl0q/Xh/q5ZjgVOVhbvN08= Received: by 10.204.10.16 with SMTP id n16mr2811024bkn.173.1272841383849; Sun, 02 May 2010 16:03:03 -0700 (PDT) Received: from localhost ([178.0.47.46]) by mx.google.com with ESMTPS id 16sm1431783bwz.9.2010.05.02.16.03.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 May 2010 16:03:03 -0700 (PDT) Date: Mon, 3 May 2010 01:02:59 +0200 From: Alexandre Fiveg To: freebsd-hackers@freebsd.org Message-ID: <20100502230259.GA6653@debian.samsung.router> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: GSoC: High performance packet capturing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexandre Fiveg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 23:33:27 -0000 Hello hackers, I am working on the project "Ringmap capturing stack for high performance packet capturing in FreeBSD". I will continue my work on this project within the context of GSoC2010. The goal of my work is implementing the new software components for efficient packet capturing at 1Gb and 10Gb in FreeBSD. The new software should make it possible to minimize packet loss and CPU load during packet capture. The project comprises an adapted version of the libpcap for transparency towards typical user-space programs. So, any applications that use libpcap for packet capturing shouldn't require modification in order to run with the new ringmap network driver (and new modified libpcap). The project details 1. Ringmap Presentation: http://ringmap.googlecode.com/files/ringmap_slides.pdf 2. Wiki Pages with project schedule for GSoC2010: http://wiki.freebsd.org/AlexandreFiveg/SOC2010AlexandreFiveg I will be happy to get your feedback, suggestions and questions... and of course your help :) Best regards, Alexandre -- Alexandre Fiveg From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 07:40:52 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E9A2106566B for ; Mon, 3 May 2010 07:40:52 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id D76C68FC1B for ; Mon, 3 May 2010 07:40:51 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id E9C312A28CFB; Mon, 3 May 2010 09:21:32 +0200 (CEST) Date: Mon, 3 May 2010 09:21:32 +0200 From: Ed Schouten To: Matthew Jacob Message-ID: <20100503072132.GW56080@hoeg.nl> References: <4BDDFDDD.6060208@feral.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x9/jIR7Zx/0waMhV" Content-Disposition: inline In-Reply-To: <4BDDFDDD.6060208@feral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: making consmsgbuf_size a tunable? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 07:40:52 -0000 --x9/jIR7Zx/0waMhV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Matthew, * Matthew Jacob wrote: > Any thoughts about this? Looks good. Maybe we should make it a tunable only? Looking at the code, once the consbuf has been allocated, there is no way you can ever resize it. --=20 Ed Schouten WWW: http://80386.nl/ --x9/jIR7Zx/0waMhV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkveeXwACgkQ52SDGA2eCwUf1ACfXC+AKWhTdqFeU4QexQa4hFMu BNsAnRMkGg8kBgq0vZPEAX8U9znSvrTg =b5bJ -----END PGP SIGNATURE----- --x9/jIR7Zx/0waMhV-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 09:22:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from office.hoster.bg (freefall.freebsd.org [69.147.83.40]) by hub.freebsd.org (Postfix) with SMTP id 1FC791065670 for ; Mon, 3 May 2010 09:22:37 +0000 (UTC) (envelope-from roam@ringlet.net) Received: (qmail 16991 invoked by uid 1000); 3 May 2010 09:22:13 -0000 Date: Mon, 3 May 2010 12:22:13 +0300 From: Peter Pentchev To: Andrius Mork??nas Message-ID: <20100503092213.GA1294@straylight.m.ringlet.net> References: <4BDD28E2.8010201@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: yuri@rawbw.com, freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 09:22:39 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: > On Sun, 02 May 2010 10:25:22 +0300, Yuri wrote: > > Having tried clang++ I have a feeling that it's not quite ready to be a > > generic c++ compiler. [snip] > > Very immature. >=20 > Many problems that C++ ports have with clang is not related to it being > immature, they're related to the fact that clang isn't gcc and that > those ports aren't written in standard C++. Too true. [snip] > > You will just keep stumbling upon various problems with various ports >=20 > I've mentioned that I've been involved with ports+clang since last > October. "Stumbling upon various problems" is what I do. I'm still here, > even doing a GSoC project, so it doesn't look like "various problems" > will scare me off. And as I've mentioned above, just because some ports > don't compile, it doesn't affect this project too much. Well said, well meant. Kudos. Thanks for your work so far, and thanks for taking up that GSoC project. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence. --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQIcBAEBCgAGBQJL3pXFAAoJEGUe77AlJ98TJIgQAIfCk7JL/drgddZ/AqIstcNs fgRBuu/Xa1i6FwVAiv924ugwyFo0vXclbHuvp6G6xRmghhWWoozs8rd4HyqCr+5X CgLL26a1BTU/fs5dvzd8oAtD+BoIY1NGctiyeJ2vVSTSYNzYeS29fQpJON0eKd++ 4yVguIKkceIT+8F5VstsAQ6SWVg7irN8YvHJSSwUg2UZgOAG80LRdsZ4x5xWby2W +uzIWmbAuUYTvQXdKyKoGvlSoHgIK7/1yJTgknu/y2g87aNpX5kKjqc9KyfgojeI EPW0adz7ykpxTcomWBvLft2tpliMVplG1WSapMqr4kiaaG7Kklntyejx0toqo9el zSXwaXVED97m495SQ04fhdWE8hoNf8cjV+2I46UyoIhKsRm6/T2B1/c7POoFWQzQ NuA+apL9+qiBw5Huw+3/Bm7Y6rLXegaFWL5+vOIiHQQHJPAKNrfPbDKOfOeO5Fd5 cxQThUClCEQsyQcQm7c9lr5DRdAnvEpSooOmzcaahFaCiyW/wZDEunlzHEb2qtGz mcsYn4P39LevHIHla3bD8OlRJWUQitbGQpxMm/grHpFxp27oTcVQGYS02TmM70xy HY/2NFoPI770oMvN6IjmAxlxCBZoEq2cdguxvdQir0XegFoxJlXW5nRTs8bzXBYl dajJG8PP/+lTppAzNTOp =cj+Z -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 10:33:54 2010 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 5BB041065670 for ; Mon, 3 May 2010 10:33:54 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 374308FC24 for ; Mon, 3 May 2010 10:33:53 +0000 (UTC) Received: by pxi11 with SMTP id 11so166582pxi.13 for ; Mon, 03 May 2010 03:33:44 -0700 (PDT) Received: by 10.142.119.22 with SMTP id r22mr2986503wfc.191.1272882824759; Mon, 03 May 2010 03:33:44 -0700 (PDT) Received: from [192.168.1.33] (ppp-58-8-182-179.revip2.asianet.co.th [58.8.182.179]) by mx.google.com with ESMTPS id 22sm4552545pzk.9.2010.05.03.03.33.42 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 03:33:44 -0700 (PDT) Message-ID: <4BDEA78F.90303@pathscale.com> Date: Mon, 03 May 2010 17:38:07 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: Peter Pentchev References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> In-Reply-To: <20100503092213.GA1294@straylight.m.ringlet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yuri@rawbw.com, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org, Andrius Mork??nas Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 10:33:54 -0000 Peter Pentchev wrote: > On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: > >> On Sun, 02 May 2010 10:25:22 +0300, Yuri wrote: >> >>> Having tried clang++ I have a feeling that it's not quite ready to be a >>> generic c++ compiler. >>> > [snip] > >>> Very immature. >>> >> Many problems that C++ ports have with clang is not related to it being >> immature, they're related to the fact that clang isn't gcc and that >> those ports aren't written in standard C++. >> > > Too true. > I can understand from a commercial perspective why having a permissive licensed production compiler could be good.. I can understand why many people don't like gcc or fsf, but what does the BSD community get? 1) Performance? 2) Robustness? 3) ... ? What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Starting early can give valuable feedback , but without actually having the resources to follow-up it's wasted effort. Is llvm at the point where it can self host BSD? If not why not start there? Maybe identify the most used applications.. I don't waste time on front-end work though so this is of course my humble opinion.. ./C From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 11:03:41 2010 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 8A1F4106566C; Mon, 3 May 2010 11:03:41 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCB98FC1E; Mon, 3 May 2010 11:03:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c169:4f32:a5e4:69a5] (unknown [IPv6:2001:7b8:3a7:0:c169:4f32:a5e4:69a5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 618685C59; Mon, 3 May 2010 12:44:49 +0200 (CEST) Message-ID: <4BDEA926.4030900@andric.com> Date: Mon, 03 May 2010 12:44:54 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.5pre) Gecko/20100430 Lanikai/3.1pre MIME-Version: 1.0 To: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> In-Reply-To: <4BDEA78F.90303@pathscale.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?dXMgTW9ya8WrbmFz?= , freebsd-hackers@freebsd.org, =?UTF-8?B?QW5kcmk=?=, freebsd-ports@freebsd.org, yuri@rawbw.com Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 11:03:41 -0000 On 2010-05-03 12:38, "C. Bergstr=C3=B6m" wrote: > What's really the goal here? What problem are you working to solve? =20 > May I humbly say that building software with a different compiler in=20 > itself doesn't really accomplish anything. Of course it does. It forces you to make your software portable. From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 11:08:25 2010 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 0D5181065670 for ; Mon, 3 May 2010 11:08:25 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id B5E888FC22 for ; Mon, 3 May 2010 11:08:24 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id A477717FBE for ; Mon, 3 May 2010 12:49:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id oGhp32kJlg1R for ; Mon, 3 May 2010 12:49:05 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn-151.95-102-172.t-com.sk [95.102.172.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 786DC17FB5 for ; Mon, 3 May 2010 12:49:05 +0200 (CEST) Message-ID: <4BDEAA20.3010108@FreeBSD.org> Date: Mon, 03 May 2010 12:49:04 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100502 Lanikai/3.1pre MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> In-Reply-To: <4BDEA78F.90303@pathscale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 11:08:25 -0000 On 3.5.2010 12:38, "C. Bergström" wrote: > the resources to follow-up it's wasted effort. Is llvm at the point > where it can self host BSD? If not why not start there? Maybe identify > the most used applications.. http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016648.html -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 11:15:38 2010 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 C96661065673; Mon, 3 May 2010 11:15:38 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3468FC12; Mon, 3 May 2010 11:15:38 +0000 (UTC) Received: by pzk39 with SMTP id 39so1213214pzk.7 for ; Mon, 03 May 2010 04:15:32 -0700 (PDT) Received: by 10.143.177.5 with SMTP id e5mr94827wfp.304.1272885331907; Mon, 03 May 2010 04:15:31 -0700 (PDT) Received: from [192.168.1.33] (ppp-58-8-182-179.revip2.asianet.co.th [58.8.182.179]) by mx.google.com with ESMTPS id 21sm4582771pzk.0.2010.05.03.04.15.26 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 04:15:31 -0700 (PDT) Message-ID: <4BDEB154.8060104@pathscale.com> Date: Mon, 03 May 2010 18:19:48 +0700 From: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: Dimitry Andric References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEA926.4030900@andric.com> In-Reply-To: <4BDEA926.4030900@andric.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?dXMgTW9ya8WrbmFz?= , freebsd-hackers@freebsd.org, =?UTF-8?B?QW5kcmk=?=, freebsd-ports@freebsd.org, yuri@rawbw.com Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 11:15:38 -0000 Dimitry Andric wrote: > On 2010-05-03 12:38, "C. Bergström" wrote: > >> What's really the goal here? What problem are you working to solve? >> May I humbly say that building software with a different compiler in >> itself doesn't really accomplish anything. >> > > Of course it does. It forces you to make your software portable. > and your point is? Are you trying to say that s/building/porting/ between compilers is going to magically make the software (have less bugs, more performance or better robustness) Porting could be a means-to-an-end, but still it's not an end goal.. I'm digging at what's the end goal.. After it's all ported what magically happens? From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 11:28:00 2010 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 BE877106566C; Mon, 3 May 2010 11:28:00 +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 400338FC08; Mon, 3 May 2010 11:27:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o43BRucv094877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 14:27:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o43BRu3H085652; Mon, 3 May 2010 14:27:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o43BRq2J085651; Mon, 3 May 2010 14:27:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 May 2010 14:27:52 +0300 From: Kostik Belousov To: "C. Bergstr??m" Message-ID: <20100503112752.GH50864@deviant.kiev.zoral.com.ua> References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEA926.4030900@andric.com> <4BDEB154.8060104@pathscale.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9sSKoi6Rw660DLir" Content-Disposition: inline In-Reply-To: <4BDEB154.8060104@pathscale.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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: us Mork??nas , freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org, yuri@rawbw.com, Dimitry Andric , =?UTF-8?B?QW5kcmk=?=@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 11:28:00 -0000 --9sSKoi6Rw660DLir Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2010 at 06:19:48PM +0700, "C. Bergstr??m" wrote: > Dimitry Andric wrote: > >On 2010-05-03 12:38, "C. Bergstr??m" wrote: > > =20 > >>What's really the goal here? What problem are you working to solve? = =20 > >>May I humbly say that building software with a different compiler in=20 > >>itself doesn't really accomplish anything. > >> =20 > > > >Of course it does. It forces you to make your software portable. > > =20 > and your point is? >=20 > Are you trying to say that s/building/porting/ between compilers is=20 > going to magically make the software (have less bugs, more performance=20 > or better robustness) Porting could be a means-to-an-end, but still=20 > it's not an end goal.. I'm digging at what's the end goal.. After it's=20 > all ported what magically happens? For me, the project that makes sense is exactly "making freebsd ports work with clang", instead of what many have read "making applications ported to freebsd and compiled with clang work". Please note the subtle but very important difference. Even more, I do think that making our ports work with exactly clang does not give us any useful bits, except putting the port _infrastructure_ into shape where it can use non-base compilers, as easy as changing two or three variables. Being able to decouple base and port compilers, and give the port system the freedom to use whatever compiler the port masters find suitable is very important. It is important both for ports, to not need to make a rush run to fix after base changes, and it is important for base to not hold on ports much to make a change. Other then that, I mostly share your refusal to drink the Kool-Aid. --9sSKoi6Rw660DLir Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkveszgACgkQC3+MBN1Mb4jnsgCglqxyOE0vw3RtKwhhLktQGITQ guwAnioVyA6/hPiCnUWV9b3yrqjSPJUt =eEXW -----END PGP SIGNATURE----- --9sSKoi6Rw660DLir-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 12:12:53 2010 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 ABD5810657FA; Mon, 3 May 2010 12:12:53 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0811A8FC17; Mon, 3 May 2010 12:12:52 +0000 (UTC) Received: by fxm15 with SMTP id 15so2323641fxm.13 for ; Mon, 03 May 2010 05:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=lzkAqEzwGUeqNtmOpOkDT4sFUEIcQyTli1lWJcPq4X0=; b=l7CGIZ3M9er3Bt1LCvwLupZF/A2ukqrBwFdaYTNoToeRBPghJJZShudIFTMNtvlAsB 4S30GWPGuiXl+2xZLP1K3Tt3+l/kTPomLMuJpX9N2JwY7uzdaCAqb7H7v7pkJiqZ7Pew z1haxyHy2UC59j2lwwX3pdaWNOqLdKvuwaqW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=KXCl2oFwmdMHmheYlYgDKS2A3cdKxbIg5nWq+RnILgFRodx3iiBScSwH/jis3KjhdJ mGJfnQLWc1QzG1IgrfJh3nvFC2+DQnoYok85NTAjt2RbC6vhfhkPfGt+ecEIhdRqMh+j m2w2xLJXGwilk8+4lQiTlK/pj9I4wQ1YnfbTQ= Received: by 10.87.20.36 with SMTP id x36mr10118729fgi.14.1272888768002; Mon, 03 May 2010 05:12:48 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id d8sm14511195fga.26.2010.05.03.05.12.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 05:12:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?C=2E_Bergstr=C3=B6m?= , "Peter Pentchev" References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> Date: Mon, 03 May 2010 15:12:44 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <4BDEA78F.90303@pathscale.com> User-Agent: Opera Mail/10.10 (FreeBSD) Cc: yuri@rawbw.com, freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 12:12:53 -0000 On Mon, 03 May 2010 13:38:07 +0300, C. Bergstr=C3=B6m wrote: > I can understand from a commercial perspective why having a permissive= > licensed production compiler could be good.. I can understand why many= > people don't like gcc or fsf, but what does the BSD community get? > > 1) Performance? > 2) Robustness? > 3) ... ? Seeing how often I see this question, maybe I'll write (or force rdivacky@ to do it) an explanation why clang/llvm is good for FreeBSD. Anyway, for now, very short version: 1) Performance - in the long run, yes. gcc 4.2 in base will not be updated anymore. llvm on the other hand is actively developed and includes fancy stuff that new CPUs have. Clang also compiles stuff faster than gcc. 2) Robustness - not yet. It's still too early to rely on stability of clang/llvm, but eventually it will get better. 3) BSD-like license, C99 and eventually C++0x support. I'm too lazy to think about this right now. > What's really the goal here? To quote myself: "make clang and ports to be friendly with each other". My goals are stated in the initial email and the wiki. I'll update the wiki with some clarification on what are and what are not my goals when I have more time. > What problem are you working to solve? The problem is that ports tree is full of assumptions that compiler is gcc. At the moment, there is no way to use alternative compiler without breaking too many things. > May I humbly say that building software with a different compiler in > itself doesn't really accomplish anything. I prefer to think that compiling software with clang is making world a better place. More seriously - clang is much more strict than gcc. It forces people to write better, standard C/C++ code and not some random walls of incomprehensible text that remotely resemble C or C++, but can't even be compiled by later versions of gcc itself. I've already seen a lot of things being fixed because clang found a bug that gcc missed, or application relied on some weird gcc-specific behaviour and clang refused to compile it. > Starting early can give valuable feedback , but without actually havin= g > the resources to follow-up it's wasted effort. Well it's my effort that's wasted, I don't see how that's bad for anyone else. And I don't plan to waste anything, I've mentioned that some of the things I'm going to do over summer (and have been doing till now) aren't clang-specific. It will also help compile ports with new versions of gcc (or any other standard C/C++ compiler), and I don't think I need to explain why newer versions of software are usually better. > Is llvm at the point where it can self host BSD? You obviously aren't subscribed to freebsd-current@, are you? http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016648.htm= l > If not why not start there? It's been started some time ago, by other people. The reason I'm doing this as a GSoC project is because the person currently working on ClangBSD suggested me to do it. > Maybe identify the most used applications.. Not sure if you're talking about base system or ports here. I've mentioned that I want to get commonly used ports to work, and I've been doing something like that for some time now. If you're talking about base system, the problem isn't identifying most used applications, it's to fix whatever is still broken. Most of FreeBSD base system works with clang without problems. -- = Andrius From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 12:26:55 2010 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 72F6B1065670; Mon, 3 May 2010 12:26:55 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB9E8FC1D; Mon, 3 May 2010 12:26:55 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [92.116.41.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id D58F08A1C42; Mon, 3 May 2010 14:26:51 +0200 (CEST) Message-ID: <4BDEC107.6060204@bsdforen.de> Date: Mon, 03 May 2010 14:26:47 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> In-Reply-To: <4BDEA78F.90303@pathscale.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: yuri@rawbw.com, Andrius Mork??nas , freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 12:26:55 -0000 On 03/05/2010 12:38, "C. Bergström" wrote: > What's really the goal here? In my opinion it's about staying away from the GPLv3. According to my understanding of the situation, GPLv3 code is not accepted into the project and that means we're stuck with gcc 4.2, which has already reached its EOL. The way I see it we /desperately/ need a new compiler for the base system. Having GPLv3 stuff in Ports is all right, so getting the base system to compile was the most important step. Now that it does I think the change should be made as soon as all the supported architectures work with clang. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 12:28:45 2010 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 678A1106566B; Mon, 3 May 2010 12:28:45 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id BCF5A8FC0A; Mon, 3 May 2010 12:28:44 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so765219fgb.13 for ; Mon, 03 May 2010 05:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=KVcie7dWryiPqVcNcmFXqO2r6r5cp1E6yA0m4Hrt9uY=; b=HpBDwduKXbenMbVWeTSHuQvX/s/Kl+xrT6ZflzWgYxqpe3ATq2QkysO9PxmZG85e7w Ct6fMXkixjGBGFPwwD3P3WuCNgiO3PNXeIJw4D1ksFIXDnSSfZlj9dHn90f5cclIp3/D qQKv6D6cy4kmcG8nOASpvvWbcYlqN8exaLdjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=gj53ITA09NFks41cpzb1QwtjYUH/jrtMSwaaj3eiMQXLK3WfLiRULUuo7nhSClUs9V lKHA4dRYnlzqzL2sBxRIVwB8O+0H58qbmk+zoJ8zsBb5LnOSeAKtHbOSeeRXW//AsTTF uS0vC1smmRJ3tB+9Z/jXecqu8+ekTN/XPn4HE= Received: by 10.87.15.35 with SMTP id s35mr10135953fgi.12.1272889718375; Mon, 03 May 2010 05:28:38 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id 4sm14478933fge.8.2010.05.03.05.28.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 05:28:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Kostik Belousov" , "C. Bergstr??m" References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEA926.4030900@andric.com> <4BDEB154.8060104@pathscale.com> <20100503112752.GH50864@deviant.kiev.zoral.com.ua> Date: Mon, 03 May 2010 15:28:23 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <20100503112752.GH50864@deviant.kiev.zoral.com.ua> User-Agent: Opera Mail/10.10 (FreeBSD) Cc: freebsd-hackers@freebsd.org, Dimitry Andric , freebsd-ports@freebsd.org, yuri@rawbw.com Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 12:28:45 -0000 On Mon, 03 May 2010 14:27:52 +0300, Kostik Belousov wrote: > For me, the project that makes sense is exactly "making freebsd ports > work with clang", instead of what many have read "making applications > ported to freebsd and compiled with clang work". Please note the subtle > but very important difference. > > Even more, I do think that making our ports work with exactly clang does > not give us any useful bits, except putting the port _infrastructure_ > into shape where it can use non-base compilers, as easy as changing > two or three variables. Being able to decouple base and port compilers, > and give the port system the freedom to use whatever compiler the port > masters find suitable is very important. It is important both for ports, > to not need to make a rush run to fix after base changes, and it is > important for base to not hold on ports much to make a change. > > Other then that, I mostly share your refusal to drink the Kool-Aid. Finally, someone who understands the benefits of my project and what I'm trying to do! Of course it's my own fault for not explaining my goals clearly enough, but now I know where to point when I try to explain what I'm doing or why it's good for FreeBSD. -- Andrius From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 12:30:31 2010 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 4FF17106564A; Mon, 3 May 2010 12:30:31 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24A288FC0A; Mon, 3 May 2010 12:30:30 +0000 (UTC) Received: by pxi11 with SMTP id 11so205173pxi.13 for ; Mon, 03 May 2010 05:30:21 -0700 (PDT) Received: by 10.140.247.17 with SMTP id u17mr3548969rvh.151.1272889821381; Mon, 03 May 2010 05:30:21 -0700 (PDT) Received: from [192.168.1.33] (ppp-58-8-182-179.revip2.asianet.co.th [58.8.182.179]) by mx.google.com with ESMTPS id q10sm1476399rvp.8.2010.05.03.05.30.18 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 05:30:20 -0700 (PDT) Message-ID: <4BDEC2E3.2030305@pathscale.com> Date: Mon, 03 May 2010 19:34:43 +0700 From: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: =?UTF-8?B?QW5kcml1cyBNb3JrxatuYXM=?= References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: yuri@rawbw.com, freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 12:30:31 -0000 Andrius MorkÅ«nas wrote: > On Mon, 03 May 2010 13:38:07 +0300, C. Bergström > wrote: >> I can understand from a commercial perspective why having a permissive >> licensed production compiler could be good.. I can understand why many >> people don't like gcc or fsf, but what does the BSD community get? >> >> 1) Performance? >> 2) Robustness? >> 3) ... ? > Seeing how often I see this question, maybe I'll write (or force > rdivacky@ to do it) an explanation why clang/llvm is good for FreeBSD. > Anyway, for now, very short version: > 1) Performance - in the long run, yes. gcc 4.2 in base will not be > updated anymore. llvm on the other hand is actively developed > and includes fancy stuff that new CPUs have. Clang also compiles > stuff faster than gcc. What fancy stuff is in the ports tree which clang will take advantage of? > 2) Robustness - not yet. It's still too early to rely on stability of > clang/llvm, but eventually it will get better. I wish someone would just buy and open source EDG.. It would be a lot faster and less expensive > 3) BSD-like license, C99 and eventually C++0x support. > I'm too lazy to think about this right now. > >> What's really the goal here? > To quote myself: "make clang and ports to be friendly with each other". > My goals are stated in the initial email and the wiki. I'll update the > wiki with some clarification on what are and what are not my goals when > I have more time. > >> What problem are you working to solve? > The problem is that ports tree is full of assumptions that compiler is > gcc. At the moment, there is no way to use alternative compiler without > breaking too many things. This is something I can clearly relate to and would see as beneficial. I can't say the gentoo/arch approach is correct, but it may not be a bad idea to steal whatever they have have done correctly. I'd be more than happy to help or work with you if it's feasible to add another compiler to this project. From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 12:38:32 2010 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 11B5B1065674; Mon, 3 May 2010 12:38:32 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 85AD18FC18; Mon, 3 May 2010 12:38:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c169:4f32:a5e4:69a5] (unknown [IPv6:2001:7b8:3a7:0:c169:4f32:a5e4:69a5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3C3685C59; Mon, 3 May 2010 14:38:30 +0200 (CEST) Message-ID: <4BDEC3CB.4@andric.com> Date: Mon, 03 May 2010 14:38:35 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.5pre) Gecko/20100430 Lanikai/3.1pre MIME-Version: 1.0 To: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEA926.4030900@andric.com> <4BDEB154.8060104@pathscale.com> In-Reply-To: <4BDEB154.8060104@pathscale.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, yuri@rawbw.com, freebsd-ports@freebsd.org, =?UTF-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 12:38:32 -0000 On 2010-05-03 13:19, "C. Bergstr=C3=B6m" wrote: >> Of course it does. It forces you to make your software portable. >> =20 > and your point is? >=20 > Are you trying to say that s/building/porting/ between compilers is=20 > going to magically make the software (have less bugs, more performance = > or better robustness) No, it gives you the choice of which compiler to use. > Porting could be a means-to-an-end, but still=20 > it's not an end goal.. I'm digging at what's the end goal.. After it's = > all ported what magically happens? You can then switch compilers freely, or at least, without too much effort. From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 13:33:29 2010 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 17E7C106566C; Mon, 3 May 2010 13:33:29 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 6D97E8FC15; Mon, 3 May 2010 13:33:28 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so629758fge.13 for ; Mon, 03 May 2010 06:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=xc/7lYFc6KsKpYWOZsYB13Cr/1bt6enNwQawKmPXUBQ=; b=r8dHZz8cctr2RuTYeBkecItAhzsEITGfyH/Rn2o1xsDQ4AVsxsIwKyOLt/P5lOcX+M CUxmq+VeIz00AFgT32olQW+SJOulv6GFzvcPIbS3459oAYfBuV3/92envlnw+59jBYaf HFlMl3D8WnooohAmBVQLGRNA11arHpT7svBgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=rULK2PJg7TVFiNGX+Psl/4PSPu78ll+QMxQLc1Pj9Z0aWDLizMzXvJgx2luPgNOjHM obZL45O4iU5XTGKPR6m6yLYoDavpgZrXVunNpZ89KoHgE2YETx5FGmP/SSNOSs3fhQDk 9SKo1ETlpmfHwYht9myW/3BSlNx7/mJF0v+cA= Received: by 10.87.63.21 with SMTP id q21mr8436761fgk.52.1272893602431; Mon, 03 May 2010 06:33:22 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id 12sm7833991fgg.9.2010.05.03.06.33.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 06:33:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?C=2E_Bergstr=C3=B6m?= References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEC2E3.2030305@pathscale.com> Date: Mon, 03 May 2010 16:33:19 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <4BDEC2E3.2030305@pathscale.com> User-Agent: Opera Mail/10.10 (FreeBSD) Cc: yuri@rawbw.com, freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 13:33:29 -0000 On Mon, 03 May 2010 15:34:43 +0300, C. Bergstr=C3=B6m wrote: > What fancy stuff is in the ports tree which clang will take advantage = of? I wasn't talking about any specific port. What I meant is that new hardw= are won't stop coming out just because FreeBSD decided not to update their g= cc. New CPUs may have new instructions and other things that are different f= rom their predecessors in one way or another. While llvm will continue to ch= ase the hardware and implement new optimizations, gcc in base will not be aw= are of those changes, continuing to produce code that runs, but may may be missing potential optimizations on those CPUs. I hope this makes sense. > I can't say the gentoo/arch approach is correct, but it may not be a b= ad > idea to steal whatever they have have done correctly. Maybe, but to steal something, I'd have to know what is "gentoo/arch approach" first. > I'd be more than happy to help or work with you if it's feasible to ad= d > another compiler to this project. Hopefully, when I finish the project it will be relatively easy to add support for other compilers. -- = Andrius From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 15:12:57 2010 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 83ADA1065670; Mon, 3 May 2010 15:12:57 +0000 (UTC) (envelope-from salfrancl.listas@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id A7A668FC15; Mon, 3 May 2010 15:12:56 +0000 (UTC) Received: by bwz8 with SMTP id 8so1481901bwz.3 for ; Mon, 03 May 2010 08:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=50ExD10vKsAL5kEWOn9IPD3CM95cHNI4ag8Y8SFQdhk=; b=Q1fkeFw74xXWLMqfO0yR/wCMqIO41xy7PkcIFEXZ7yX+sjI3V8TbTyLN+tIeapmJvi riF1yOSwM7tENNOE+UBJSFxP14JHcgqYSMUanRP+hny9OQftEwOYP6cm17oU+CKYvV+b NUW2kv9s/Ruei4NSsLCqstozJusxHIhLaGZPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OaYxwFnpy/+AaNBMCeslfMQWgmxD5xmZ7Dh6N1CjFM1v3ee9S72OhapS6WW9yXJQbl NxhXAsinxucMnl2DDBG7ox1HhuSduX9oC80EbkTseVXplAoH0PAzMVJBUuweWbtkLZUK 2C3rJdGOCUg5Zb+mhXGWhHfde/OXuCwkKhBsk= MIME-Version: 1.0 Received: by 10.204.47.153 with SMTP id n25mr2345683bkf.199.1272899568524; Mon, 03 May 2010 08:12:48 -0700 (PDT) Received: by 10.204.119.68 with HTTP; Mon, 3 May 2010 08:12:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 11:12:48 -0400 Message-ID: From: Leinier Cruz Salfran To: David Forsythe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GSoC: Libpkg, package tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 15:12:57 -0000 On Sat, May 1, 2010 at 3:32 PM, David Forsythe wrote= : > Hi all, > hello david > I'm David Forsythe, and I'll be working on completing libpkg (started > during Summer of Code 2009) and putting together some production ready > package tools. =C2=A0My mentor will be Tim Kientzle. > that's a great news > You can email me on or off list is you have any questions, comments, > or suggestions. =C2=A0Or if you just want to say hi. > okey .. i want to ask you that the library have notifications callbacks in order to know the progress of the package operation example: pkg_add =3D> start, download, download progress, getting dependencies, bla = bla bla pkg_delete =3D> analizing package, removing files, execing uninstall operations, deleting, bla bla bla bla bla bla well thanks From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 16:14:59 2010 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 BCF7F106566C for ; Mon, 3 May 2010 16:14:59 +0000 (UTC) (envelope-from ak@natsys-lab.com) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by mx1.freebsd.org (Postfix) with ESMTP id 62E8B8FC1E for ; Mon, 3 May 2010 16:14:59 +0000 (UTC) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o43GEwp1012127 for ; Mon, 3 May 2010 12:14:58 -0400 Authentication-Results: cm-omr3 smtp.user=ak; auth=pass (CRAM-MD5) Received: from [81.200.119.167] ([81.200.119.167:7011] helo=[81.200.119.167]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9D/E9-04284-086FEDB4; Mon, 03 May 2010 12:14:58 -0400 Message-ID: <4BDF2E4C.4090009@natsys-lab.com> Date: Mon, 03 May 2010 20:13:00 +0000 From: Alexander Krizhanovsky Organization: NatSys Lab. User-Agent: Thunderbird 2.0.0.23 (X11/20100322) MIME-Version: 1.0 To: Kostik Belousov References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> In-Reply-To: <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------090003080800020009070304" Cc: freebsd-hackers@freebsd.org, ur4ina@gmail.com Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 16:14:59 -0000 This is a multi-part message in MIME format. --------------090003080800020009070304 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Kostik, thank you very much for the review! Kostik Belousov wrote: > On Mon, Apr 19, 2010 at 12:46:48AM +0000, Alexander Krizhanovsky wrote: > >> Hi all! >> >> This patch implements per-thread rusage statistic (like RUSAGE_THREAD in >> Linux and RUSAGE_LWP in OpenSolaris). >> >> Unfortunately, we have to acquire a number of locks to read/update >> system and user times for current thread rusage information because it's >> also used for whole process statistic and needs to be zeroed. >> >> Any comments are very appreciated. >> >> It's tested against 8.0-RELEASE. Appropriate PR is submitted. >> >> -- >> Alexander Krizhanovsky >> NatSys Lab. (http://natsys-lab.com) >> tel: +7 (916) 717-3899, +7 (499) 747-6304 >> e-mail: ak@natsys-lab.com >> >> > I think this should be somewhat modified before commit. > > First, please separate patch into two pieces. One would introduce > ruxagg_tlock() helper and use it in existing locations instead of > three-liners. Possibly, add K&R->ANSI C kern_getrusage definition > change. > > Second would actually add RUSAGE_THREAD. There, please follow > the style(9), in particular, do not initialize the local variables > at the declaration, instead, use explicit initialization in the code. > Done. I have also introduced third patch for casting microseconds to timeval and replaced a few appropriate places in whole kernel code. patch-rusage-thread-03052010.txt is incremental for patch-ruxagg_tlock-03052010.txt, which is by turn incremental for patch-usec2timeval-03052010.txt. I have made following change for calcru1(): - if ((int64_t)tu < 0) { - /* XXX: this should be an assert /phk */ - printf("calcru: negative runtime of %jd usec for pid %d (%s)\n", - (intmax_t)tu, p->p_pid, p->p_comm); - tu = ruxp->rux_tu; - } + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " + "for pid %d (%s)\n", + (intmax_t)tu, p->p_pid, p->p_comm)); tu can become negative at about 300 thousand years of uptime, so this condition seems quite unrealistic and indeed should be replaced by an assertion. However I didn't understand why it isn't done so far and the comment only was added. Did I miss something? > Should calctru() share the code with calcru1() ? I am esp. concerned > with sanity check like negative runtime etc. Possibly, this code > from calcru1() should be separated into function used from both > calcru1() and calctru(). > > Man page for getrusage(2) should be updated. > It's added to patch-rusage-thread-03052010.txt. In the end - shoud I raise a new PR (the original one is kern/145813)? > Thanks for the submission. > > >> --- sys/sys/resource.h.orig 2009-10-25 01:10:29.000000000 +0000 >> +++ sys/sys/resource.h 2010-04-11 23:31:14.000000000 +0000 >> @@ -56,6 +56,7 @@ >> >> #define RUSAGE_SELF 0 >> #define RUSAGE_CHILDREN -1 >> +#define RUSAGE_THREAD 1 >> >> struct rusage { >> struct timeval ru_utime; /* user time used */ >> --- sys/kern/kern_resource.c.orig 2009-10-25 01:10:29.000000000 +0000 >> +++ sys/kern/kern_resource.c 2010-04-18 23:49:04.000000000 +0000 >> @@ -76,6 +76,7 @@ static void calcru1(struct proc *p, stru >> struct timeval *up, struct timeval *sp); >> static int donice(struct thread *td, struct proc *chgp, int n); >> static struct uidinfo *uilookup(uid_t uid); >> +static void ruxagg_tlock(struct proc *p, struct thread *td); >> >> /* >> * Resource controls and accounting. >> @@ -623,9 +624,7 @@ lim_cb(void *arg) >> return; >> PROC_SLOCK(p); >> FOREACH_THREAD_IN_PROC(p, td) { >> - thread_lock(td); >> - ruxagg(&p->p_rux, td); >> - thread_unlock(td); >> + ruxagg_tlock(p, td); >> } >> PROC_SUNLOCK(p); >> if (p->p_rux.rux_runtime > p->p_cpulimit * cpu_tickrate()) { >> @@ -836,9 +835,7 @@ calcru(struct proc *p, struct timeval *u >> FOREACH_THREAD_IN_PROC(p, td) { >> if (td->td_incruntime == 0) >> continue; >> - thread_lock(td); >> - ruxagg(&p->p_rux, td); >> - thread_unlock(td); >> + ruxagg_tlock(p, td); >> } >> calcru1(p, &p->p_rux, up, sp); >> } >> @@ -918,6 +915,29 @@ calcru1(struct proc *p, struct rusage_ex >> sp->tv_usec = su % 1000000; >> } >> >> +static void >> +calctru(struct thread *td) >> +{ >> + u_int64_t tu = cputick2usec(td->td_incruntime); >> + u_int64_t ut = td->td_uticks; >> + u_int64_t it = td->td_iticks; >> + u_int64_t st = td->td_sticks; >> + u_int64_t tt, uu, su; >> + >> + tt = ut + st + it; >> + if (!tt) { >> + /* Avoid divide by zero */ >> + st = 1; >> + tt = 1; >> + } >> + uu = td->td_ru.ru_utime.tv_usec + (ut * tu) / tt; >> + su = td->td_ru.ru_stime.tv_usec + (st * tu) / tt; >> + td->td_ru.ru_utime.tv_sec += uu / 1000000; >> + td->td_ru.ru_utime.tv_usec = uu % 1000000; >> + td->td_ru.ru_stime.tv_sec += su / 1000000; >> + td->td_ru.ru_stime.tv_usec = su % 1000000; >> +} >> + >> #ifndef _SYS_SYSPROTO_H_ >> struct getrusage_args { >> int who; >> @@ -939,10 +959,7 @@ getrusage(td, uap) >> } >> >> int >> -kern_getrusage(td, who, rup) >> - struct thread *td; >> - int who; >> - struct rusage *rup; >> +kern_getrusage(struct thread *td, int who, struct rusage *rup) >> { >> struct proc *p; >> int error; >> @@ -961,6 +978,13 @@ kern_getrusage(td, who, rup) >> calccru(p, &rup->ru_utime, &rup->ru_stime); >> break; >> >> + case RUSAGE_THREAD: >> + PROC_SLOCK(p); >> + ruxagg_tlock(p, td); >> + PROC_SUNLOCK(p); >> + *rup = td->td_ru; >> + break; >> + >> default: >> error = EINVAL; >> } >> @@ -1010,12 +1034,24 @@ ruxagg(struct rusage_ext *rux, struct th >> rux->rux_uticks += td->td_uticks; >> rux->rux_sticks += td->td_sticks; >> rux->rux_iticks += td->td_iticks; >> + >> + /* update thread rusage before ticks counters cleaning */ >> + calctru(td); >> + >> td->td_incruntime = 0; >> td->td_uticks = 0; >> td->td_iticks = 0; >> td->td_sticks = 0; >> } >> >> +static void >> +ruxagg_tlock(struct proc *p, struct thread *td) >> +{ >> + thread_lock(td); >> + ruxagg(&p->p_rux, td); >> + thread_unlock(td); >> +} >> + >> /* >> * Update the rusage_ext structure and fetch a valid aggregate rusage >> * for proc p if storage for one is supplied. >> @@ -1030,9 +1066,7 @@ rufetch(struct proc *p, struct rusage *r >> *ru = p->p_ru; >> if (p->p_numthreads > 0) { >> FOREACH_THREAD_IN_PROC(p, td) { >> - thread_lock(td); >> - ruxagg(&p->p_rux, td); >> - thread_unlock(td); >> + ruxagg_tlock(p, td); >> rucollect(ru, &td->td_ru); >> } >> } >> > > >> _______________________________________________ >> 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" >> -- Alexander Krizhanovsky NatSys Lab. (http://natsys-lab.com) tel: +7 (916) 717-3899, +7 (499) 747-6304 e-mail: ak@natsys-lab.com --------------090003080800020009070304 Content-Type: text/plain; name="patch-rusage-thread-03052010.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-rusage-thread-03052010.txt" --- src/sys/sys/resource.h.orig 2010-05-02 16:37:26.537274709 +0000 +++ src/sys/sys/resource.h 2010-05-03 19:45:46.357159359 +0000 @@ -56,6 +56,7 @@ #define RUSAGE_SELF 0 #define RUSAGE_CHILDREN -1 +#define RUSAGE_THREAD 1 struct rusage { struct timeval ru_utime; /* user time used */ --- src/sys/kern/kern_resource.c.orig 2010-05-03 19:42:08.474513380 +0000 +++ src/sys/kern/kern_resource.c 2010-05-03 19:45:46.358157251 +0000 @@ -840,29 +840,35 @@ calcru(struct proc *p, struct timeval *u calcru1(p, &p->p_rux, up, sp); } +static __inline uint64_t +calcru_adjust_time(uint64_t it, uint64_t ut, uint64_t *st) +{ + uint64_t tt; + + tt = it + ut + *st; + if (tt == 0) { + /* Avoid divide by zero. */ + *st = 1; + tt = 1; + } + return (tt); +} + static void calcru1(struct proc *p, struct rusage_ext *ruxp, struct timeval *up, struct timeval *sp) { /* {user, system, interrupt, total} {ticks, usec}: */ - u_int64_t ut, uu, st, su, it, tt, tu; + uint64_t ut, uu, st, su, it, tt, tu; ut = ruxp->rux_uticks; st = ruxp->rux_sticks; it = ruxp->rux_iticks; - tt = ut + st + it; - if (tt == 0) { - /* Avoid divide by zero */ - st = 1; - tt = 1; - } + tt = calcru_adjust_time(it, ut, &st); tu = cputick2usec(ruxp->rux_runtime); - if ((int64_t)tu < 0) { - /* XXX: this should be an assert /phk */ - printf("calcru: negative runtime of %jd usec for pid %d (%s)\n", - (intmax_t)tu, p->p_pid, p->p_comm); - tu = ruxp->rux_tu; - } + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " + "for pid %d (%s)\n", + (intmax_t)tu, p->p_pid, p->p_comm)); if (tu >= ruxp->rux_tu) { /* @@ -913,6 +919,25 @@ calcru1(struct proc *p, struct rusage_ex usec2timeval(su, sp); } +static void +calctru(struct thread *td) +{ + uint64_t ut, uu, st, su, it, tt, tu; + + ut = td->td_uticks; + it = td->td_iticks; + st = td->td_sticks; + tt = calcru_adjust_time(it, ut, &st); + tu = cputick2usec(td->td_incruntime); + KASSERT((int64_t)tu < 0, ("calctru: negative runtime of %jd usec " + "for tid %d\n", (intmax_t)tu, td->td_tid)); + + uu = td->td_ru.ru_utime.tv_usec + (ut * tu) / tt; + su = td->td_ru.ru_stime.tv_usec + (st * tu) / tt; + usec2timeval(&td->td_ru.ru_utime, uu); + usec2timeval(&td->td_ru.ru_stime, su); +} + #ifndef _SYS_SYSPROTO_H_ struct getrusage_args { int who; @@ -953,6 +978,13 @@ kern_getrusage(struct thread *td, int wh calccru(p, &rup->ru_utime, &rup->ru_stime); break; + case RUSAGE_THREAD: + PROC_SLOCK(p); + ruxagg_tlock(p, td); + PROC_SUNLOCK(p); + *rup = td->td_ru; + break; + default: error = EINVAL; } @@ -1002,6 +1034,10 @@ ruxagg(struct rusage_ext *rux, struct th rux->rux_uticks += td->td_uticks; rux->rux_sticks += td->td_sticks; rux->rux_iticks += td->td_iticks; + + /* Update thread rusage before ticks counters cleaning. */ + calctru(td); + td->td_incruntime = 0; td->td_uticks = 0; td->td_iticks = 0; --- src/lib/libc/sys/getrusage.2.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/lib/libc/sys/getrusage.2 2010-05-03 19:45:46.359155143 +0000 @@ -42,6 +42,7 @@ .In sys/resource.h .Fd "#define RUSAGE_SELF 0" .Fd "#define RUSAGE_CHILDREN -1" +.Fd "#define RUSAGE_THREAD 1" .Ft int .Fn getrusage "int who" "struct rusage *rusage" .Sh DESCRIPTION @@ -49,11 +50,13 @@ The .Fn getrusage system call returns information describing the resources utilized by the current -process, or all its terminated child processes. -The +process, the current thread or all terminated children of the +current process. +The corresponding .Fa who argument is either -.Dv RUSAGE_SELF +.Dv RUSAGE_SELF , +.Dv RUSAGE_THREAD or .Dv RUSAGE_CHILDREN . The buffer to which --------------090003080800020009070304 Content-Type: text/plain; name="patch-ruxagg_tlock-03052010.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-ruxagg_tlock-03052010.txt" --- src/sys/kern/kern_resource.c.orig 2010-05-03 19:31:45.051576945 +0000 +++ src/sys/kern/kern_resource.c 2010-05-03 19:42:08.474513380 +0000 @@ -76,6 +76,7 @@ static void calcru1(struct proc *p, stru struct timeval *up, struct timeval *sp); static int donice(struct thread *td, struct proc *chgp, int n); static struct uidinfo *uilookup(uid_t uid); +static void ruxagg_tlock(struct proc *p, struct thread *td); /* * Resource controls and accounting. @@ -623,9 +624,7 @@ lim_cb(void *arg) return; PROC_SLOCK(p); FOREACH_THREAD_IN_PROC(p, td) { - thread_lock(td); - ruxagg(&p->p_rux, td); - thread_unlock(td); + ruxagg_tlock(p, td); } PROC_SUNLOCK(p); if (p->p_rux.rux_runtime > p->p_cpulimit * cpu_tickrate()) { @@ -836,9 +835,7 @@ calcru(struct proc *p, struct timeval *u FOREACH_THREAD_IN_PROC(p, td) { if (td->td_incruntime == 0) continue; - thread_lock(td); - ruxagg(&p->p_rux, td); - thread_unlock(td); + ruxagg_tlock(p, td); } calcru1(p, &p->p_rux, up, sp); } @@ -937,10 +934,7 @@ getrusage(td, uap) } int -kern_getrusage(td, who, rup) - struct thread *td; - int who; - struct rusage *rup; +kern_getrusage(struct thread *td, int who, struct rusage *rup) { struct proc *p; int error; @@ -1014,6 +1008,15 @@ ruxagg(struct rusage_ext *rux, struct th td->td_sticks = 0; } +static void +ruxagg_tlock(struct proc *p, struct thread *td) +{ + + thread_lock(td); + ruxagg(&p->p_rux, td); + thread_unlock(td); +} + /* * Update the rusage_ext structure and fetch a valid aggregate rusage * for proc p if storage for one is supplied. @@ -1028,9 +1031,7 @@ rufetch(struct proc *p, struct rusage *r *ru = p->p_ru; if (p->p_numthreads > 0) { FOREACH_THREAD_IN_PROC(p, td) { - thread_lock(td); - ruxagg(&p->p_rux, td); - thread_unlock(td); + ruxagg_tlock(p, td); rucollect(ru, &td->td_ru); } } --------------090003080800020009070304 Content-Type: text/plain; name="patch-usec2timeval-03052010.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-usec2timeval-03052010.txt" --- src/sys/sys/time.h.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/sys/sys/time.h 2010-05-03 19:31:45.008535442 +0000 @@ -178,6 +178,14 @@ timeval2bintime(const struct timeval *tv /* timevaladd and timevalsub are not inlined */ +static __inline void +usec2timeval(uint64_t msec, struct timeval *tv) +{ + + tv->tv_sec = msec / 1000000; + tv->tv_usec = msec % 1000000; +} + #endif /* _KERNEL */ #ifndef _KERNEL /* NetBSD/OpenBSD compatible interfaces */ --- src/sys/dev/sound/midi/sequencer.c.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/sys/dev/sound/midi/sequencer.c 2010-05-03 19:31:45.037557566 +0000 @@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/dev/sound/mi #include #include #include +#include #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_snd.h" @@ -364,8 +365,7 @@ timer_wait(struct seq_softc *t, int tick i = ticks * 60ull * 1000000ull / (t->tempo * t->timerbase); - when.tv_sec = i / 1000000; - when.tv_usec = i % 1000000; + usec2timeval(i, &when); #if 0 printf("timer_wait tempo %d timerbase %d ticks %d abs %d u_sec %llu\n", --- src/sys/kern/kern_ntptime.c.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/sys/kern/kern_ntptime.c 2010-05-03 19:31:45.048574050 +0000 @@ -952,8 +952,7 @@ kern_adjtime(struct thread *td, struct t mtx_lock(&Giant); if (olddelta) { - atv.tv_sec = time_adjtime / 1000000; - atv.tv_usec = time_adjtime % 1000000; + usec2timeval(time_adjtime, &atv); if (atv.tv_usec < 0) { atv.tv_usec += 1000000; atv.tv_sec--; --- src/sys/kern/kern_resource.c.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/sys/kern/kern_resource.c 2010-05-03 19:31:45.051576945 +0000 @@ -912,10 +912,8 @@ calcru1(struct proc *p, struct rusage_ex ruxp->rux_su = su; ruxp->rux_tu = tu; - up->tv_sec = uu / 1000000; - up->tv_usec = uu % 1000000; - sp->tv_sec = su / 1000000; - sp->tv_usec = su % 1000000; + usec2timeval(uu, up); + usec2timeval(su, sp); } #ifndef _SYS_SYSPROTO_H_ --- src/sys/netinet/sctp_timer.c.orig 2009-10-25 01:10:29.000000000 +0000 +++ src/sys/netinet/sctp_timer.c 2010-05-03 19:31:45.058544591 +0000 @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD: src/sys/netinet/sctp #include #include #include +#include void @@ -75,8 +76,7 @@ sctp_early_fr_timer(struct sctp_inpcb *i cur_rtt = SCTP_BASE_SYSCTL(sctp_early_fr_msec); } cur_rtt *= 1000; - tv.tv_sec = cur_rtt / 1000000; - tv.tv_usec = cur_rtt % 1000000; + usec2timeval(cur_rtt, &tv); min_wait = now; timevalsub(&min_wait, &tv); if (min_wait.tv_sec < 0 || min_wait.tv_usec < 0) { --------------090003080800020009070304-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 16:35:29 2010 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 AC3C5106566B for ; Mon, 3 May 2010 16:35:29 +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 CA5B38FC24 for ; Mon, 3 May 2010 16:35:28 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o43GZOI2018954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 19:35:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o43GZOmS025377; Mon, 3 May 2010 19:35:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o43GZOsV025376; Mon, 3 May 2010 19:35:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 May 2010 19:35:24 +0300 From: Kostik Belousov To: Alexander Krizhanovsky Message-ID: <20100503163524.GE23646@deviant.kiev.zoral.com.ua> References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Content-Disposition: inline In-Reply-To: <4BDF2E4C.4090009@natsys-lab.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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, ur4ina@gmail.com Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 16:35:29 -0000 --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2010 at 08:13:00PM +0000, Alexander Krizhanovsky wrote: > Kostik, >=20 > thank you very much for the review! >=20 > Kostik Belousov wrote: > >On Mon, Apr 19, 2010 at 12:46:48AM +0000, Alexander Krizhanovsky wrote: > > =20 > >>Hi all! > >> > >>This patch implements per-thread rusage statistic (like RUSAGE_THREAD i= n=20 > >>Linux and RUSAGE_LWP in OpenSolaris). > >> > >>Unfortunately, we have to acquire a number of locks to read/update=20 > >>system and user times for current thread rusage information because it'= s=20 > >>also used for whole process statistic and needs to be zeroed. > >> > >>Any comments are very appreciated. > >> > >>It's tested against 8.0-RELEASE. Appropriate PR is submitted. > >> > >>--=20 > >>Alexander Krizhanovsky > >>NatSys Lab. (http://natsys-lab.com) > >>tel: +7 (916) 717-3899, +7 (499) 747-6304 > >>e-mail: ak@natsys-lab.com > >> > >> =20 > >I think this should be somewhat modified before commit. > > > >First, please separate patch into two pieces. One would introduce > >ruxagg_tlock() helper and use it in existing locations instead of > >three-liners. Possibly, add K&R->ANSI C kern_getrusage definition > >change. > > > >Second would actually add RUSAGE_THREAD. There, please follow > >the style(9), in particular, do not initialize the local variables > >at the declaration, instead, use explicit initialization in the code. > > =20 > Done. I have also introduced third patch for casting microseconds to=20 > timeval and replaced a few appropriate places in whole kernel code. > patch-rusage-thread-03052010.txt is incremental for=20 > patch-ruxagg_tlock-03052010.txt, which is by turn incremental for=20 > patch-usec2timeval-03052010.txt. >=20 > I have made following change for calcru1(): > - if ((int64_t)tu < 0) { > - /* XXX: this should be an assert /phk */ > - printf("calcru: negative runtime of %jd usec for pid %d= =20 > (%s)\n", > - (intmax_t)tu, p->p_pid, p->p_comm); > - tu =3D ruxp->rux_tu; > - } > + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " > + "for pid %d (%s)\n", > + (intmax_t)tu, p->p_pid, p->p_comm)); >=20 > tu can become negative at about 300 thousand years of uptime, so this=20 > condition seems quite unrealistic and indeed should be replaced by an=20 > assertion. However I didn't understand why it isn't done so far and the= =20 > comment only was added. Did I miss something? >=20 > >Should calctru() share the code with calcru1() ? I am esp. concerned > >with sanity check like negative runtime etc. Possibly, this code > >from calcru1() should be separated into function used from both > >calcru1() and calctru(). > > > >Man page for getrusage(2) should be updated. > > =20 > It's added to patch-rusage-thread-03052010.txt. >=20 > In the end - shoud I raise a new PR (the original one is kern/145813)? >=20 > >Thanks for the submission. It was some time, I already committed ruxagg_tlock() part, that caused some feedback, and I reworked the rest of the patch myself. See svn-src@ for some discussion, and the latest version that I intend to commit shortly is below. Your comments are welcome. Lets discuss third patch after this is landed. diff --git a/lib/libc/sys/getrusage.2 b/lib/libc/sys/getrusage.2 index bdf5d45..423503f 100644 --- a/lib/libc/sys/getrusage.2 +++ b/lib/libc/sys/getrusage.2 @@ -28,7 +28,7 @@ .\" @(#)getrusage.2 8.1 (Berkeley) 6/4/93 .\" $FreeBSD$ .\" -.Dd June 4, 1993 +.Dd May 1, 2010 .Dt GETRUSAGE 2 .Os .Sh NAME @@ -42,6 +42,7 @@ .In sys/resource.h .Fd "#define RUSAGE_SELF 0" .Fd "#define RUSAGE_CHILDREN -1" +.Fd "#define RUSAGE_THREAD 1" .Ft int .Fn getrusage "int who" "struct rusage *rusage" .Sh DESCRIPTION @@ -49,11 +50,12 @@ The .Fn getrusage system call returns information describing the resources utilized by the current -process, or all its terminated child processes. +thread, the current process, or all its terminated child processes. The .Fa who argument is either -.Dv RUSAGE_SELF +.Dv RUSAGE_THREAD , +.Dv RUSAGE_SELF , or .Dv RUSAGE_CHILDREN . The buffer to which @@ -175,6 +177,10 @@ The .Fn getrusage system call appeared in .Bx 4.2 . +The +.Dv RUSAGE_THREAD +facility first appeared in +.Fx 8.1 . .Sh BUGS There is no way to obtain information about a child process that has not yet terminated. diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 49a3097..6c50f1f 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -901,7 +901,7 @@ fill_kinfo_thread(struct thread *td, struct kinfo_proc = *kp, int preferthread) kp->ki_pri.pri_user =3D td->td_user_pri; =20 if (preferthread) { - kp->ki_runtime =3D cputick2usec(td->td_runtime); + kp->ki_runtime =3D td->td_rux.rux_runtime; kp->ki_pctcpu =3D sched_pctcpu(td); kp->ki_estcpu =3D td->td_estcpu; } diff --git a/sys/kern/kern_resource.c b/sys/kern/kern_resource.c index a3ed75d..0bc78d0 100644 --- a/sys/kern/kern_resource.c +++ b/sys/kern/kern_resource.c @@ -76,7 +76,7 @@ static void calcru1(struct proc *p, struct rusage_ext *ru= xp, struct timeval *up, struct timeval *sp); static int donice(struct thread *td, struct proc *chgp, int n); static struct uidinfo *uilookup(uid_t uid); -static void ruxagg_tlock(struct proc *p, struct thread *td); +static void ruxagg(struct proc *p, struct thread *td); =20 /* * Resource controls and accounting. @@ -630,7 +630,7 @@ lim_cb(void *arg) return; PROC_SLOCK(p); FOREACH_THREAD_IN_PROC(p, td) { - ruxagg_tlock(p, td); + ruxagg(p, td); } PROC_SUNLOCK(p); if (p->p_rux.rux_runtime > p->p_cpulimit * cpu_tickrate()) { @@ -841,7 +841,7 @@ calcru(struct proc *p, struct timeval *up, struct timev= al *sp) FOREACH_THREAD_IN_PROC(p, td) { if (td->td_incruntime =3D=3D 0) continue; - ruxagg_tlock(p, td); + ruxagg(p, td); } calcru1(p, &p->p_rux, up, sp); } @@ -961,6 +961,16 @@ kern_getrusage(struct thread *td, int who, struct rusa= ge *rup) calccru(p, &rup->ru_utime, &rup->ru_stime); break; =20 + case RUSAGE_THREAD: + PROC_SLOCK(p); + ruxagg(p, td); + PROC_SUNLOCK(p); + thread_lock(td); + *rup =3D td->td_ru; + calcru1(p, &td->td_rux, &rup->ru_utime, &rup->ru_stime); + thread_unlock(td); + break; + default: error =3D EINVAL; } @@ -1001,7 +1011,7 @@ ruadd(struct rusage *ru, struct rusage_ext *rux, stru= ct rusage *ru2, * Aggregate tick counts into the proc's rusage_ext. */ void -ruxagg(struct rusage_ext *rux, struct thread *td) +ruxagg_locked(struct rusage_ext *rux, struct thread *td) { =20 THREAD_LOCK_ASSERT(td, MA_OWNED); @@ -1010,18 +1020,19 @@ ruxagg(struct rusage_ext *rux, struct thread *td) rux->rux_uticks +=3D td->td_uticks; rux->rux_sticks +=3D td->td_sticks; rux->rux_iticks +=3D td->td_iticks; - td->td_incruntime =3D 0; - td->td_uticks =3D 0; - td->td_iticks =3D 0; - td->td_sticks =3D 0; } =20 static void -ruxagg_tlock(struct proc *p, struct thread *td) +ruxagg(struct proc *p, struct thread *td) { =20 thread_lock(td); - ruxagg(&p->p_rux, td); + ruxagg_locked(&p->p_rux, td); + ruxagg_locked(&td->td_rux, td); + td->td_incruntime =3D 0; + td->td_uticks =3D 0; + td->td_iticks =3D 0; + td->td_sticks =3D 0; thread_unlock(td); } =20 @@ -1039,7 +1050,7 @@ rufetch(struct proc *p, struct rusage *ru) *ru =3D p->p_ru; if (p->p_numthreads > 0) { FOREACH_THREAD_IN_PROC(p, td) { - ruxagg_tlock(p, td); + ruxagg(p, td); rucollect(ru, &td->td_ru); } } diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index 9be4c2f..b32c584 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -432,7 +432,7 @@ thread_exit(void) PROC_UNLOCK(p); thread_lock(td); /* Save our tick information with both the thread and proc locked */ - ruxagg(&p->p_rux, td); + ruxagg_locked(&p->p_rux, td); PROC_SUNLOCK(p); td->td_state =3D TDS_INACTIVE; #ifdef WITNESS diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fb31cfc..e32e494 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -173,6 +173,27 @@ struct kdtrace_thread; struct cpuset; =20 /* + * XXX: Does this belong in resource.h or resourcevar.h instead? + * Resource usage extension. The times in rusage structs in the kernel are + * never up to date. The actual times are kept as runtimes and tick counts + * (with control info in the "previous" times), and are converted when + * userland asks for rusage info. Backwards compatibility prevents putting + * this directly in the user-visible rusage struct. + * + * Locking for p_rux: (cj) means (j) for p_rux and (c) for p_crux. + * Locking for td_rux: (t) for all fields. + */ +struct rusage_ext { + u_int64_t rux_runtime; /* (cj) Real time. */ + u_int64_t rux_uticks; /* (cj) Statclock hits in user mode. */ + u_int64_t rux_sticks; /* (cj) Statclock hits in sys mode. */ + u_int64_t rux_iticks; /* (cj) Statclock hits in intr mode. */ + u_int64_t rux_uu; /* (c) Previous user time in usec. */ + u_int64_t rux_su; /* (c) Previous sys time in usec. */ + u_int64_t rux_tu; /* (c) Previous total time in usec. */ +}; + +/* * Kernel runnable context (thread). * This is what is put to sleep and reactivated. * Thread context. Processes may have multiple threads. @@ -219,7 +240,8 @@ struct thread { u_int td_estcpu; /* (t) estimated cpu utilization */ int td_slptick; /* (t) Time at sleep. */ int td_blktick; /* (t) Time spent blocked. */ - struct rusage td_ru; /* (t) rusage information */ + struct rusage td_ru; /* (t) rusage information. */ + struct rusage_ext td_rux; /* (t) Internal rusage information. */ uint64_t td_incruntime; /* (t) Cpu ticks to transfer to proc. */ uint64_t td_runtime; /* (t) How many cpu ticks we've run. */ u_int td_pticks; /* (t) Statclock hits for profiling */ @@ -426,26 +448,6 @@ do { \ #define TD_SET_CAN_RUN(td) (td)->td_state =3D TDS_CAN_RUN =20 /* - * XXX: Does this belong in resource.h or resourcevar.h instead? - * Resource usage extension. The times in rusage structs in the kernel are - * never up to date. The actual times are kept as runtimes and tick counts - * (with control info in the "previous" times), and are converted when - * userland asks for rusage info. Backwards compatibility prevents putting - * this directly in the user-visible rusage struct. - * - * Locking: (cj) means (j) for p_rux and (c) for p_crux. - */ -struct rusage_ext { - u_int64_t rux_runtime; /* (cj) Real time. */ - u_int64_t rux_uticks; /* (cj) Statclock hits in user mode. */ - u_int64_t rux_sticks; /* (cj) Statclock hits in sys mode. */ - u_int64_t rux_iticks; /* (cj) Statclock hits in intr mode. */ - u_int64_t rux_uu; /* (c) Previous user time in usec. */ - u_int64_t rux_su; /* (c) Previous sys time in usec. */ - u_int64_t rux_tu; /* (c) Previous total time in usec. */ -}; - -/* * Process structure. */ struct proc { diff --git a/sys/sys/resource.h b/sys/sys/resource.h index 9af96af..e703744 100644 --- a/sys/sys/resource.h +++ b/sys/sys/resource.h @@ -56,6 +56,7 @@ =20 #define RUSAGE_SELF 0 #define RUSAGE_CHILDREN -1 +#define RUSAGE_THREAD 1 =20 struct rusage { struct timeval ru_utime; /* user time used */ diff --git a/sys/sys/resourcevar.h b/sys/sys/resourcevar.h index 21728aa..95a9b49 100644 --- a/sys/sys/resourcevar.h +++ b/sys/sys/resourcevar.h @@ -131,7 +131,7 @@ void rucollect(struct rusage *ru, struct rusage *ru2); void rufetch(struct proc *p, struct rusage *ru); void rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up, struct timeval *sp); -void ruxagg(struct rusage_ext *rux, struct thread *td); +void ruxagg_locked(struct rusage_ext *rux, struct thread *td); int suswintr(void *base, int word); struct uidinfo *uifind(uid_t uid); --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkve+0sACgkQC3+MBN1Mb4hhTQCdHxQjkIky/1btVbOxD+rJK8Eg W3wAoOfLQpeAaYAMFX85U2Bph/HHyj8b =rSe2 -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 18:21:39 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65332106566B for ; Mon, 3 May 2010 18:21:39 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4225C8FC08 for ; Mon, 3 May 2010 18:21:38 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o43ILX38040220 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 May 2010 11:21:34 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BDF142D.4010105@feral.com> Date: Mon, 03 May 2010 11:21:33 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ed Schouten References: <4BDDFDDD.6060208@feral.com> <20100503072132.GW56080@hoeg.nl> In-Reply-To: <20100503072132.GW56080@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 03 May 2010 11:21:34 -0700 (PDT) Cc: FreeBSD Hackers Subject: Re: making consmsgbuf_size a tunable? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 18:21:39 -0000 On 05/03/2010 12:21 AM, Ed Schouten wrote: > Hello Matthew, > > * Matthew Jacob wrote: > >> Any thoughts about this? >> > Looks good. Maybe we should make it a tunable only? Looking at the code, > once the consbuf has been allocated, there is no way you can ever resize > it. > > You could, but on closer inspection of the code, this doesn't seem to really kick in until you're multiuser anyway (until somebody executes TIOCONS), so maybe it doesn't really matter. From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:02:26 2010 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 A6043106567D for ; Mon, 3 May 2010 20:02:26 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from yorgi.telenet-ops.be (yorgi.telenet-ops.be [195.130.133.69]) by mx1.freebsd.org (Postfix) with ESMTP id 629778FC16 for ; Mon, 3 May 2010 20:02:26 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by yorgi.telenet-ops.be (Postfix) with ESMTP id 246C16812F3 for ; Mon, 3 May 2010 21:51:11 +0200 (CEST) Received: from triton.sigsegv.be ([213.119.97.224]) by gerard.telenet-ops.be with bizsmtp id D7r91e0014qUA0t0H7r9u7; Mon, 03 May 2010 21:51:09 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 0925E1C157; Mon, 3 May 2010 21:51:08 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Mon, 03 May 2010 21:51:07 +0200 Date: Mon, 3 May 2010 21:51:07 +0200 From: Kristof Provost To: Jakub Klama Message-ID: <20100503195107.GC24372@nereid> References: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Generic DMA engine framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:02:26 -0000 Hi, On 2010-04-30 19:44:45 (+0200), Jakub Klama wrote: > This summer I'll add generic mechanism for using general purpose > DMA engines found in embedded system-on-chip devices. This will make > possible to schedule transfers from kernel and userspace and will > allow to use DMA in other devices using systemwide DMA engine. > > My earlier experience with kernel development was writing FreeBSD/arm > port to TI DaVinci Digital-media system-on-chip - more details here: [1]. > Development of this project will be done also on DaVinci - I'll provide > implementation of its DMA engine as well as example DMA-enabled device > driver - DaVinci's SD/MMC controller (current implementation uses only > PIO transfers). > > You can read more details here: http://wiki.freebsd.org/SOC2010JakubKlama > > I will appreciate your comments and suggestions about this project. This looks like a very interesting project. I'm quite interested in seeing the idam(4) driver as I'm working on a driver for the hardware crypto engine in the 88F5182 (and later the 88F6xxx I hope) and it'd be much improved by DMA support. Good luck, Kristof From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:22:28 2010 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 6A629106564A for ; Mon, 3 May 2010 20:22:28 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from georges.telenet-ops.be (georges.telenet-ops.be [195.130.137.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3908FC12 for ; Mon, 3 May 2010 20:22:26 +0000 (UTC) Received: from triton.sigsegv.be ([213.119.97.224]) by georges.telenet-ops.be with bizsmtp id D8NS1e0014qUA0t068NStz; Mon, 03 May 2010 22:22:26 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 9B1B51C157; Mon, 3 May 2010 22:22:21 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Mon, 03 May 2010 22:22:21 +0200 Date: Mon, 3 May 2010 22:22:20 +0200 From: Kristof Provost To: Rafal Jaworowski Message-ID: <20100503202220.GD24372@nereid> References: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> <20100503195107.GC24372@nereid> <8CE0B65C-58CE-44AA-9DF1-804F03769DD1@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CE0B65C-58CE-44AA-9DF1-804F03769DD1@semihalf.com> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Jakub Klama Subject: Re: GSoC: Generic DMA engine framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:22:28 -0000 On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski wrote: > > Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. Yes, I'd be quite interested to see how my attempts compare to your work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I didn't study the Sheevaplug documentation in great detail but I believe the CESA is similar (but not identical) on the two chips. > BTW: out of curiousity, what is the platform based on 88F5281 you're using? It's a TS-7800: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 Regards, Kristof From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:31:19 2010 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 7D8171065670 for ; Mon, 3 May 2010 20:31:19 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 252528FC1A for ; Mon, 3 May 2010 20:31:19 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 2405DC42D1; Mon, 3 May 2010 22:16:46 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id E0Rm01tD-91A; Mon, 3 May 2010 22:16:45 +0200 (CEST) Received: from [192.168.133.14] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 64EB8C427A; Mon, 3 May 2010 22:16:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20100503195107.GC24372@nereid> Date: Mon, 3 May 2010 22:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CE0B65C-58CE-44AA-9DF1-804F03769DD1@semihalf.com> References: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> <20100503195107.GC24372@nereid> To: Kristof Provost X-Mailer: Apple Mail (2.1078) Cc: freebsd-hackers@freebsd.org, Jakub Klama Subject: Re: GSoC: Generic DMA engine framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:31:19 -0000 On 2010-05-03, at 21:51, Kristof Provost wrote: > Hi, >=20 > On 2010-04-30 19:44:45 (+0200), Jakub Klama = wrote: >> This summer I'll add generic mechanism for using general purpose=20 >> DMA engines found in embedded system-on-chip devices. This will make=20= >> possible to schedule transfers from kernel and userspace and will=20 >> allow to use DMA in other devices using systemwide DMA engine. >>=20 >> My earlier experience with kernel development was writing FreeBSD/arm=20= >> port to TI DaVinci Digital-media system-on-chip - more details here: = [1]. >> Development of this project will be done also on DaVinci - I'll = provide=20 >> implementation of its DMA engine as well as example DMA-enabled = device >> driver - DaVinci's SD/MMC controller (current implementation uses = only >> PIO transfers).=20 >>=20 >> You can read more details here: = http://wiki.freebsd.org/SOC2010JakubKlama >>=20 >> I will appreciate your comments and suggestions about this project. >=20 > This looks like a very interesting project. I'm quite interested in > seeing the idam(4) driver as I'm working on a driver for the hardware > crypto engine in the 88F5182 (and later the 88F6xxx I hope) and it'd = be > much improved by DMA support. Not sure how far you went with the crypto engine work, but be advised we = already have completed the CESA driver, only I haven't managed to commit = the code yet.. Let me know if you'd like to see / test drive this. BTW: out of curiousity, what is the platform based on 88F5281 you're = using? Rafal From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:47:34 2010 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 B9877106566B for ; Mon, 3 May 2010 20:47:34 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 620EC8FC08 for ; Mon, 3 May 2010 20:47:34 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id ABA0BC42D1; Mon, 3 May 2010 22:51:39 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id vnB9yTNftTwE; Mon, 3 May 2010 22:51:39 +0200 (CEST) Received: from [192.168.133.14] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id C398FC427A; Mon, 3 May 2010 22:51:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20100503202220.GD24372@nereid> Date: Mon, 3 May 2010 22:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> <20100503195107.GC24372@nereid> <8CE0B65C-58CE-44AA-9DF1-804F03769DD1@semihalf.com> <20100503202220.GD24372@nereid> To: Kristof Provost X-Mailer: Apple Mail (2.1078) Cc: freebsd-hackers@freebsd.org, Jakub Klama Subject: Re: GSoC: Generic DMA engine framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:47:34 -0000 On 2010-05-03, at 22:22, Kristof Provost wrote: > On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski = wrote: >>=20 >> Not sure how far you went with the crypto engine work, but be advised = we already have completed the CESA driver, only I haven't managed to = commit the code yet.. Let me know if you'd like to see / test drive = this. > Yes, I'd be quite interested to see how my attempts compare to your > work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I > didn't study the Sheevaplug documentation in great detail but I = believe > the CESA is similar (but not identical) on the two chips. I believe the 88F5182 has CESA as well, although as far I can see the = main difference is that while the 88F6xxx (and MV-78xxx) CESA has an = associated (to some extent can be considered as dedicated) TDMA engine, = the one in 88F5182 does not, and can only use the generic purpose engine = (IDMA). Our driver assumes TDMA and was only tested with 88F6xxx and = 78xxx, so it seems there's some work involved with getting this to work = on the 5182. Let me carve the code out for your reference so that you = can try to extend it to work wirh Orion. >> BTW: out of curiousity, what is the platform based on 88F5281 you're = using? > It's a TS-7800: > http://www.embeddedarm.com/products/board-detail.php?product=3DTS-7800 Does the generic DB-88F5XXX kernel config and existing code work with = this device, or have you had to modify anything? Rafal From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:52:39 2010 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 B135A106564A for ; Mon, 3 May 2010 20:52:39 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by mx1.freebsd.org (Postfix) with ESMTP id 194768FC1F for ; Mon, 3 May 2010 20:52:38 +0000 (UTC) Received: from triton.sigsegv.be ([213.119.97.224]) by juliette.telenet-ops.be with bizsmtp id D8sd1e0034qUA0t068sdC6; Mon, 03 May 2010 22:52:37 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 175F61C157; Mon, 3 May 2010 22:52:36 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Mon, 03 May 2010 22:52:35 +0200 Date: Mon, 3 May 2010 22:52:35 +0200 From: Kristof Provost To: Rafal Jaworowski Message-ID: <20100503205235.GE24372@nereid> References: <61BCAC8D-B468-41BD-9537-6DC6E5AFB834@semihalf.com> <20100503195107.GC24372@nereid> <8CE0B65C-58CE-44AA-9DF1-804F03769DD1@semihalf.com> <20100503202220.GD24372@nereid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Jakub Klama Subject: Re: GSoC: Generic DMA engine framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:52:39 -0000 On 2010-05-03 22:47:31 (+0200), Rafal Jaworowski wrote: > > On 2010-05-03, at 22:22, Kristof Provost wrote: > > > On 2010-05-03 22:12:28 (+0200), Rafal Jaworowski wrote: > >> > >> Not sure how far you went with the crypto engine work, but be advised we already have completed the CESA driver, only I haven't managed to commit the code yet.. Let me know if you'd like to see / test drive this. > > Yes, I'd be quite interested to see how my attempts compare to your > > work. Does it support the Sheevaplug SoC or the 88F5182 (Orion)? I > > didn't study the Sheevaplug documentation in great detail but I believe > > the CESA is similar (but not identical) on the two chips. > > I believe the 88F5182 has CESA as well, although as far I can see the main difference is that while the 88F6xxx (and MV-78xxx) CESA has an associated (to some extent can be considered as dedicated) TDMA engine, the one in 88F5182 does not, and can only use the generic purpose engine (IDMA). Our driver assumes TDMA and was only tested with 88F6xxx and 78xxx, so it seems there's some work involved with getting this to work on the 5182. Let me carve the code out for your reference so that you can try to extend it to work wirh Orion. > Thanks. > >> BTW: out of curiousity, what is the platform based on 88F5281 you're using? > > It's a TS-7800: > > http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 > > Does the generic DB-88F5XXX kernel config and existing code work with this device, or have you had to modify anything? > I've disabled PCI but that's about it. Regards, Kristof From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 20:54:11 2010 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 1E3341065672; Mon, 3 May 2010 20:54:11 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 9D93F8FC1E; Mon, 3 May 2010 20:54:10 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o43Ks6N3023433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 06:54:06 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o43Ks5Ff052983; Tue, 4 May 2010 06:54:05 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o43Ks4EY052982; Tue, 4 May 2010 06:54:04 +1000 (EST) (envelope-from peter) Date: Tue, 4 May 2010 06:54:04 +1000 From: Peter Jeremy To: Andrius =?utf-8?B?TW9ya8WrbmFz?= Message-ID: <20100503205404.GA52895@server.vk2pj.dyndns.org> References: <4BDD28E2.8010201@rawbw.com> <20100503092213.GA1294@straylight.m.ringlet.net> <4BDEA78F.90303@pathscale.com> <4BDEC2E3.2030305@pathscale.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: yuri@rawbw.com, =?iso-8859-1?Q?C=2E_Bergstr=F6m?= , freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: GSoC: Making ports work with clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 03 May 2010 20:54:11 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-May-03 16:33:19 +0300, Andrius Mork=C5=ABnas w= rote: >I wasn't talking about any specific port. What I meant is that new hardware >won't stop coming out just because FreeBSD decided not to update their gcc. >New CPUs may have new instructions and other things that are different from >their predecessors in one way or another. As an example of an increasingly common CPU that gcc 4.2 doen't support, consider the Intel Atom. It supports the 'Core' (ie up to SSSE3) instructions but only does in-order execution (like the Pentium 1). --=20 Peter Jeremy --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvfN+wACgkQ/opHv/APuIfLRACfWpX5rqzK6X751XG8M4JWtlcr 5MQAnjAruI30pFO7l0U1mnOhKxZawB3j =PT3+ -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 02:40:08 2010 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 BBD45106566C for ; Tue, 4 May 2010 02:40:08 +0000 (UTC) (envelope-from kimelto@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1A98FC13 for ; Tue, 4 May 2010 02:40:07 +0000 (UTC) Received: by bwz28 with SMTP id 28so1714414bwz.14 for ; Mon, 03 May 2010 19:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=10cWM4gdBmQEh2J/m/10xvIHRn6MUaJFcirhDCUkvlM=; b=qHiPs5LHKW0t4IoG0362OjE0n6sQcHnGxidybaUSezMSkFx9y5yhnel5lwvnxnwJen tXjFU2b8fnIYJOec+o41wUAlWldDHpIIHR2PNeolzyOyS96B+8+/KJtZY9zVZHTGf4YC jC7wA/C9YQfca/2Hg6o1FW8+D/KEBlsJbjRA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Av/FBx9ztPqo+H/picT89w+DbCzKJQr+6oJEadaHpMlE12O0QvJGTlKMturhPa4jGU iUIlAFGSaRRlwS3xOuvcnkBCOPRL3eKpMW91VcGHmuOhCPM5xmnq8Qn2FpyzyKSP+Q/N 3Cxzt3m4w6pxQBeIMRCoTDfCS9dySrXxrn4+E= MIME-Version: 1.0 Received: by 10.204.45.193 with SMTP id g1mr9953374bkf.12.1272940093947; Mon, 03 May 2010 19:28:13 -0700 (PDT) Received: by 10.204.59.135 with HTTP; Mon, 3 May 2010 19:28:13 -0700 (PDT) Date: Mon, 3 May 2010 19:28:13 -0700 Message-ID: From: Julien Laffaye To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GSoC:Complete Package support in the pkg_install tools and cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 04 May 2010 02:40:08 -0000 Hello, During this summer, I'll work on the pkg_install tools to add complete package support. A complete package is a package which includes all the required dependencies in its tarball. Unlike the PBI package format of PC-BSD, once a complete package is installed, it appears as every package contained in the complete package was installed separately. As a side effect, I'll add libarchive support to the pkg_add tool to make installation as efficient as possible and do some refactoring to allow code re usability. I'll also surely write automated tests which would benefit to the pkg_install tools. My page on the wiki is http://wiki.freebsd.org/SOC2010JulienLaffaye You can email me on or off list is you have any questions, comments or suggestions. Best regards, Julien Laffaye From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 10:15:41 2010 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 86F5B106566C for ; Tue, 4 May 2010 10:15:41 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1628D8FC0C for ; Tue, 4 May 2010 10:15:40 +0000 (UTC) Received: by fxm15 with SMTP id 15so3418717fxm.13 for ; Tue, 04 May 2010 03:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=vUuv8pASRVnoJTa/qiEE0m/hj2aaoBiZPvjWOP0/4XU=; b=hU4QrbOtkayBO3j6gJr1GymMEzw4LrhCmTSx0zv5OhLu6CX+aWikZFnCMaVFsLlwUr zPRSLkFUk6dsBpPz2u2pix3fctLJ1wxiKySNlRd+d4iTR/dBaM7DGCDW8HtBEo9mx+CK xT9Uv7MT0ICKMikoHroGZGNwnw5H0g/I3XDzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=BLUEbepR1JNBU5rRgHq+rxQcr0q7GOej0n6+2Rmiv0LKTEHojJubXlOSUxKBd9s+A3 O76UTHzSnyZMu+z2cGmXxNlgp/rPP0BXyEV2vwoaxwSmr8qj3P4FoWJvYyje0FHFhQt+ BapM5PDGjOn0gIqtF3RVBfrRMU5nsaF7cr6n4= MIME-Version: 1.0 Received: by 10.223.99.212 with SMTP id v20mr3966850fan.44.1272968134650; Tue, 04 May 2010 03:15:34 -0700 (PDT) Sender: brampton@gmail.com Received: by 10.223.126.208 with HTTP; Tue, 4 May 2010 03:15:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 11:15:34 +0100 X-Google-Sender-Auth: 4e81b4a7cf5e023d Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org, Julien Laffaye Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: GSoC:Complete Package support in the pkg_install tools and cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 04 May 2010 10:15:41 -0000 On Tue, May 4, 2010 at 3:28 AM, Julien Laffaye wrote: > > Hello, > > During this summer, I'll work on the pkg_install tools to add complete > package support. > A complete package is a package which includes all the required > dependencies in its tarball. > Unlike the PBI package format of PC-BSD, once a complete package is installed, > it appears as every package contained in the complete package was > installed separately. > [snip] > > Best regards, > Julien Laffaye Hi Julien, Glad you got onto the GSoC programme. I'm curious, what benefit is a complete package over many individual ones? Andrew From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 17:30:22 2010 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 AC05D106564A for ; Tue, 4 May 2010 17:30:22 +0000 (UTC) (envelope-from kimelto@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 393308FC15 for ; Tue, 4 May 2010 17:30:21 +0000 (UTC) Received: by bwz28 with SMTP id 28so2155387bwz.34 for ; Tue, 04 May 2010 10:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YUOmLWr6ja5qmGYjvcVul43Sx3XkwkAAggTFFJDtZAI=; b=EPVCncoxIX6cM+PI5uk4uGAESCDBO+YKZhCLe2urKIBkjlzYSpufbGzRuRujxOpkzk SYzQJX1wuAPJ+QVjb0hJr29FdUCA/ipIO2VCEXOeghcI3QUeNisIYTm6qILXKCEpfnka DQLpbxwbJYXjfqx6BRC4nxGmNvxXDHZm/DHJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VJeP2PjXuDbYCCBPRKlpt/RptgGYzo5+SmjIdmwucgW3m6yg+xDISCPl3y0YKCUeXK pgU1IggX7vKud+zyk2fxtd89lgXFyP8WNvSVxKNYnkYbfpOpGhijM2Z5VLmsXlUSxp3A MJI7Qo8koO3YdHLME5ayFqLowfVw6bKxD8xQ0= MIME-Version: 1.0 Received: by 10.204.9.23 with SMTP id j23mr170334bkj.132.1272994213960; Tue, 04 May 2010 10:30:13 -0700 (PDT) Received: by 10.204.59.135 with HTTP; Tue, 4 May 2010 10:30:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 10:30:13 -0700 Message-ID: From: Julien Laffaye To: Andrew Brampton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC:Complete Package support in the pkg_install tools and cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 04 May 2010 17:30:22 -0000 On Tue, May 4, 2010 at 3:15 AM, Andrew Brampton wrote: > > Hi Julien, > > Glad you got onto the GSoC programme. I'm curious, what benefit is a > complete package over many individual ones? Hi Andrew, If you cant or dont want to use the remote feature of of pkg_add (ex. your packages are built with non default options and you think its overkill to setup a server to distribute them) then you make a complete package. You only have to copy one file (say on an usb device), which is less error prone than 150 files. The global idea is to write a meta port which depends on the desired ports, type `make complete-package`, copy the output file on the machine to bootstrap, pkg_add /path/to/complete-pkg and voila! Regards, Julien From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 20:08:05 2010 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 827D9106564A for ; Tue, 4 May 2010 20:08:05 +0000 (UTC) (envelope-from phcoder@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 128BF8FC19 for ; Tue, 4 May 2010 20:08:04 +0000 (UTC) Received: by wwb13 with SMTP id 13so3317554wwb.13 for ; Tue, 04 May 2010 13:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=Q+zq55Yqmu6qC9lx3n2iZBt9gUSlLKiIFlNL2QFE5Yk=; b=gOFz5FB8xQ2gV5yFBBsAiR1egwGcP7psTLdoNDkcfEuNv262bakvnu69vX6Z9JlmRN qOTG20N3cc154riMEKBQ61EEkr+0XLG4OzWTaJpkiwgX8i1pmZzgpVLJxj6S6E4/IOCZ 23VhoqsX2T+i5Hh+v1PAAaV/7qRR+JKA2Hwzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=bwVyfLV2DPp04t3OeSJEVGgdkLDzjpQgxyvBTGUFnBs2ltQn78/wZ+5EI8w8fsx7ZB dlkAA+FtpJIvjb0+icQYvVr9fFi7CFVf3T1cdR5ejyiF9brHDgej7j9CjMhJxRT/P7zY DdH+KpZjiZZdL/yGGxT8wmUvx+wuOCdrNHspg= Received: by 10.227.137.134 with SMTP id w6mr1719333wbt.100.1273001835732; Tue, 04 May 2010 12:37:15 -0700 (PDT) Received: from debian.bg45.phnet (gprs55.swisscom-mobile.ch [193.247.250.55]) by mx.google.com with ESMTPS id b2sm45649920wbb.2.2010.05.04.12.37.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 May 2010 12:37:15 -0700 (PDT) Message-ID: <4BE07768.2010800@gmail.com> Date: Tue, 04 May 2010 21:37:12 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2D2F6C5E0687756B3D4A3E2D" Subject: GSoC: FreeBSD port to Yeeloong X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 04 May 2010 20:08:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D2F6C5E0687756B3D4A3E2D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, all. I'm a guy who ported GRUB to Yeeloong and for this GSoC I'll applying porting operator to FreeBSD as well. I'm currently GRUB maintainer and study at the ETH Z=C3=BCrich. I find collaboration between FreeBSD and GNU very important. With this port FreeBSD will be able to capture its fair share of users on this netbook. Wiki Page: http://wiki.freebsd.org/SOC2010VladimirSerbinenko Have a nice GSoC everyone. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig2D2F6C5E0687756B3D4A3E2D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkvgd2gACgkQNak7dOguQgnFpQEAjPp5rcPfsJrt9zTgfpMrq8pz l3XwzAPiIqWDMo6n69AA/2sDLQfNPCwWStMhAr0ZSVzbtFEqxbA57HJ5ihX/iYXt =I8kQ -----END PGP SIGNATURE----- --------------enig2D2F6C5E0687756B3D4A3E2D-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 20:51:02 2010 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 C9B2C1065670 for ; Tue, 4 May 2010 20:51:02 +0000 (UTC) (envelope-from ak@natsys-lab.com) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by mx1.freebsd.org (Postfix) with ESMTP id 75C708FC1A for ; Tue, 4 May 2010 20:51:02 +0000 (UTC) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o44Kp1o9011618 for ; Tue, 4 May 2010 16:51:01 -0400 Authentication-Results: cm-omr6 smtp.user=ak; auth=pass (CRAM-MD5) Received: from [81.200.119.167] ([81.200.119.167:60518] helo=[81.200.119.167]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A1/44-29263-3B880EB4; Tue, 04 May 2010 16:51:01 -0400 Message-ID: <4BE0C075.2040106@natsys-lab.com> Date: Wed, 05 May 2010 00:48:53 +0000 From: Alexander Krizhanovsky Organization: NatSys Lab. User-Agent: Thunderbird 2.0.0.23 (X11/20100322) MIME-Version: 1.0 To: Kostik Belousov References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> <20100503163524.GE23646@deviant.kiev.zoral.com.ua> In-Reply-To: <20100503163524.GE23646@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, svn-src-all@freebsd.org, ur4ina@gmail.com Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 20:51:03 -0000 Konstantin, Concerning i/o counters we collect them in rucollect() in for loop and update in various places, for example in vfs_bio.c. Rusage of an exiting threads is handled in exit1() -> ruadd(). Your version of the patch certainly is more robust, however I'm still concerning about following things, which could be done better: 1) Zeroing of thread runtime statistic looks fine if we use it only for whole process statistic calculating, but now (when it's also used as is for the thread statistic) it should be handled independently, i.e. RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures somehow. So I suppose we need to introduce some new counters to proc structure and counters update code (it was stopped me to go on this way). 2) With first in mind, getruasge(RUSAGE_THREAD) is called in current thread and doesn't affect or use information from other threads, so it definitely should use less number of locks, may be with atomic operations for read-update-write operations. In fact the same getting per-thread statistic in Linux is done _without_ locks at all (however Linux uses different process/thread model). If we're in time and it really looks like a problem (is getrusage() ever a hotspot?) I can try to prepare the patch with less locking on this weekend. Also I still don't understand the sanity check in calccru1() for negativeness of tu ( (int64_t)tu < 0 ) - is it reachable? It seems that it is possible only after about 300 thousand years of uptime... Could you please explain this? Should I write further about the patch to svn-src-all@ (sorry, but I'm new in FreeBSD mailing) ? Kostik Belousov wrote: > On Mon, May 03, 2010 at 08:13:00PM +0000, Alexander Krizhanovsky wrote: > >> Kostik, >> >> thank you very much for the review! >> >> Kostik Belousov wrote: >> >>> On Mon, Apr 19, 2010 at 12:46:48AM +0000, Alexander Krizhanovsky wrote: >>> >>> >>>> Hi all! >>>> >>>> This patch implements per-thread rusage statistic (like RUSAGE_THREAD in >>>> Linux and RUSAGE_LWP in OpenSolaris). >>>> >>>> Unfortunately, we have to acquire a number of locks to read/update >>>> system and user times for current thread rusage information because it's >>>> also used for whole process statistic and needs to be zeroed. >>>> >>>> Any comments are very appreciated. >>>> >>>> It's tested against 8.0-RELEASE. Appropriate PR is submitted. >>>> >>>> -- >>>> Alexander Krizhanovsky >>>> NatSys Lab. (http://natsys-lab.com) >>>> tel: +7 (916) 717-3899, +7 (499) 747-6304 >>>> e-mail: ak@natsys-lab.com >>>> >>>> >>>> >>> I think this should be somewhat modified before commit. >>> >>> First, please separate patch into two pieces. One would introduce >>> ruxagg_tlock() helper and use it in existing locations instead of >>> three-liners. Possibly, add K&R->ANSI C kern_getrusage definition >>> change. >>> >>> Second would actually add RUSAGE_THREAD. There, please follow >>> the style(9), in particular, do not initialize the local variables >>> at the declaration, instead, use explicit initialization in the code. >>> >>> >> Done. I have also introduced third patch for casting microseconds to >> timeval and replaced a few appropriate places in whole kernel code. >> patch-rusage-thread-03052010.txt is incremental for >> patch-ruxagg_tlock-03052010.txt, which is by turn incremental for >> patch-usec2timeval-03052010.txt. >> >> I have made following change for calcru1(): >> - if ((int64_t)tu < 0) { >> - /* XXX: this should be an assert /phk */ >> - printf("calcru: negative runtime of %jd usec for pid %d >> (%s)\n", >> - (intmax_t)tu, p->p_pid, p->p_comm); >> - tu = ruxp->rux_tu; >> - } >> + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " >> + "for pid %d (%s)\n", >> + (intmax_t)tu, p->p_pid, p->p_comm)); >> >> tu can become negative at about 300 thousand years of uptime, so this >> condition seems quite unrealistic and indeed should be replaced by an >> assertion. However I didn't understand why it isn't done so far and the >> comment only was added. Did I miss something? >> >> >>> Should calctru() share the code with calcru1() ? I am esp. concerned >>> with sanity check like negative runtime etc. Possibly, this code >>> >> >from calcru1() should be separated into function used from both >> >>> calcru1() and calctru(). >>> >>> Man page for getrusage(2) should be updated. >>> >>> >> It's added to patch-rusage-thread-03052010.txt. >> >> In the end - shoud I raise a new PR (the original one is kern/145813)? >> >> >>> Thanks for the submission. >>> > > It was some time, I already committed ruxagg_tlock() part, that caused > some feedback, and I reworked the rest of the patch myself. See svn-src@ > for some discussion, and the latest version that I intend to commit > shortly is below. Your comments are welcome. > > Lets discuss third patch after this is landed. > > diff --git a/lib/libc/sys/getrusage.2 b/lib/libc/sys/getrusage.2 > index bdf5d45..423503f 100644 > --- a/lib/libc/sys/getrusage.2 > +++ b/lib/libc/sys/getrusage.2 > @@ -28,7 +28,7 @@ > .\" @(#)getrusage.2 8.1 (Berkeley) 6/4/93 > .\" $FreeBSD$ > .\" > -.Dd June 4, 1993 > +.Dd May 1, 2010 > .Dt GETRUSAGE 2 > .Os > .Sh NAME > @@ -42,6 +42,7 @@ > .In sys/resource.h > .Fd "#define RUSAGE_SELF 0" > .Fd "#define RUSAGE_CHILDREN -1" > +.Fd "#define RUSAGE_THREAD 1" > .Ft int > .Fn getrusage "int who" "struct rusage *rusage" > .Sh DESCRIPTION > @@ -49,11 +50,12 @@ The > .Fn getrusage > system call > returns information describing the resources utilized by the current > -process, or all its terminated child processes. > +thread, the current process, or all its terminated child processes. > The > .Fa who > argument is either > -.Dv RUSAGE_SELF > +.Dv RUSAGE_THREAD , > +.Dv RUSAGE_SELF , > or > .Dv RUSAGE_CHILDREN . > The buffer to which > @@ -175,6 +177,10 @@ The > .Fn getrusage > system call appeared in > .Bx 4.2 . > +The > +.Dv RUSAGE_THREAD > +facility first appeared in > +.Fx 8.1 . > .Sh BUGS > There is no way to obtain information about a child process > that has not yet terminated. > diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c > index 49a3097..6c50f1f 100644 > --- a/sys/kern/kern_proc.c > +++ b/sys/kern/kern_proc.c > @@ -901,7 +901,7 @@ fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp, int preferthread) > kp->ki_pri.pri_user = td->td_user_pri; > > if (preferthread) { > - kp->ki_runtime = cputick2usec(td->td_runtime); > + kp->ki_runtime = td->td_rux.rux_runtime; > kp->ki_pctcpu = sched_pctcpu(td); > kp->ki_estcpu = td->td_estcpu; > } > diff --git a/sys/kern/kern_resource.c b/sys/kern/kern_resource.c > index a3ed75d..0bc78d0 100644 > --- a/sys/kern/kern_resource.c > +++ b/sys/kern/kern_resource.c > @@ -76,7 +76,7 @@ static void calcru1(struct proc *p, struct rusage_ext *ruxp, > struct timeval *up, struct timeval *sp); > static int donice(struct thread *td, struct proc *chgp, int n); > static struct uidinfo *uilookup(uid_t uid); > -static void ruxagg_tlock(struct proc *p, struct thread *td); > +static void ruxagg(struct proc *p, struct thread *td); > > /* > * Resource controls and accounting. > @@ -630,7 +630,7 @@ lim_cb(void *arg) > return; > PROC_SLOCK(p); > FOREACH_THREAD_IN_PROC(p, td) { > - ruxagg_tlock(p, td); > + ruxagg(p, td); > } > PROC_SUNLOCK(p); > if (p->p_rux.rux_runtime > p->p_cpulimit * cpu_tickrate()) { > @@ -841,7 +841,7 @@ calcru(struct proc *p, struct timeval *up, struct timeval *sp) > FOREACH_THREAD_IN_PROC(p, td) { > if (td->td_incruntime == 0) > continue; > - ruxagg_tlock(p, td); > + ruxagg(p, td); > } > calcru1(p, &p->p_rux, up, sp); > } > @@ -961,6 +961,16 @@ kern_getrusage(struct thread *td, int who, struct rusage *rup) > calccru(p, &rup->ru_utime, &rup->ru_stime); > break; > > + case RUSAGE_THREAD: > + PROC_SLOCK(p); > + ruxagg(p, td); > + PROC_SUNLOCK(p); > + thread_lock(td); > + *rup = td->td_ru; > + calcru1(p, &td->td_rux, &rup->ru_utime, &rup->ru_stime); > + thread_unlock(td); > + break; > + > default: > error = EINVAL; > } > @@ -1001,7 +1011,7 @@ ruadd(struct rusage *ru, struct rusage_ext *rux, struct rusage *ru2, > * Aggregate tick counts into the proc's rusage_ext. > */ > void > -ruxagg(struct rusage_ext *rux, struct thread *td) > +ruxagg_locked(struct rusage_ext *rux, struct thread *td) > { > > THREAD_LOCK_ASSERT(td, MA_OWNED); > @@ -1010,18 +1020,19 @@ ruxagg(struct rusage_ext *rux, struct thread *td) > rux->rux_uticks += td->td_uticks; > rux->rux_sticks += td->td_sticks; > rux->rux_iticks += td->td_iticks; > - td->td_incruntime = 0; > - td->td_uticks = 0; > - td->td_iticks = 0; > - td->td_sticks = 0; > } > > static void > -ruxagg_tlock(struct proc *p, struct thread *td) > +ruxagg(struct proc *p, struct thread *td) > { > > thread_lock(td); > - ruxagg(&p->p_rux, td); > + ruxagg_locked(&p->p_rux, td); > + ruxagg_locked(&td->td_rux, td); > + td->td_incruntime = 0; > + td->td_uticks = 0; > + td->td_iticks = 0; > + td->td_sticks = 0; > thread_unlock(td); > } > > @@ -1039,7 +1050,7 @@ rufetch(struct proc *p, struct rusage *ru) > *ru = p->p_ru; > if (p->p_numthreads > 0) { > FOREACH_THREAD_IN_PROC(p, td) { > - ruxagg_tlock(p, td); > + ruxagg(p, td); > rucollect(ru, &td->td_ru); > } > } > diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c > index 9be4c2f..b32c584 100644 > --- a/sys/kern/kern_thread.c > +++ b/sys/kern/kern_thread.c > @@ -432,7 +432,7 @@ thread_exit(void) > PROC_UNLOCK(p); > thread_lock(td); > /* Save our tick information with both the thread and proc locked */ > - ruxagg(&p->p_rux, td); > + ruxagg_locked(&p->p_rux, td); > PROC_SUNLOCK(p); > td->td_state = TDS_INACTIVE; > #ifdef WITNESS > diff --git a/sys/sys/proc.h b/sys/sys/proc.h > index fb31cfc..e32e494 100644 > --- a/sys/sys/proc.h > +++ b/sys/sys/proc.h > @@ -173,6 +173,27 @@ struct kdtrace_thread; > struct cpuset; > > /* > + * XXX: Does this belong in resource.h or resourcevar.h instead? > + * Resource usage extension. The times in rusage structs in the kernel are > + * never up to date. The actual times are kept as runtimes and tick counts > + * (with control info in the "previous" times), and are converted when > + * userland asks for rusage info. Backwards compatibility prevents putting > + * this directly in the user-visible rusage struct. > + * > + * Locking for p_rux: (cj) means (j) for p_rux and (c) for p_crux. > + * Locking for td_rux: (t) for all fields. > + */ > +struct rusage_ext { > + u_int64_t rux_runtime; /* (cj) Real time. */ > + u_int64_t rux_uticks; /* (cj) Statclock hits in user mode. */ > + u_int64_t rux_sticks; /* (cj) Statclock hits in sys mode. */ > + u_int64_t rux_iticks; /* (cj) Statclock hits in intr mode. */ > + u_int64_t rux_uu; /* (c) Previous user time in usec. */ > + u_int64_t rux_su; /* (c) Previous sys time in usec. */ > + u_int64_t rux_tu; /* (c) Previous total time in usec. */ > +}; > + > +/* > * Kernel runnable context (thread). > * This is what is put to sleep and reactivated. > * Thread context. Processes may have multiple threads. > @@ -219,7 +240,8 @@ struct thread { > u_int td_estcpu; /* (t) estimated cpu utilization */ > int td_slptick; /* (t) Time at sleep. */ > int td_blktick; /* (t) Time spent blocked. */ > - struct rusage td_ru; /* (t) rusage information */ > + struct rusage td_ru; /* (t) rusage information. */ > + struct rusage_ext td_rux; /* (t) Internal rusage information. */ > uint64_t td_incruntime; /* (t) Cpu ticks to transfer to proc. */ > uint64_t td_runtime; /* (t) How many cpu ticks we've run. */ > u_int td_pticks; /* (t) Statclock hits for profiling */ > @@ -426,26 +448,6 @@ do { \ > #define TD_SET_CAN_RUN(td) (td)->td_state = TDS_CAN_RUN > > /* > - * XXX: Does this belong in resource.h or resourcevar.h instead? > - * Resource usage extension. The times in rusage structs in the kernel are > - * never up to date. The actual times are kept as runtimes and tick counts > - * (with control info in the "previous" times), and are converted when > - * userland asks for rusage info. Backwards compatibility prevents putting > - * this directly in the user-visible rusage struct. > - * > - * Locking: (cj) means (j) for p_rux and (c) for p_crux. > - */ > -struct rusage_ext { > - u_int64_t rux_runtime; /* (cj) Real time. */ > - u_int64_t rux_uticks; /* (cj) Statclock hits in user mode. */ > - u_int64_t rux_sticks; /* (cj) Statclock hits in sys mode. */ > - u_int64_t rux_iticks; /* (cj) Statclock hits in intr mode. */ > - u_int64_t rux_uu; /* (c) Previous user time in usec. */ > - u_int64_t rux_su; /* (c) Previous sys time in usec. */ > - u_int64_t rux_tu; /* (c) Previous total time in usec. */ > -}; > - > -/* > * Process structure. > */ > struct proc { > diff --git a/sys/sys/resource.h b/sys/sys/resource.h > index 9af96af..e703744 100644 > --- a/sys/sys/resource.h > +++ b/sys/sys/resource.h > @@ -56,6 +56,7 @@ > > #define RUSAGE_SELF 0 > #define RUSAGE_CHILDREN -1 > +#define RUSAGE_THREAD 1 > > struct rusage { > struct timeval ru_utime; /* user time used */ > diff --git a/sys/sys/resourcevar.h b/sys/sys/resourcevar.h > index 21728aa..95a9b49 100644 > --- a/sys/sys/resourcevar.h > +++ b/sys/sys/resourcevar.h > @@ -131,7 +131,7 @@ void rucollect(struct rusage *ru, struct rusage *ru2); > void rufetch(struct proc *p, struct rusage *ru); > void rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up, > struct timeval *sp); > -void ruxagg(struct rusage_ext *rux, struct thread *td); > +void ruxagg_locked(struct rusage_ext *rux, struct thread *td); > int suswintr(void *base, int word); > struct uidinfo > *uifind(uid_t uid); > -- Alexander Krizhanovsky NatSys Lab. (http://natsys-lab.com) tel: +7 (916) 717-3899, +7 (499) 747-6304 e-mail: ak@natsys-lab.com From owner-freebsd-hackers@FreeBSD.ORG Tue May 4 21:25:03 2010 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 732FD106564A; Tue, 4 May 2010 21:25:03 +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 0C0588FC08; Tue, 4 May 2010 21:25:01 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o44LOmgY063660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2010 00:24:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o44LOm1b051577; Wed, 5 May 2010 00:24:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o44LOmgJ051576; Wed, 5 May 2010 00:24:48 +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: Wed, 5 May 2010 00:24:48 +0300 From: Kostik Belousov To: Alexander Krizhanovsky Message-ID: <20100504212448.GS23646@deviant.kiev.zoral.com.ua> References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> <20100503163524.GE23646@deviant.kiev.zoral.com.ua> <4BE0C075.2040106@natsys-lab.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2u4WfPhYOuYlOsk" Content-Disposition: inline In-Reply-To: <4BE0C075.2040106@natsys-lab.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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, ur4ina@gmail.com, bde@freebsd.org Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 21:25:03 -0000 --p2u4WfPhYOuYlOsk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 05, 2010 at 12:48:53AM +0000, Alexander Krizhanovsky wrote: > Konstantin, >=20 > Concerning i/o counters we collect them in rucollect() in for loop and=20 > update in various places, for example in vfs_bio.c. Rusage of an exiting= =20 > threads is handled in exit1() -> ruadd(). >=20 > Your version of the patch certainly is more robust, however I'm still=20 > concerning about following things, which could be done better: >=20 > 1) Zeroing of thread runtime statistic looks fine if we use it only for= =20 > whole process statistic calculating, but now (when it's also used as is= =20 > for the thread statistic) it should be handled independently, i.e.=20 > RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures=20 > somehow. So I suppose we need to introduce some new counters to proc=20 > structure and counters update code (it was stopped me to go on this way). What do you mean by zeroing of thread runtime statistic ? Can you, please, point me to exact location in code ? I did not found such code when I did initial review of your patch. I did testing by repeatedly calling getrusage with alternated RUSAGE_SELF/RUSAGE_THREAD commands, and got sane increasing snapshots of statistic. >=20 > 2) With first in mind, getruasge(RUSAGE_THREAD) is called in current=20 > thread and doesn't affect or use information from other threads, so it=20 > definitely should use less number of locks, may be with atomic=20 > operations for read-update-write operations. In fact the same getting=20 > per-thread statistic in Linux is done _without_ locks at all (however=20 > Linux uses different process/thread model). thread_lock() is spinlock, and it disables preemption. calcru1() is very sensible to have ticks counters to be in consistent state. You can look at kern_time.c implementation of CLOCK_THREAD_CPUTIME_ID, where indeed only preepmtion is disabled by use of critical section. On the other hand, td_rux is accessed by other threads, and caclru1() updates should be properly syncronized. Since thread_lock would be needed for this, and it would give slightly more consistent results for the copy of td_ru, I used it. I do not think that thread_lock for running thread is a bottleneck, and getrusage definitely should be not a contention point for properly written application. >=20 > If we're in time and it really looks like a problem (is getrusage() ever= =20 > a hotspot?) I can try to prepare the patch with less locking on this=20 > weekend. >=20 > Also I still don't understand the sanity check in calccru1() for=20 > negativeness of tu ( (int64_t)tu < 0 ) - is it reachable? It seems that= =20 > it is possible only after about 300 thousand years of uptime... Could=20 > you please explain this? I never saw this message, may be change it to assertion, as proposed in phk comment, is reasonable. I do not have an opinion. >=20 > Should I write further about the patch to svn-src-all@ (sorry, but I'm=20 > new in FreeBSD mailing) ? I dropped svn-src@, lets discuss it there. --p2u4WfPhYOuYlOsk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvgkJ8ACgkQC3+MBN1Mb4jvxACeJc0aX1u7F5sVKJztUDLJN0oR T5AAoM+ltDqR0I032lNdrTNY91rcrOPz =YJdg -----END PGP SIGNATURE----- --p2u4WfPhYOuYlOsk-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 02:34:27 2010 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 E888A1065679 for ; Thu, 6 May 2010 02:34:27 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.50.215]) by mx1.freebsd.org (Postfix) with ESMTP id C2D2E8FC19 for ; Thu, 6 May 2010 02:34:27 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id BD8E65C37; Wed, 5 May 2010 22:34:57 -0400 (EDT) Date: Wed, 5 May 2010 22:34:57 -0400 From: Wesley Shields To: Julien Laffaye Message-ID: <20100506023457.GA45107@atarininja.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Andrew Brampton , freebsd-hackers@freebsd.org Subject: Re: GSoC:Complete Package support in the pkg_install tools and cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 02:34:28 -0000 On Tue, May 04, 2010 at 10:30:13AM -0700, Julien Laffaye wrote: > On Tue, May 4, 2010 at 3:15 AM, Andrew Brampton > wrote: > > > > Hi Julien, > > > > Glad you got onto the GSoC programme. I'm curious, what benefit is a > > complete package over many individual ones? > > Hi Andrew, > > If you cant or dont want to use the remote feature of of pkg_add (ex. > your packages are built with non default options and you think its > overkill to setup a server to distribute them) then you make a > complete package. You only have to copy one file (say on an usb > device), which is less error prone than 150 files. > The global idea is to write a meta port which depends on the desired > ports, type `make complete-package`, copy the output file on the > machine to bootstrap, pkg_add /path/to/complete-pkg and voila! Do you intend to add the "complete-package" target also or is that out of scope? -- WXS From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 02:58:47 2010 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 7CD0C106566B for ; Thu, 6 May 2010 02:58:47 +0000 (UTC) (envelope-from kimelto@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id CEE5C8FC12 for ; Thu, 6 May 2010 02:58:46 +0000 (UTC) Received: by bwz8 with SMTP id 8so3222904bwz.3 for ; Wed, 05 May 2010 19:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9y6Ka2inSqCRfLUY9Td+J/X4kfvRRk4vJAKhACewM+w=; b=APDZJvGaJ7AoV7KXGI2czU8Iw9PNs4fFTqq5+S2RZYLyxwqTL5UTlLFgH3JCW6o/S0 1kDXaYiW9+Zc/+hHAaBNvO2GcSIlZEefNf4x5YQfum0lSMusLfd2cYMjtadLOw+25Rop YrLRdrkvb499AWbqlNiWiKMrKllr2B2TTk39Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aGzO8H8QbUz+1v5bHViZzKYxGiK1MDTAhzirmPRvGTXRRFKgL4rLoXCtcofoW4YFYF vHmuZ3NEmqigMKHI1oDsiavudBrdCk/gM5u76kDDkc5kX8USkK5apjBKWeJy9ipG4uKG P54wByXBfMWwczat/t6WkyM0HRJ9xPU3xkRNM= MIME-Version: 1.0 Received: by 10.204.22.79 with SMTP id m15mr1912098bkb.80.1273114717033; Wed, 05 May 2010 19:58:37 -0700 (PDT) Received: by 10.204.59.135 with HTTP; Wed, 5 May 2010 19:58:36 -0700 (PDT) In-Reply-To: <20100506023457.GA45107@atarininja.org> References: <20100506023457.GA45107@atarininja.org> Date: Wed, 5 May 2010 19:58:36 -0700 Message-ID: From: Julien Laffaye To: Wesley Shields Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Brampton , freebsd-hackers@freebsd.org Subject: Re: GSoC:Complete Package support in the pkg_install tools and cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 02:58:47 -0000 On Wed, May 5, 2010 at 7:34 PM, Wesley Shields wrote: > On Tue, May 04, 2010 at 10:30:13AM -0700, Julien Laffaye wrote: >> On Tue, May 4, 2010 at 3:15 AM, Andrew Brampton >> wrote: >> > >> > Hi Julien, >> > >> > Glad you got onto the GSoC programme. I'm curious, what benefit is a >> > complete package over many individual ones? >> >> Hi Andrew, >> >> If you cant or dont want to use the remote feature of of pkg_add (ex. >> your packages are built with non default options and you think its >> overkill to setup a server to distribute them) then you make a >> complete package. You only have to copy one file (say on an usb >> device), which is less error prone than 150 files. >> The global idea is to write a meta port which depends on the desired >> ports, type `make complete-package`, copy the output file on the >> machine to bootstrap, pkg_add /path/to/complete-pkg and voila! > > Do you intend to add the "complete-package" target also or is that out > of scope? > Yes, it is scheduled to add the ability to build complete packages from the ports tree. The name of the target is not yet endorsed but I think that "complete-package" is pretty straight forward. Regards, Julien From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 06:44:50 2010 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 36755106567A for ; Thu, 6 May 2010 06:44:50 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id C0A3A8FC1F for ; Thu, 6 May 2010 06:44:49 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so29925eyd.9 for ; Wed, 05 May 2010 23:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=HZZ1BQ8hmH9npcJ/xqvy85Icb71XKNoeA82Nm02puXI=; b=LB0V8ktI0rm5J4nKrgFhL8nneHdtGAzTCrmyMojo5qRvj7rueo4nW/CwBsbN8YJrHH /lKXpZrMK4LOUrxUtKdfws4Cb91NlQQ0N9cAt5eFKCYQ031OYFJnV483f2TYR2tGQ8Yj 6TDLfEBRTiAU59g6CVavJIKpvEq0tlc5G656g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZfAS2XG8YBGULS/kFhjanvB6d+5PxLJmFcXvMB5wqBRlrMCG8rU9aem1zFZ+0mZthy 3XuiABPYDrzm5b3PxCK7lwEuCTcXDaMmWurSE23VWxosCYuKk0SNDx/22qiWV4dQG7Zw 1w58pjUuvUko/85jALkkk+qGCdvLhrNRxv7r0= MIME-Version: 1.0 Received: by 10.213.55.76 with SMTP id t12mr3172174ebg.3.1273128283356; Wed, 05 May 2010 23:44:43 -0700 (PDT) Received: by 10.213.33.18 with HTTP; Wed, 5 May 2010 23:44:43 -0700 (PDT) Date: Thu, 6 May 2010 08:44:43 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Converting pointer to vm_offset_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 06:44:50 -0000 Hi all, Is there a way to convert a (char *) pointer (or in general any pointer) to a vm_offset_t type? I was thinking of sbuf_copyin, but I'm dealing with a process different from current in kernel. I want to copy the pointer to kernel space using a struct uio. Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 08:44:27 2010 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 70BE1106566C for ; Thu, 6 May 2010 08:44:27 +0000 (UTC) (envelope-from ak@natsys-lab.com) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9358FC15 for ; Thu, 6 May 2010 08:44:26 +0000 (UTC) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o468iQ9d019565 for ; Thu, 6 May 2010 04:44:26 -0400 Authentication-Results: cm-omr9 smtp.user=ak; auth=pass (PLAIN) Received: from [81.200.119.167] ([81.200.119.167:30138] helo=[81.200.119.167]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A2/C8-05259-96182EB4; Thu, 06 May 2010 04:44:26 -0400 Message-ID: <4BE2B93F.4020003@natsys-lab.com> Date: Thu, 06 May 2010 16:42:39 +0400 From: Alexander Krizhanovsky Organization: NatSys Lab. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100502 Thunderbird/3.0.4 MIME-Version: 1.0 References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> <20100503163524.GE23646@deviant.kiev.zoral.com.ua> <4BE0C075.2040106@natsys-lab.com> <20100504212448.GS23646@deviant.kiev.zoral.com.ua> In-Reply-To: <20100504212448.GS23646@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, ur4ina@gmail.com, bde@freebsd.org Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 08:44:27 -0000 On 05/05/10 01:24, Kostik Belousov wrote: > On Wed, May 05, 2010 at 12:48:53AM +0000, Alexander Krizhanovsky wrote: > >> Konstantin, >> >> Concerning i/o counters we collect them in rucollect() in for loop and >> update in various places, for example in vfs_bio.c. Rusage of an exiting >> threads is handled in exit1() -> ruadd(). >> >> Your version of the patch certainly is more robust, however I'm still >> concerning about following things, which could be done better: >> >> 1) Zeroing of thread runtime statistic looks fine if we use it only for >> whole process statistic calculating, but now (when it's also used as is >> for the thread statistic) it should be handled independently, i.e. >> RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures >> somehow. So I suppose we need to introduce some new counters to proc >> structure and counters update code (it was stopped me to go on this way). >> > What do you mean by zeroing of thread runtime statistic ? Can you, please, > point me to exact location in code ? I did not found such code when > I did initial review of your patch. > > I did testing by repeatedly calling getrusage with alternated > RUSAGE_SELF/RUSAGE_THREAD commands, and got sane increasing snapshots > of statistic. > I meant zeroing of per-thread statistic in ruxagg() after updating of the whole process time counters. > >> 2) With first in mind, getruasge(RUSAGE_THREAD) is called in current >> thread and doesn't affect or use information from other threads, so it >> definitely should use less number of locks, may be with atomic >> operations for read-update-write operations. In fact the same getting >> per-thread statistic in Linux is done _without_ locks at all (however >> Linux uses different process/thread model). >> > thread_lock() is spinlock, and it disables preemption. calcru1() is > very sensible to have ticks counters to be in consistent state. > You can look at kern_time.c implementation of CLOCK_THREAD_CPUTIME_ID, > where indeed only preepmtion is disabled by use of critical section. > > On the other hand, td_rux is accessed by other threads, and caclru1() > updates should be properly syncronized. Since thread_lock would > be needed for this, and it would give slightly more consistent results > for the copy of td_ru, I used it. > > I do not think that thread_lock for running thread is a bottleneck, > and getrusage definitely should be not a contention point for properly > written application. > > Yes, you're right - if we wish to have lockless thread accounting, then we need to redesign the whole rusage accounting, so I'm voting for commit of the patch. Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired both in kern_getrusage() and could be a problem in multithreaded process with intensive performance accounting in threads. This happens for example in resource accounting systems for shared hosting which are solved by custom extensions of Apache, MySQL and other servers. >> If we're in time and it really looks like a problem (is getrusage() ever >> a hotspot?) I can try to prepare the patch with less locking on this >> weekend. >> >> Also I still don't understand the sanity check in calccru1() for >> negativeness of tu ( (int64_t)tu < 0 ) - is it reachable? It seems that >> it is possible only after about 300 thousand years of uptime... Could >> you please explain this? >> > I never saw this message, may be change it to assertion, as proposed > in phk comment, is reasonable. I do not have an opinion. > > I asked about it in my message from 3rd of May and also there I've proposesed following patch for calcru1(): - if ((int64_t)tu < 0) { - /* XXX: this should be an assert /phk */ - printf("calcru: negative runtime of %jd usec for pid %d (%s)\n", - (intmax_t)tu, p->p_pid, p->p_comm); - tu = ruxp->rux_tu; - } + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " + "for pid %d (%s)\n", + (intmax_t)tu, p->p_pid, p->p_comm)); -- Alexander Krizhanovsky NatSys Lab. (http://natsys-lab.com) tel: +7 (916) 717-3899, +7 (499) 747-6304 e-mail: ak@natsys-lab.com From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 08:56:57 2010 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 EFA661065670 for ; Thu, 6 May 2010 08:56:57 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id BDFAA8FC17 for ; Thu, 6 May 2010 08:56:57 +0000 (UTC) Received: (qmail 80211 invoked by uid 1000); 6 May 2010 08:56:54 -0000 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Date: Thu, 6 May 2010 20:57:05 +1200 (NZST) From: Atom Smasher Message-ID: <1005062053260.2629@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt To: freebsd-hackers@freebsd.org X-POM: The Moon is Waning Crescent (49% of Full) X-Hashcash: 1:20:1005060857:freebsd-hackers@freebsd.org::8gwbgf2z/YC+dpwO:000000 0000000000000000000000004rWF Subject: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 08:56:58 -0000 i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "What luck for rulers, that men do not think." -- Adolf Hitler From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 10:30:14 2010 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 2DD161065675 for ; Thu, 6 May 2010 10:30:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id B67818FC16 for ; Thu, 6 May 2010 10:30:13 +0000 (UTC) Received: by ewy24 with SMTP id 24so1602326ewy.33 for ; Thu, 06 May 2010 03:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2+fa1JKjBDTfXpuEPTK+PfkiKU/K5Yc9nKWzkmRc1tI=; b=DUV6S8avb0+T0TvDIblN8ZWwh9Cl76sWTlusarFxyTEgNPE5LiODpbFptWrFPnDEeg r5nU7CG122uIWyygEtpxUx6dvG/suDVkZcH1jFRN/RFe3+VG345n5UQ7t96GW2rSaP9t haRj174IuWKdiljZUyKhZu7BT/qk+G0r9wsAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g7Ox9HYbRD6lUF0JFqzG+0PU02pV+CclFc643DTrRAxjS/olWoD5traGO9IXjlANhl TYJuaeoNfqAxCOs8WFB+SwKL9/0sVVuX7Fir5MPztvch0bjrE6HLJAvcmEPrOBgtfttb 0qVUG4oysMzcbmMy5e3vskvn/g1LFcS7ym2GM= MIME-Version: 1.0 Received: by 10.213.51.208 with SMTP id e16mr3319283ebg.27.1273141801748; Thu, 06 May 2010 03:30:01 -0700 (PDT) Received: by 10.213.10.6 with HTTP; Thu, 6 May 2010 03:30:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 May 2010 06:30:01 -0400 Message-ID: From: Ryan Stone To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers Subject: Re: Converting pointer to vm_offset_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 10:30:14 -0000 Just cast the point to vm_offset_t. From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 11:10:53 2010 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 2EAF8106566C for ; Thu, 6 May 2010 11:10:53 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id C48698FC17 for ; Thu, 6 May 2010 11:10:52 +0000 (UTC) Received: (qmail 82317 invoked from network); 6 May 2010 11:10:52 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with AES256-SHA encrypted SMTP; 6 May 2010 11:10:52 -0000 Message-ID: <4BE2A3A1.5030805@acm.poly.edu> Date: Thu, 06 May 2010 07:10:25 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: Atom Smasher References: <1005062053260.2629@smasher> In-Reply-To: <1005062053260.2629@smasher> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 11:10:53 -0000 Atom Smasher wrote: > i suspect i've got bad RAM but memtest has run through several dozen > iterations without a problem. my (3 year old) laptop will run for a > few days or weeks and then crash/freeze/hang. i've enabled crash dumps > and i'm wondering if/how the dump might be able to (dis)prove that the > RAM is bad. any ideas? > > thanks... > My experience with bad memory is that if it causes the machine to crash, it won't always happen while the machine is running the same process (or kernel thread)--so look for it crashing in a wide variety of places--and upon inspection of the core dump, a pointer somewhere will be pointing to garbage. -Boris From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 11:55:45 2010 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 263ED106566B for ; Thu, 6 May 2010 11:55:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ED9AD8FC21 for ; Thu, 6 May 2010 11:55:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8B18A46BA0; Thu, 6 May 2010 07:55:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7BE168A01F; Thu, 6 May 2010 07:55:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 6 May 2010 07:48:48 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <1005062053260.2629@smasher> In-Reply-To: <1005062053260.2629@smasher> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005060748.48256.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 06 May 2010 07:55:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Atom Smasher Subject: Re: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 11:55:45 -0000 On Thursday 06 May 2010 4:57:05 am Atom Smasher wrote: > i suspect i've got bad RAM but memtest has run through several dozen > iterations without a problem. my (3 year old) laptop will run for a few > days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm > wondering if/how the dump might be able to (dis)prove that the RAM is bad. > any ideas? If you can find a bad pointer that has a single-bit error that can certainly point to bad memory. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 11:58:48 2010 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 D8F261065670 for ; Thu, 6 May 2010 11:58:48 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id A1C2C8FC12 for ; Thu, 6 May 2010 11:58:48 +0000 (UTC) Received: (qmail 76897 invoked by uid 1000); 6 May 2010 11:32:06 -0000 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Thu, 6 May 2010 23:32:16 +1200 (NZST) From: Atom Smasher In-Reply-To: <4BE2A3A1.5030805@acm.poly.edu> Message-ID: <1005062327340.2629@smasher> MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt References: <1005062053260.2629@smasher> <4BE2A3A1.5030805@acm.poly.edu> To: freebsd-hackers@freebsd.org X-POM: The Moon is Waning Crescent (48% of Full) X-Hashcash: 1:20:1005061132:freebsd-hackers@freebsd.org::Wp2JZtYCra55sNlQ:000000 000000000000000000000000BvPQ Subject: Re: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 11:58:48 -0000 On Thu, 6 May 2010, Boris Kochergin wrote: > My experience with bad memory is that if it causes the machine to crash, > it won't always happen while the machine is running the same process (or > kernel thread)--so look for it crashing in a wide variety of places--and > upon inspection of the core dump, a pointer somewhere will be pointing > to garbage. ============ so really i'd need to collect two or more crash dumps, and if they point to different addresses then i can reasonably say the RAM is bad? thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "You don't get everything you want. A dictatorship would be a lot easier." -- George "dubya" Bush, describing what it's like to be governor of Texas. (Governing Magazine 7/98) "If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator." -- George "dubya" Bush http://www.cnn.com/TRANSCRIPTS/0012/18/nd.01.html 18 Dec 2000 CNN.com "A dictatorship would be a heck of a lot easier, there's no question about it." George "dubya" Bush, 27 Jul 2001 Associated Press From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 13:11:42 2010 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 896AB1065675 for ; Thu, 6 May 2010 13:11:42 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by mx1.freebsd.org (Postfix) with ESMTP id 90CD68FC0C for ; Thu, 6 May 2010 13:11:30 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LAAXe+fUNIQRjzc/pkXrocH4eMvPt4@postini.com; Thu, 06 May 2010 06:11:42 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 6 May 2010 06:10:17 -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, 6 May 2010 09:10:16 -0400 From: Andrew Duane To: Atom Smasher , "freebsd-hackers@freebsd.org" Date: Thu, 6 May 2010 09:10:16 -0400 Thread-Topic: bad RAM? prove it with a crash dump? Thread-Index: AcrtFAtSlQJAg8rpSHCgyBEF5s5aZwACNdVg Message-ID: References: <1005062053260.2629@smasher> <4BE2A3A1.5030805@acm.poly.edu> <1005062327340.2629@smasher> In-Reply-To: <1005062327340.2629@smasher> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 13:11:42 -0000 owner-freebsd-hackers@freebsd.org wrote: > On Thu, 6 May 2010, Boris Kochergin wrote: >=20 >> My experience with bad memory is that if it causes the machine to >> crash, it won't always happen while the machine is running the same >> process (or kernel thread)--so look for it crashing in a wide >> variety of places--and upon inspection of the core dump, a pointer >> somewhere will be pointing to garbage. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > so really i'd need to collect two or more crash dumps, and if they > point to different addresses then i can reasonably say the RAM is bad? >=20 > thanks... It's not just that they point to different addresses, it is garbage in many= completely independent places. For example, pulling bad registers/return a= ddresses off the stack, or garbage in random unrelated buffers/structures/p= ointers. On the other hand, if you often have garbage in some structure's "= foo" pointer, that indicates a problem (maybe locking) in how your code man= ages setting that foo pointer. It's a subtle difference. It is also useful to make sure that the garbage itself is different. As men= tioned before, a single bit error in an otherwise valid value, or maybe a m= issing/scrambled byte, these are good indications of memory problems. If ra= ndom places are often overwritten with something else, that could just be a= nother piece of misbehaving code that is writing someplace it shouldn't. I'= ve often found code that writes some buffer into e.g. a piece of memory it = no longer owns that looks like memory corruption until you realize the garb= age is always something specific like a vnode structure. /Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 13:38:37 2010 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 8B8AE106566B for ; Thu, 6 May 2010 13:38:37 +0000 (UTC) (envelope-from czerner.lukas@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 1BAEA8FC13 for ; Thu, 6 May 2010 13:38:36 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so287628fgb.13 for ; Thu, 06 May 2010 06:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to :subject:message-id:user-agent:mime-version:content-type; bh=nNdgioV9Q97+ZyyH3Byq57JwqgxjrFwsCnBphn3C7PM=; b=jzfywpysXfKNWw55NCl1qBSeUyYBQf6AiA44gdjzS06PC0i5QGO+z/Mlrc/zuWDSU9 mUD/nSN9NgUDX8/T5hTfD/H9+mVZF0/l3Va1R/ep805Nj0oGw3Lw+9DMK/cVS+QfjKtW 1JQSTu1re6Fu+m+GFK5OjMOPisRpTOy4JO1Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:subject:message-id:user-agent:mime-version :content-type; b=fH/zAEQO82+71UhCrWZ84qkP51qYLuBw1H/z/ZolLHzwD/P5tkK6cnkbiPy9/P/nfu H15vxY1wSDVJIATar9t+bVr7UGNe+XsulntCF7uNKtN8jjIAc5xDnVxetPAosxwKmkhp 0JLgmOBjcLt1LyBGmOzqm8s5g6jPdP3OIRzk8= Received: by 10.87.64.29 with SMTP id r29mr1683288fgk.6.1273153112803; Thu, 06 May 2010 06:38:32 -0700 (PDT) Received: from a04-0215a.kn.vutbr.cz (a04-0215a.kn.vutbr.cz [147.229.216.20]) by mx.google.com with ESMTPS id 4sm2839160fgg.22.2010.05.06.06.38.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 May 2010 06:38:31 -0700 (PDT) Date: Thu, 6 May 2010 15:38:30 +0200 (CEST) From: "=?ISO-8859-15?Q?Luk=E1=A8_Czerner?=" X-X-Sender: bratt@a04-0215a.kn.vutbr.cz To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 13:38:37 -0000 Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. Thanks! -Lukas From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 13:47:27 2010 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 4AFE11065674; Thu, 6 May 2010 13:47:27 +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 8BDDB8FC1C; Thu, 6 May 2010 13:47:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o46DlJ2h062473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 May 2010 16:47:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o46DlJce064745; Thu, 6 May 2010 16:47:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o46DlJxA064744; Thu, 6 May 2010 16:47:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 6 May 2010 16:47:19 +0300 From: Kostik Belousov To: Alexander Krizhanovsky Message-ID: <20100506134719.GY23646@deviant.kiev.zoral.com.ua> References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> <20100503163524.GE23646@deviant.kiev.zoral.com.ua> <4BE0C075.2040106@natsys-lab.com> <20100504212448.GS23646@deviant.kiev.zoral.com.ua> <4BE2B93F.4020003@natsys-lab.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ubca5Sl/zyRO+Ah+" Content-Disposition: inline In-Reply-To: <4BE2B93F.4020003@natsys-lab.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=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, ur4ina@gmail.com, bde@freebsd.org Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 13:47:27 -0000 --Ubca5Sl/zyRO+Ah+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote: > On 05/05/10 01:24, Kostik Belousov wrote: > > On Wed, May 05, 2010 at 12:48:53AM +0000, Alexander Krizhanovsky wrote: > > =20 > >> Konstantin, > >> > >> Concerning i/o counters we collect them in rucollect() in for loop and= =20 > >> update in various places, for example in vfs_bio.c. Rusage of an exiti= ng=20 > >> threads is handled in exit1() -> ruadd(). > >> > >> Your version of the patch certainly is more robust, however I'm still= =20 > >> concerning about following things, which could be done better: > >> > >> 1) Zeroing of thread runtime statistic looks fine if we use it only fo= r=20 > >> whole process statistic calculating, but now (when it's also used as i= s=20 > >> for the thread statistic) it should be handled independently, i.e.=20 > >> RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures= =20 > >> somehow. So I suppose we need to introduce some new counters to proc= =20 > >> structure and counters update code (it was stopped me to go on this wa= y). > >> =20 > > What do you mean by zeroing of thread runtime statistic ? Can you, plea= se, > > point me to exact location in code ? I did not found such code when > > I did initial review of your patch. > > > > I did testing by repeatedly calling getrusage with alternated > > RUSAGE_SELF/RUSAGE_THREAD commands, and got sane increasing snapshots > > of statistic. > > =20 >=20 > I meant zeroing of per-thread statistic in ruxagg() after updating of > the whole process time counters. I still do not understand which code you are referencing. Please note that ruxagg() does not clear any thread statistic. It does clear the accumulated tick counts for the thread after moving them _both_ to per-process and per-thread resource usage storage. Please see the HEAD code that contains the committed patch. >=20 >=20 > > =20 > >> 2) With first in mind, getruasge(RUSAGE_THREAD) is called in current= =20 > >> thread and doesn't affect or use information from other threads, so it= =20 > >> definitely should use less number of locks, may be with atomic=20 > >> operations for read-update-write operations. In fact the same getting= =20 > >> per-thread statistic in Linux is done _without_ locks at all (however= =20 > >> Linux uses different process/thread model). > >> =20 > > thread_lock() is spinlock, and it disables preemption. calcru1() is > > very sensible to have ticks counters to be in consistent state. > > You can look at kern_time.c implementation of CLOCK_THREAD_CPUTIME_ID, > > where indeed only preepmtion is disabled by use of critical section. > > > > On the other hand, td_rux is accessed by other threads, and caclru1() > > updates should be properly syncronized. Since thread_lock would > > be needed for this, and it would give slightly more consistent results > > for the copy of td_ru, I used it. > > > > I do not think that thread_lock for running thread is a bottleneck, > > and getrusage definitely should be not a contention point for properly > > written application. > > > > =20 >=20 > Yes, you're right - if we wish to have lockless thread accounting, then > we need to redesign the whole rusage accounting, so I'm voting for > commit of the patch. Patch was committed two days ago. >=20 > Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired > both in kern_getrusage() and could be a problem in multithreaded process > with intensive performance accounting in threads. This happens for > example in resource accounting systems for shared hosting which are > solved by custom extensions of Apache, MySQL and other servers. We still need per-process lock for resource summation code. On the other hand, I do not understand why p_rux have to be protected by spinlock and not by process mutex. Hm, spinlock disables preemption, but only for curthread, Process spinlock is not acquired in the mi_switch(), so I really do not see a reason not to change protection to mutex. Any idea ? >=20 >=20 > >> If we're in time and it really looks like a problem (is getrusage() ev= er=20 > >> a hotspot?) I can try to prepare the patch with less locking on this= =20 > >> weekend. > >> > >> Also I still don't understand the sanity check in calccru1() for=20 > >> negativeness of tu ( (int64_t)tu < 0 ) - is it reachable? It seems tha= t=20 > >> it is possible only after about 300 thousand years of uptime... Could= =20 > >> you please explain this? > >> =20 > > I never saw this message, may be change it to assertion, as proposed > > in phk comment, is reasonable. I do not have an opinion. > > > > =20 >=20 > I asked about it in my message from 3rd of May and also there I've > proposesed following patch for calcru1(): >=20 > - if ((int64_t)tu < 0) { > - /* XXX: this should be an assert /phk */ > - printf("calcru: negative runtime of %jd usec for pid %d > (%s)\n", > - (intmax_t)tu, p->p_pid, p->p_comm); > - tu =3D ruxp->rux_tu; > - } > + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " > + "for pid %d (%s)\n", > + (intmax_t)tu, p->p_pid, p->p_comm)); >=20 I did understand your proposal, but, as I said, I have no opinion. --Ubca5Sl/zyRO+Ah+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkviyGYACgkQC3+MBN1Mb4iXxACgjZeh7Iw4ofhWMZ308BKuVoRv zqUAn0JI19gWqM7UawSwaypB/H7huEjp =CvcD -----END PGP SIGNATURE----- --Ubca5Sl/zyRO+Ah+-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 14:10:23 2010 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 1FBD31065674 for ; Thu, 6 May 2010 14:10:23 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id D152F8FC0A for ; Thu, 6 May 2010 14:10:22 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:60573 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1OA1jo-0001Zv-71 for freebsd-hackers@freebsd.org; Thu, 06 May 2010 16:07:43 +0200 Received: (qmail 45206 invoked by uid 1001); 6 May 2010 16:07:36 +0200 Date: Thu, 6 May 2010 16:07:36 +0200 From: Erik Trulsson To: =?iso-8859-1?B?THVr4ag=?= Czerner Message-ID: <20100506140736.GA45117@falcon.midgard.homeip.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1OA1jo-0001Zv-71. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1OA1jo-0001Zv-71 75d63da2ed83526d9cee926f455d0349 Cc: freebsd-hackers@freebsd.org Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 14:10:23 -0000 On Thu, May 06, 2010 at 03:38:30PM +0200, Luk=E1=A8 Czerner wrote: > Hi, >=20 > I am creating a kernel module and I need to get some information from > that module. I can do this with ioctl and pass the data to the > user space but it seems a bit unpractical to me, because I do not know=20 > the amount of the data - it can differ. I do not know of any way to > pass a list of structures to the userspace through ioctl - is there > any? >=20 > So my question is, is there any standard way in FreeBSD to do this ? > In linux I would probably use the sysfs, but in FreeBSD I can not find > anything similar, except just creating some virtual filesystem on my > own and obviously this is not what I want to do. sysctl(3) seems to be the usual way of getting information from the kernel. --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 14:40:22 2010 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 D357F1065670 for ; Thu, 6 May 2010 14:40:22 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 68E4F8FC0A for ; Thu, 6 May 2010 14:40:22 +0000 (UTC) Received: by wyb36 with SMTP id 36so23256wyb.13 for ; Thu, 06 May 2010 07:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=S7eQ3TvgOQwM0JCD7UErErW5I3NuucBvkec91e+nx5I=; b=wKkcOdko1Mns73+Evkyi4AfQHvZuWdjYv0VAVumQ2vFlJe21Q5XfyDgD6oUkkXc36Q WOh5zjgPKBdETgcMmiBqiDkqVaIt5w+LUwFrz+kc/beZfqloTsLsm3wc1K1HF1ptqW3E fHpBykLZUacFFpeOxfycl6DqvwbOMKb/rHQ/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=FOp/zKoEKoNXDn1l7hxGrYsA14+08Y+EiyHQ/KET9MX0cRFSgxZS4KcBR5bDAVHiuA dKt7wXIerpprBr2PdAD+aIUqSjVOXWM8MrBQhLFRYuGJn9LHgMisYN5vsLFpY6Jgfkdg kne6qTD/nLWeq005PGkpDzfkzEbwf0WGcbri4= Received: by 10.227.68.144 with SMTP id v16mr4256048wbi.156.1273156812433; Thu, 06 May 2010 07:40:12 -0700 (PDT) Received: from viper.internal.network (dsl78-143-204-136.in-addr.fast.co.uk [78.143.204.136]) by mx.google.com with ESMTPS id x6sm3560419gvf.12.2010.05.06.07.40.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 May 2010 07:40:11 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 63F5A4AC08; Thu, 6 May 2010 14:40:10 +0000 (UTC) Date: Thu, 6 May 2010 14:40:10 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20100506144010.GA62314@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: QTDIR? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 14:40:22 -0000 When compiling some QT4 based programs from source, the configure script asks for $QTDIR. On Debian and other systems, there's a single QT root with symlinks to the real locations: $ ls -alF /usr/share/qt4/ total 356 drwxr-xr-x 6 root root 4096 2010-05-05 15:01 ./ drwxr-xr-x 187 root root 4096 2010-05-06 02:16 ../ drwxr-xr-x 2 root root 4096 2010-05-05 15:01 bin/ drwxr-xr-x 3 root root 4096 2010-05-05 15:01 doc/ lrwxrwxrwx 1 root root 17 2010-05-05 15:01 include -> ../../include/qt4/ drwxr-xr-x 99 root root 4096 2010-05-05 15:01 mkspecs/ lrwxrwxrwx 1 root root 21 2010-05-05 15:01 plugins -> ../../lib/qt4/plugins/ -rw-r--r-- 1 root root 333331 2010-02-11 15:55 q3porting.xml drwxr-xr-x 2 root root 4096 2010-05-05 15:01 translations/ On FreeBSD, there doesn't seem to be any such directory (meaning some programs actually become impossible to compile as they want to look in one place for their includes/binaries and can't do so). Is there are directory I'm not aware of, or am I going to have to do some manual surgery? xw From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 15:26:23 2010 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 972B9106564A for ; Thu, 6 May 2010 15:26:23 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 77E9A8FC12 for ; Thu, 6 May 2010 15:26:23 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o46FQMY21729; Thu, 6 May 2010 08:26:22 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o46FQM902364; Thu, 6 May 2010 08:26:22 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 6 May 2010 08:26:21 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Andrew Duane In-Reply-To: Message-ID: References: <1005062053260.2629@smasher> <4BE2A3A1.5030805@acm.poly.edu> <1005062327340.2629@smasher> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" , Atom Smasher Subject: RE: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 15:26:23 -0000 On Thu, 6 May 2010, Andrew Duane wrote: > It is also useful to make sure that the garbage itself is different. As > mentioned before, a single bit error in an otherwise valid value, or > maybe a missing/scrambled byte, these are good indications of memory > problems. If random places are often overwritten with something else, > that could just be another piece of misbehaving code that is writing > someplace it shouldn't. I've often found code that writes some buffer > into e.g. a piece of memory it no longer owns that looks like memory > corruption until you realize the garbage is always something specific > like a vnode structure. There are trickier things too. I once had a machine with bad cache memory where once in a while you would get a cache line that had come from somewhere else in memory. This was particularly vexing when it happened to an I/O buffer, and I wound up with a large zip file that had 32 bytes of libc.so somewhere in the middle... :-( And of course, swapping out the RAM wouldn't have fixed it. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 16:41:58 2010 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 2D8061065676 for ; Thu, 6 May 2010 16:41:58 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B1EDE8FC18 for ; Thu, 6 May 2010 16:41:56 +0000 (UTC) Received: by wyb36 with SMTP id 36so138808wyb.13 for ; Thu, 06 May 2010 09:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=owLNJAYbDOlChZLQx465ej/kFvopybOu2ZkEeI0TMgc=; b=G826PHEs85tlamRVszOYBqnUBkBGIcOUr/V/o/94ButDp2jj9DP4SUoh4qbwD5qnMF ZkUjxVhQDNauQaMhV3KJUR3mV7ZbiD1WjDBfZ371QghAc4zBDCsa6aeBxZxTfzQ/ESPw qoc1K44pRrpjMYdjKS1CNdzYnSCkK6pRaJAmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BJNg+u0sS4RiHZJvVXt3uhQiQG0OBvxqL49t0N9ll6iyDke9Rxm+r9kKhSR5pHDDnV iSau6fGJx5GNTWu5o5ZyGXT1ym+Hpp2+L0mLx5bT3A9tbbuAIPpX99yqqGfA6NKOWKDF RbjbjuM5HcxBTkoTk/NtX5UhP8JJa0KJgC6Ow= Received: by 10.227.144.16 with SMTP id x16mr4518898wbu.174.1273164108136; Thu, 06 May 2010 09:41:48 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id x14sm8473628wbs.12.2010.05.06.09.41.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 May 2010 09:41:42 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BE2F13C.4010708@elischer.org> Date: Thu, 06 May 2010 09:41:32 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?windows-1252?Q?Luk=E1=9A_Czerner?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 16:41:58 -0000 On 5/6/10 6:38 AM, Lukáš Czerner wrote: > Hi, > > I am creating a kernel module and I need to get some information from > that module. I can do this with ioctl and pass the data to the > user space but it seems a bit unpractical to me, because I do not know > the amount of the data - it can differ. I do not know of any way to > pass a list of structures to the userspace through ioctl - is there > any? > > So my question is, is there any standard way in FreeBSD to do this ? > In linux I would probably use the sysfs, but in FreeBSD I can not find > anything similar, except just creating some virtual filesystem on my > own and obviously this is not what I want to do. > you can add a sysctl to pass out arbitrary information very easily. It's up to you to decide where you want to put it in the sysctl tree. > Thanks! > -Lukas > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 17:10:35 2010 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 38ECD1065670 for ; Thu, 6 May 2010 17:10:35 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id DF39B8FC13 for ; Thu, 6 May 2010 17:10:34 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o46GoHwX090471; Thu, 6 May 2010 11:50:17 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 6 May 2010 11:50:17 -0500 (CDT) From: "Sean C. Farley" To: Atom Smasher In-Reply-To: <1005062053260.2629@smasher> Message-ID: References: <1005062053260.2629@smasher> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.5 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on mail.farley.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 17:10:35 -0000 On Thu, 6 May 2010, Atom Smasher wrote: > i suspect i've got bad RAM but memtest has run through several dozen > iterations without a problem. my (3 year old) laptop will run for a > few days or weeks and then crash/freeze/hang. i've enabled crash dumps > and i'm wondering if/how the dump might be able to (dis)prove that the > RAM is bad. any ideas? > > thanks... Do not discount other hardware problems: video cards, bad capacitors and power supplies. Sadly, I mention these as a subset of my experience. :( I have even had a faulty left mouse button that would lock my X server (many years ago). While holding the button down (scrolling through a menu), the mouse would release and acquire too quickly for the server. Unfortunately, it is harder to find the problem in a laptop where you cannot easily (if at all) switch out pieces of hardware to find the problem. Have you investigated whether or not the laptop is overheating? Sean -- scf@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 18:00:06 2010 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 876BB1065675 for ; Thu, 6 May 2010 18:00:06 +0000 (UTC) (envelope-from czerner.lukas@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09A6B8FC1B for ; Thu, 6 May 2010 18:00:05 +0000 (UTC) Received: by fxm15 with SMTP id 15so215386fxm.13 for ; Thu, 06 May 2010 10:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to:cc :subject:in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=nv89blVxfIT704yu2McWOq2+OgtaR+cPbdWDvSr/3Z4=; b=YjwJHNYc9Pc4cvsDLf5MMH2SBWC7FwFxAcjtaoJdowW5DPwYm+EkgDWsIRxXUHdXJs lTRSMNWYBqIXCk6IeReLphJvPAErgf4Ap1+s5qKztDYzutzWxk1j8N0K9NrfmBToHPAt CRmYHqD6wtGJIosmXMbX0lm1OYbxggjXUHVJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=ZDgoknoWZSsolGLJfHshtTit7bUbEumfkAKqEpjZJcCNBW3Un/VnkxwYs8de0nJ2KB 9JHJQqYXLXJFln0/apqb+1W9TYfC8XDm96RrSh2Ri9aU4P3LqgWLPqiQxjsjQMbZwGCb SoQ2r4/MXUezCaDQ/DkJ7icgp1JrvIyTKI53w= Received: by 10.87.47.6 with SMTP id z6mr2148755fgj.13.1273168799446; Thu, 06 May 2010 10:59:59 -0700 (PDT) Received: from a04-0215a.kn.vutbr.cz (a04-0215a.kn.vutbr.cz [147.229.216.20]) by mx.google.com with ESMTPS id 4sm3524642fgg.2.2010.05.06.10.59.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 May 2010 10:59:58 -0700 (PDT) Date: Thu, 6 May 2010 19:59:56 +0200 (CEST) From: "=?ISO-8859-15?Q?Luk=E1=A8_Czerner?=" X-X-Sender: bratt@a04-0215a.kn.vutbr.cz To: Julian Elischer In-Reply-To: <4BE2F13C.4010708@elischer.org> Message-ID: References: <4BE2F13C.4010708@elischer.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-695050703-1273168798=:21095" Cc: freebsd-hackers@freebsd.org, =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 18:00:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-695050703-1273168798=:21095 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: 8BIT On Thu, 6 May 2010, Julian Elischer wrote: > Date: Thu, 06 May 2010 09:41:32 -0700 > From: Julian Elischer > To: Lukáš Czerner > Cc: freebsd-hackers@freebsd.org > Subject: Re: How to get data from kernel module ? > > On 5/6/10 6:38 AM, Lukáš Czerner wrote: > > Hi, > > > > I am creating a kernel module and I need to get some information from > > that module. I can do this with ioctl and pass the data to the > > user space but it seems a bit unpractical to me, because I do not know > > the amount of the data - it can differ. I do not know of any way to > > pass a list of structures to the userspace through ioctl - is there > > any? > > > > So my question is, is there any standard way in FreeBSD to do this ? > > In linux I would probably use the sysfs, but in FreeBSD I can not find > > anything similar, except just creating some virtual filesystem on my > > own and obviously this is not what I want to do. > > > > you can add a sysctl to pass out arbitrary information very easily. > It's up to you to decide where you want to put it in the sysctl > tree. > Thank to you all for suggestions. I will look at the sysctl then. Thanks! -Lukas --8323329-695050703-1273168798=:21095-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 18:12:10 2010 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 2AE141065673 for ; Thu, 6 May 2010 18:12:10 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D908B8FC14 for ; Thu, 6 May 2010 18:12:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OA5YO-0004lX-D8 for freebsd-hackers@freebsd.org; Thu, 06 May 2010 20:12:08 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 May 2010 20:12:08 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 May 2010 20:12:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Thu, 06 May 2010 20:12:07 +0200 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 18:12:10 -0000 On 05/06/10 15:38, Lukáš Czerner wrote: > Hi, > > I am creating a kernel module and I need to get some information from > that module. I can do this with ioctl and pass the data to the > user space but it seems a bit unpractical to me, because I do not know > the amount of the data - it can differ. I do not know of any way to > pass a list of structures to the userspace through ioctl - is there > any? > > So my question is, is there any standard way in FreeBSD to do this ? > In linux I would probably use the sysfs, but in FreeBSD I can not find > anything similar, except just creating some virtual filesystem on my > own and obviously this is not what I want to do. As others said, sysctl is one way to go, but might not be very convenient if the amount of data is large. I'd rather setup a device and a simple protocol to read/write to/from it. http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-char.html (you want the 5+ version) From owner-freebsd-hackers@FreeBSD.ORG Thu May 6 22:21:03 2010 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 53C0A1065675 for ; Thu, 6 May 2010 22:21:03 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id A27DB8FC19 for ; Thu, 6 May 2010 22:21:02 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id 0B67ED63D for ; Fri, 7 May 2010 08:05:38 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id B4oZM35aoCUB for ; Fri, 7 May 2010 08:05:34 +1000 (EST) Received: from [10.168.1.156] (dhcp156.gothic.net.au [10.168.1.156]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id 77219D632 for ; Fri, 7 May 2010 08:05:34 +1000 (EST) Message-ID: <4BE33D36.6050400@gothic.net.au> Date: Fri, 07 May 2010 08:05:42 +1000 From: Sean User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100430 Thunderbird/3.1b2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1005062053260.2629@smasher> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bad RAM? prove it with a crash dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 06 May 2010 22:21:03 -0000 On 7/05/2010 2:50 AM, Sean C. Farley wrote: > On Thu, 6 May 2010, Atom Smasher wrote: > >> i suspect i've got bad RAM but memtest has run through several dozen >> iterations without a problem. my (3 year old) laptop will run for a >> few days or weeks and then crash/freeze/hang. i've enabled crash dumps >> and i'm wondering if/how the dump might be able to (dis)prove that the >> RAM is bad. any ideas? >> >> thanks... > > Do not discount other hardware problems: video cards, bad capacitors and > power supplies. Sadly, I mention these as a subset of my experience. :( > I have even had a faulty left mouse button that would lock my X server > (many years ago). While holding the button down (scrolling through a > menu), the mouse would release and acquire too quickly for the server. > And to add the most obscure, the USB wireless kb/mouse adapter (or the keyboard/mouse itself) randomly crashing any operating system. Completely new PC with all components except that, reinstalled OS, change of OS, and it still crashed randomly. Swap the logitech adapter and the wireless keyboard/mouse that were locked to it, and all stability problems disappeared. > Unfortunately, it is harder to find the problem in a laptop where you > cannot easily (if at all) switch out pieces of hardware to find the > problem. > > Have you investigated whether or not the laptop is overheating? > > Sean From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 00:50:25 2010 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 C875D106564A for ; Fri, 7 May 2010 00:50:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id C0F308FC0C for ; Fri, 7 May 2010 00:50:24 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o46MvQS6005886 for ; Fri, 7 May 2010 08:57:26 +1000 Received: from besplex.bde.org (c122-106-171-133.carlnfd1.nsw.optusnet.com.au [122.106.171.133]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o46MvLpL001132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2010 08:57:22 +1000 Date: Fri, 7 May 2010 08:57:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20100506134719.GY23646@deviant.kiev.zoral.com.ua> Message-ID: <20100507074313.L1195@besplex.bde.org> References: <4BCBA7F8.3060109@natsys-lab.com> <20100425145929.GJ2422@deviant.kiev.zoral.com.ua> <4BDF2E4C.4090009@natsys-lab.com> <20100503163524.GE23646@deviant.kiev.zoral.com.ua> <4BE0C075.2040106@natsys-lab.com> <20100504212448.GS23646@deviant.kiev.zoral.com.ua> <4BE2B93F.4020003@natsys-lab.com> <20100506134719.GY23646@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 07 May 2010 02:45:39 +0000 Cc: freebsd-hackers@FreeBSD.org, Alexander Krizhanovsky , ur4ina@gmail.com, bde@FreeBSD.org Subject: Re: [PATCH] RUSAGE_THREAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 00:50:25 -0000 On Thu, 6 May 2010, Kostik Belousov wrote: > On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote: >> ... >> Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired >> both in kern_getrusage() and could be a problem in multithreaded process >> with intensive performance accounting in threads. This happens for >> example in resource accounting systems for shared hosting which are >> solved by custom extensions of Apache, MySQL and other servers. > > We still need per-process lock for resource summation code. It's hard to see how it can be done without any lock at all. The oldest example of per-CPU summation code is in vm_meter.c It doesn't use any locks, but without any lock at all it is fundamentally broken. Incoherencies in the data (due to reading and writing the counters at different unsynchronized times in the past) would be more obvious for times (except when the unsynchronized accesses give an off-by-2**32 error due to wraparound of a 32-bit counter), so I think getrusage() should be more careful than vm_meter. calcru() already does a lot of work and locking just to synchronize times relative to previous readings. > On the other > hand, I do not understand why p_rux have to be protected by spinlock and > not by process mutex. Hm, spinlock disables preemption, but only for > curthread, It is probably mostly historical. The read-modify-write of pc_switchtime and some other things used to be protected by splstatclock(). Hmm, that was the lowest spl level, closer to a non-spin mutex than anything. In RELENG_4, calcru() doesn't modify switchtime either, and mi_switch() has comments saying that even the splstatclock() should be unnecessary. RELENG_4 is of course non-preemptive, so it has close to the equivalent of critical_enter() automatically. > Process spinlock is not acquired in the mi_switch(), so I > really do not see a reason not to change protection to mutex. mi_switch)() holds thread lock, which is a special type of spinlock. I think the following philosphy is adequate for reading times: the time returned shall be no earlier than the time (according to a uniquely selected clock at the point where the time is read) at the beginning of the call, and coherent with itself. (It will be indeterminately far in the past by the time that it gets back to the caller. Times read by a single caller shall be monotonic, but times read by separate callers are incomparable unless the callers do additional synchronization). Thus the locked part of reading a clock is: - lock sufficiently to synchronize the next step - update memory copy of the time, so that it is not in the past - drop locks needed for the update, but keep ones needed to prevent the memory copy changing - read and use the memory copy, reassembling it into the form needed by the caller. This step may be long delayed from the update, but there is no point in trying to minimize the delay for this step, since we must soon drop all time-related locks and thus lose all control over the delay seen by the caller. Only in very critical kernel environments would it be necessary and possible to hold strong locks to minimize the delay across the whole operation of reading the time and acting on the result. >> I asked about it in my message from 3rd of May and also there I've >> proposesed following patch for calcru1(): >> >> - if ((int64_t)tu < 0) { >> - /* XXX: this should be an assert /phk */ >> - printf("calcru: negative runtime of %jd usec for pid %d >> (%s)\n", >> - (intmax_t)tu, p->p_pid, p->p_comm); >> - tu = ruxp->rux_tu; >> - } >> + KASSERT((int64_t)tu < 0, ("calcru: negative runtime of %jd usec " >> + "for pid %d (%s)\n", >> + (intmax_t)tu, p->p_pid, p->p_comm)); >> > I did understand your proposal, but, as I said, I have no opinion. This patch is mostly backwards: - backwards condition in KASSERT() - removal of KNF formatting - removal of the fixup when the KASSERT() is null. I think I prefer removing the whole statement. But the KASSERT() may be useful for verifying that the failure case really is unreachable due to programming bugs. I think it reachable due to hardware bugs, but only ones that are less likely than a memory parity error, and the handling of hardware bugs here shouldn't be to panic. Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 07:29:01 2010 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 9082B106566B for ; Fri, 7 May 2010 07:29:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 479078FC08 for ; Fri, 7 May 2010 07:29:00 +0000 (UTC) Received: by qyk11 with SMTP id 11so1228545qyk.13 for ; Fri, 07 May 2010 00:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7uBXkoORGAOOb+H+IJtT9W0uWxRYCR4/oxBe98TBdMU=; b=ZzOV8EnM7RVTMCUNlD6qbNd2YBcMbjXdiC92smbUYsE1NycXnjZEjQkOFAemf1hzz1 y5hmAXfA/w9Zy+lZegD61d7OOoioYugVoJHYgPbasbX+/Bq1AWnxfLmdcME9nfVTQ/Hs Wsc1ucwQ1rV1hiYY0XvQ8wi/WQnjXAM37orFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M9dqOqRB8OrbM6Qs6bqAj2lBCQMIdEWyjXoEBVw3Jn/fI4fRUIh5MAgPYCo1LkZ5ho 36xXFGWX6J0NJFCM3fREIvNpFqDQxCf6QtAeDel1ZiQUOWrokdFQK0YgJilkf6/sBleL vG8MvIhJtQNhra0e1jjXVI5eAbk6UtBkgXVCk= MIME-Version: 1.0 Received: by 10.229.225.72 with SMTP id ir8mr5997590qcb.73.1273217336679; Fri, 07 May 2010 00:28:56 -0700 (PDT) Received: by 10.229.193.14 with HTTP; Fri, 7 May 2010 00:28:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 May 2010 00:28:56 -0700 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers Subject: Re: Converting pointer to vm_offset_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 07:29:01 -0000 2010/5/6 Fernando Apestegu=EDa : > 2010/5/7 Garrett Cooper : >> 2010/5/5 Fernando Apestegu=EDa : >>> Hi all, >>> >>> Is there a way to convert a (char *) pointer (or in general any >>> pointer) to a vm_offset_t type? >> >> Be wary that char * is not compat layer friendly though :(... > > Ummm... I'm asking this because I want to access an array of strings > that resides in user space. If I'm not wrong, I need to copy in with > proc_rwmem the array itself and then, every one of the strings, > right?. I can easily locate the array through the > proc->p_sysent->sv_psstrings (that is actually a vm_offset_t), but how > can I specify the offset for the strings? void* is the preferred method I'm told for direct address translation (32-bit to 32-bit or 64-bit to 64-bit). Not sure about the compatibility types (kind of why I was waiting for a reply from someone more knowledgeable). I know the equivalent for Linux, not FreeBSD [yet]. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 07:59:58 2010 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 43927106566B for ; Fri, 7 May 2010 07:59:58 +0000 (UTC) (envelope-from czerner.lukas@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C10198FC17 for ; Fri, 7 May 2010 07:59:57 +0000 (UTC) Received: by fxm15 with SMTP id 15so630987fxm.13 for ; Fri, 07 May 2010 00:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to:cc :subject:in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=qfI39jfwFWMGDa/BERdwwHoLqnpa5H7lCTvRkYuYvTI=; b=rJSQWASG0DVB7BdF+fB/5/Xs373ziO+GEiu2AclGUv3fUi/mqQ6ug3MRejzN2tL7eT KSGrXzLmXX43f+F2IF+yyTHyppkYG4jt2qW9Y3jvt1ucVNSzv2gKw2qnLwzGo0twZBjQ oen9CgKA3aHKmOigfPXZIWyOHPNjMYnr8aFIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=JU6LsoNS25cf1l2v96EJ2NPvzo0kXO8DXo4OvQm9jVKNMpe7V4ehzfUr1gsdfhJNaZ IJQQwLjUeZ8r2dMc2JHvUjwJaYrCxMmBb9ZC72Us5XSfLIkx0S+0TR7l/b641bjr3eWL onoFFOTmolaEpRZgEkhV8L7GfkvUD/arlv5Fk= Received: by 10.223.100.141 with SMTP id y13mr1130679fan.15.1273219189251; Fri, 07 May 2010 00:59:49 -0700 (PDT) Received: from a04-0215a.kn.vutbr.cz (a04-0215a.kn.vutbr.cz [147.229.216.20]) by mx.google.com with ESMTPS id z10sm3604467fka.1.2010.05.07.00.59.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 00:59:48 -0700 (PDT) Date: Fri, 7 May 2010 09:59:46 +0200 (CEST) From: "=?ISO-8859-15?Q?Luk=E1=A8_Czerner?=" X-X-Sender: bratt@a04-0215a.kn.vutbr.cz To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-791890826-1273219188=:21095" Cc: freebsd-hackers@freebsd.org Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 07:59:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-791890826-1273219188=:21095 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 6 May 2010, Ivan Voras wrote: > Date: Thu, 06 May 2010 20:12:07 +0200 > From: Ivan Voras > To: freebsd-hackers@freebsd.org > Subject: Re: How to get data from kernel module ? > > On 05/06/10 15:38, Lukáš Czerner wrote: > > Hi, > > > > I am creating a kernel module and I need to get some information from > > that module. I can do this with ioctl and pass the data to the > > user space but it seems a bit unpractical to me, because I do not know > > the amount of the data - it can differ. I do not know of any way to > > pass a list of structures to the userspace through ioctl - is there > > any? > > > > So my question is, is there any standard way in FreeBSD to do this ? > > In linux I would probably use the sysfs, but in FreeBSD I can not find > > anything similar, except just creating some virtual filesystem on my > > own and obviously this is not what I want to do. > > As others said, sysctl is one way to go, but might not be very convenient if > the amount of data is large. I'd rather setup a device and a simple protocol > to read/write to/from it. > > http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-char.html > > (you want the 5+ version) > That seems even better. Thank you very much! -Lukas. --8323329-791890826-1273219188=:21095-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 08:59:23 2010 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 701401065670 for ; Fri, 7 May 2010 08:59:23 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 061838FC1D for ; Fri, 7 May 2010 08:59:22 +0000 (UTC) Received: by ewy24 with SMTP id 24so199600ewy.33 for ; Fri, 07 May 2010 01:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=liiAUXldFRhd+CtEAkC/ioKeoacqWusrgQClWTBQJeA=; b=jM6meGzauTpITA47UHQAkSEuZrytswQBBwJ36JYg94QJw2hCBY1b4XJ7jYoY4n4IkG WM0EiqKHjh7QJJM2l1DduzDPkri24vK/ABQgv79JGw+wFeIRcJ89g/awgW8QTbG5Kpir 6XKBUn25z9drRyslt45KSDljLZZ8LaUYaqog8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ge4PKjmy0oaAXnvwsw/s89zElD159d9a1LcoteorqC2Lu1xUjKCzZhT94t5zzHxYp4 B+AWOItV9Omx+DUrgX3BV1GE9wFv1rmMnRqdDXQjJzmSBQCWJeG0twOD+UgnzQT0BgWb CvC86v+fpX3cWvVy0sILKTKea2llAabBhlHyU= MIME-Version: 1.0 Received: by 10.213.55.209 with SMTP id v17mr4004462ebg.98.1273222750812; Fri, 07 May 2010 01:59:10 -0700 (PDT) Received: by 10.213.35.197 with HTTP; Fri, 7 May 2010 01:59:10 -0700 (PDT) Date: Fri, 7 May 2010 12:59:10 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 08:59:23 -0000 Hello Hackers, I'm working on porting some kernel modules written for FreeBSD7 to FreeBSD8. Some of these modules contain the following code: struct cdev *dev; ... int dev_num = minor(dev); This code doesn't compile on FreeBSD8. I found that in FreeBSD7 minor() was defined as follows: 515 int 516 minor(struct cdev *x) 517 { 518 if (x == NULL) 519 return NODEV; 520 return(x->si_drv0 & MAXMINOR); 521 } where MAXMINOR was defined as 236 #define MAXMINOR 0xffff00ffU But in FreeBSD8 minor() is defined as macro that takes integer as a parameter: 323 #define minor(x) ((int)((x)&0xffff00ff)) /* minor number */ I also found that FreeBSD8 provides dev2unit macro: 276 #define dev2unit(d) ((d)->si_drv0) It looks like dev2unit is exactly what I need to fix compilation issue. I changed the code of all modules as follows: - int dev_num = minor(dev); + int dev_num = minor(dev2unit(dev)); and now it compiles and works well. Is this the proper way of solving the problem? Thanks in advance! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 17:58:28 2010 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 006ED1065675 for ; Fri, 7 May 2010 17:58:28 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by mx1.freebsd.org (Postfix) with ESMTP id AFBA68FC1B for ; Fri, 7 May 2010 17:58:27 +0000 (UTC) Received: by gxk26 with SMTP id 26so814596gxk.13 for ; Fri, 07 May 2010 10:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u8DAUlcSDMFZxjYJI6ZY9ECDJgSI9Y/xO7V8QftsXxs=; b=JpBXF82sCmbKpJq4Nx8Wkdj/iakZIM4eVxJvCrmTKj28M338qH770p8SJ7os0kE8Kz rq7S+xHS9cwr0mYc04rxbrsUP3YjKn65iiG/Wa+bY0k8rhH5Sp1+r3leKzk3/K02NIgo 7OomV8vNHb1aJhXT5QH/TU9YF1BwCcCf/2bNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tk+ddLegSE9RdrT1i5dZjAwb7rWle5rLi9pta3XiQjdSoTx3gpsx/y+DfEpuNOEIxG aCkDXZ2D11cNibzhmDQ22ifWyYQtf8T7+cYBjbyl402p2c/K/kATL/Ymfg15Vplvvxxn MECAGHoODX63rEI5U9Ka4zUQ5Jv0M+teHsfec= MIME-Version: 1.0 Received: by 10.150.170.2 with SMTP id s2mr2353626ybe.379.1273253747758; Fri, 07 May 2010 10:35:47 -0700 (PDT) Received: by 10.150.192.4 with HTTP; Fri, 7 May 2010 10:35:47 -0700 (PDT) In-Reply-To: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> Date: Fri, 7 May 2010 10:35:47 -0700 Message-ID: From: Matt Reimer To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 17:58:28 -0000 On Tue, Dec 8, 2009 at 6:48 PM, Steven Hartland w= rote: > I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a > strange > segv which seems to indicate a core library error in _rtld_error. Could t= his > be the case or is the stack just badly corrupted? > > (gdb) bt > #0 =A00x00000008005577dc in _rtld_error () from /libexec/ld-elf.so.1 > #1 =A00x0000000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 > #2 =A00x0000000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 > #3 =A00x000000080055851b in dladdr () from /libexec/ld-elf.so.1 > #4 =A00x00000008005585f3 in dladdr () from /libexec/ld-elf.so.1 > #5 =A00x000000080055576d in ?? () from /libexec/ld-elf.so.1 > #6 =A00x0000000000000001 in ?? () > #7 =A00x00000000004117f8 in > boost::detail::sp_counted_impl_p= ::dispose > (this=3D0x800768980) at sp_counted_impl.hpp:78 > Previous frame inner to this frame (corrupt stack?) > > =A0 Regards > =A0 Steve Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. Matt From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 18:55:17 2010 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 71A88106564A for ; Fri, 7 May 2010 18:55:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3E08FC15 for ; Fri, 7 May 2010 18:55:16 +0000 (UTC) X-AuditID: 1209190c-b7bd2ae000005d05-0b-4be462147f86 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id F0.DC.23813.41264EB4; Fri, 7 May 2010 14:55:16 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o47ItGIA020495; Fri, 7 May 2010 14:55:16 -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 o47ItE3E014054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 May 2010 14:55:15 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o47ItEpD026227; Fri, 7 May 2010 14:55:14 -0400 (EDT) Date: Fri, 7 May 2010 14:55:13 -0400 (EDT) From: Benjamin Kaduk To: Dmitry Krivenok In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org Subject: Re: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 18:55:17 -0000 On Fri, 7 May 2010, Dmitry Krivenok wrote: > > It looks like dev2unit is exactly what I need to fix compilation issue. > I changed the code of all modules as follows: > > - int dev_num = minor(dev); > + int dev_num = minor(dev2unit(dev)); > > and now it compiles and works well. > > Is this the proper way of solving the problem? It should be -- see the commit message for svn revision 187830 on 2009-01-28 17:57:16Z by ed -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 19:38:48 2010 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 8A87A1065673; Fri, 7 May 2010 19:38:48 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (launchpad.bluezbox.com [195.137.202.161]) by mx1.freebsd.org (Postfix) with ESMTP id 411E88FC08; Fri, 7 May 2010 19:38:48 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.5.9]) by launchpad.bluezbox.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OASzh-000KIz-BE; Fri, 07 May 2010 19:13:57 +0000 Message-ID: <4BE46650.7010008@bluezbox.com> Date: Fri, 07 May 2010 12:13:20 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list Cc: Sam Leffler Subject: hifn(4) DMA fix for review X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 19:38:48 -0000 Proposed patch addresses hifn(4) problems on FreeBSD/mips. Current implementation keeps some of the state information (indexes in buffers, etc) in DMA-mapped memory and bus_dma code invalidates them during sync operations. This fix moves data that doesn't belong to DMA ring to softc structure. Patch: http://people.freebsd.org/~gonzo/hifn.diff Stats for original driver: http://people.freebsd.org/~gonzo/hifn.stats.orig.txt Stats for patched version: http://people.freebsd.org/~gonzo/hifn.stats.patched.txt From owner-freebsd-hackers@FreeBSD.ORG Fri May 7 21:32:48 2010 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 229471065672; Fri, 7 May 2010 21:32:48 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by mx1.freebsd.org (Postfix) with ESMTP id B71178FC0A; Fri, 7 May 2010 21:32:47 +0000 (UTC) Received: by gxk26 with SMTP id 26so953419gxk.13 for ; Fri, 07 May 2010 14:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Upmt280cmtOdmd6A2MWb4WLV28RA4GtQKjR2HwaPMqE=; b=Ikea9x7SkRpxWkm61h2LCYqDPlDy4sWqhaClah6D6H2bZfyWcw2EwwazbrcErRSAkM VRyBLHvb9iedxN5vVXwhlP6mYmX1qFWf9pPnoDyHwDDF7/+0k/J6TF9jnywVmWu1s2n7 c9OaiojRwBrDCuzTGhDiZRJ9Cb/RnowhAjKjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Eq9CS1hGmoNX3jzXhYV9TF+zDiF73n7JrVKsB/o5GvnWxhc2J4UhByH8p2af1h9yYM 7MGPdlNVlpYYkmBVZMOpAB9uZj4WB+WZzbSKFdOnFTIeETNsNA75oGd68P4HfqcWURkO eEM0yEbN8HSWLlaFriAavpNGZJ9abzP5MVpSo= MIME-Version: 1.0 Received: by 10.150.61.2 with SMTP id j2mr2325499yba.360.1273267957869; Fri, 07 May 2010 14:32:37 -0700 (PDT) Received: by 10.150.192.4 with HTTP; Fri, 7 May 2010 14:32:37 -0700 (PDT) In-Reply-To: <3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> <20091209102122.GC43143@deviant.kiev.zoral.com.ua> <3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> Date: Fri, 7 May 2010 14:32:37 -0700 Message-ID: From: Matt Reimer To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 May 2010 21:32:48 -0000 On Wed, Dec 9, 2009 at 4:20 AM, Steven Hartland w= rote: > > ----- Original Message ----- From: "Kostik Belousov" > To: "Steven Hartland" > Cc: ; > Sent: Wednesday, December 09, 2009 10:21 AM > Subject: Re: nginx + passenger =3D segv in _rtld_error on restart on > FreeBSD8.0? > > This is the trace once world had been recompiled with:- > CFLAGS=3D-pipe > WITH_CTF=3D1 > DEBUG_FLAGS=3D-g > > > #0 =A00x0000000800c95eec in thr_kill () at thr_kill.S:3 > #1 =A00x0000000800b22e9e in _thr_send_sig (thread=3D0x800f06600, sig=3D6)= at > /usr/src/lib/libthr/thread/thr_kern.c:92 > #2 =A00x0000000800b1f878 in _raise (sig=3D6) at > /usr/src/lib/libthr/thread/thr_sig.c:187 > #3 =A00x0000000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:= 65 > #4 =A00x000000000043b8a7 in Client::threadMain (this=3D0x800f9cf40) at > ext/nginx/HelperServer.cpp:516 > #5 =A00x0000000000411302 in boost::_mfi::mf0::operator() > (this=3D0x7fffffa45ea8, p=3D0x800f9cf40) at mem_fn_template.hpp:49 > #6 =A00x0000000000411651 in boost::_bi::list1 >>::operator(), boost::_bi::list0> > (this=3D0x7fffffa45eb8, f=3D@0x7fffffa45ea8, a=3D@0x7fffffa45d7f) at bind= .hpp:232 > #7 =A00x0000000000411696 in boost::_bi::bind_t Client>, boost::_bi::list1 > >::operator() > (this=3D0x7fffffa45ea8) at bind_template.hpp:20 > #8 =A00x00000000004116bd in > boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf0, boost::_bi::list1 >> >, void>::invoke ( > =A0 function_obj_ptr=3D@0x7fffffa45ea8) at function_template.hpp:158 > #9 =A00x000000000042e73a in boost::function0 >>::operator() (this=3D0x7fffffa45ea0) at function_template.hpp:825 > #10 0x0000000000435760 in oxt::thread::thread_main (func=3D@0x7fffffa45ea= 0, > data=3D@0x7fffffa45e90) at thread.hpp:107 > #11 0x000000000041310e in > boost::_bi::list2 std::allocator > >, > boost::_bi::value > >>::operator() >, > boost::shared_ptr), boost::_bi::list0> > (this=3D0x800f3ee80, f=3D@0x800f3ee78, a=3D@0x7fffffa45f0f) at bind.hpp:2= 89 > #12 0x0000000000413196 in boost::_bi::bind_t (*)(boost::function >, > boost::shared_ptr), > boost::_bi::list2 std::allocator > >, > boost::_bi::value > > >>::operator() (this=3D0x800f3ee78) at bind_template.hpp:20 > #13 0x00000000004131b9 in > boost::thread::thread_data (*)(boost::function >, > boost::shared_ptr), > boost::_bi::list2 std::allocator > >, > boost::_bi::value > > > >::ru= n > (this=3D0x800f3ee00) at thread.hpp:130 > #14 0x0000000000443259 in thread_proxy (param=3D0x800f3ee00) at > ext/boost/src/pthread/thread.cpp:127 > #15 0x0000000800b1badd in thread_start (curthread=3D0x800f06600) at > /usr/src/lib/libthr/thread/thr_create.c:288 > #16 0x0000000000000000 in ?? () > Cannot access memory at address 0x7fffffa46000 > Current language: =A0auto; currently asm > > It seems that in the passenger client threads it calls closeStream which > errors when > the socket close errors with ENOTCONN > =A0 =A0 =A0 virtual void closeStream() { > =A0 =A0 =A0 =A0 =A0 TRACE_POINT(); > =A0 =A0 =A0 =A0 =A0 if (fd !=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 int ret =3D syscalls::close(fd); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 fd =3D -1; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret =3D=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (errno =3D=3D EIO) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 throw SystemException("A writ= e operation on the > session stream failed", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errno); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 throw SystemException("Cannot= close the session > stream", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errno); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 } > > This causes it to call abort on the the thread which then crashes the app > with > the above stack trace, which seems really weird. Anyone got any ideas? > > =A0 Regards > =A0 steve Steve, The patch for PR 144061 works for us. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.htm= l http://www.freebsd.org/cgi/query-pr.cgi?pr=3D144061 Matt From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 11:39:58 2010 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 160D4106566C for ; Sat, 8 May 2010 11:39:58 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id CE33C8FC1E for ; Sat, 8 May 2010 11:39:57 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OAhzy-0005ts-5J for freebsd-hackers@freebsd.org; Sat, 08 May 2010 11:15:10 +0000 Date: Sat, 8 May 2010 14:15:09 +0300 From: Ali Polatel To: freebsd-hackers@freebsd.org Message-ID: <20100508111509.GB8186@harikalardiyari> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Ability to tell the difference between normal and syscall traps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 11:39:58 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Does FreeBSD's ptrace have a way to tell the difference between normal traps and those caused by a system call? On Linux=B9 this is possible by passing PTRACE_O_TRACESYSGOOD option to the ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the syscall number when delivering system call traps, (i.e., deliver (SIGTRAP | 0x80)). I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks related but can't be sure. =B9: http://linux.die.net/man/2/ptrace --=20 Regards, Ali Polatel --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvlR70ACgkQQU4yORhF8iCx3gCgpUf/8eYvPKBnfN8onbzuhPGw 66sAoLIjdjLdq33XBiIy+9p8j/3DxOAA =yN3P -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 12:36:34 2010 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 E1AF31065672 for ; Sat, 8 May 2010 12:36:34 +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 5D59E8FC08 for ; Sat, 8 May 2010 12:36:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o48CaT9F071678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 May 2010 15:36:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o48CaTmb096601; Sat, 8 May 2010 15:36:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o48CaQF8096600; Sat, 8 May 2010 15:36:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 May 2010 15:36:26 +0300 From: Kostik Belousov To: Ali Polatel Message-ID: <20100508123626.GC83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <20100508111509.GB8186@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 12:36:35 -0000 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > Does FreeBSD's ptrace have a way to tell the difference between normal > traps and those caused by a system call? >=20 > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to the > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the > syscall number when delivering system call traps, > (i.e., deliver (SIGTRAP | 0x80)). >=20 > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks > related but can't be sure. >=20 > ?: http://linux.die.net/man/2/ptrace There is already procfs(5)-based interface to get a reason for stop. Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. The interface can be lifted to ptrace(2), but I think using the capacity of procfs is not wrong there. --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvlWsoACgkQC3+MBN1Mb4ipZACcDTTw2Zy/whf/WscIEfyCiU35 5+gAoJz9AbZTCeR8KjW5wCJyIpLPJeMO =arWV -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 14:47:29 2010 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 36EA11065672 for ; Sat, 8 May 2010 14:47:29 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id ED2478FC12 for ; Sat, 8 May 2010 14:47:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OAlJP-0006Ss-9K; Sat, 08 May 2010 14:47:27 +0000 Date: Sat, 8 May 2010 17:47:25 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100508144725.GC8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <20100508123626.GC83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 14:47:29 -0000 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > Does FreeBSD's ptrace have a way to tell the difference between normal > > traps and those caused by a system call? > >=20 > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to t= he > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the > > syscall number when delivering system call traps, > > (i.e., deliver (SIGTRAP | 0x80)). > >=20 > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks > > related but can't be sure. > >=20 > > ?: http://linux.die.net/man/2/ptrace >=20 > There is already procfs(5)-based interface to get a reason for stop. > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. >=20 > The interface can be lifted to ptrace(2), but I think using the capacity > of procfs is not wrong there. Thanks, although not optimal, this solution works for me :-) --=20 Regards, Ali Polatel --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvleX0ACgkQQU4yORhF8iBWCQCfUPIsE9xqRSqBtmrrTZxkOlPG CgMAoJG2R79OMaqlPRPIVXaypQ1WhMwz =pjdd -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 16:23:17 2010 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 26575106566C; Sat, 8 May 2010 16:23:17 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 912458FC14; Sat, 8 May 2010 16:23:16 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:16:47 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:16:47 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010221205.msg; Sat, 08 May 2010 17:16:47 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <729F67D8486E42A99F38592C642D74AE@multiplay.co.uk> From: "Steven Hartland" To: "Matt Reimer" References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> Date: Sat, 8 May 2010 17:16:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 16:23:17 -0000 As you may have guessed by my last reply no we didn't we had to revert to apache + passenger, but seems you've found a fix anyway. Out of interest what lead you to the close race condition PR as a potential fix? ----- Original Message ----- From: "Matt Reimer" Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 16:23:17 2010 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 2D0611065670; Sat, 8 May 2010 16:23:17 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 958408FC15; Sat, 8 May 2010 16:23:16 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:13:01 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:13:01 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010221189.msg; Sat, 08 May 2010 17:13:00 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4D0732ED9A714C7EA6B004E852F0D695@multiplay.co.uk> From: "Steven Hartland" To: "Matt Reimer" References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk><20091209102122.GC43143@deviant.kiev.zoral.com.ua><3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> Date: Sat, 8 May 2010 17:12:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart onFreeBSD8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 16:23:17 -0000 Thanks Matt most appreciated! ----- Original Message ----- From: "Matt Reimer" Steve, The patch for PR 144061 works for us. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html http://www.freebsd.org/cgi/query-pr.cgi?pr=144061 ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat May 8 22:14:26 2010 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 BD2721065674 for ; Sat, 8 May 2010 22:14:26 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 98FBF8FC1F for ; Sat, 8 May 2010 22:14:26 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o48MJDRe061550; Sat, 8 May 2010 15:19:14 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4BE5E241.2030604@mahan.org> Date: Sat, 08 May 2010 15:14:25 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: =?UTF-8?B?THVrw6HFoSBDemVybmVy?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: How to get data from kernel module ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 May 2010 22:14:26 -0000 Luk=C3=A1=C5=A1 Czerner wrote: > Hi, >=20 > I am creating a kernel module and I need to get some information from > that module. I can do this with ioctl and pass the data to the > user space but it seems a bit unpractical to me, because I do not know = > the amount of the data - it can differ. I do not know of any way to > pass a list of structures to the userspace through ioctl - is there > any? >=20 > So my question is, is there any standard way in FreeBSD to do this ? > In linux I would probably use the sysfs, but in FreeBSD I can not find > anything similar, except just creating some virtual filesystem on my > own and obviously this is not what I want to do. >=20 You could use ioctl(). You will need to make two calls. Once without the data pointer and once with. Take a look at src/sbin/ifconfig/ifmedia.c Take a look at sysctl(3) in particular, if you have the sources online look at src/usr.bin/netstat/inet.c or src/usr.bin/netstat/route.c. You will need to also look at their corresponding kernel code. Or finally, you could use kvm(3). Good luck, Patrick