From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 08:39:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61395106566C for ; Sun, 17 May 2009 08:39:48 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id E3C3C8FC14 for ; Sun, 17 May 2009 08:39:47 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fxm12 with SMTP id 12so2679899fxm.43 for ; Sun, 17 May 2009 01:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=aimK/W5lAMroxFVhORtGnnYZMNMBiQ3bJQxoS/GtM0Y=; b=wH7zIOsok6byi570bJyRVmqjRHEvh/U6rBrcTn0vONjthaMbem0FrcBlo2oYf5lqv7 KqJ1qmRX7C/EXlpqlXhddGLPMwmt/7P7lPBj74lGA4PWveMnmPa8l2VJdYd90cU1XJMw pszuZ55+clCLu/xbD/cNIczd0lyiMgbFkoXYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=wtc8IT2h4DeFXBgb/3vPNZT3xzQS3Eqnsro+kEKoUOXDpT3q6rFREkMPTSM69Fku9X 1VJBfKlhOh4NskO/rrIDyllrDStGm7L8FxlI4C4rVEU4HK2hzwqftuPZ8WujFq6XLaPh 39AlJnDxXOYNVXbnRzm6KslIxLHir47Zg3yEM= Received: by 10.86.86.2 with SMTP id j2mr5558405fgb.74.1242549585789; Sun, 17 May 2009 01:39:45 -0700 (PDT) Received: from localhost ([95.69.161.2]) by mx.google.com with ESMTPS id 4sm2543755fge.13.2009.05.17.01.39.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 01:39:45 -0700 (PDT) To: freebsd-hackers@freebsd.org References: <814ovqn8dp.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 17 May 2009 11:39:43 +0300 In-Reply-To: <814ovqn8dp.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 12 May 2009 09\:27\:30 +0300") Message-ID: <86d4a8unqo.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Memory leak on thread removal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 08:39:48 -0000 On Tue, 12 May 2009 09:27:30 +0300 Mikolaj Golub wrote: MG> Hi, MG> The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386, amd64): MG> #include MG> #include MG> int n = 4, m = 2; MG> int main () { MG> for (;;) { MG> int i; MG> //sleep(2); MG> #pragma omp parallel for num_threads(m) MG> for(i = 0; i < 1; i++) {} MG> //sleep(2); MG> #pragma omp parallel for num_threads(n) MG> for(i = 0; i < 1; i++) {} MG> MG> } MG> return 0; MG> } MG> During the run the program's virtual memory usage constantly grows. The growth MG> is observed only when n != m. When running the program with uncommented MG> sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4 MG> threads. So it looks like memory leak when thread is removed. Should I fill MG> PR? Reported. http://www.freebsd.org/cgi/query-pr.cgi?pr=134604 -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 10:22:11 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 573C01065672 for ; Sun, 17 May 2009 10:22:11 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 0868C8FC21 for ; Sun, 17 May 2009 10:22:11 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id C885C8FC4E for ; Sun, 17 May 2009 14:22:08 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 875648FC18; Sun, 17 May 2009 14:22:03 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id B7A4439830; Sun, 17 May 2009 14:22:36 +0400 (MSD) Date: Sun, 17 May 2009 14:22:31 +0400 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20090517142231.2968f311.stas@FreeBSD.org> In-Reply-To: <20090501.081229.1359784281.imp@bsdimp.com> References: <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun May 17 14:22:08 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4a0fe550994292383363236 Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org, christoph.mallon@gmx.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 10:22:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 01 May 2009 08:12:29 -0600 (MDT) "M. Warner Losh" mentioned: > > This is a religious point, and we're dangerously close to saying my > religion is better than your religion. I don't like this part of the > proposal at all. I can see the value in relaxing it for when you have > a series of variables that are initialized, but relaxing it to the > point where you intermix code and declarations goes way too far. It > is bad enough to have to deal with inner scopes, but tolerable. It is > intolerable to have to look for it anywhere in a big function. It > tends to encourage spaghetti code, which is one of the things that > style(9) tries to discourage in many subtle ways. > Seconded. Furthermore, when declaring the every advanced editor supports jumping to variables declarations, Christoph ignored the point that the code gets written for people and not for compilers and editors. Last ones can live without any style at all, people can't. The thing people love about BSD code is that it is always perfectly known where to look for declarations and specific parts of the code. Strict style implies a lot of implicit knowledge, so you don't have to study a piece of code for a long time before you understand how it works in general. By relaxing style(9) we're in danger of loosing this benefit. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoP5WwACgkQK/VZk+smlYFocACfTzVHRpQb8H3tAeg97ljqn3bv DZ4An2iOQXXjTNWpivyHrGR3sBaeOfmJ =qz0I -----END PGP SIGNATURE----- !DSPAM:4a0fe550994292383363236! From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 10:30:06 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6CF10656CD for ; Sun, 17 May 2009 10:30:06 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF068FC1C for ; Sun, 17 May 2009 10:30:06 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 155A88FC51 for ; Sun, 17 May 2009 14:30:04 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id F25288FC18; Sun, 17 May 2009 14:30:03 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 82F5E39830; Sun, 17 May 2009 14:30:37 +0400 (MSD) Date: Sun, 17 May 2009 14:30:37 +0400 From: Stanislav Sedov To: Christoph Mallon Message-Id: <20090517143037.9c62ef1f.stas@FreeBSD.org> In-Reply-To: <49FBF5F7.7000600@gmx.de> References: <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> <20090501.083712.396385864.imp@bsdimp.com> <49FBF5F7.7000600@gmx.de> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun May 17 14:30:04 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4a0fe72c994292017410001 Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 10:30:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 02 May 2009 09:27:51 +0200 Christoph Mallon mentioned: > I also have to object, that it leads to hunting for declarations. > Actually it usually reduces scrolling around in the code: Many variables > are only assigned once. A typical example is getting the softc of a > device; especially there the type is important, because > device_get_softc() returns void*. So it is very convenient to have this > single assignment and its declaration at the same place. Not only the > type of a variable is important, but also its value, so this assignment > needs to be looked up, too. Doing declaration and initialisation at once > you only have to look at one place instead of two. If you use vim as > editor, then the current way makes it hard to find this assignment: "gd" > jumps only to the declaration, the assignment is somewhere else. But if > the declaration and the only assignment are the same, you get both at > the same place and time. You're talking about automatic text processing tools, which is an entirely different subject. If your current tool can't handle the code, it may be the time to improve the tool or change it. Tools can be improved, people can't. By 'hunting for declarations' it usually meant that it is hard to find pieces of the code by looking into it, not that tools can't handle the task. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoP500ACgkQK/VZk+smlYGO7QCeM3HRKTMqp54SIo28eBN86vc5 fZcAniVfL+cY4rhP/ulp0MQFbxD+twwL =hJYk -----END PGP SIGNATURE----- !DSPAM:4a0fe72c994292017410001! From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 10:44:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3E6106566B for ; Sun, 17 May 2009 10:44:46 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7488FC1A for ; Sun, 17 May 2009 10:44:46 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 639D18FC1D for ; Sun, 17 May 2009 14:44:45 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id BDA3B8FC18; Sun, 17 May 2009 14:44:42 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 2473339830; Sun, 17 May 2009 14:45:16 +0400 (MSD) Date: Sun, 17 May 2009 14:45:16 +0400 From: Stanislav Sedov To: Christoph Mallon Message-Id: <20090517144516.331b01a8.stas@FreeBSD.org> In-Reply-To: <49FAE4EA.1010205@gmx.de> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun May 17 14:44:45 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4a0fea9d994295559415935 Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 10:44:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 01 May 2009 14:02:50 +0200 Christoph Mallon mentioned: > > [Don't parenthesize return values] > >> Removed, because it does not improve maintainability in any way. > > > > This change could be made and tested mechanically. But there is > > no justification for making it - stating that the existing rule > > is no better than the proposed rule is no reason to change. > > Just remove the rule. There's no need to add more redundant parentheses. > Again: There is no need to change all existing code at once, but the > rule is removed so that not anymore redundant parentheses are added. If only the rule gets removed this will lead to inconsistent code. Currently it is much easier to experienced leader to notice return statements with parenthesis around the value than without. Recall that people's eyes are build in way that they recognized entire expressions and not letter combinations. > > [ Don't insert an empty line if the function has no local variables.] > > > > This change could be made and tested mechanically. IMHO, this change > > has neglible risk and could be safely implemented. > > Again: No need for immediate global change, but just do not add anymore > of those. There are already quite some functions, which do not have the > unnecessary empty line. > What seems to you as unnecessary rule may be of a great use for other code users. For me it improves the code readability as an empty line at the start clearly points that there're no local variables used. I don't see enough argumentation for removing this rule. > >>> +.Sh LOCAL VARIABLES > > > >> Last, but definitely not least, I added this paragraph about the use of > >> local variables. This is to clarify, how today's compilers handle > >> unaliased local variables. > > > > Every version of gcc that FreeBSD has ever used would do this for > > primitive types when optimisation was enabled. This approach can > > become expensive in stack (and this is an issue for kernel code) when > > using non-primitive types or when optimisation is not enabled (though > > I'm not sure if this is supported). Assuming that gcc (and icc and > > clang) behaves as stated in all supported optimisation modes, this > > change would appear to be quite safe to make. > > Most local variables are scalars (pointers, ints, ...). A struct or > array as local variable is rare and then usually used in one context. So > IMO this is fine. Even considereing the extremly rare case of multiple > non-scalar declarations in a function, then a compiler can coalesce them > if their life ranges are disjoint. It is easier to do so for a compiler > to do so, if they are declared with smaller life ranges, example: > > struct Foo { int x[16]; }; > struct Bar { int* y[16]; }; > > void f(struct Foo*); > void g(struct Bar*); > > void e(int x) > { > struct Foo a; > struct Bar b; > if (x) { > f(&a); > } else { > g(&b); > } > } > > Stack usage: > subl $140, %esp > > moving the declarations into the branches: > subl $76, %esp > > So, apart from improved readability, it also can lead to better code. > But I consider the latter way less important the benefits observed by a > reader of the code. > I particulary like this change. Aliasing behavior is stritcly described in ISO C99 standard, so there's a good point to enforcing strict-aliasing clear code in our kernel. On the other hand the big work should be done on clearing the existing code before any rule on this can be enforced. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoP6rwACgkQK/VZk+smlYHdAACeJo64Mc0syCLtXq93yg0f87Y7 T2kAn1gLof6OMcHHs3EbRYTx7QE5NwU8 =5waq -----END PGP SIGNATURE----- !DSPAM:4a0fea9d994295559415935! From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 10:53:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D121065674 for ; Sun, 17 May 2009 10:53:03 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 946358FC21 for ; Sun, 17 May 2009 10:53:03 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 5496B8FC51 for ; Sun, 17 May 2009 14:53:02 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id D7E4C8FC18; Sun, 17 May 2009 14:52:59 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 03E9C39830; Sun, 17 May 2009 14:53:32 +0400 (MSD) Date: Sun, 17 May 2009 14:53:31 +0400 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20090517145331.fda0f91f.stas@FreeBSD.org> In-Reply-To: <20090501.082020.698246310.imp@bsdimp.com> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> <20090501.082020.698246310.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun May 17 14:53:02 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4a0fec8e994291872371064 Cc: sobomax@freebsd.org, freebsd-hackers@freebsd.org, rdivacky@freebsd.org, ed@freebsd.org, marius@alchemy.franken.de, christoph.mallon@gmx.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 10:53:04 -0000 On Fri, 01 May 2009 08:20:20 -0600 (MDT) "M. Warner Losh" mentioned: > > It is a debugging aid, but one of dubious value for a far more > fundamental reason: > > return; > > will break any macro. > You can use variadic marcos in this case if the piece of code debugged uses void returns. -- Stanislav Sedov ST4096-RIPE !DSPAM:4a0fec8e994291872371064! From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 12:32:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A5691065673 for ; Sun, 17 May 2009 12:32:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A10878FC16 for ; Sun, 17 May 2009 12:32:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 17 May 2009 12:32:03 -0000 Received: from p54A3C65F.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.198.95] by mail.gmx.net (mp019) with SMTP; 17 May 2009 14:32:03 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19RWZhcvgRRHfTS/zELeAbjNG05HHM5+9iaLpO4tl 7C5XyUOaQ9gRqK Message-ID: <4A1003C2.8070901@gmx.de> Date: Sun, 17 May 2009 14:32:02 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Stanislav Sedov References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> <20090501.082020.698246310.imp@bsdimp.com> <20090517145331.fda0f91f.stas@FreeBSD.org> In-Reply-To: <20090517145331.fda0f91f.stas@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: sobomax@freebsd.org, freebsd-hackers@freebsd.org, rdivacky@freebsd.org, ed@freebsd.org, marius@alchemy.franken.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 12:32:05 -0000 Stanislav Sedov schrieb: > On Fri, 01 May 2009 08:20:20 -0600 (MDT) > "M. Warner Losh" mentioned: >> It is a debugging aid, but one of dubious value for a far more >> fundamental reason: >> >> return; >> >> will break any macro. >> > > You can use variadic marcos in this case if the piece of code debugged > uses void returns. No, you cannot. Function like macros with ellipsis ("variadic macros") cannot be treated as object like macros. See ISO/IEC 9899:1999 (E) §6.10.3:4. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 12:36:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190E5106564A for ; Sun, 17 May 2009 12:36:06 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 80D0E8FC1D for ; Sun, 17 May 2009 12:36:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 17 May 2009 12:36:04 -0000 Received: from p54A3C65F.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.198.95] by mail.gmx.net (mp061) with SMTP; 17 May 2009 14:36:04 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+vq5QXI6uvE1zLS/pyy28bcWlS6frnsuyt4SasM3 tgq19RiPgLYUZg Message-ID: <4A1004B3.5040805@gmx.de> Date: Sun, 17 May 2009 14:36:03 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Stanislav Sedov References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> <20090517144516.331b01a8.stas@FreeBSD.org> In-Reply-To: <20090517144516.331b01a8.stas@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 12:36:06 -0000 Stanislav Sedov schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 01 May 2009 14:02:50 +0200 > Christoph Mallon mentioned: > >>> [Don't parenthesize return values] >>>> Removed, because it does not improve maintainability in any way. >>> This change could be made and tested mechanically. But there is >>> no justification for making it - stating that the existing rule >>> is no better than the proposed rule is no reason to change. >> Just remove the rule. There's no need to add more redundant parentheses. >> Again: There is no need to change all existing code at once, but the >> rule is removed so that not anymore redundant parentheses are added. > > If only the rule gets removed this will lead to inconsistent code. Currently > it is much easier to experienced leader to notice return statements with > parenthesis around the value than without. Recall that people's eyes are > build in way that they recognized entire expressions and not letter > combinations. I don't buy this for a simple reason: Parentheses are in many statements (if, while, for). The only thing which distinguishs a return statement from others is the word "return". >>>>> +.Sh LOCAL VARIABLES >>>> Last, but definitely not least, I added this paragraph about the use of >>>> local variables. This is to clarify, how today's compilers handle >>>> unaliased local variables. >>> Every version of gcc that FreeBSD has ever used would do this for >>> primitive types when optimisation was enabled. This approach can >>> become expensive in stack (and this is an issue for kernel code) when >>> using non-primitive types or when optimisation is not enabled (though >>> I'm not sure if this is supported). Assuming that gcc (and icc and >>> clang) behaves as stated in all supported optimisation modes, this >>> change would appear to be quite safe to make. >> Most local variables are scalars (pointers, ints, ...). A struct or >> array as local variable is rare and then usually used in one context. So >> IMO this is fine. Even considereing the extremly rare case of multiple >> non-scalar declarations in a function, then a compiler can coalesce them >> if their life ranges are disjoint. It is easier to do so for a compiler >> to do so, if they are declared with smaller life ranges, example: >> >> struct Foo { int x[16]; }; >> struct Bar { int* y[16]; }; >> >> void f(struct Foo*); >> void g(struct Bar*); >> >> void e(int x) >> { >> struct Foo a; >> struct Bar b; >> if (x) { >> f(&a); >> } else { >> g(&b); >> } >> } >> >> Stack usage: >> subl $140, %esp >> >> moving the declarations into the branches: >> subl $76, %esp >> >> So, apart from improved readability, it also can lead to better code. >> But I consider the latter way less important the benefits observed by a >> reader of the code. >> > > I particulary like this change. Why? > Aliasing behavior is stritcly described in > ISO C99 standard, so there's a good point to enforcing strict-aliasing clear > code in our kernel. If you like this addition because of this reason, I have to disappoint you: This addition has absolutly *nothing* to do with strict-aliasing. > On the other hand the big work should be done on clearing > the existing code before any rule on this can be enforced. This addition is about improving readability for humans, because it simplifies the def-use-chains, and as a side effect sometimes leads to better generated code. It is not sensible to check millions of lines of code whether a variables are used in different contexts within a function before this can added. Anyway, this is moot, because this thread was dead because every suggested improvement was rejected - especially this last improvement was rejected by the guy who requested it in the first place. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 15:42:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC6B1065675 for ; Sun, 17 May 2009 15:42:40 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by mx1.freebsd.org (Postfix) with ESMTP id 750378FC0C for ; Sun, 17 May 2009 15:42:36 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fxm12 with SMTP id 12so2791386fxm.43 for ; Sun, 17 May 2009 08:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=2JLJ7iQ6EuDPcvD5Kx8HYWIgOx+6yhGAKIYnRj8OBGc=; b=WhGJc6WRIVwKbRaCMReR+Vq1yOVwzl0OjGmHeWzMZrdpvma10FA83AWT1B2X68x6CB eDrC65AHWhTGdCqfVaOSfxJT78qNxYUoxXLQXk4nZ+T846w4rIaRGc/5tVAp7taGfxtL M0ohKNF1RaQAti+Xus1d7ib6spyckfusnr+CA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=UAgRlCClYk4C4R4jKx9UMGWel8r6vJm+ZS9A7+WOm+rqjW6vwpMVRt7zNb5CEUAHc0 xL5gcwpJkdeunk7NgIUBvOvvLx8Hj5Vwaiju7xxN9w8c//v/OgURHcm8AlFmDJsTRq5a izavBLsQidzs3pcIJ3L1DJH9AA8vGXNBC+XMk= Received: by 10.86.33.9 with SMTP id g9mr5823912fgg.66.1242574955383; Sun, 17 May 2009 08:42:35 -0700 (PDT) Received: from localhost ([95.69.175.115]) by mx.google.com with ESMTPS id 3sm3067801fge.4.2009.05.17.08.42.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 08:42:34 -0700 (PDT) To: Marius =?iso-8859-1?Q?N=FCnnerich?= References: <814ovqn8dp.fsf@zhuzha.ua1> <86k54hvuzv.fsf@kopusha.onet> Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 17 May 2009 18:42:31 +0300 In-Reply-To: ("Marius =?iso-8859-1?Q?N=FCnnerich=22's?= message of "Sat\, 16 May 2009 20\:24\:09 +0200") Message-ID: <864ovjviqg.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Memory leak on thread removal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 15:42:41 -0000 On Sat, 16 May 2009 20:24:09 +0200 Marius N=FCnnerich wrote: >> http://freshmeat.net/projects/lmdbg >> >> This is a small memory leak debugger. It does not provide all functiona= lity >> you can find in more sophisticated tools but is lightweight, portable a= nd >> simple in use. It was very useful when I traced this bug. MN> Thanks, I'll take a look at it. Today I submitted lmdbg port. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D134617 At present it is waiting to be committed in ports tree, but you can use shar from the PR to build the port yourself. --=20 Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 16:04:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5068E1065670 for ; Sun, 17 May 2009 16:04:28 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 032638FC1A for ; Sun, 17 May 2009 16:04:28 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id E568D8FC1D for ; Sun, 17 May 2009 20:04:25 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 60A5A8FC18; Sun, 17 May 2009 20:04:24 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id D832B3982B; Sun, 17 May 2009 20:04:56 +0400 (MSD) Date: Sun, 17 May 2009 20:04:56 +0400 From: Stanislav Sedov To: Christoph Mallon Message-Id: <20090517200456.cefa04fb.stas@FreeBSD.org> In-Reply-To: <4A1004B3.5040805@gmx.de> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> <20090517144516.331b01a8.stas@FreeBSD.org> <4A1004B3.5040805@gmx.de> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun May 17 20:04:25 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4a103589994292021119546 Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 16:04:28 -0000 On Sun, 17 May 2009 14:36:03 +0200 Christoph Mallon mentioned: > > > Aliasing behavior is stritcly described in > > ISO C99 standard, so there's a good point to enforcing strict-aliasing clear > > code in our kernel. > If you like this addition because of this reason, I have to disappoint > you: This addition has absolutly *nothing* to do with strict-aliasing. > I didn't meant I like this change only from aliasing point of view: certianly, the code readability argument is very important. But this change also works towards the strict aliasing problem solving too: there's just a less chance someone will reuse a variable, address of which was previously taken. > > On the other hand the big work should be done on clearing > > the existing code before any rule on this can be enforced. > This addition is about improving readability for humans, because it > simplifies the def-use-chains, and as a side effect sometimes leads to > better generated code. It is not sensible to check millions of lines of > code whether a variables are used in different contexts within a > function before this can added. > -- Stanislav Sedov ST4096-RIPE !DSPAM:4a103589994292021119546! From owner-freebsd-hackers@FreeBSD.ORG Sun May 17 16:41:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E6D106566C for ; Sun, 17 May 2009 16:41:17 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A97308FC0C for ; Sun, 17 May 2009 16:41:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 17 May 2009 16:41:14 -0000 Received: from p54A3C65F.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.198.95] by mail.gmx.net (mp013) with SMTP; 17 May 2009 18:41:14 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+o+HElkfOoTEFe1Q0D+Wm8VyIGBTu9VUr+YqfSCk rnta1kESQsmGyD Message-ID: <4A103E29.4040309@gmx.de> Date: Sun, 17 May 2009 18:41:13 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Stanislav Sedov References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> <20090517144516.331b01a8.stas@FreeBSD.org> <4A1004B3.5040805@gmx.de> <20090517200456.cefa04fb.stas@FreeBSD.org> In-Reply-To: <20090517200456.cefa04fb.stas@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 May 2009 16:41:17 -0000 Stanislav Sedov schrieb: > On Sun, 17 May 2009 14:36:03 +0200 > Christoph Mallon mentioned: > >>> Aliasing behavior is stritcly described in >>> ISO C99 standard, so there's a good point to enforcing strict-aliasing clear >>> code in our kernel. >> If you like this addition because of this reason, I have to disappoint >> you: This addition has absolutly *nothing* to do with strict-aliasing. >> > > I didn't meant I like this change only from aliasing point of view: certianly, > the code readability argument is very important. But this change also > works towards the strict aliasing problem solving too: there's just > a less chance someone will reuse a variable, address of which was > previously taken. Something like this would violate strict-aliasing: int i; short* p = (short*)&i; A short pointer may never point at an int object (ISO/IEC 9899:1999 (E) §6.5:7). The suggested paragraph has nothing to do with strict-aliasing. It's "just" about reusing the same variable in different contexts. Reusing the same variable in different contexts is bad, because it's harder for a human reader to identify the def-use-chains and additionally if the address of the variable has escaped (just a "normal" alias problem, nothing about type-punning and strict-aliasing) the generated code will be worse. Please, can we stop this now? It was already rejected. It's a pity, but maintaining status quo for style(9) seems to be too holy. *sigh* Christoph From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 08:48:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D8EC106566B for ; Mon, 18 May 2009 08:48:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id AA0A88FC08 for ; Mon, 18 May 2009 08:48:34 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so3734564ewy.43 for ; Mon, 18 May 2009 01:48:34 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=lLjLSBdjVK0EKoFdvMc0tx5owr0jgWcpL+zQ0l6E+pI=; b=sh/Pkjl0412QwsjaD4t6DXNBTiYVes1m1hFrZXCfPcKGEdF1KLx/BnMRrmg0+4hx+T 7CC1PxIZQd3Yh4CYDnp2yrSFFZZJn7bGLQ4nG93gCqZ31dYP03nO9NziFv6oaQMcnfyK rWnZWxETN35EeVfdhNTJkFVX3mpWL+0CoyEDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=Y/W5sjPCvL0MH22lH5GR+OXDYOqIXTEgdFC/69DNg0mKvfXLtA2kZHdEUOdPz+8DGi W+E8nBABAwZMLpQ/B9cskm0YgiWJEb460gr3rUpc/edFtmNYJo3dIBxetPaxgBgVVrum zOYfi3eyM/JLVWalB3Lsobf1TyY1iZbBVBxAk= Received: by 10.210.53.1 with SMTP id b1mr291336eba.31.1242636514074; Mon, 18 May 2009 01:48:34 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 8sm5754905ewy.13.2009.05.18.01.48.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 May 2009 01:48:33 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 804EA5D59; Mon, 18 May 2009 08:48:31 +0000 (UTC) Date: Mon, 18 May 2009 09:48:31 +0100 From: xorquewasp@googlemail.com To: Daniel Eischen Message-ID: <20090518084831.GA95354@logik.internal.network> References: <20090504185644.GA16315@logik.internal.network> <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090508211022.GA37475@logik.internal.network> Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 May 2009 08:48:37 -0000 Hi. After a week off, another update: I've realised, too late, that I'm using a version of binutils (2.19) that's incompatible with the system binutils (2.15). Specifically, assembler code emitted by the native GNAT contains .cfi_personality directives (and no doubt other things too) that can't be processed by the system 'as'. I've got two choices now and would appreciate some advice on which to take given that I want to produce a FreeBSD port: 1. Compile binutils-2.15. Unfortunately, compiling these as cross-binutils appear to be problematic: gmake[3]: Entering directory `/root/memfs/c1-bu-obj/gas' gcc -DHAVE_CONFIG_H -I. -I/root/binutils-2.15/gas -I. -D_GNU_SOURCE -I. -I/root/binutils-2.15/gas -I../bfd -I/root/binutils-2.15/gas/config -I/root/binutils-2.15/gas/../include -I/root/binutils-2.15/gas/.. -I/root/binutils-2.15/gas/../bfd -I/root/binutils-2.15/gas/../intl -I../intl -DLOCALEDIR="\"/cross/x86_64/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c /root/binutils-2.15/gas/app.c In file included from /root/binutils-2.15/gas/as.h:94, from /root/binutils-2.15/gas/app.c:30: /root/binutils-2.15/gas/../include/getopt.h:116: warning: function declaration isn't a prototype In file included from ./targ-cpu.h:1, from /root/binutils-2.15/gas/config/obj-elf.h:42, from ./obj-format.h:1, from /root/binutils-2.15/gas/config/te-freebsd.h:30, from ./targ-env.h:1, from /root/binutils-2.15/gas/as.h:626, from /root/binutils-2.15/gas/app.c:30: /root/binutils-2.15/gas/config/tc-i386.h:451: error: array type has incomplete element type gmake[3]: *** [app.o] Error 1 gmake[3]: Leaving directory `/root/memfs/c1-bu-obj/gas' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/root/memfs/c1-bu-obj/gas' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/root/memfs/c1-bu-obj/gas' gmake: *** [all-gas] Error 2 2. Continue to use binutils-2.19. This would appear to require me to create a binutils-2.19 port just for the GNAT compiler. Seems like it would be preferable to use the system binutils rather than to take this route... xw From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 10:07:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F16E2106564A for ; Mon, 18 May 2009 10:07:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 756AF8FC17 for ; Mon, 18 May 2009 10:07:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so3771968ewy.43 for ; Mon, 18 May 2009 03:07:36 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=wEQdxu8v6SGXpJd2Tl5OCjA5+buSOZfgQgYAQpGBexs=; b=qKplTuGZ3GDCup7Zd3BOhzOVxfLjVjNYVwzYf0igcohxLox/n4Ff6fYceH/xPZrXD1 9xX6CBsaaxFggm0A/bRFuNuH5SEVvxZ8CxgS2srAkOhg2WdSKp3p3PAinOSAdmUO1cQo TyQMhzRNFmTjfc1RpqL5nlQNJs6ryWXOM/SME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=bE883uh3aHbG1b9VksQj4NbJglu38A2UMneA+IPGGsvAXVlx1UgDetz28E4Vcuc8Y0 GZdmJRHZj1WtUhUITnbML1lqetFlqE2tc8pZ2XH2NMflHJ6DKfDv+A/HQ4i2hbeU7RoN jmi7U5MG/5AcWlpBYwff5PtYU0+UkeWLw9rGA= Received: by 10.210.115.17 with SMTP id n17mr2949268ebc.94.1242641256488; Mon, 18 May 2009 03:07:36 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 1sm4827572ewy.5.2009.05.18.03.07.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 May 2009 03:07:35 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 3C2E65D59; Mon, 18 May 2009 10:07:34 +0000 (UTC) Date: Mon, 18 May 2009 11:07:34 +0100 From: xorquewasp@googlemail.com To: Daniel Eischen Message-ID: <20090518100734.GA36229@logik.internal.network> References: <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090518084831.GA95354@logik.internal.network> Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 May 2009 10:07:38 -0000 On 2009-05-18 09:48:31, xorquewasp@googlemail.com wrote: > 1. Compile binutils-2.15. > > Unfortunately, compiling these as cross-binutils appear to be problematic: > > gmake[3]: Entering directory `/root/memfs/c1-bu-obj/gas' > gcc -DHAVE_CONFIG_H -I. -I/root/binutils-2.15/gas -I. -D_GNU_SOURCE -I. -I/root/binutils-2.15/gas -I../bfd -I/root/binutils-2.15/gas/config -I/root/binutils-2.15/gas/../include -I/root/binutils-2.15/gas/.. -I/root/binutils-2.15/gas/../bfd -I/root/binutils-2.15/gas/../intl -I../intl -DLOCALEDIR="\"/cross/x86_64/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c /root/binutils-2.15/gas/app.c > In file included from /root/binutils-2.15/gas/as.h:94, > from /root/binutils-2.15/gas/app.c:30: > /root/binutils-2.15/gas/../include/getopt.h:116: warning: function declaration isn't a prototype > In file included from ./targ-cpu.h:1, > from /root/binutils-2.15/gas/config/obj-elf.h:42, > from ./obj-format.h:1, > from /root/binutils-2.15/gas/config/te-freebsd.h:30, > from ./targ-env.h:1, > from /root/binutils-2.15/gas/as.h:626, > from /root/binutils-2.15/gas/app.c:30: > /root/binutils-2.15/gas/config/tc-i386.h:451: error: array type has incomplete element type > gmake[3]: *** [app.o] Error 1 > gmake[3]: Leaving directory `/root/memfs/c1-bu-obj/gas' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/root/memfs/c1-bu-obj/gas' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory `/root/memfs/c1-bu-obj/gas' > gmake: *** [all-gas] Error 2 Correction. Will compile with patches from here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299671 But doesn't pass test suite: # of expected passes 28 # of unexpected failures 20 Test logs show: Executing /root/binutils-2.15/gas/testsuite/lib/run ../as-new --32 -al /root/binutils-2.15/gas/testsuite/gas/i386/float.s >&dump.out regexp_diff match failure regexp "^.*: Assembler messages:$" line "Assembler messages:" regexp_diff match failure regexp "^.*:3: Warning:.*faddp.*$" line "FATAL: can't create a.out: Invalid bfd target" extra regexps in /root/binutils-2.15/gas/testsuite/gas/i386/float.l starting with "^.*:14: Warning:.*fsubp.*$" EOF from dump.out FAIL: i386 float I have no idea why this happens. xw From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 20:02:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDCAD1065687 for ; Mon, 18 May 2009 20:02:37 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id ACB6F8FC20 for ; Mon, 18 May 2009 20:02:37 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 3296 invoked from network); 18 May 2009 19:35:55 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 May 2009 19:35:55 -0000 Message-ID: <4A11B893.1000808@telenix.org> Date: Mon, 18 May 2009 15:35:47 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: FreeBSD-Hackers X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: porting info for FreeBSD's kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 20:02:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been googling, trying to see if I can find notes regarding what needs changing, in what order, to adapt the FreeBSD kernel to a new processor. Anyone know where stuff like that can be found? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRuJMACgkQz62J6PPcoOmq/gCaAkpfszx/RV6ETjyqsBrYjkKy G4cAniK2BsXTsgTFuvsbPmS7siv2DwTA =Y+ww -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon May 18 22:36:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6658E1065679 for ; Mon, 18 May 2009 22:36:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 031498FC1A for ; Mon, 18 May 2009 22:36:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n4IMaFpH025912; Mon, 18 May 2009 18:36:15 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 18 May 2009 18:36:15 -0400 (EDT) Date: Mon, 18 May 2009 18:36:15 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: xorquewasp@googlemail.com In-Reply-To: <20090518084831.GA95354@logik.internal.network> Message-ID: References: <20090504185644.GA16315@logik.internal.network> <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 22:36:18 -0000 On Mon, 18 May 2009, xorquewasp@googlemail.com wrote: > Hi. > > After a week off, another update: > > I've realised, too late, that I'm using a version of binutils > (2.19) that's incompatible with the system binutils (2.15). > Specifically, assembler code emitted by the native GNAT contains > .cfi_personality directives (and no doubt other things too) that > can't be processed by the system 'as'. > > I've got two choices now and would appreciate some advice on > which to take given that I want to produce a FreeBSD port: > > 1. Compile binutils-2.15. > > Unfortunately, compiling these as cross-binutils appear to be problematic: Hmm, if the system binutils is 2.15, then it should build as a cross. You can do a cross build of all FreeBSD - I think you just set TARGET="amd64" to build amd64 from a different arch. Part of this process should be to create a cross binutils toolset. > 2. Continue to use binutils-2.19. > > This would appear to require me to create a binutils-2.19 port > just for the GNAT compiler. Seems like it would be preferable > to use the system binutils rather than to take this route... Well, I used a newer binutils on sparc when I did the original port. Once I built the cross compiler and binutils toolset, I was done with it. After the native compiler is built using the cross tools, you should be able to rebuild the native compiler _again_ but this time with the system (amd64) binutils. -- DE From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 03:16:49 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0FC1106564A for ; Tue, 19 May 2009 03:16:49 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 55B088FC14 for ; Tue, 19 May 2009 03:16:49 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by ewy3 with SMTP id 3so4417699ewy.43 for ; Mon, 18 May 2009 20:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=42sL7pcZTVgg8ZUjvE5wcuauvAxuSXSeoGbFaRBIxJ0=; b=Qzwegke5ITaRQQTr/vPMrnrGteWIqAMYw4H6hRzLgc6PPYkytanwJRF6RdKfctmImE x3J1thznGy4hfVWysVrfgFQmx0uwMmFlH1Io3fB0H/ecu0ZVs08tMA0rUzYqIPka/75t IsCIe5Od4uZGVrc2UvuQS25XuqfjBLfJnFFMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=mnSD3ikkhpEFXagi+N9dNPmAcO/napV3u2Qz+rSLud5rmFER8lKWtEJ7arKpq3V69T 6q57E3ZIkgBUuU4glRQXu45hzQE4xBFbOW/3lzpxDZmLn12mtGmsdXpOfW/LbjVswNlk kwhadhfbJqiD8emH2qqoFqy6PDwWQzIbYOu7w= MIME-Version: 1.0 Received: by 10.216.29.208 with SMTP id i58mr2398133wea.85.1242701392309; Mon, 18 May 2009 19:49:52 -0700 (PDT) Date: Mon, 18 May 2009 22:49:52 -0400 Message-ID: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> From: Glen Barber To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: sshd(8) - alert user when fails to execute from rc.d X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 03:16:50 -0000 Good evening, hackers. Earlier this evening, I submitted a PR about sshd(8) giving a false-positive when starting on an already occupied socket[1]. I would like to enable some form of console output when the rc.d script is called if the service cannot properly bind to the socket, but I want to make sure I do it "the right way." I was digging through src/crypto/openssh/sshd.c hoping to submit a patch to enable this, but I'm not certain that is the right place to be looking. After digging through erc/etc/rc.d/sshd, I am failing to understand how the service would check the listening port, so now I feel like I am hitting a wall. Any suggestions on how best to enable this? Thanks in advance. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=134694 -- Glen Barber From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 06:04:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9DE1065691; Tue, 19 May 2009 06:04:09 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2058FC1F; Tue, 19 May 2009 06:04:08 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 9so1121804eyd.7 for ; Mon, 18 May 2009 23:04:07 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=fpuZVTVq2+KJX4A66TUoxZGlQ6qQe05pcPorUPV+GfM=; b=Rf2f66RaZaAfhG4I14OAQJM/9sH0eVjOjE9gHGNsy1qD+/gbj7KqHR6Rcdwu7ZND4+ yyrmi1rYdeHqDNWhcTi8a6ieW/iCCMCRqFIuIMzSX6VOXfNhFy3KpO69ZS33TH4rDcrH K88Bnks3lH5/UVWXgq/h8tnAYIyFdN8mcBkZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=Qzlu/SiFAJkeypnYiTMQiVyo82nPNYKrRRw5OpDJDd1vF+sPc56eyUpDrVVq4LFr3+ FatghA5Amtr6/I9NZEqSotVmhQm3yL+Sn3v4vbJhj4Z5ZFtQ9MJx9EFNI3Ga3ldMjQS7 WV9ANboWFbRwk9JxDF0cmMLSDfalvXX7z2LUk= Received: by 10.210.114.1 with SMTP id m1mr8622550ebc.77.1242713047593; Mon, 18 May 2009 23:04:07 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 9sm6092248ewy.57.2009.05.18.23.04.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 May 2009 23:04:07 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 67B495D59; Tue, 19 May 2009 06:04:05 +0000 (UTC) Date: Tue, 19 May 2009 07:04:05 +0100 From: xorquewasp@googlemail.com To: Daniel Eischen Message-ID: <20090519060405.GA43127@logik.internal.network> References: <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 06:04:09 -0000 On 2009-05-18 18:36:15, Daniel Eischen wrote: > Hmm, if the system binutils is 2.15, then it should build > as a cross. You can do a cross build of all FreeBSD - I > think you just set TARGET="amd64" to build amd64 from > a different arch. Part of this process should be to > create a cross binutils toolset. Ok. Silly question - is it actually possible to build contrib/binutils (including TARGET=amd64) without building the whole tree? Trying the obvious: cd /usr/obj /usr/src/contrib/binutils/configure \ --target=x86_64-pc-freebsd7.2 \ --host=i386-pc-freebsd7.2 \ --build=i386-pc-freebsd7.2 \ --prefix=/cross/x86_64 .. Didn't work (didn't really expect it to). xw From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 08:21:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF08106568E for ; Tue, 19 May 2009 08:21:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 48A228FC1A for ; Tue, 19 May 2009 08:21:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=1eQnrbQGtHIA:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=bwsEZA-d16ctZT403zQA:9 a=HIDQYUdJ559a-CJGmxuIfnk9nTcA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1071559095 for freebsd-hackers@freebsd.org; Tue, 19 May 2009 09:21:03 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Tue, 19 May 2009 09:23:39 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190923.39298.hselasky@c2i.net> Subject: Which priority do taskqueues have? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 08:21:07 -0000 Hi, I'm about to factor out some taskqueue-alike code from USB(II) and I need to know at which priority taskqueues are running. I know there is a priority argument which can be specified for TASK_INIT(), but tracing in the code shows that this is just a queue-priority. At which priority level is taskqueue code being [guaranteed to] run? --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 11:45:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3195B10656E6; Tue, 19 May 2009 11:45:52 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6557E8FC33; Tue, 19 May 2009 11:45:51 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so4624115ewy.43 for ; Tue, 19 May 2009 04:45:50 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=9XATr+GI5yK1MFJzhqh9e52bpdMTkb4BVq0cWweoM5M=; b=A4shTtU3SxCMYhm+/FYNW5rgHefiSCUZbjoEVZIYJZQyP1z5WgSd54MTdEx7EbxKf5 Dfeg4k0+m8W3gY6O6xYS9MB7lP5qWS5Ghn2kCdigvL1baSA/c3J94fKVwWqrkssmMu/4 cULC+udP9LnM0QYE+aYmgm88aYA8Pp/Sz/htg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=IoYWQutTYVg2QbvPTy7F/55Nb7MVeHOFDpzs06MoGFnb/0LYdMNsvEO8EKY6sPdYZ4 ByYgqO6p2Yemb4lrsX+QGCM8hNUr/Hvr9AfpeelaiS+ZxH7mDCp3OCYKx97qyHt2Gdq+ cM5zFd4GvqnzLQ3YCseSsP2Ox2VUkmZMTQPAU= Received: by 10.210.71.12 with SMTP id t12mr4980902eba.8.1242733550519; Tue, 19 May 2009 04:45:50 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 2sm6777705ewy.62.2009.05.19.04.45.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 May 2009 04:45:49 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 36F8C5D59; Tue, 19 May 2009 11:45:48 +0000 (UTC) Date: Tue, 19 May 2009 12:45:48 +0100 From: xorquewasp@googlemail.com To: Daniel Eischen Message-ID: <20090519114548.GA8610@logik.internal.network> References: <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 11:45:53 -0000 On 2009-05-18 18:36:15, Daniel Eischen wrote: > Well, I used a newer binutils on sparc when I did the original > port. Once I built the cross compiler and binutils toolset, > I was done with it. After the native compiler is built using > the cross tools, you should be able to rebuild the native > compiler _again_ but this time with the system (amd64) > binutils. I probably should point out that I don't think this is the case anymore. GCC apparently detects what capabilities the currently selected binutils have so when the first native compiler has been compiled using the cross, it will emit code that can't be assembled using the system binutils (because it uses features from the new binutils that aren't supported by the older system ones). In other words, you can't rebuild the native compiler using the system binutils. If the worst comes to the worst, I can create a dependency on the devel/cross-binutils port. xw From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 13:35:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68CC51065672 for ; Tue, 19 May 2009 13:35:28 +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 3CE428FC1C for ; Tue, 19 May 2009 13:35:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E72F846B23; Tue, 19 May 2009 09:35:27 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B5A868A026; Tue, 19 May 2009 09:35:26 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 19 May 2009 08:25:13 -0400 User-Agent: KMail/1.9.7 References: <200905190923.39298.hselasky@c2i.net> In-Reply-To: <200905190923.39298.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905190825.13595.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 19 May 2009 09:35:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Hans Petter Selasky Subject: Re: Which priority do taskqueues have? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 13:35:28 -0000 On Tuesday 19 May 2009 3:23:39 am Hans Petter Selasky wrote: > Hi, > > I'm about to factor out some taskqueue-alike code from USB(II) and I need to > know at which priority taskqueues are running. I know there is a priority > argument which can be specified for TASK_INIT(), but tracing in the code > shows that this is just a queue-priority. At which priority level is > taskqueue code being [guaranteed to] run? It depends on the queue I think. taskqueue_swi runs as a SWI and thus at a software-interrupt priority. taskqueue_thread runs at the default priority for kernel threads (currently a rather bogus PVM I think). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 13:51:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A6541065679 for ; Tue, 19 May 2009 13:51:10 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id DCA5C8FC16 for ; Tue, 19 May 2009 13:51:09 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n4JDp8f1014743; Tue, 19 May 2009 09:51:08 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 19 May 2009 09:51:08 -0400 (EDT) Date: Tue, 19 May 2009 09:51:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: xorquewasp@googlemail.com In-Reply-To: <20090519114548.GA8610@logik.internal.network> Message-ID: References: <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> <20090519114548.GA8610@logik.internal.network> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 13:51:10 -0000 On Tue, 19 May 2009, xorquewasp@googlemail.com wrote: > On 2009-05-18 18:36:15, Daniel Eischen wrote: >> Well, I used a newer binutils on sparc when I did the original >> port. Once I built the cross compiler and binutils toolset, >> I was done with it. After the native compiler is built using >> the cross tools, you should be able to rebuild the native >> compiler _again_ but this time with the system (amd64) >> binutils. > > I probably should point out that I don't think this is the case anymore. > > GCC apparently detects what capabilities the currently selected binutils > have so when the first native compiler has been compiled using the > cross, it will emit code that can't be assembled using the system > binutils (because it uses features from the new binutils that aren't > supported by the older system ones). In other words, you can't rebuild the > native compiler using the system binutils. > > If the worst comes to the worst, I can create a dependency on the > devel/cross-binutils port. Even so, you shouldn't need a cross-binutils, only a native (amd64) binutils. Your port won't be a cross port, but a native amd64 port. The native amd64 GNAT will need a native binutils, not a cross binutils. The only thing you will have to make is a minimal bootstrap (native amd64) compiler. Of course you can create a cross port if you want to facilitate cross builds for ports that don't exist yet, but no one running amd64 will want to make a cross build when they can make a faster native build with less dependencies. -- DE From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 13:55:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC86C1065680 for ; Tue, 19 May 2009 13:55:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 755CA8FC13 for ; Tue, 19 May 2009 13:55:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n4JDtZP9017731; Tue, 19 May 2009 09:55:35 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 19 May 2009 09:55:35 -0400 (EDT) Date: Tue, 19 May 2009 09:55:35 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: xorquewasp@googlemail.com In-Reply-To: <20090519060405.GA43127@logik.internal.network> Message-ID: References: <20090505005128.GA4519@logik.internal.network> <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> <20090519060405.GA43127@logik.internal.network> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:55:37 -0000 On Tue, 19 May 2009, xorquewasp@googlemail.com wrote: > On 2009-05-18 18:36:15, Daniel Eischen wrote: >> Hmm, if the system binutils is 2.15, then it should build >> as a cross. You can do a cross build of all FreeBSD - I >> think you just set TARGET="amd64" to build amd64 from >> a different arch. Part of this process should be to >> create a cross binutils toolset. > > Ok. > > Silly question - is it actually possible to build contrib/binutils > (including TARGET=amd64) without building the whole tree? Trying > the obvious: > > cd /usr/obj > /usr/src/contrib/binutils/configure \ > --target=x86_64-pc-freebsd7.2 \ > --host=i386-pc-freebsd7.2 \ > --build=i386-pc-freebsd7.2 \ > --prefix=/cross/x86_64 > > .. Didn't work (didn't really expect it to). I've not done a cross build before, but I'd look in src/Makefile.inc1 if you want to try to build it piecemeal (see the target for cross-tools). -- DE From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 13:59:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2BC2106564A for ; Tue, 19 May 2009 13:59:20 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2641A8FC29 for ; Tue, 19 May 2009 13:59:19 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 9so1177384eyd.7 for ; Tue, 19 May 2009 06:59:19 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=HG4C1lvQVwciLWkyeBgr9tbryYT5WPIbFQb8V6ZKaoc=; b=Z5n25OphwHmflPBZRYcGj6CCkuuKUKNe55l1GFusHkuqbBhXVoBelK7A5+sUz6Y874 NYumhijs6Z7hat+JrIb0J0pYy9aEOc+YY6V9EFMWAmupRxxbubYbewfwGdKhc02XvzLK 7RN7pZAzcxPMhcZo4pWC+wZIoMTI5w4e2mTrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=LEm1cGYDIkc3KTnPQq7O/VkL8uLm4kYqDBgjH5Nk4wtPUJ4GTefq0Cv4W8HA/HU4rY xZhLQuRI6gkgbBoZWoUxIBytluRWK594guWLJ+PaA3jJrCYBkT90fQEzXH18Jdl8OIxH ahhBtnVWVPlVBjEAxM2Qc3mAU+/q07vC9oOj4= Received: by 10.210.127.13 with SMTP id z13mr147007ebc.10.1242741559044; Tue, 19 May 2009 06:59:19 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 11sm7102002ewy.98.2009.05.19.06.59.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 May 2009 06:59:18 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 527D85D59; Tue, 19 May 2009 13:59:17 +0000 (UTC) Date: Tue, 19 May 2009 14:59:17 +0100 From: xorquewasp@googlemail.com To: Daniel Eischen Message-ID: <20090519135917.GA5391@logik.internal.network> References: <20090505022151.GA32477@logik.internal.network> <20090506140325.GA69468@logik.internal.network> <20090506152222.GC69468@logik.internal.network> <20090508211022.GA37475@logik.internal.network> <20090518084831.GA95354@logik.internal.network> <20090519114548.GA8610@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: bootstrapping gnat GCC on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 13:59:21 -0000 On 2009-05-19 09:51:08, Daniel Eischen wrote: > > Even so, you shouldn't need a cross-binutils, only a native > (amd64) binutils. Your port won't be a cross port, but a > native amd64 port. The native amd64 GNAT will need a native > binutils, not a cross binutils. The only thing you will have > to make is a minimal bootstrap (native amd64) compiler. > > Of course you can create a cross port if you want to facilitate > cross builds for ports that don't exist yet, but no one running > amd64 will want to make a cross build when they can make a > faster native build with less dependencies. 'lo, Sorry, I should have been a bit clearer there. I mean if in the very worst case, I can't get by with the system binutils, I can create a "native" set of recent binutils using the cross-binutils port: cd /usr/ports/devel/cross-binutils make TGTARCH=x86_64 TGTABI=freebsd7.2 install That way, the port can just depend on those and I won't have to create my own binutils port. Like I said, I'm hoping this won't happen. Current status is that I have a working native AMD64 GNAT using 2.19 binutils! $ gcc44 -v Using built-in specs. Target: x86_64-pc-freebsd7.2 Configured with: /usr/jails/i386/root/gcc-4.4.0/configure --build=x86_64-pc-freebsd7.2 --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=44 --bindir=/usr/local/bin/gcc44 --libdir=/usr/local/lib/gcc-4.4.0 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc44 Thread model: posix gcc version 4.4.0 (GCC) Needless to say, I'm pretty pleased. xw From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 16:30:07 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07A2D1065687; Tue, 19 May 2009 16:30:07 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2918FC17; Tue, 19 May 2009 16:30:05 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by bwz9 with SMTP id 9so3931683bwz.43 for ; Tue, 19 May 2009 09:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PLrcpCSRKOYsHBsq1/TfOXg8aQjvyczsq5W3r3p9rIA=; b=kxh9cJS0iYK5ke0o9DkVliY3puPbgfauqDm4sv5xoyyLsStNtD2KlBEmL+kdjnSP7w w2P3mOuu/f7f68c5eAzBmnoEpoQH5eF8lI7qw2zMtdXwPXhPSS8WXFIRaRY6reI2fNf2 5Ano55rTUr2uly4Dt6lGD2/8D5ayWl4Ix4nu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hkl7/YoccE7h/VVm+M4q+lJ6itJHvrWkbznwWB8koCvzRQxIGt6H0ELMpXNggDvVya qEUJjfYd479VPHAMYqBNhvV7kTT8CZHTBLkIsklWEp55B4xbn5MkILzucKOdIlOidKQV Y96+l6PpvlLK+tQxHLxtQt/6bMKeaeBw4AzSg= MIME-Version: 1.0 Received: by 10.204.62.133 with SMTP id x5mr199694bkh.60.1242749240173; Tue, 19 May 2009 09:07:20 -0700 (PDT) Date: Tue, 19 May 2009 13:07:20 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Shteryana Shopova , Harti Brandt Subject: IPv6 support on BSNMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 16:30:07 -0000 Hello, Is there any ongoing work on adding support for IPv6 to BSNMP? Do you have an idea of how much effort it would need? Thanks in advance. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 19:56:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CCB11065686 for ; Tue, 19 May 2009 19:56:17 +0000 (UTC) (envelope-from emorras@xroff.net) Received: from xroff.net (xroff.net [200.46.208.231]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2B68FC1A for ; Tue, 19 May 2009 19:56:16 +0000 (UTC) (envelope-from emorras@xroff.net) Received: from localhost (unknown [200.46.208.211]) by xroff.net (Postfix) with ESMTP id 080EB4FC945 for ; Tue, 19 May 2009 19:37:30 +0000 (UTC) Received: from xroff.net ([200.46.208.231]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 77005-08 for ; Tue, 19 May 2009 16:37:28 -0300 (ADT) Received: from argente-2005.xroff.net (83.173.186.39.dyn.user.ono.com [83.173.186.39]) by xroff.net (Postfix) with ESMTPA id 7512E4FC814 for ; Tue, 19 May 2009 19:37:27 +0000 (UTC) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 May 2009 21:37:23 +0200 To: freebsd-hackers@freebsd.org From: Eduardo Morras Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090519193727.7512E4FC814@xroff.net> Subject: Question about PCIe networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 19:56:18 -0000 Hello, don't know if this has been discussed but here it goes. I have read recently this http://www.wwpi.com/hardware/hardware/6540-ethernet-tunneling-through-pci-express-inter-processor-communication-low-latency-storage-io It's about using PCIe to connect 2 servers directly, without using ethernet or other hardware. Can it be done in FreeBSD? What is needed to know? TIA From owner-freebsd-hackers@FreeBSD.ORG Tue May 19 21:22:12 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 605A91065675 for ; Tue, 19 May 2009 21:22:12 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 403F48FC0C for ; Tue, 19 May 2009 21:22:11 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.14.3/8.14.3) with ESMTP id n4JKwSfY031383 for ; Tue, 19 May 2009 13:58:28 -0700 (PDT) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.14.3/8.14.3/Submit) id n4JKwSAH031382 for hackers@freebsd.org; Tue, 19 May 2009 13:58:28 -0700 (PDT) (envelope-from steve) Message-Id: <200905192058.n4JKwSAH031382@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <20090519193727.7512E4FC814@xroff.net> From: steve@Watt.COM (Steve Watt) Organization: Watt Consultants, San Jose, CA, USA Date: Tue, 19 May 2009 13:58:28 -0700 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: hackers@freebsd.org X-Archived: 1242766708.073375022@wattres.Watt.COM X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (wattres.watt.com [127.0.0.1]); Tue, 19 May 2009 13:58:28 -0700 (PDT) Cc: Subject: Re: Question about PCIe networks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 19 May 2009 21:22:12 -0000 In <20090519193727.7512E4FC814@xroff.net>, emorras@xroff.net write: >I have read recently this >http://www.wwpi.com/hardware/hardware/6540-ethernet-tunneling-through-pci-express-inter-processor-communication-low-latency-storage-io (From a company that makes PCIe switches to connect multiple root complexes together.) >It's about using PCIe to connect 2 servers directly, without using >ethernet or other hardware. > >Can it be done in FreeBSD? What is needed to know? Certainly. Non-transparent PCIe bridges basically create windows of memory space into the other side. You'd need the two sides to agree on the data structures, and what signalling mechanism to use for packet availability. Quite straightforward, really. What you'll need is the bridge hardware that connects to the two systems, the two systems, datasheets, and some time. Each side of the bridge would allocate some DMAable memory, and set up the bridge so that is visible to the other side. Set up a pair of rings (one per direction of traffic), and go. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 10:39:03 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03201065674 for ; Wed, 20 May 2009 10:39:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 580D18FC23 for ; Wed, 20 May 2009 10:39:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=YMCXFvQB5YlTAZGkt1zGg8cCeSyWrXMpxutow3z4ARe0XWyOhNO74AvL8vl7Mnc+CxhLmS9mC/w+gIp3typV0rafVIQSyHe8e4YbW9pI1BcsZsfHEdoOw2QNLkqIKulmN7rjBNLoqiTNj66vY2qnn4ZkblqMXGM0F1i4h57uVFQ=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M6itQ-000CVP-IB; Wed, 20 May 2009 14:19:24 +0400 Date: Wed, 20 May 2009 14:19:22 +0400 From: Eygene Ryabinkin To: Glen Barber Message-ID: References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:39:04 -0000 Glen, good day. Mon, May 18, 2009 at 10:49:52PM -0400, Glen Barber wrote: > Earlier this evening, I submitted a PR about sshd(8) giving a > false-positive when starting on an already occupied socket[1]. I > would like to enable some form of console output when the rc.d script > is called if the service cannot properly bind to the socket, but I > want to make sure I do it "the right way." Reading through the PR, I can't figure out what do you mean. You're saying that 1. you spawn the other service on a port N; 2. then you're spawning SSH on the same port via rc.d script; 3. after this '/etc/rc.d/sshd status' gives you 'sshd is not running'. But this is completely right: after step 2 there will be no SSH daemon listening, because it fails to bind to the port. And the 'status' command of an rc.d script is perfectly correct -- no SSH daemon is running, really. > I was digging through src/crypto/openssh/sshd.c hoping to submit a > patch to enable this, but I'm not certain that is the right place to > be looking. After digging through erc/etc/rc.d/sshd, I am failing to > understand how the service would check the listening port, so now I > feel like I am hitting a wall. You seem to mix two things: binding to the port and the output from rc.d 'status' command. Binding to the port is done by SSH by the bind(2) system call and if something is already listening on the given address, the socket won't be bound, so SSH daemon terminates. 'status' (for the case of /etc/rc.d/sshd) deduces the status of the service from it's pid file (variable pidfile) with the subroutine check_pidfile. Look at /etc/rc.subr: 'status' is handled via "run_rc_command status" that evaluates _pidcmd that sets $rc_pid. And then $rc_pid it checked for being non-empty, and if emptiness found, command ----- echo "${name} is not running." ----- is executed. It produces the result you're seeing. So, I would say that the PR in question is somewhat false positive. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 10:54:56 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F409C1065675; Wed, 20 May 2009 10:54:55 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id B3B058FC18; Wed, 20 May 2009 10:54:55 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342] (unknown [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CFD405C42; Wed, 20 May 2009 12:54:54 +0200 (CEST) Message-ID: <4A13E180.1040606@andric.com> Date: Wed, 20 May 2009 12:54:56 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Glen Barber , bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:54:56 -0000 On 2009-05-20 12:19, Eygene Ryabinkin wrote: > You seem to mix two things: binding to the port and the output from rc.d > 'status' command. Binding to the port is done by SSH by the bind(2) > system call and if something is already listening on the given address, > the socket won't be bound, so SSH daemon terminates. I think what might be confusing, is the fact that sshd dies due to bind() failing, and it should; but you will only see this in the syslog, NOT on the command line. E.g. the /etc/rc.d/sshd script will NOT give an error, because the /usr/bin/sshd it calls will fork, and as soon as the fork is okay, the original instance with exit with 0. The forked instance is what will die on bind(), so you will not see any failures from it. From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 11:27:01 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E104C1065670; Wed, 20 May 2009 11:27:01 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A07498FC18; Wed, 20 May 2009 11:27:01 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342] (unknown [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BBABF5C42; Wed, 20 May 2009 13:27:00 +0200 (CEST) Message-ID: <4A13E906.7020907@andric.com> Date: Wed, 20 May 2009 13:27:02 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre MIME-Version: 1.0 To: Tobias Fendin References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> <4A13E6F7.7070309@glocalnet.net> In-Reply-To: <4A13E6F7.7070309@glocalnet.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Glen Barber , hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:27:02 -0000 On 2009-05-20 13:18, Tobias Fendin wrote: > Does the child really die? I did a little test: > > # /etc/rc.d/sshd status > sshd is not running. > # nc -l 22 >/tmp/ssh_test & > [1] 1733 > # /etc/rc.d/sshd start > Starting sshd. > # /etc/rc.d/sshd status > sshd is running as pid 1740. This is because sshd binds to both IPv4 and IPv6 ports. The IPv4 bind fails, as you will see in syslog, while the IPv6 bind succeeds. Thus sshd keeps on running. If you start two nc's (I don't know any way to do this with one instance), e.g.: nc -4 -l 22 > /tmp/ssh_test4 & nc -6 -l 22 > /tmp/ssh_test6 & and then try starting sshd, you should see it quit. From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 11:41:12 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BC1106566C; Wed, 20 May 2009 11:41:12 +0000 (UTC) (envelope-from tobias.fendin@glocalnet.net) Received: from atthis.its.uu.se (atthis.its.uu.se [130.238.7.58]) by mx1.freebsd.org (Postfix) with ESMTP id 483B68FC1D; Wed, 20 May 2009 11:41:04 +0000 (UTC) (envelope-from tobias.fendin@glocalnet.net) Received: from [192.168.2.2] (nl101-225-62.student.uu.se [130.243.225.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by atthis.its.uu.se (Postfix) with ESMTP id 5C30910D987; Wed, 20 May 2009 13:18:16 +0200 (CEST) Message-ID: <4A13E6F7.7070309@glocalnet.net> Date: Wed, 20 May 2009 13:18:15 +0200 From: Tobias Fendin User-Agent: Thunderbird 2.0.0.21 (X11/20090511) MIME-Version: 1.0 To: Dimitry Andric References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> In-Reply-To: <4A13E180.1040606@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Debian amavisd-new at localdomain Cc: Glen Barber , hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:41:13 -0000 Dimitry Andric wrote: > On 2009-05-20 12:19, Eygene Ryabinkin wrote: > >> You seem to mix two things: binding to the port and the output from rc.d >> 'status' command. Binding to the port is done by SSH by the bind(2) >> system call and if something is already listening on the given address, >> the socket won't be bound, so SSH daemon terminates. >> > > I think what might be confusing, is the fact that sshd dies due to > bind() failing, and it should; but you will only see this in the syslog, > NOT on the command line. > > E.g. the /etc/rc.d/sshd script will NOT give an error, because the > /usr/bin/sshd it calls will fork, and as soon as the fork is okay, the > original instance with exit with 0. The forked instance is what will > die on bind(), so you will not see any failures from it. > _______________________________________________ > 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" > > Does the child really die? I did a little test: # /etc/rc.d/sshd status sshd is not running. # nc -l 22 >/tmp/ssh_test & [1] 1733 # /etc/rc.d/sshd start Starting sshd. # /etc/rc.d/sshd status sshd is running as pid 1740. # ssh someuser@localhost // This didn't timeout or anything, just didn't give any output. I killed it after a couple of minutes. ^C [1]+ Done nc -l 22 > /tmp/ssh_test # ssh someuser@localhost The authenticity of host 'localhost (::1)' can't be established. DSA key fingerprint is 9f:fa:ee:f5:39:c5:de:c4:8f:b9:c5:43:d8:9d:85:23. Are you sure you want to continue connecting (yes/no)? ^C # uname -a FreeBSD asator 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Thu Mar 5 03:16:15 CET 2009 root@asator:/usr/obj/usr/src/sys/A_KERNEL i386 As you can see, the first execution of ssh connects to nc (which terminated when I killed the ssh client). And the second execution it gets through to sshd (thus, sshd never failed at it's startup). I don't know if this is the expected behavior, or if it has changed on -CURRENT. From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 14:38:20 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C3EA106564A for ; Wed, 20 May 2009 14:38:20 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id EB0F68FC1D for ; Wed, 20 May 2009 14:38:19 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz9 with SMTP id 9so459077bwz.43 for ; Wed, 20 May 2009 07:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HMgpJMWhPGx/Fw+dU4eYnlMN2nNA3Ai7hHE0pH1Lga8=; b=RuUv1Ks/OcN8VY6H4BW2TJCjdMW+elXv4mpfzrClShdv8OS9ZNvHTvqlbl3R3DSSfo XNQHgra90zvsUPt8fswgWmgAx2JWhbYv+e/W3XxlHMwwjVCjPRNe0JBJp2prYx3rvvTO UvJUsX18n9Gd2Kw7LI94uPkww1l3gGVygva30= 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=IP9qcF7US70DAj8UPmIj9/zNPZJppeNL0ZNqdDl/grkDTEpLOlfgPwzSHf05MFfYX/ cHX/gSYTvfntti1/Qw1Cph4+HbrrRvcdvYztXe0a02Gx8XWPIs3dRZnB+AvQS305QFGp 9twci0snrzjfzphQnmWOl2LP8wJuHJ2txSjIY= MIME-Version: 1.0 Received: by 10.223.103.207 with SMTP id l15mr1035426fao.2.1242830298520; Wed, 20 May 2009 07:38:18 -0700 (PDT) In-Reply-To: References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> Date: Wed, 20 May 2009 10:38:18 -0400 Message-ID: <4ad871310905200738g79989fb6l58616f16495beccb@mail.gmail.com> From: Glen Barber To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:38:20 -0000 Hi, Eygene On Wed, May 20, 2009 at 6:19 AM, Eygene Ryabinkin wr= ote: > Glen, good day. > > Mon, May 18, 2009 at 10:49:52PM -0400, Glen Barber wrote: >> Earlier this evening, I submitted a PR about sshd(8) giving a >> false-positive when starting on an already occupied socket[1]. =A0I >> would like to enable some form of console output when the rc.d script >> is called if the service cannot properly bind to the socket, but I >> want to make sure I do it "the right way." > > Reading through the PR, I can't figure out what do you mean. > You're saying that > =A01. you spawn the other service on a port N; > =A02. then you're spawning SSH on the same port via rc.d script; > =A03. after this '/etc/rc.d/sshd status' gives you 'sshd is not running'. > > But this is completely right: after step 2 there will be no SSH daemon > listening, because it fails to bind to the port. =A0And the 'status' > command of an rc.d script is perfectly correct -- no SSH daemon is > running, really. > That is correct. There is no daemon running, but there is no output on the console that starting sshd failed -- it is only listed in messages. (And if you don't know it failed, you may never look in messages to realize this.) >> I was digging through src/crypto/openssh/sshd.c hoping to submit a >> patch to enable this, but I'm not certain that is the right place to >> be looking. =A0After digging through erc/etc/rc.d/sshd, I am failing to >> understand how the service would check the listening port, so now I >> feel like I am hitting a wall. > > You seem to mix two things: binding to the port and the output from rc.d > 'status' command. =A0Binding to the port is done by SSH by the bind(2) > system call and if something is already listening on the given address, > the socket won't be bound, so SSH daemon terminates. > > 'status' (for the case of /etc/rc.d/sshd) deduces the status of the > service from it's pid file (variable pidfile) with the subroutine > check_pidfile. =A0Look at /etc/rc.subr: 'status' is handled via > "run_rc_command status" that evaluates _pidcmd that sets $rc_pid. =A0And > then $rc_pid it checked for being non-empty, and if emptiness found, > command > ----- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0echo "${na= me} is not running." > ----- > is executed. =A0It produces the result you're seeing. > > So, I would say that the PR in question is somewhat false positive. > -- > Eygene > =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___ =A0 =A0 =A0 _.--. =A0 # > =A0\`.|\..----...-'` =A0 `-._.-'_.-'` =A0 # =A0Remember that it is hard > =A0/ =A0' ` =A0 =A0 =A0 =A0 , =A0 =A0 =A0 __.--' =A0 =A0 =A0# =A0to read = the on-line manual > =A0)/' _/ =A0 =A0 \ =A0 `-_, =A0 / =A0 =A0 =A0 =A0 =A0 =A0# =A0while sing= le-stepping the kernel. > =A0`-'" `"\_ =A0,_.-;_.-\_ ', =A0fsc/as =A0 # > =A0 =A0 _.-'_./ =A0 {_.' =A0 ; / =A0 =A0 =A0 =A0 =A0 # =A0 =A0-- FreeBSD = Developers handbook > =A0 =A0{_.-``-' =A0 =A0 =A0 =A0 {_/ =A0 =A0 =A0 =A0 =A0 =A0# > --=20 Glen Barber From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 14:41:00 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D739A106567F for ; Wed, 20 May 2009 14:41:00 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1138FC1D for ; Wed, 20 May 2009 14:40:59 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fxm12 with SMTP id 12so474174fxm.43 for ; Wed, 20 May 2009 07:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I4XE6u+6l+4GqVypeHOeBua0gIOiwseWJLqgs5e8y7A=; b=sltvB0MX23gZ7bLS0lmqGVTR6q8iOXeIrUMPGUkUg8tSaEphd1sA6gX9KJOoc/BUNL 9zVagRhOV3wS0zI+gN1neAxJscLyEVVTWJDliNu1jdKRG+YnBbAFI+DRVGn5CFOlt6ED 8T4WTG8huaGqs0JpH/v9Lb7XPAP3LTTso4mtE= 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=mpifnpSk++uK0FR5WurjUpcKeFLSSzS6k8TrEAi29lMT217We8hIAiyzCO132QvBd/ 1uTmWQ8QF4fvNYuFB1Ral428cGxMWgBmpzbWf/FvJ9Ku9m8lxYNMS45lKA6nZL/jEvVw oC7Ub+kmWW8v2HT3lzld2VUAElUeiz+NYrer4= MIME-Version: 1.0 Received: by 10.223.117.1 with SMTP id o1mr1017885faq.96.1242830459181; Wed, 20 May 2009 07:40:59 -0700 (PDT) In-Reply-To: <4A13E906.7020907@andric.com> References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> <4A13E6F7.7070309@glocalnet.net> <4A13E906.7020907@andric.com> Date: Wed, 20 May 2009 10:40:59 -0400 Message-ID: <4ad871310905200740n744f9b83j96db2a3c1a6bec43@mail.gmail.com> From: Glen Barber To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:41:01 -0000 Hi, Dimitry On Wed, May 20, 2009 at 7:27 AM, Dimitry Andric wrote: > On 2009-05-20 13:18, Tobias Fendin wrote: >> Does the child really die? I did a little test: >> >> # /etc/rc.d/sshd status >> sshd is not running. >> # nc -l 22 >/tmp/ssh_test & >> [1] 1733 >> # /etc/rc.d/sshd start >> Starting sshd. >> # /etc/rc.d/sshd status >> sshd is running as pid 1740. > > This is because sshd binds to both IPv4 and IPv6 ports. =A0The IPv4 bind > fails, as you will see in syslog, while the IPv6 bind succeeds. =A0Thus > sshd keeps on running. > > If you start two nc's (I don't know any way to do this with one > instance), e.g.: > > nc -4 -l 22 > /tmp/ssh_test4 & > nc -6 -l 22 > /tmp/ssh_test6 & > > and then try starting sshd, you should see it quit. > It's not an IPv4 versus IPv6 problem. How I tested this, as I had this problem in the past (which was a non-standard setup, but still a problem): sshd was listening on :25, both IPv4 and IPv6 sendmail was listening on :25 (because I had forgotten to disable it) The system boots, and sendmail starts before sshd. When sshd starts (or tries to) there is no console output that it had failed. The only way you realize it is not running, is when you cannot remotely log in. --=20 Glen Barber From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 14:43:00 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F42106566B for ; Wed, 20 May 2009 14:43:00 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id E3D408FC0A for ; Wed, 20 May 2009 14:42:59 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz9 with SMTP id 9so461946bwz.43 for ; Wed, 20 May 2009 07:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tW2icagNb7qbX5+Vnvr9eSo+W6D+kjktKNbXRdlS5As=; b=DoRp5+isnT/Lt9Gny15WZL/WEChLqWaFxcG0SfPqQtBXLeBRvFz0IqJxs/iXTrt8et z3fjWv68pe3PCaN0/d7G+8bNcXruRMJC24nV1oFiv4JYKWyqMFUCYa0jSEwSd9zPQQXF DErtGyMzweIIUKZ00PWT9VxB041JSQuRji4sE= 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=iBnYh2LYSzrpgiCPVns4Pw5D2bbOa7bnRF5ahk9gYfcrxZW1LYUqxnPYdddfX1oz9X SNwJUWDOouB1AkKHV2mqplNpJ0jJooCPOiWbY0zz2QS7JH0YCM4WQLDrRC9BUeXbHJDy tC1edvdGPAkGDXpeNRcFvk5QVeaIiw/roPivQ= MIME-Version: 1.0 Received: by 10.223.106.14 with SMTP id v14mr1019913fao.49.1242830578752; Wed, 20 May 2009 07:42:58 -0700 (PDT) In-Reply-To: <4A13E6F7.7070309@glocalnet.net> References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> <4A13E6F7.7070309@glocalnet.net> Date: Wed, 20 May 2009 10:42:58 -0400 Message-ID: <4ad871310905200742r10944459i2a0d5ada4df10d91@mail.gmail.com> From: Glen Barber To: Tobias Fendin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:43:00 -0000 Hi, Tobias On Wed, May 20, 2009 at 7:18 AM, Tobias Fendin wrote: > > Does the child really die? I did a little test: > > # /etc/rc.d/sshd status > sshd is not running. > # nc -l 22 >/tmp/ssh_test & > [1] 1733 > # /etc/rc.d/sshd start > Starting sshd. > # /etc/rc.d/sshd status > sshd is running as pid 1740. > # ssh someuser@localhost =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0// This didn't timeout or > anything, just didn't give any output. I killed it after a couple of > minutes. > ^C > [1]+ =A0Done =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nc -l 22 > /tmp/ssh_t= est > # ssh someuser@localhost > The authenticity of host 'localhost (::1)' can't be established. > DSA key fingerprint is 9f:fa:ee:f5:39:c5:de:c4:8f:b9:c5:43:d8:9d:85:23. > Are you sure you want to continue connecting (yes/no)? ^C > # uname -a > FreeBSD asator 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Thu Mar =A05 03:= 16:15 > CET 2009 =A0 =A0 root@asator:/usr/obj/usr/src/sys/A_KERNEL =A0i386 > > As you can see, the first execution of ssh connects to nc (which terminat= ed > when I killed the ssh client). And the second execution it gets through t= o > sshd (thus, sshd never failed at it's startup). > I don't know if this is the expected behavior, or if it has changed on > -CURRENT. > Perhaps sshd is checking for forked processes of itself, but not other daemons listening on that socket? --=20 Glen Barber From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 14:46:10 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2F6106564A; Wed, 20 May 2009 14:46:10 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AD15B8FC17; Wed, 20 May 2009 14:46:10 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342] (unknown [IPv6:2001:7b8:3a7:0:8d33:c8ee:aff8:342]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D222A5C42; Wed, 20 May 2009 16:46:09 +0200 (CEST) Message-ID: <4A1417B3.3030303@andric.com> Date: Wed, 20 May 2009 16:46:11 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre MIME-Version: 1.0 To: Glen Barber References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> <4A13E6F7.7070309@glocalnet.net> <4A13E906.7020907@andric.com> <4ad871310905200740n744f9b83j96db2a3c1a6bec43@mail.gmail.com> In-Reply-To: <4ad871310905200740n744f9b83j96db2a3c1a6bec43@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:46:11 -0000 On 2009-05-20 16:40, Glen Barber wrote: > sshd was listening on :25, both IPv4 and IPv6 > sendmail was listening on :25 (because I had forgotten to disable it) > > The system boots, and sendmail starts before sshd. When sshd starts > (or tries to) there is no console output that it had failed. The only > way you realize it is not running, is when you cannot remotely log in. Yes, this is unfortunate, but normal, as I explained in an earlier post. The sshd process does not return any error (and thus the /etc/rc.d script doesn't either), because it has no way to know that its forked copy died. The solution to this PR is "don't run stuff on conflicting ports". :) From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 15:51:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1877B106566B for ; Wed, 20 May 2009 15:51:45 +0000 (UTC) (envelope-from kostjn@peterhost.ru) Received: from fb0.z8.ru (fb0.z8.ru [80.93.58.95]) by mx1.freebsd.org (Postfix) with ESMTP id 813338FC1B for ; Wed, 20 May 2009 15:51:44 +0000 (UTC) (envelope-from kostjn@peterhost.ru) Received: from mail.z8.ru ([80.93.58.56]) by fb0.z8.ru with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M6nqF-000Idz-6Z for freebsd-hackers@freebsd.org; Wed, 20 May 2009 19:36:27 +0400 Received: from [85.235.196.139] (helo=kostjn.pht) by mail.z8.ru with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1M6nq2-000E9o-V6 for freebsd-hackers@freebsd.org; Wed, 20 May 2009 19:36:15 +0400 Message-ID: <4A1423D9.30105@peterhost.ru> Date: Wed, 20 May 2009 19:38:01 +0400 From: =?UTF-8?B?0JzQtdC90YzRiNC40LrQvtCyINCa0L7QvdGB0YLQsNC90YLQuNC9?= User-Agent: Thunderbird 2.0.0.18 (X11/20090328) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <49ED55FF.5080306@peterhost.ru> In-Reply-To: <49ED55FF.5080306@peterhost.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Jail limits under CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 15:51:45 -0000 Меньшиков КонÑтантин wrote: Hi. I`m rewrite jail limit patch under CURRENT. New patch limited CPU, memory, filedesc, process. And allow change limit on the fly You can download tar.gz from http://kostjn.spb.ru/patch-jail-limit-8CURRENT.tar.gz =========================================================================== How to use. =========================================================================== Build cvsup CURRENT cd /usr/src patch -p0 < patch-jail-limit-8CURRENT make buildkernel make buildworld make installkernel reboot make installworld Create new entry in login.conf, for example class jail128 jail128:\ :cputime=10:\ :memoryuse=128M:\ :maxproc=256:\ :openfiles=1024:\ :tc=default: Cputime is percent on 1 core. Openfiles is sum filedesc for all proc in jail. Create new jail. ... Add in /etc/rc.conf jail_test_flags="-Ljail128" Run new jail /etc/rc.d/jail start test =========================================================================== Sysctl =========================================================================== Added sysctl [root@book ~]# sysctl security.jail.limit security.jail.limit.enable: 1 security.jail.limit.memory_exceed_kill: 0 [root@book ~]# sysctl -d security.jail.limit security.jail.limit: Jail limit security.jail.limit.enable: Enable jail limit security.jail.limit.memory_exceed_kill: Kill biggest proc in jail, if jail excee d memory limit =========================================================================== Jset and Jget =========================================================================== jset and jget is program for set new jail limit and get current limit Example [root@book ~]# cat /etc/rc.conf | grep jail2 jail_list="jail1 jail2 jail3 jail4 jail5 jail6 jail7 jail8 jail9 jail10" jail_jail2_rootdir="/usr/jails/jail2/" jail_jail2_hostname="jail2.book.pht" jail_jail2_interface="re0" jail_jail2_ip="192.168.200.22" jail_jail2_flags="-Ljail64" [root@book ~]# /etc/rc.d/jail start jail2 Configuring jails:. Starting jails: jail2.book.pht. [root@book ~]# cd ~kostjn/ [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 6M, NPROC 9, NOFILE 65 [root@book /home/kostjn]# ./jset.o 1 jail2048 Set new jail limits, jid = 1 Limits: CPU 30, MEM 2048M, NPROC 1024, NOFILE 2048 [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 30, MEM 2048M, NPROC 1024, NOFILE 2048 Usage: CPU 0, MEM 6M, NPROC 9, NOFILE 65 You see that new limit is set. =========================================================================== Test =========================================================================== Cpu limit <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Script [root@book /home/kostjn]# cat test.sh #!/bin/sh for i in `jot 8 1`; do cpuset -l0 jexec 1 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 2 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 3 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 4 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 5 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 6 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 7 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 8 /a.out & done for i in `jot 8 1`; do cpuset -l0 jexec 9 /a.out & done cpuset -l0 jexec 10 /a.out & Set class for all jail. [root@book /home/kostjn]# for i in `jot 10 1`; do ./jset.o $i jail128 ;done Set new jail limits, jid = 1 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 2 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 3 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 4 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 5 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 6 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 7 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 8 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 9 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 Set new jail limits, jid = 10 Limits: CPU 10, MEM 128M, NPROC 256, NOFILE 1024 [root@book /home/kostjn]# jexec 1 bash [root@jail1 /]# cat cpu.c #include #include #include #include int main(int argc,char *argv[]){ int64_t i,j=0; char *s; for (;;){ } } Run test.sh Result top last pid: 3513; load averages: 70.87, 37.58, 16.40 up 0+00:44:02 14:19:46 185 processes: 74 running, 111 sleeping CPU: 49.9% user, 0.0% nice, 0.0% system, 0.2% interrupt, 49.9% idle Mem: 139M Active, 24M Inact, 47M Wired, 192K Cache, 29M Buf, 1785M Free Swap: 4044M Total, 4044M Free PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN 3502 10 root 1 97 0 1480K 1244K CPU0 0 0:13 8.79% a.out 3474 6 root 1 97 0 1480K 1244K RUN 0 0:04 4.69% a.out 3431 2 root 1 96 0 1480K 1244K RUN 0 0:03 4.30% a.out 3454 4 root 1 97 0 1480K 1244K RUN 0 0:03 4.05% a.out 3422 1 root 1 96 0 1480K 1244K RUN 0 0:04 3.86% a.out 3482 7 root 1 97 0 1480K 1244K RUN 0 0:03 3.86% a.out 3447 3 root 1 97 0 1480K 1244K RUN 0 0:03 3.86% a.out 3429 1 root 1 96 0 1480K 1244K RUN 0 0:03 3.66% a.out 3485 8 root 1 97 0 1480K 1244K RUN 0 0:05 3.56% a.out 3424 1 root 1 96 0 1480K 1244K RUN 0 0:04 3.56% a.out 3464 5 root 1 97 0 1480K 1244K RUN 0 0:02 3.56% a.out 3438 2 root 1 96 0 1480K 1244K RUN 0 0:03 3.47% a.out 3494 9 root 1 96 0 1480K 1244K RUN 0 0:03 3.27% a.out 3497 9 root 1 97 0 1480K 1244K RUN 0 0:05 3.17% a.out 3433 2 root 1 96 0 1480K 1244K RUN 0 0:03 2.88% a.out 3428 1 root 1 96 0 1480K 1244K RUN 0 0:02 2.88% a.out 3487 8 root 1 97 0 1480K 1244K RUN 0 0:04 2.78% a.out ps auxwwww -ojid | more root 3502 9.0 0.1 1480 1244 v2 RJ 2:15PM 0:07.40 /a.out 10 root 3476 4.4 0.1 1480 1244 v2 RJ 2:15PM 0:04.38 /a.out 7 root 3480 4.1 0.1 1480 1244 v2 RJ 2:15PM 0:03.02 /a.out 7 root 3498 3.9 0.1 1480 1244 v2 RJ 2:15PM 0:04.00 /a.out 9 root 3429 3.7 0.1 1480 1244 v2 RJ 2:15PM 0:01.38 /a.out 1 root 3487 3.6 0.1 1480 1244 v2 RJ 2:15PM 0:03.32 /a.out 8 root 3452 3.5 0.1 1480 1244 v2 RJ 2:15PM 0:01.37 /a.out 4 root 3463 3.5 0.1 1480 1244 v2 RJ 2:15PM 0:01.65 /a.out 5 root 3472 3.3 0.1 1480 1244 v2 RJ 2:15PM 0:02.63 /a.out 6 root 3437 3.2 0.1 1480 1244 v2 RJ 2:15PM 0:01.93 /a.out 2 root 3494 3.0 0.1 1480 1244 v2 RJ 2:15PM 0:02.92 /a.out 9 root 3500 3.0 0.1 1480 1244 v2 RJ 2:15PM 0:03.63 /a.out 9 We see that jail 10 (1 thread), used ~10 % cpu under heavy load. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Resourse compute [root@book /home/kostjn]# ./jset.o 1 jail64 Set new jail limits, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 6M, NPROC 9, NOFILE 65 [root@book /home/kostjn]# [root@book /home/kostjn]# jexec 1 bash [root@jail1 /]# apachectl stop /usr/local/sbin/apachectl stop: httpd stopped [root@jail1 /]# exit [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 3M, NPROC 3, NOFILE 24 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Resource limit [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 3M, NPROC 3, NOFILE 24 [root@book /home/kostjn]# jexec 1 bash [root@jail1 /]# cat mem.c #include #include #include #include int main(int argc,char *argv[]){ int64_t i,j=0; char *s; for (i=0; i < 1000 ;i++){ s = malloc(100000 * sizeof(char)); } sleep(1000); } [root@jail1 /]# cc mem.c && ./a.out & [1] 1320 [root@jail1 /]# ls bash: fork: Cannot allocate memory [root@jail1 /]# exit [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 1, MEM 103M, NPROC 5, NOFILE 31 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< We see that jail exceed memory limit. And new fork, mmap syscall not permitted. If you set sysctl [root@book /home/kostjn]# sysctl security.jail.limit.memory_exceed_kill=1 security.jail.limit.memory_exceed_kill: 1 -> 1 [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 3M, NPROC 3, NOFILE 24 [root@book /home/kostjn]# jexec 1 bash [root@jail1 /]# ./a.out Killed: 9 [root@jail1 /]# exit [root@book /home/kostjn]# tail -n 1 /var/log/messages May 20 14:10:17 book kernel: pid 1337 (a.out), uid 0, jid 1 was killed: Prison e xceed memory limit <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< If you attempt set nonexisten class, limit set to infinity. [root@book /home/kostjn]# ./jset.o 1 jail123 Set new jail limits, jid = 1 Limits: CPU 9223372036854775807, MEM 20M, NPROC 9223372036854775807, NOFILE 9223 372036854775807 =========================================================================== Problem =========================================================================== If you have problem in this patch. Add to kernel config options KTR options KTR_ENTRIES=1024 options KTR_COMPILE=(KTR_PROC|KTR_JAIL|KTR_SCHED|KTR_RUNQ|KTR_LOCK|KTR_CONTENTIO N) options KTR_MASK=KTR_JAIL options KTR_CPUMASK=0x3 options KTR_VERBOSE options PRINTF_BUFR_SIZE=128 Rebuild kernel. Reboot. Set sysctl sysctl debug.ktr.mask=65536 and check /var/log/messages From owner-freebsd-hackers@FreeBSD.ORG Wed May 20 17:39:30 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03EED1065673; Wed, 20 May 2009 17:39:30 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3E18FC17; Wed, 20 May 2009 17:39:29 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz9 with SMTP id 9so564107bwz.43 for ; Wed, 20 May 2009 10:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iT74WRbkEE08CcasNrFC074623Kmt9vTBEPYVWn8QJg=; b=Yl9Xhqu8KUz17rbWgkFTGM6aKtRE6At9Tdif0QWxef3SVmqBViyTptqirjrrJYSJrI yxh69TAkZ1BQ1FjtM016wd9XgIO+2XdLo7xA7Lh+nHrDrsmvPo3EKKcpxUMFMua3E4dJ i9Wpz4aJXr5eI/S6TZBcHSUtbn2bgfV6rVO6Q= 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=FXtvTFhr7IYHT3M152Fqmh3UzB2Yu+TVGMsrrT6prwaxd/GKVed9SCUvyCd3A5kua6 AmaHpp7bD+x3orn1G6Nx3j9zyPEj42k53ELslQJ/Kwa0TSCjwK9r2FVQg3GxvCExB+K+ hmoZW4Okp1NQDg3uvjIEtvCKjdOrmqliehWQg= MIME-Version: 1.0 Received: by 10.204.57.79 with SMTP id b15mr1469237bkh.70.1242841168213; Wed, 20 May 2009 10:39:28 -0700 (PDT) In-Reply-To: <4A1417B3.3030303@andric.com> References: <4ad871310905181949s2874795eoa5ddf425746310bf@mail.gmail.com> <4A13E180.1040606@andric.com> <4A13E6F7.7070309@glocalnet.net> <4A13E906.7020907@andric.com> <4ad871310905200740n744f9b83j96db2a3c1a6bec43@mail.gmail.com> <4A1417B3.3030303@andric.com> Date: Wed, 20 May 2009 13:39:28 -0400 Message-ID: <4ad871310905201039nb17251cueedd11f54ad8806@mail.gmail.com> From: Glen Barber To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:39:30 -0000 Hi, Dimitry On Wed, May 20, 2009 at 10:46 AM, Dimitry Andric wrote= : > On 2009-05-20 16:40, Glen Barber wrote: >> sshd was listening on :25, both IPv4 and IPv6 >> sendmail was listening on :25 (because I had forgotten to disable it) >> >> The system boots, and sendmail starts before sshd. =A0When sshd starts >> (or tries to) there is no console output that it had failed. =A0The only >> way you realize it is not running, is when you cannot remotely log in. > > Yes, this is unfortunate, but normal, as I explained in an earlier post. > > The sshd process does not return any error (and thus the /etc/rc.d > script doesn't either), because it has no way to know that its forked > copy died. > > The solution to this PR is "don't run stuff on conflicting ports". :) > I absolutely agree about not running sshd on conflicting ports. After a bit more testing, I found that "most" other services will complain when they cannot obtain the requested socket, and you will see a failure notice via the rc.d script. My concern is when someone has a "definite need" to run sshd on a non-standard port less than, say 1024 for example. This is the real reason I initially created the PR and posted to hackers@ about this -- I'd like to fix it. But, I want to fix it the right way, and not hack a crude solution. Regards, --=20 Glen Barber From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 00:53:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C192106566C for ; Thu, 21 May 2009 00:53:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD908FC1A for ; Thu, 21 May 2009 00:53:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E69891A3C3B; Wed, 20 May 2009 17:36:46 -0700 (PDT) Date: Wed, 20 May 2009 17:36:46 -0700 From: Alfred Perlstein To: Chuck Robey Message-ID: <20090521003646.GS67847@elvis.mu.org> References: <4A11B893.1000808@telenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A11B893.1000808@telenix.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-Hackers Subject: Re: porting info for FreeBSD's kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 00:53:16 -0000 * Chuck Robey [090518 13:03] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've been googling, trying to see if I can find notes regarding what needs > changing, in what order, to adapt the FreeBSD kernel to a new processor. Anyone > know where stuff like that can be found? You need a cross compile toolchain of course, look into how FreeBSD is configured for the various arches. Then I would suggest looking at the loaders, followed by kern/init_main.c. If you trace down init_main.c and some of the early sysinits that should give you an idea. You might also be able to backtrack using CVS/svn to follow how mips or arm was done. Note: freebsd has a decent cross-compile setup now, see "make universe" so things should be easier to get started. -- - Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 06:32:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DCE106566C for ; Thu, 21 May 2009 06:32:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 247FE8FC1C for ; Thu, 21 May 2009 06:32:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-35-171.dsl.snfc21.pacbell.net [71.139.35.171]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n4L6WoZV015095 for ; Wed, 20 May 2009 23:32:50 -0700 (PDT) Message-ID: <4A14F58F.8000801@rawbw.com> Date: Wed, 20 May 2009 23:32:47 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? 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: Thu, 21 May 2009 06:32:51 -0000 Seems like failing system calls (mmap and sbrk) that allocate memory is more graceful and would allow the program to at least issue the reasonable error message. And more intelligent programs would be able to reduce used memory instead of just dying. Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 07:15:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5621D106566B for ; Thu, 21 May 2009 07:15:24 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA5C8FC1C for ; Thu, 21 May 2009 07:15:24 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) 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 n4L7FNo21758; Thu, 21 May 2009 00:15:23 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n4L7FN321461; Thu, 21 May 2009 00:15:23 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 21 May 2009 00:15:23 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Yuri In-Reply-To: <4A14F58F.8000801@rawbw.com> Message-ID: References: <4A14F58F.8000801@rawbw.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 07:15:24 -0000 On Wed, 20 May 2009, Yuri wrote: > Seems like failing system calls (mmap and sbrk) that allocate memory is more > graceful and would allow the program to at least issue the reasonable error > message. > And more intelligent programs would be able to reduce used memory instead of > just dying. It's a feature, called "memory overcommit". It has a variety of pros and cons, and is somewhat controversial. One advantage is that programs often allocate memory (in various ways) that they will never use, which under a conservative policy would result in that memory being wasted, or programs failing unnecessarily. With overcommit, you sometimes allocate more memory than you have, on the assumption that some of it will not actually be needed. Although memory allocated by mmap and sbrk usually does get used in fairly short order, there are other ways of allocating memory that are easy to overlook, and which may "allocate" memory that you don't actually intend to use. Probably the best example is fork(). For instance, consider the following program. #define SIZE 1000000000 /* 1 GB */ int main(void) { char *buf = malloc(SIZE); /* 1 GB */ memset(buf, 'x', SIZE); /* touch the buffer */ pid_t pid = fork(); if (pid == 0) { execlp("true", "true", (char *)NULL); perror("true"); _exit(1); } else if (pid > 0) { for (;;); /* do work */ } else { perror("fork"); exit(1); } return 0; } Suppose we run this program on a machine with just over 1 GB of memory. The fork() should give the child a private "copy" of the 1 GB buffer, by setting it to copy-on-write. In principle, after the fork(), the child might want to rewrite the buffer, which would require an additional 1GB to be available for the child's copy. So under a conservative allocation policy, the kernel would have to reserve that extra 1 GB at the time of the fork(). Since it can't do that on our hypothetical 1+ GB machine, the fork() must fail, and the program won't work. However, in fact that memory is not going to be used, because the child is going to exec() right away, which will free the child's "copy". Indeed, this happens most of the time with fork() (but of course the kernel can't know when it will or won't.) With overcommit, we pretend to give the child a writable private copy of the buffer, in hopes that it won't actually use more of it than we can fulfill with physical memory. If it doesn't use it, all is well; if it does use it, then disaster occurs and we have to start killing things. So the advantage is you can run programs like the one above on machines that technically don't have enough memory to do so. The disadvantage, of course, is that if someone calls the bluff, then we kill random processes. However, this is not all that much worse than failing allocations: although programs can in theory handle failed allocations and respond accordingly, in practice they don't do so and just quit anyway. So in real life, both cases result in disaster when memory "runs out"; with overcommit, the disaster is a little less predictable but happens much less often. If you google for "memory overcommit" you will see lots of opinions and debate about this feature on various operating systems. There may be a way to enable the conservative behavior; I know Linux has an option to do this, but am not sure about FreeBSD. This might be useful if you are paranoid, or run programs that you know will gracefully handle running out of memory. IMHO for general use it is better to have overcommit, but I know there are those who disagree. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 07:19:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1374106564A for ; Thu, 21 May 2009 07:19:20 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 4488D8FC12 for ; Thu, 21 May 2009 07:19:20 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: by fxm12 with SMTP id 12so882215fxm.43 for ; Thu, 21 May 2009 00:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SA/G8otAvlAMT8KJRu8NEBeaBlJNz31l8R4D6bu7ITM=; b=XgE5KJR06wqDbd6VWCU69AEaBjzxDoEJ57PlCPUgKbSYTWAOFBBx67MSNwmXla3p/o WlmS2dmZQBG0WoS7m/qPZQFUfD9yq3HTo+8AM42/wjtnQv0zV7F9ocm5so/QGnpBtEf7 U0yFnFh10xZFoFVaLj8MncujqZjE99NuUzJAQ= 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=RdLRTM9XvMn03AfLdGxmA+B34bQAZJb6sw9Q1iIh7f9MU2G2oZBab4jt9ky9LaANI/ szrCQAC9x6uudH+cWTl30Wuwx8sS8+7lokfxlxm6X/bVNTEDktIdeapQmgC3gtRvUv9d 046Be0Myjl5PvBzlhAmQiOy0o3h7x95A58Nc4= MIME-Version: 1.0 Received: by 10.239.129.194 with SMTP id 2mr158605hbg.93.1242888999356; Wed, 20 May 2009 23:56:39 -0700 (PDT) In-Reply-To: <4A14F58F.8000801@rawbw.com> References: <4A14F58F.8000801@rawbw.com> Date: Thu, 21 May 2009 01:56:39 -0500 Message-ID: <73a01bf20905202356t5fd65eb5n7ec97f6c318e6045@mail.gmail.com> From: Rayson Ho To: yuri@rawbw.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 07:19:20 -0000 Because the kernel is lazy!! You can google for "lazy algorithm", or find an OS internals book and read about the advantages of doing it this way... Rayson On Thu, May 21, 2009 at 1:32 AM, Yuri wrote: > Seems like failing system calls (mmap and sbrk) that allocate memory is more > graceful and would allow the program to at least issue the reasonable error > message. > And more intelligent programs would be able to reduce used memory instead of > just dying. > > Yuri > > _______________________________________________ > 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 21 08:12:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C051065670 for ; Thu, 21 May 2009 08:12:51 +0000 (UTC) (envelope-from elias@artx.ru) Received: from round.artx.ru (round.artx.ru [80.73.175.73]) by mx1.freebsd.org (Postfix) with ESMTP id C4F188FC18 for ; Thu, 21 May 2009 08:12:50 +0000 (UTC) (envelope-from elias@artx.ru) Received: by round.artx.ru (Postfix, from userid 1001) id C183C5C29; Thu, 21 May 2009 11:39:18 +0400 (MSD) Date: Thu, 21 May 2009 11:39:18 +0400 From: Ilya Orehov To: Yuri Message-ID: <20090521073918.GA54618@artx.ru> Mail-Followup-To: Ilya Orehov , Yuri , freebsd-hackers@freebsd.org References: <4A14F58F.8000801@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4A14F58F.8000801@rawbw.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 08:12:51 -0000 +------- Yuri, 2009-05-20 ------- | Seems like failing system calls (mmap and sbrk) that allocate memory is more | graceful and would allow the program to at least issue the reasonable | error message. | And more intelligent programs would be able to reduce used memory | instead of just dying. Hi! You can set memory limit to achieve your goal: tcsh% limit vmemoryuse 20M In this case, malloc(1000000000) will return 0. Ilya. | | Yuri | | _______________________________________________ | 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 21 08:21:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85E24106564A for ; Thu, 21 May 2009 08:21:50 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5E66D8FC13 for ; Thu, 21 May 2009 08:21:50 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n4L8Lnst050356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 May 2009 01:21:49 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n4L8Lnfx050355; Thu, 21 May 2009 01:21:49 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01437; Thu, 21 May 09 01:06:49 PDT Date: Thu, 21 May 2009 01:06:19 -0700 From: perryh@pluto.rain.com To: yuri@rawbw.com, neldredge@math.ucsd.edu Message-Id: <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com> References: <4A14F58F.8000801@rawbw.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 08:21:50 -0000 Nate Eldredge wrote: > For instance, consider the following program. > this happens most of the time with fork() ... It may be worthwhile to point out that one extremely common case is the shell itself. Even /bin/sh is large; csh (the default FreeBSD shell) is quite a bit larger and bash larger yet. The case of "big program forks, and the child process execs a small program" arises almost every time a shell command (other than a built-in) is executed. > With overcommit, we pretend to give the child a writable private > copy of the buffer, in hopes that it won't actually use more of it > than we can fulfill with physical memory. I am about 99% sure that the issue involves virtual memory, not physical, at least in the fork/exec case. The incidence of such events under any particular system load scenario can be reduced or eliminated simply by adding swap space. From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 09:53:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79A51065677 for ; Thu, 21 May 2009 09:53:09 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 582F48FC0A for ; Thu, 21 May 2009 09:53:09 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so1108580ewy.43 for ; Thu, 21 May 2009 02:53:08 -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=x/NBjfU+zWVc0GBzdZCUWy3kScI0rkAjKXRRGMCbwsU=; b=w1e6IIkYM4OsAbG8FYo1Cz9f15d/GWpfl/0/hHg7qy8YwMaEnvI+LxpBy+zcNIo9pu 7mUm7d8cOgltJCZukhMElHSZrfmmukMjGo+v1EWY5QDvmpMds8Y7xczH7lpkA56qlVbL dPwKZwRzsqHBZDUYaQlfU5I2uNSw94m5REPsY= 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=GqtwT/JOjRrH0KIHMt+92gXwyZB9tYpowmCGFaThWV2fXQoTsbglQDT3mL/gnyt+YL y2CB9W7QjCvUqt8xeSfLbWbScSjnn2oDNovw8AVnRTX1cLhWaam7jrrvLB/YyJkrrZxE ZDDda6Vv4hwkMKEbFNgGrnso7rZ1XyXIhkZI0= Received: by 10.210.36.8 with SMTP id j8mr781865ebj.38.1242899587511; Thu, 21 May 2009 02:53:07 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 23sm1549751ewy.44.2009.05.21.02.53.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 May 2009 02:53:07 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 319B65D59; Thu, 21 May 2009 09:53:05 +0000 (UTC) Date: Thu, 21 May 2009 10:53:05 +0100 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20090521095305.GA27043@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: compiling system binutils as cross 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: Thu, 21 May 2009 09:53:10 -0000 Hi. How do I compile the system binutils (contrib/binutils) as i386 -> x86_64 cross utils? That is, binutils that will run on an i386 host but will produce x86_64 binaries? I'm trying to produce a bootstrapping compiler for a port and need to get these working. I've spent a while reading Makefiles but would rather get information from someone who actually knows rather than waste *another* week on this stuff. I'd rather not compile the entire world if it can be avoided. cheers, xw From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 10:20:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7FE61065674 for ; Thu, 21 May 2009 10:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 93F4A8FC1C for ; Thu, 21 May 2009 10:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 334E746B17; Thu, 21 May 2009 06:20:21 -0400 (EDT) Date: Thu, 21 May 2009 11:20:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: xorquewasp@googlemail.com In-Reply-To: <20090521095305.GA27043@logik.internal.network> Message-ID: References: <20090521095305.GA27043@logik.internal.network> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 10:20:22 -0000 On Thu, 21 May 2009, xorquewasp@googlemail.com wrote: > How do I compile the system binutils (contrib/binutils) as i386 -> x86_64 > cross utils? That is, binutils that will run on an i386 host but will > produce x86_64 binaries? > > I'm trying to produce a bootstrapping compiler for a port and need to get > these working. I've spent a while reading Makefiles but would rather get > information from someone who actually knows rather than waste *another* week > on this stuff. > > I'd rather not compile the entire world if it can be avoided. Not really my area, but if you haven't found "make toolchain" and "make buildenv" then you might want to take a look. Typically these will be combined with TARGET_ARCH=foo, and in your case foo is 'amd64'. The former builds the toolchain required for the architecture, and the latter creates a shell environment with paths appropriately munged and environments appropriately set to cross-compile using that chain. Normally the toolchain step is part of our integrated buildworld/buildkernel/etc process, but you can also use it for other things with buildenv. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 11:55:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54159106566B for ; Thu, 21 May 2009 11:55:05 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id AAB528FC17 for ; Thu, 21 May 2009 11:55:04 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 9so250275eyd.7 for ; Thu, 21 May 2009 04:55:03 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=G5wcWZIQI/9kz7pHWKrcI7mjqQvstuLXmbQwsJzUqoo=; b=Hw9z6Cqw2hLfndY5xIFNJf+zIGQn1hI9QxzOJSOZbGlHOxAHmaRLmYgKeKNC2sooP3 nW8++ZPGHgaxHhfR50aiHe67LPjlNwR98wQZ+jRt9YKSj5LzExbeWWf+/DF6aVOpSxE4 0iFFmxk/vYwcftyU5jZ9UQZujbOHcyh1Qut80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=ZM8G8zfDJGWf2S5Nr01wcILFy8l4lo9Xw2oVpJemrsym2W5+ASZcLQLZhZnc7I9HQC rOrE83GGqkizd+nmdzqNV3TcsglZ0IcatxRJbZ8WeqZ9unTlLVGCPL9CRp/1enkmVjQz 4vCbPJNPBlf2xVfOodGgyMYRBUz3n97L2EMUQ= Received: by 10.210.137.17 with SMTP id k17mr925969ebd.99.1242906902653; Thu, 21 May 2009 04:55:02 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 9sm1791257ewy.57.2009.05.21.04.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 May 2009 04:55:00 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 5C20D5D59; Thu, 21 May 2009 11:54:58 +0000 (UTC) Date: Thu, 21 May 2009 12:54:58 +0100 From: xorquewasp@googlemail.com To: Robert Watson Message-ID: <20090521115458.GA54961@logik.internal.network> References: <20090521095305.GA27043@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 11:55:05 -0000 On 2009-05-21 11:20:21, Robert Watson wrote: > Not really my area, but if you haven't found "make toolchain" and "make > buildenv" then you might want to take a look. Typically these will be > combined with TARGET_ARCH=foo, and in your case foo is 'amd64'. The > former builds the toolchain required for the architecture, and the latter > creates a shell environment with paths appropriately munged and > environments appropriately set to cross-compile using that chain. > Normally the toolchain step is part of our integrated > buildworld/buildkernel/etc process, but you can also use it for other > things with buildenv. Thanks, 'make toolchain' looks like it'll work. 'make buildenv' gave me the paths to the binaries I needed to tell the compiler I'm working on to use those for cross compilation. What tangled webs we weave... cheers, xw From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 12:10:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4140110656A6 for ; Thu, 21 May 2009 12:10:27 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id E83D38FC15 for ; Thu, 21 May 2009 12:10:26 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id 17E238FC4F for ; Thu, 21 May 2009 16:10:24 +0400 (MSD) Received: from localhost (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id E257D8FC4E; Thu, 21 May 2009 16:10:23 +0400 (MSD) Date: Thu, 21 May 2009 16:10:18 +0400 From: Stanislav Sedov To: xorquewasp@googlemail.com Message-ID: <20090521161018.66b3015c@FreeBSD.org> In-Reply-To: <20090521095305.GA27043@logik.internal.network> References: <20090521095305.GA27043@logik.internal.network> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu May 21 16:10:24 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4a1544b0994291380925937 Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 12:10:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 21 May 2009 10:53:05 +0100 xorquewasp@googlemail.com mentioned: > Hi. > > How do I compile the system binutils (contrib/binutils) as i386 -> > x86_64 cross utils? That is, binutils that will run on an i386 host but > will produce x86_64 binaries? > > I'm trying to produce a bootstrapping compiler for a port and need to > get these working. I've spent a while reading Makefiles but would rather > get information from someone who actually knows rather than waste > *another* week on this stuff. > > I'd rather not compile the entire world if it can be avoided. > You can also try using devel/cross-binutils to build cross-tools for x86_64-freebsd. Random people reported they're working fine. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoVRK4ACgkQK/VZk+smlYGbjwCff1f6hJ+PAE4OSqPV7IIQi8kY 8iwAn2CcQ3H9D5Q+mZdern+11PgRGapq =Amr/ -----END PGP SIGNATURE----- !DSPAM:4a1544b0994291380925937! From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 16:00:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DA210656C0 for ; Thu, 21 May 2009 16:00:37 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id B3BB88FC0A for ; Thu, 21 May 2009 16:00:37 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) 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 n4LG0bo07233; Thu, 21 May 2009 09:00:37 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n4LG0bO22110; Thu, 21 May 2009 09:00:37 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 21 May 2009 09:00:37 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: perryh@pluto.rain.com In-Reply-To: <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com> Message-ID: References: <4A14F58F.8000801@rawbw.com> <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: neldredge@math.ucsd.edu, yuri@rawbw.com, freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 16:00:38 -0000 On Thu, 21 May 2009, perryh@pluto.rain.com wrote: > Nate Eldredge wrote: >> With overcommit, we pretend to give the child a writable private >> copy of the buffer, in hopes that it won't actually use more of it >> than we can fulfill with physical memory. > > I am about 99% sure that the issue involves virtual memory, not > physical, at least in the fork/exec case. The incidence of such > events under any particular system load scenario can be reduced or > eliminated simply by adding swap space. True. When I said "a system with 1GB of memory", I should have said "a system with 1 GB of physical memory + swap". -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 16:44:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7FAF106567C for ; Thu, 21 May 2009 16:44:46 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 383D48FC0A for ; Thu, 21 May 2009 16:44:46 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so1353798ewy.43 for ; Thu, 21 May 2009 09:44:45 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=C+K/I2CWVMPPJNAzORJf0vMwtmdhX+9Rsp27njppIU0=; b=YzE60dYYyKUr4FsrtxHg0LjW2uJ7iwHS3e3jDGetS7xPWA6BH+6UQ/1gnRQSH/2QEP kbJE76u+rGpO9FeFKUh+1f3KlKnXYdWUVyFAqAhehDJC8zzQyAEJwIg1AaXjnZOu3m0U P6O+P4V5D0IlQ+ujVQGz9lYTrwsZe5CTFpgzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=wqZJ4BaTfQ/jYyvwUB3gJsuibqK65r6zOXt40p4FO+U2RpHOYdR+ExaK/R2JMjRnXi puBb3NtMr2OMOvjDGNIiIU3vzERkmu6ddSJZiqgyhFCEO+uXB1eVr4fc0YbRP09Ig4lp MhfObu/KHBOOz5W5BGz+6249YGiUfeWTvidDY= Received: by 10.210.35.5 with SMTP id i5mr3501001ebi.29.1242924284548; Thu, 21 May 2009 09:44:44 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 11sm2154039ewy.50.2009.05.21.09.44.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 May 2009 09:44:43 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 4A9615D59; Thu, 21 May 2009 16:44:42 +0000 (UTC) Date: Thu, 21 May 2009 17:44:42 +0100 From: xorquewasp@googlemail.com To: Stanislav Sedov Message-ID: <20090521164442.GA59069@logik.internal.network> References: <20090521095305.GA27043@logik.internal.network> <20090521161018.66b3015c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090521161018.66b3015c@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 16:44:47 -0000 On 2009-05-21 16:10:18, Stanislav Sedov wrote: > You can also try using devel/cross-binutils to build cross-tools for > x86_64-freebsd. Random people reported they're working fine. Unfortunately, as noted in this thread: http://marc.info/?l=freebsd-hackers&m=124146166902690&w=2 Using that port works but creates a compiler that emits code that can't be assembled by the default system binutils. Not great for a port... xw From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 17:49:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2846E1065672 for ; Thu, 21 May 2009 17:49:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outr.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 08DEA8FC0C for ; Thu, 21 May 2009 17:49:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id DD54F14DD04; Thu, 21 May 2009 10:49:23 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 05A162D601C; Thu, 21 May 2009 10:49:22 -0700 (PDT) Message-ID: <4A159423.2040500@elischer.org> Date: Thu, 21 May 2009 10:49:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Watson References: <20090521095305.GA27043@logik.internal.network> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, xorquewasp@googlemail.com Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 17:49:24 -0000 Robert Watson wrote: > > On Thu, 21 May 2009, xorquewasp@googlemail.com wrote: > >> How do I compile the system binutils (contrib/binutils) as i386 -> >> x86_64 cross utils? That is, binutils that will run on an i386 host >> but will produce x86_64 binaries? >> >> I'm trying to produce a bootstrapping compiler for a port and need to >> get these working. I've spent a while reading Makefiles but would >> rather get information from someone who actually knows rather than >> waste *another* week on this stuff. >> >> I'd rather not compile the entire world if it can be avoided. > > Not really my area, but if you haven't found "make toolchain" and "make > buildenv" then you might want to take a look. Typically these will be > combined with TARGET_ARCH=foo, and in your case foo is 'amd64'. The > former builds the toolchain required for the architecture, and the > latter creates a shell environment with paths appropriately munged and > environments appropriately set to cross-compile using that chain. > Normally the toolchain step is part of our integrated > buildworld/buildkernel/etc process, but you can also use it for other > things with buildenv. I munged that once to create a nested jail/chroot set up so that default toolchain was the cross set. so if you did 'cc foo.c' you got a cross binary.. if you needed a native cc you did it in the outside chroot. worked like a charm. from the outside, you just did 'chroot cross cc foo.c' to get cross binary. > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 21 17:52:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BBEC1065670 for ; Thu, 21 May 2009 17:52:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 777D28FC1E for ; Thu, 21 May 2009 17:52:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-35-171.dsl.snfc21.pacbell.net [71.139.35.171]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n4LHqSfp051284; Thu, 21 May 2009 10:52:28 -0700 (PDT) Message-ID: <4A1594DA.2010707@rawbw.com> Date: Thu, 21 May 2009 10:52:26 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Nate Eldredge References: <4A14F58F.8000801@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? 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: Thu, 21 May 2009 17:52:29 -0000 Nate Eldredge wrote: > Suppose we run this program on a machine with just over 1 GB of > memory. The fork() should give the child a private "copy" of the 1 GB > buffer, by setting it to copy-on-write. In principle, after the > fork(), the child might want to rewrite the buffer, which would > require an additional 1GB to be available for the child's copy. So > under a conservative allocation policy, the kernel would have to > reserve that extra 1 GB at the time of the fork(). Since it can't do > that on our hypothetical 1+ GB machine, the fork() must fail, and the > program won't work. I don't have strong opinion for or against "memory overcommit". But I can imagine one could argue that fork with intent of exec is a faulty scenario that is a relict from the past. It can be replaced by some atomic method that would spawn the child without ovecommitting. Are there any other than fork (and mmap/sbrk) situations that would overcommit? Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 19:37:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D9D1065674 for ; Thu, 21 May 2009 19:37:11 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 840A38FC29 for ; Thu, 21 May 2009 19:37:10 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n4LJOKEc013250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 May 2009 21:24:20 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n4LJNxP8064228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2009 21:23:59 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n4LJNwUT054745; Thu, 21 May 2009 21:23:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n4LJNuT6054744; Thu, 21 May 2009 21:23:56 +0200 (CEST) (envelope-from ticso) Date: Thu, 21 May 2009 21:23:56 +0200 From: Bernd Walter To: Yuri Message-ID: <20090521192356.GA54607@cicely7.cicely.de> References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1594DA.2010707@rawbw.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Nate Eldredge , freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 19:37:12 -0000 On Thu, May 21, 2009 at 10:52:26AM -0700, Yuri wrote: > Nate Eldredge wrote: > >Suppose we run this program on a machine with just over 1 GB of > >memory. The fork() should give the child a private "copy" of the 1 GB > >buffer, by setting it to copy-on-write. In principle, after the > >fork(), the child might want to rewrite the buffer, which would > >require an additional 1GB to be available for the child's copy. So > >under a conservative allocation policy, the kernel would have to > >reserve that extra 1 GB at the time of the fork(). Since it can't do > >that on our hypothetical 1+ GB machine, the fork() must fail, and the > >program won't work. > > I don't have strong opinion for or against "memory overcommit". But I > can imagine one could argue that fork with intent of exec is a faulty > scenario that is a relict from the past. It can be replaced by some > atomic method that would spawn the child without ovecommitting. > > Are there any other than fork (and mmap/sbrk) situations that would > overcommit? If your system has enough virtual memory for working without overcommitment it will run fine with overcommitment as well. If you don't have enough memory it can do much more with overcommitment. A simple apache process needing 1G and serving 1000 Clients would need 1TB swap without ever touching it. Same for small embedded systems with limited swap. So the requirement of overcomittment is not just a requirement of old days. Overcomittment is even used more and more. An example are snapshots, which are popular these days can lead to space failure in case you rewrite a file with new data without growing its length. The old sparse file concept is also one of them, which can confuse unaware software. And then we have geom_virstore since a while. Many modern databases do it as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 21:12:01 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE2871065672 for ; Thu, 21 May 2009 21:12:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id B38258FC0C for ; Thu, 21 May 2009 21:12:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7FYW-0009oJ-FA; Thu, 21 May 2009 21:12:00 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 3F416188307E; Thu, 21 May 2009 14:12:00 -0700 (PDT) Date: Thu, 21 May 2009 14:12:00 -0700 Message-ID: From: Randy Bush To: Dario Freni User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 21 May 2009 21:17:05 +0000 Cc: hackers@freebsd.org Subject: Re: Installation from USB pen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 21:12:02 -0000 i succeeded with putting 8-current snap on a pen and booting. but i can not figure out how to tell it to use the pen drive for system image loads. do i have to back off to 7 and then upgrade forward after install? rndy From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 21:37:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE63B106564A for ; Thu, 21 May 2009 21:37:21 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD0A8FC1A for ; Thu, 21 May 2009 21:37:21 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) 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 n4LLbLo02473; Thu, 21 May 2009 14:37:21 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n4LLbLZ23776; Thu, 21 May 2009 14:37:21 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 21 May 2009 14:37:20 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Yuri In-Reply-To: <4A1594DA.2010707@rawbw.com> Message-ID: References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 21:37:22 -0000 On Thu, 21 May 2009, Yuri wrote: > Nate Eldredge wrote: >> Suppose we run this program on a machine with just over 1 GB of memory. The >> fork() should give the child a private "copy" of the 1 GB buffer, by >> setting it to copy-on-write. In principle, after the fork(), the child >> might want to rewrite the buffer, which would require an additional 1GB to >> be available for the child's copy. So under a conservative allocation >> policy, the kernel would have to reserve that extra 1 GB at the time of the >> fork(). Since it can't do that on our hypothetical 1+ GB machine, the >> fork() must fail, and the program won't work. > > I don't have strong opinion for or against "memory overcommit". But I can > imagine one could argue that fork with intent of exec is a faulty scenario > that is a relict from the past. It can be replaced by some atomic method that > would spawn the child without ovecommitting. I would say rather it's a centerpiece of Unix design, with an unfortunate consequence. Actually, historically this would have been much more of a problem than at present, since early Unix systems had much less memory, no copy-on-write, and no virtual memory (this came in with BSD, it appears; it's before my time.) The modern "atomic" method we have these days is posix_spawn, which has a pretty complicated interface if you want to use pipes or anything. It exists mostly for the benefit of systems whose hardware is too primitive to be able to fork() in a reasonable manner. The old way to avoid the problem of needing this extra memory temporarily was to use vfork(), but this has always been a hack with a number of problems. IMHO neither of these is preferable in principle to fork/exec. Note another good example is a large process that forks, but the child rather than exec'ing performs some simple task that writes to very little of its "copied" address space. Apache does this, as Bernd mentioned. This also is greatly helped by having overcommit, but can't be circumvented by replacing fork() with something else. If it really doesn't need to modify any of its shared address space, a thread can sometimes be used instead of a forked subprocess, but this has issues of its own. Of course all these problems are solved, under any policy, by having more memory or swap. But overcommit allows you to do more with less. > Are there any other than fork (and mmap/sbrk) situations that would > overcommit? Perhaps, but I can't think of good examples offhand. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 21:56:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11AD31065673 for ; Thu, 21 May 2009 21:56:05 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id E18A48FC12 for ; Thu, 21 May 2009 21:56:04 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 5065 invoked from network); 21 May 2009 21:56:04 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 May 2009 21:56:04 -0000 Message-ID: <4A15CE00.4040600@telenix.org> Date: Thu, 21 May 2009 17:56:16 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: Alfred Perlstein References: <4A11B893.1000808@telenix.org> <20090521003646.GS67847@elvis.mu.org> In-Reply-To: <20090521003646.GS67847@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: porting info for FreeBSD's kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:56:05 -0000 Alfred Perlstein wrote: > * Chuck Robey [090518 13:03] wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I've been googling, trying to see if I can find notes regarding what needs >> changing, in what order, to adapt the FreeBSD kernel to a new processor. Anyone >> know where stuff like that can be found? > > You need a cross compile toolchain of course, look into how FreeBSD > is configured for the various arches. > > Then I would suggest looking at the loaders, followed by > kern/init_main.c. If you trace down init_main.c and some > of the early sysinits that should give you an idea. > > You might also be able to backtrack using CVS/svn to follow > how mips or arm was done. > > Note: freebsd has a decent cross-compile setup now, see > "make universe" so things should be easier to get started. > Thanks. I will *definitely* read all the parts you hint me at, I won't be deleting this mail, and I appreciate it. I was asking on the llvm maillist about Cortex-A8 support. What I got says that it's not there yet, but it's being worked upon, that and the -A9 support (definite differences). So, any crosstools needed today would have to be gcc, from a version at least as new as the 4.3 branch (that's where they brought in the -A8 support). The tool I got by doing the freeBSD crosstools was 4.2.1, which isn't going to do it for the Cortex-A8, and I had someone else (from a FreeBSD list) tell me that bringing in a newer version of gcc wasn't extremely likely, that they'd want llvm instead. I see 3 alternatives for a Cortex-A8 port: using a new gcc port, waiting on the upgrade of llvm, or maybe deciding that the version the llvm that's out now, with the v6 compatibility, would be (for the short term) good enough. Any idea which one to choose? The only one that interests me is for the TI OMAP 3530 (Cortex-A8, among other parts). Maybe if the currently available llvm is good enough, maybe gcc-4.2.1 may creak along well enough for the short term? I need to understand this. My own personal Pandora won't probably won't arrive on my doorstep for maybe as long as 3 more months, so in the meantime, I think I will be reading all I can get my hands on regarding llvm. Maybe I can really learn enough to make a difference. In school, I concentrated very definitely on OSes (I've written 3 of them over the years, of quite varying levels of performance), so for compilers, I'm relying on my old 1988 version of the Aho/Sethi/Ullman compilers book. If anyone knows a more modern book that will show me enough about compilers to be useful, I'd really appreciate the name, maybe Amazon will let me get a cheap used version. From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 22:15:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C501C106564A for ; Thu, 21 May 2009 22:15:24 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id A83DD8FC20 for ; Thu, 21 May 2009 22:15:24 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 32488 invoked from network); 21 May 2009 22:15:24 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 May 2009 22:15:24 -0000 Message-ID: <4A15D288.3060008@telenix.org> Date: Thu, 21 May 2009 18:15:36 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: FreeBSD-Hackers , Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: about building the crosstools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 22:15:25 -0000 I got instructions from Warner about how to build my crosstools (the FreeBSD ones) and after a minor startup contretemps, things began to work better. My problem is that on doing the linking step, I'm getting a complaint that it can't figure out how to build the /usr/cross/usr/lib/libc.a (/usr/cross being my toolls destdir). I don't know how to fix this in the build, so I'd appreciate any hints. I mean, it *seems* to me that these tools are meant to run on my current host (i386), not the target (arm) so it really should already know about my /usr/lib/libc.a (or shared version)) right? From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 22:30:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 652F6106564A for ; Thu, 21 May 2009 22:30:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 261178FC08 for ; Thu, 21 May 2009 22:30:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n4LMSegO091156; Thu, 21 May 2009 16:28:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 21 May 2009 16:28:51 -0600 (MDT) Message-Id: <20090521.162851.439727948.imp@bsdimp.com> To: chuckr@telenix.org From: "M. Warner Losh" In-Reply-To: <4A15D288.3060008@telenix.org> References: <4A15D288.3060008@telenix.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: about building the crosstools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 22:30:55 -0000 In message: <4A15D288.3060008@telenix.org> Chuck Robey writes: : I got instructions from Warner about how to build my crosstools (the FreeBSD : ones) and after a minor startup contretemps, things began to work better. My : problem is that on doing the linking step, I'm getting a complaint that it can't : figure out how to build the /usr/cross/usr/lib/libc.a (/usr/cross being my : toolls destdir). I don't know how to fix this in the build, so I'd appreciate : any hints. I mean, it *seems* to me that these tools are meant to run on my : current host (i386), not the target (arm) so it really should already know about : my /usr/lib/libc.a (or shared version)) right? You may have some contamination. The xdev targets doesn't use /usr/cross at all. I'd blow that away entirely and try again. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 22:46:52 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1B68106566B for ; Thu, 21 May 2009 22:46:52 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 944F88FC1A for ; Thu, 21 May 2009 22:46:52 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id BC1C58FC1D for ; Fri, 22 May 2009 02:46:50 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 57C058FC18; Fri, 22 May 2009 02:46:50 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 99F1F3982B; Fri, 22 May 2009 02:47:29 +0400 (MSD) Date: Fri, 22 May 2009 02:47:21 +0400 From: Stanislav Sedov To: Randy Bush Message-Id: <20090522024721.da1ec85a.stas@FreeBSD.org> In-Reply-To: References: Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri May 22 02:46:50 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4a15d9da994292682134302 Cc: hackers@freebsd.org, Dario Freni Subject: Re: Installation from USB pen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 22:46:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 21 May 2009 14:12:00 -0700 Randy Bush mentioned: > i succeeded with putting 8-current snap on a pen and booting. but i can > not figure out how to tell it to use the pen drive for system image > loads. > What do you mean by system image loads? Does it load kernel succesfully but cannot find root filesystem? - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoV2gEACgkQK/VZk+smlYHVqQCfb0lmeXbKdbk+Ktq1l2Dngz01 HEsAn1U5V1nnnyFs89Yvxo5xbjvIwzmY =gp18 -----END PGP SIGNATURE----- !DSPAM:4a15d9da994292682134302! From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 22:52:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 218EC106564A for ; Thu, 21 May 2009 22:52:46 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id C6C918FC08 for ; Thu, 21 May 2009 22:52:45 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id D0C5E8FC4E for ; Fri, 22 May 2009 02:52:44 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 70DE98FC18; Fri, 22 May 2009 02:52:43 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 51A5F3982B; Fri, 22 May 2009 02:53:22 +0400 (MSD) Date: Fri, 22 May 2009 02:53:22 +0400 From: Stanislav Sedov To: xorquewasp@googlemail.com Message-Id: <20090522025322.2acebb01.stas@FreeBSD.org> In-Reply-To: <20090521164442.GA59069@logik.internal.network> References: <20090521095305.GA27043@logik.internal.network> <20090521161018.66b3015c@FreeBSD.org> <20090521164442.GA59069@logik.internal.network> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri May 22 02:52:44 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4a15db3c994295534499307 Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Thu, 21 May 2009 22:52:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 21 May 2009 17:44:42 +0100 xorquewasp@googlemail.com mentioned: > On 2009-05-21 16:10:18, Stanislav Sedov wrote: > > You can also try using devel/cross-binutils to build cross-tools for > > x86_64-freebsd. Random people reported they're working fine. > > Unfortunately, as noted in this thread: > > http://marc.info/?l=freebsd-hackers&m=124146166902690&w=2 > > Using that port works but creates a compiler that emits code > that can't be assembled by the default system binutils. Not > great for a port... > Why not make this compiler to use fresh binutils from cross-binutils instead of using systems binutils? This will also allow to support newer processor families and architectures. Is it possible to tell GNAT where to look for binutils to assembly and link with? - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkoV22IACgkQK/VZk+smlYGJSACghXD2H4iN9HE/DmNDKhdNVfMY /SQAnjQ+HMeyMP9ZKJhF5F09Buex1tOz =VB1I -----END PGP SIGNATURE----- !DSPAM:4a15db3c994295534499307! From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 22:49:09 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00A45106564A; Thu, 21 May 2009 22:49:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D05888FC1D; Thu, 21 May 2009 22:49:08 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7H4W-000A0v-Ji; Thu, 21 May 2009 22:49:08 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 674D6188C446; Thu, 21 May 2009 15:49:08 -0700 (PDT) Date: Thu, 21 May 2009 15:49:08 -0700 Message-ID: From: Randy Bush To: Stanislav Sedov In-Reply-To: <20090522024721.da1ec85a.stas@FreeBSD.org> References: <20090522024721.da1ec85a.stas@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 21 May 2009 22:56:43 +0000 Cc: hackers@freebsd.org, Dario Freni Subject: Re: Installation from USB pen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 21 May 2009 22:49:09 -0000 >> i succeeded with putting 8-current snap on a pen and booting. but i can >> not figure out how to tell it to use the pen drive for system image >> loads. > What do you mean by system image loads? Does it load kernel succesfully > but cannot find root filesystem? sorry. no. it wants the cd or ftp or ... to get the install pieces. as it is a snapshot, there are none on net (that i can find). but they went onto the usb. but i can not figure out how to tell it to get them from there. randy From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 02:09:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AD5A1065670 for ; Fri, 22 May 2009 02:09:52 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from ita.aagh.net (ita.aagh.net [208.86.225.114]) by mx1.freebsd.org (Postfix) with ESMTP id 602DF8FC1F for ; Fri, 22 May 2009 02:09:52 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from cpc1-hart9-2-0-cust900.11-3.cable.virginmedia.com ([86.30.3.133] helo=voi.aagh.net ident=mailnull) by ita.aagh.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7Jlv-0001bt-VA; Fri, 22 May 2009 01:42:08 +0000 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7Jlu-000GlA-A5; Fri, 22 May 2009 02:42:06 +0100 Date: Fri, 22 May 2009 02:42:06 +0100 From: Thomas Hurst To: Nate Eldredge Message-ID: <20090522014206.GA62573@voi.aagh.net> Mail-Followup-To: Nate Eldredge , Yuri , freebsd-hackers@freebsd.org References: <4A14F58F.8000801@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Not much. User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 02:09:52 -0000 * Nate Eldredge (neldredge@math.ucsd.edu) wrote: > There may be a way to enable the conservative behavior; I know Linux > has an option to do this, but am not sure about FreeBSD. I seem to remember a patch to disable overcommit. Here we go: http://people.freebsd.org/~kib/overcommit/ -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 02:26:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E60A106564A for ; Fri, 22 May 2009 02:26:16 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0756A8FC14 for ; Fri, 22 May 2009 02:26:15 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n4M2Bgxu036855 for ; Thu, 21 May 2009 19:11:42 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n4M2Bg5b036854; Thu, 21 May 2009 19:11:42 -0700 (PDT) Date: Thu, 21 May 2009 19:11:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200905220211.n4M2Bg5b036854@apollo.backplane.com> To: freebsd-hackers@freebsd.org References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 02:26:16 -0000 There is no such thing as a graceful way to deal with running out of memory. What is a program supposed to do? Even if it gracefully exits it still fails to perform the function for which it was designed. If such a program is used in a script then the script fails as well. Even the best systems (e.g. space shuttle, mars rover, airplane control systems) which try to deal with unexpected situations still have to have the final option, that being a complete reset. And even a complete reset is no guarantee of recovery (as one of the original airbus accidents during an air-show revealed when the control systems got into a reset loop and the pilot could not regain control of the plane). The most robust systems do things like multiple independant built-to-spec programs and a voting system which require 10 times the man power to code and test, something you will likely never see in the open-source world or even in most of the commercial application world. In fact, it is nearly impossible to write code which gracefully fails even if the intent is to gracefully fail (and even if one can even figure out what a workable graceful failure path would even be). You would have to build code paths to deal with the failure conditions, significantly increasing the size of the code base, and you would have to test every possible failure combination to exercise those code paths to make sure they actually work as expected. If you don't then the code paths designed to deal with the failure will themselves likely be full of bugs and make the problem worse. People who try to program this way but don't have the massive resources required often wind up with seriously bloated and buggy code. So if the system runs out of memory (meaning physical memory + all available swap), having a random subset of programs of any size start to fail will rapidly result in a completely unusable system and only a reboot will get it back into shape. At least until it runs out of memory again. -- The best one can do is make the failures more deterministic. Killing the largest program is one such mechanic. Knowing how the system will react makes it easier to restore the system without necessarily rebooting it. Of course there might have to be exceptions as you don't want your X server to be the program chosen. Generally, though, having some sort of deterministic progression is going to be far better then having half a dozen random programs which happen to be trying to allocate memory suddenly get an unexpected memory allocation failure. Also, it's really a non-problem. Simply configure a lot of swap... like 8G or 16G if you really care. Or 100G. Then you *DO* get a graceful failure which gives you time to figure out what is going on and fix it. The graceful failure is that the system starts to page to swap more and more heavily, getting slower and slower in the process, but doesn't actually have to kill anything for minutes to hours depending on the failure condition. It's a lot easier to write code which reacts to a system which is operating at less then ideal efficiency then it is to write code which reacts to the failure of a core function (that of allocating memory). One could even monitor swap use as ring the alarm bells if it goes above a certain point. Overcommit has never been the problem. The problem is there is no way a large system can gracefully deal with running out of memory, overcommit or not. -Matt From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 06:17:33 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23904106564A; Fri, 22 May 2009 06:17:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 879D98FC14; Fri, 22 May 2009 06:17:32 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4M6HT9i092644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 15:47:29 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Fri, 22 May 2009 15:47:18 +0930 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1822001.IoynI4FbPK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905221547.27453.doconnor@gsoft.com.au> X-Spam-Score: -3.508 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Randy Bush , hackers@freebsd.org, Dario Freni Subject: Re: Installation from USB pen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 06:17:33 -0000 --nextPart1822001.IoynI4FbPK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 22 May 2009, Randy Bush wrote: > i succeeded with putting 8-current snap on a pen and booting. but i > can not figure out how to tell it to use the pen drive for system > image loads. > > do i have to back off to 7 and then upgrade forward after install? I don't believe you can install from UFS unless you mount it first and=20 then tell it to do an FS install. I have a 7.x based USB installer that is split in 2 - half FAT32 half=20 UFS and it works. Having half FAT32 is handy if you need to edit/add stuff from Windows.=20 It does make it a PITA to build the install key though. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1822001.IoynI4FbPK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKFkN35ZPcIHs/zowRAuA3AJ0TC8kWInVvIENlWUqVAlIQj8vHzwCbBK2Y mtUZUkwMJvM5wAILUOudVzE= =KPk+ -----END PGP SIGNATURE----- --nextPart1822001.IoynI4FbPK-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 06:17:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23904106564A; Fri, 22 May 2009 06:17:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 879D98FC14; Fri, 22 May 2009 06:17:32 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4M6HT9i092644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 15:47:29 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Fri, 22 May 2009 15:47:18 +0930 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1822001.IoynI4FbPK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905221547.27453.doconnor@gsoft.com.au> X-Spam-Score: -3.508 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Randy Bush , hackers@freebsd.org, Dario Freni Subject: Re: Installation from USB pen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 06:17:33 -0000 --nextPart1822001.IoynI4FbPK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 22 May 2009, Randy Bush wrote: > i succeeded with putting 8-current snap on a pen and booting. but i > can not figure out how to tell it to use the pen drive for system > image loads. > > do i have to back off to 7 and then upgrade forward after install? I don't believe you can install from UFS unless you mount it first and=20 then tell it to do an FS install. I have a 7.x based USB installer that is split in 2 - half FAT32 half=20 UFS and it works. Having half FAT32 is handy if you need to edit/add stuff from Windows.=20 It does make it a PITA to build the install key though. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1822001.IoynI4FbPK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKFkN35ZPcIHs/zowRAuA3AJ0TC8kWInVvIENlWUqVAlIQj8vHzwCbBK2Y mtUZUkwMJvM5wAILUOudVzE= =KPk+ -----END PGP SIGNATURE----- --nextPart1822001.IoynI4FbPK-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 06:25:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1795A106566C for ; Fri, 22 May 2009 06:25:48 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 630E08FC12 for ; Fri, 22 May 2009 06:25:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4M6PiBW092816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 15:55:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org, yuri@rawbw.com Date: Fri, 22 May 2009 15:55:40 +0930 User-Agent: KMail/1.9.10 References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> In-Reply-To: <4A1594DA.2010707@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1803539.heUJSqalCy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905221555.42775.doconnor@gsoft.com.au> X-Spam-Score: -3.508 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Nate Eldredge Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 06:25:48 -0000 --nextPart1803539.heUJSqalCy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 22 May 2009, Yuri wrote: > Nate Eldredge wrote: > > Suppose we run this program on a machine with just over 1 GB of > > memory. The fork() should give the child a private "copy" of the 1 > > GB buffer, by setting it to copy-on-write. In principle, after the > > fork(), the child might want to rewrite the buffer, which would > > require an additional 1GB to be available for the child's copy. So > > under a conservative allocation policy, the kernel would have to > > reserve that extra 1 GB at the time of the fork(). Since it can't > > do that on our hypothetical 1+ GB machine, the fork() must fail, > > and the program won't work. > > I don't have strong opinion for or against "memory overcommit". But I > can imagine one could argue that fork with intent of exec is a faulty > scenario that is a relict from the past. It can be replaced by some > atomic method that would spawn the child without ovecommitting. If all you are going to do is call execve() then use vfork(). That explicitly does not copy the parent's address space. Also your example is odd, if you have a program using 1Gb (RAM + swap)=20 and you want to start another (in any way) then that is going to be=20 impossible. If you had a 750Mb process that forked and the child only modified 250Mb=20 you'd be all right because the other pages would be copies. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1803539.heUJSqalCy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKFkVm5ZPcIHs/zowRAq2jAJ4ukljsV0PaIASBrO2YZOWvBumGMQCdHGP/ dHLr3G3LFnwNE9pJIqngrkM= =Q6yy -----END PGP SIGNATURE----- --nextPart1803539.heUJSqalCy-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 06:54:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AF0B106568F for ; Fri, 22 May 2009 06:54:24 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from a.mail.ru.ac.za (a.mail.ru.ac.za [IPv6:2001:4200:1010::25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC388FC2A for ; Fri, 22 May 2009 06:54:23 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ru-msa; d=ru.ac.za; h=Received:From:Organization:To:Subject:Date:User-Agent:References:In-Reply-To:X-Face:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id:X-Virus-Scanned:X-Authenticated-User; b=o2/KQMl1Bk05W6GxpuC99npLRBuwLoS+Yq7TEvwuixTzDqYD9BF7m6F0qzR/16RfR3E2xlmLiVApfk1mSgVccHYGaFzwlxgMO19a4O++8mRl2xk0AROyXbxldcjXbIgB; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:52492) by a.mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M7Oe6-00052k-5g for freebsd-hackers@freebsd.org; Fri, 22 May 2009 08:54:22 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Fri, 22 May 2009 08:54:21 +0200 User-Agent: KMail/1.9.10 References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> In-Reply-To: X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: a.mail.ru.ac.za (2001:4200:1010::25:1) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 06:54:25 -0000 On Thursday 21 May 2009 23:37:20 Nate Eldredge wrote: > Of course all these problems are solved, under any policy, by having more > memory or swap. =A0But overcommit allows you to do more with less. Or to put it another way, 90% of the problems that could be solved by havin= g=20 more memory can also be solved by pretending you have more memory and hopin= g=20 no-one calls your bluff. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 07:31:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2039B106566B for ; Fri, 22 May 2009 07:31:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 03BF18FC0C for ; Fri, 22 May 2009 07:31:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id D03441A3C3B; Fri, 22 May 2009 00:31:30 -0700 (PDT) Date: Fri, 22 May 2009 00:31:30 -0700 From: Alfred Perlstein To: Chuck Robey Message-ID: <20090522073130.GI67847@elvis.mu.org> References: <4A11B893.1000808@telenix.org> <20090521003646.GS67847@elvis.mu.org> <4A15CE00.4040600@telenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A15CE00.4040600@telenix.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-Hackers Subject: Re: porting info for FreeBSD's kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:31:31 -0000 * Chuck Robey [090521 14:56] wrote: > Alfred Perlstein wrote: > > * Chuck Robey [090518 13:03] wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> I've been googling, trying to see if I can find notes regarding what needs > >> changing, in what order, to adapt the FreeBSD kernel to a new processor. Anyone > >> know where stuff like that can be found? > > > > You need a cross compile toolchain of course, look into how FreeBSD > > is configured for the various arches. > > > > Then I would suggest looking at the loaders, followed by > > kern/init_main.c. If you trace down init_main.c and some > > of the early sysinits that should give you an idea. > > > > You might also be able to backtrack using CVS/svn to follow > > how mips or arm was done. > > > > Note: freebsd has a decent cross-compile setup now, see > > "make universe" so things should be easier to get started. > > > > Thanks. I will *definitely* read all the parts you hint me at, I won't be > deleting this mail, and I appreciate it. I was asking on the llvm maillist > about Cortex-A8 support. What I got says that it's not there yet, but it's > being worked upon, that and the -A9 support (definite differences). So, any > crosstools needed today would have to be gcc, from a version at least as new as > the 4.3 branch (that's where they brought in the -A8 support). > > The tool I got by doing the freeBSD crosstools was 4.2.1, which isn't going to > do it for the Cortex-A8, and I had someone else (from a FreeBSD list) tell me > that bringing in a newer version of gcc wasn't extremely likely, that they'd > want llvm instead. I see 3 alternatives for a Cortex-A8 port: using a new gcc > port, waiting on the upgrade of llvm, or maybe deciding that the version the > llvm that's out now, with the v6 compatibility, would be (for the short term) > good enough. Any idea which one to choose? The only one that interests me is > for the TI OMAP 3530 (Cortex-A8, among other parts). Maybe if the currently > available llvm is good enough, maybe gcc-4.2.1 may creak along well enough for > the short term? I need to understand this. > > My own personal Pandora won't probably won't arrive on my doorstep for maybe as > long as 3 more months, so in the meantime, I think I will be reading all I can > get my hands on regarding llvm. Maybe I can really learn enough to make a > difference. In school, I concentrated very definitely on OSes (I've written 3 > of them over the years, of quite varying levels of performance), so for > compilers, I'm relying on my old 1988 version of the Aho/Sethi/Ullman compilers > book. If anyone knows a more modern book that will show me enough about > compilers to be useful, I'd really appreciate the name, maybe Amazon will let me > get a cheap used version. I wouldn't sweat the compiler as much as the actual OS code, I think it should be relatively easy to trick the build to use an external compiler (ie, don't get caught up in the compiler bootstrap quagmire, leave that for later...) Anyhow, you're talking to someone that has studied, but not implemented a port, so take my advice with a few heaps of salt. :) Typically what people focus on is: 1) "how am I going to get the first line of dmesg to come up" 2) "how am I going to get to single user mode" 3) "multi user?" 4) cleanup of compiler and bootstrap issues. If you get sidetracked by #4, you can spend months doing that instead of just rolling with it when you get there. -- - Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 07:33:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B1D106564A for ; Fri, 22 May 2009 07:33:59 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D697A8FC1F for ; Fri, 22 May 2009 07:33:59 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C4C821A3C40; Fri, 22 May 2009 00:33:59 -0700 (PDT) Date: Fri, 22 May 2009 00:33:59 -0700 From: Alfred Perlstein To: Yuri Message-ID: <20090522073359.GJ67847@elvis.mu.org> References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1594DA.2010707@rawbw.com> User-Agent: Mutt/1.4.2.3i Cc: Nate Eldredge , freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 07:34:00 -0000 * Yuri [090521 10:52] wrote: > Nate Eldredge wrote: > >Suppose we run this program on a machine with just over 1 GB of > >memory. The fork() should give the child a private "copy" of the 1 GB > >buffer, by setting it to copy-on-write. In principle, after the > >fork(), the child might want to rewrite the buffer, which would > >require an additional 1GB to be available for the child's copy. So > >under a conservative allocation policy, the kernel would have to > >reserve that extra 1 GB at the time of the fork(). Since it can't do > >that on our hypothetical 1+ GB machine, the fork() must fail, and the > >program won't work. > > I don't have strong opinion for or against "memory overcommit". But I > can imagine one could argue that fork with intent of exec is a faulty > scenario that is a relict from the past. It can be replaced by some > atomic method that would spawn the child without ovecommitting. vfork, however that's not sufficient for many scenarios. > Are there any other than fork (and mmap/sbrk) situations that would > overcommit? sysv shm? maybe more. -- - Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 08:15:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 728BE106568F; Fri, 22 May 2009 08:15:29 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4D97E8FC0C; Fri, 22 May 2009 08:15:28 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy3 with SMTP id 3so1754064ewy.43 for ; Fri, 22 May 2009 01:15:27 -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:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=FjZMV90dnZX/lx1t97owe6AO7vGkGOg8ojyskv9Hdcg=; b=oHkZaCOqncQTUWRtie64wm/Tp634I/CevMP0Bg+j+aqWtAPAfIq7CITKmoTbdlsbKH X1fEyOC4x5uJ3WOTGdhtQ0NiqU08cPx9Bs8F+ju/z4YX/l/N5qhLCSplyBEEGKyDbwlO zH1ba2yQcjy2y3T0yNXcZh3N7rO7FO4zcVcAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=GgUSCso5jrzoRbzWdkkXhKJZq2JBWUjCWJ7mIh0K2eytcR1Miq3Vbov8AssracKu7i c9giUhWzshYdVkSnXtTKlkvKvclY44a+iMMkGyoWC1AjL4u1314+/8HX9agHcw3kU9zI x3umHEixU6T1FXlicoB47vH+xeCyCyUBtd8GI= Received: by 10.210.111.17 with SMTP id j17mr4418832ebc.63.1242980127163; Fri, 22 May 2009 01:15:27 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 18sm3018706ewy.93.2009.05.22.01.15.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 May 2009 01:15:26 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 415195D59; Fri, 22 May 2009 08:15:25 +0000 (UTC) Date: Fri, 22 May 2009 09:15:25 +0100 From: xorquewasp@googlemail.com To: Stanislav Sedov Message-ID: <20090522081525.GA59432@logik.internal.network> References: <20090521095305.GA27043@logik.internal.network> <20090521161018.66b3015c@FreeBSD.org> <20090521164442.GA59069@logik.internal.network> <20090522025322.2acebb01.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090522025322.2acebb01.stas@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: compiling system binutils as cross 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: Fri, 22 May 2009 08:15:47 -0000 On 2009-05-22 02:53:22, Stanislav Sedov wrote: > > Why not make this compiler to use fresh binutils from cross-binutils > instead of using systems binutils? This will also allow to support > newer processor families and architectures. Is it possible to tell > GNAT where to look for binutils to assembly and link with? > Well, like I said, at the moment there's a choice of using the system binutils or the cross-binutils port. The compiler isn't actually intended to be a cross compiler but a native amd64 compiler (the lang/gnat-gcc* ports have been marked as i386-only for ages). I'm not sure if it's possible to tell GNAT where to look for binutils at runtime. I have some patches to send to both Adacore and the GCC developers to add support for FreeBSD amd64. I decided to use the system binutils because in order for someone to actually build the port, they have to use bootstrap compiler binaries provided by me (the gnat-gcc* ports do the same thing) and having those binaries depend on a moving target like cross-binutils might create even more complications. I'll be providing full documentation and build scripts to show how the bootstrapping compiler was created so if someone feels the need to use the cross-binutils port, they can. cheers, xw From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 08:32:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D97F5106566B for ; Fri, 22 May 2009 08:32:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1198FC15 for ; Fri, 22 May 2009 08:32:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1M7QAu-000047-Lj; Fri, 22 May 2009 11:32:20 +0300 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 n4M8WHxY091086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 11:32:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n4M8WHTB079874; Fri, 22 May 2009 11:32:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n4M8WHNm079873; Fri, 22 May 2009 11:32:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 May 2009 11:32:17 +0300 From: Kostik Belousov To: Nate Eldredge , Yuri , freebsd-hackers@freebsd.org Message-ID: <20090522083217.GZ1927@deviant.kiev.zoral.com.ua> References: <4A14F58F.8000801@rawbw.com> <20090522014206.GA62573@voi.aagh.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JQJYpj0es6mGpGbU" Content-Disposition: inline In-Reply-To: <20090522014206.GA62573@voi.aagh.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1M7QAu-000047-Lj 3a0471a0d0d1a110d3aa7a80f35c0b1f X-Terabit: YES Cc: Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 08:32:24 -0000 --JQJYpj0es6mGpGbU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 22, 2009 at 02:42:06AM +0100, Thomas Hurst wrote: > * Nate Eldredge (neldredge@math.ucsd.edu) wrote: >=20 > > There may be a way to enable the conservative behavior; I know Linux > > has an option to do this, but am not sure about FreeBSD. >=20 > I seem to remember a patch to disable overcommit. Here we go: >=20 > http://people.freebsd.org/~kib/overcommit/ Latest version is at http://people.freebsd.org/~kib/overcommit/vm_overcommit.22.patch applicable to the today CURRENT. --JQJYpj0es6mGpGbU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoWYxEACgkQC3+MBN1Mb4iBkwCg2D9rtG4ASA8fpAZNjEH6kb21 8OkAoLzWw2c/kuLFW3vjX1CnkYTFyQXn =GG7D -----END PGP SIGNATURE----- --JQJYpj0es6mGpGbU-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 14:09:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C6C1065670 for ; Fri, 22 May 2009 14:09:34 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6698FC1A for ; Fri, 22 May 2009 14:09:33 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 7719 invoked from network); 22 May 2009 14:09:33 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 May 2009 14:09:33 -0000 Message-ID: <4A16B22C.6010201@telenix.org> Date: Fri, 22 May 2009 10:09:48 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: Alfred Perlstein References: <4A11B893.1000808@telenix.org> <20090521003646.GS67847@elvis.mu.org> <4A15CE00.4040600@telenix.org> <20090522073130.GI67847@elvis.mu.org> In-Reply-To: <20090522073130.GI67847@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: porting info for FreeBSD's kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 14:09:34 -0000 Alfred Perlstein wrote: > * Chuck Robey [090521 14:56] wrote: >> Alfred Perlstein wrote: >>> * Chuck Robey [090518 13:03] wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I've been googling, trying to see if I can find notes regarding what needs >>>> changing, in what order, to adapt the FreeBSD kernel to a new processor. Anyone >>>> know where stuff like that can be found? >>> You need a cross compile toolchain of course, look into how FreeBSD >>> is configured for the various arches. >>> >>> Then I would suggest looking at the loaders, followed by >>> kern/init_main.c. If you trace down init_main.c and some >>> of the early sysinits that should give you an idea. >>> >>> You might also be able to backtrack using CVS/svn to follow >>> how mips or arm was done. >>> >>> Note: freebsd has a decent cross-compile setup now, see >>> "make universe" so things should be easier to get started. >>> >> Thanks. I will *definitely* read all the parts you hint me at, I won't be >> deleting this mail, and I appreciate it. I was asking on the llvm maillist >> about Cortex-A8 support. What I got says that it's not there yet, but it's >> being worked upon, that and the -A9 support (definite differences). So, any >> crosstools needed today would have to be gcc, from a version at least as new as >> the 4.3 branch (that's where they brought in the -A8 support). >> >> The tool I got by doing the freeBSD crosstools was 4.2.1, which isn't going to >> do it for the Cortex-A8, and I had someone else (from a FreeBSD list) tell me >> that bringing in a newer version of gcc wasn't extremely likely, that they'd >> want llvm instead. I see 3 alternatives for a Cortex-A8 port: using a new gcc >> port, waiting on the upgrade of llvm, or maybe deciding that the version the >> llvm that's out now, with the v6 compatibility, would be (for the short term) >> good enough. Any idea which one to choose? The only one that interests me is >> for the TI OMAP 3530 (Cortex-A8, among other parts). Maybe if the currently >> available llvm is good enough, maybe gcc-4.2.1 may creak along well enough for >> the short term? I need to understand this. >> >> My own personal Pandora won't probably won't arrive on my doorstep for maybe as >> long as 3 more months, so in the meantime, I think I will be reading all I can >> get my hands on regarding llvm. Maybe I can really learn enough to make a >> difference. In school, I concentrated very definitely on OSes (I've written 3 >> of them over the years, of quite varying levels of performance), so for >> compilers, I'm relying on my old 1988 version of the Aho/Sethi/Ullman compilers >> book. If anyone knows a more modern book that will show me enough about >> compilers to be useful, I'd really appreciate the name, maybe Amazon will let me >> get a cheap used version. > > I wouldn't sweat the compiler as much as the actual OS code, I think > it should be relatively easy to trick the build to use an external > compiler (ie, don't get caught up in the compiler bootstrap quagmire, > leave that for later...) > > Anyhow, you're talking to someone that has studied, but not implemented > a port, so take my advice with a few heaps of salt. :) > > Typically what people focus on is: > > 1) "how am I going to get the first line of dmesg to come up" > 2) "how am I going to get to single user mode" > 3) "multi user?" > 4) cleanup of compiler and bootstrap issues. > > If you get sidetracked by #4, you can spend months doing that > instead of just rolling with it when you get there. > I'll admit it's not terribly hard to just get a foreign compiler to work, and I've already gotten a version of gcc-4.3.1 jiggered. I was going to concentrate next on cleaning up the compiler issue, which is why I wanted to get a pronouncement on which way to go. If I simply try to duck as much of that issue as possible, I can use the gcc-4.3.1 without huge problems. I can see that fine ,,, BUT the next part, getting ghe booting working, that does seem to be something which is necessary to do. How could U just duck out of that the way I could easily do for the compiler? I mean, how could you cause the booting to get fooled into thinking it was working? If you could give me an example of any possible way to get past this issue, I'm willing to do as you request, if only I could recognize the action you're asking me to take. In the meantime (Until I understand what you're asking for) I'm rereading my old Dragon book, so I can begin to understand what llvm is doing. From Sandeep Patel, of llvm, btw, he tells me that the -A8 and -A9 work on llvm is going very rapidly, and it may well be ready before we realize, so being able to push off making the compiler decision is actually maybe quite agood thing to contemplate. > From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 20:07:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64978106564A for ; Fri, 22 May 2009 20:07:11 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7178FC0C for ; Fri, 22 May 2009 20:07:10 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n4MK7AVu046087 for ; Fri, 22 May 2009 13:07:10 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n4MK7ALn046086; Fri, 22 May 2009 13:07:10 -0700 (PDT) Date: Fri, 22 May 2009 13:07:10 -0700 (PDT) From: Matthew Dillon Message-Id: <200905222007.n4MK7ALn046086@apollo.backplane.com> To: freebsd-hackers@freebsd.org References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> <200905220854.21917.j.mckeown@ru.ac.za> Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 22 May 2009 20:07:11 -0000 :On Thursday 21 May 2009 23:37:20 Nate Eldredge wrote: :> Of course all these problems are solved, under any policy, by having more :> memory or swap. =A0But overcommit allows you to do more with less. : :Or to put it another way, 90% of the problems that could be solved by havin= :g=20 :more memory can also be solved by pretending you have more memory and hopin= :g=20 :no-one calls your bluff. : :Jonathan It's a bit more complicated then that. Most of the memory duplication (or lack of) which occurs after a fork() is deterministic. It's not a matter of pretending, it's a matter of practical application. For example, when sendmail fork()'s a deterministic subset of the duplicated writable memory will never be modified by the child. Ever. This is what overcommit takes advantage of. Nearly every program which fork()'s has a significant level of duplication of writable memory which deterministically reduces the set of pages which will ever need to be demand-copied. The OS cannot predict which pages these will be, but the effect from a whole-systems point of view is well known and deterministic. Similarly the OS cannot really determine who is responsible for running the system out of memory. Is it that big whopping program X or is it the 200 fork()'ed copies of server Y? Only a human being can really make the determination. This is also why turning off overcommit can easily lead to the system failing even if it is nowhere near running out of actual memory. In otherwords, the only real practical result of turning off overcommit is to make a system less stable and less able to deal with exceptional conditions. Systems which cannot afford to run out of memory are built from the ground-up to not allocate an unbounded amount of memory in the first place. There's no other way to do it. The Mars Rover is a good example of that. In such systems actually running out of memory is often considered to be a fatal fault. -Matt