From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 05:20:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D836DD5 for ; Sun, 31 Mar 2013 05:20:23 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by mx1.freebsd.org (Postfix) with ESMTP id 70193A34 for ; Sun, 31 Mar 2013 05:20:23 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id kp14so849721pab.8 for ; Sat, 30 Mar 2013 22:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Cup+7JMUEs0BjkSKuq0n5WqLdhej1lxiqy+ZEd2ynOM=; b=z/43TI3jyke2bd8oQPU9d+VKLmEJ9Mv2jv7CTkf1dUCUdqlcg5/tJ047rShyYfTYy2 dXQ0Fd2nQOGjQFMia9D+0rd7koW6rlb4ZdVuG7L1X6l/aTfHHbwG6mLxyamn36Ozf60M DrYIlMDewpe5iLaFVqidWNzzvOPUDHMs34Sfxn+Lk0X6gkQUaOXkFm8x4nBk5xEj2NiY X5jAC3mGnCNigMPVWFW54je1zwJXo+EHcx0xiq/tfGxWayF2nC4FTMya+5koY5+82d6A asF1byDhh4lyqxs40qazKK85yxOsEu/5F/zT3+VBaNjsaT8GxITau091Z/vo60YZZyAK Kpxg== MIME-Version: 1.0 X-Received: by 10.66.228.194 with SMTP id sk2mr12787251pac.51.1364707217853; Sat, 30 Mar 2013 22:20:17 -0700 (PDT) Received: by 10.68.52.233 with HTTP; Sat, 30 Mar 2013 22:20:17 -0700 (PDT) Date: Sun, 31 Mar 2013 01:20:17 -0400 Message-ID: Subject: how to force all packets to be ipv4 not v6 From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 05:20:23 -0000 I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 05:37:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B074CF26; Sun, 31 Mar 2013 05:37:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 86D12A81; Sun, 31 Mar 2013 05:37:25 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id ABE5F23F804; Sun, 31 Mar 2013 01:37:22 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us ABE5F23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 31 Mar 2013 01:37:20 -0400 From: Glen Barber To: Aryeh Friedman Subject: Re: how to force all packets to be ipv4 not v6 Message-ID: <20130331053720.GD1548@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 05:37:25 -0000 --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline freebsd-net@ might have been a better choice, but... On Sun, Mar 31, 2013 at 01:20:17AM -0400, Aryeh Friedman wrote: > I have a host that for ISP reasons must have a ipv6 addr as well as the > ipv4 but the ISP does not offer external ipv6 routing but all the commanes > (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there > anyway to force them to always use 4? Which version of FreeBSD? See rc.conf(5) for 'ip6addrctl_policy'; I think this is what you're looking for. Glen --xA/XKXTdy9G3iaIz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRV8uQAAoJEFJPDDeguUajGe0H/1tcz5P8WN9YNFsB9F5A7WKE y43zMWvN1EeXRiPsgUVzx05wFGpRMp4Q2IN0yX3fXbA0RrICqm6FMb2SLALxhUwb u7nYDRQefI6ohk6DjO/aS7cc7428HuY0JQOjgCqNrSlATlO7lrIOMQYH0U3V5ZIJ ++NVTIsUddZoixM8YAYQoE0K5y9JHl2xnEn992emTIja0vXCwwTbJWnI1nkJFrzA O+tNSEIAz9FWO8FE+8rJAeMFyeNcNdsYf0uH2tj7f7DJ4gbJAVhO5zKgwFGHTjUP HfQ8pqPDNp07Da0nXeFI48J8E/xNwdkJScrvV4/Wfm3T4hqDuc2aZpqI5rTCLKk= =Fzbc -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 05:44:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FE58E8; Sun, 31 Mar 2013 05:44:33 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 2813AAA3; Sun, 31 Mar 2013 05:44:33 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id f10so677818dak.39 for ; Sat, 30 Mar 2013 22:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hPJqtOvX0uswglVdbHM5DaLX6Lis5GnbqrS5GkcuNKk=; b=iBitPwHCTDqciRVzFvclJPs1ivfmMZp1OXktQ2hDr5hKdYSG3KIEMCFUFXd6q6GBW1 9s3x7KcxpLGqCIjUX26h8tWjgB369zUM4knOMs88gHUom7N/rI1dPm1V7Zo795pLAuXg s5Ty6xqe4JxsV0zxeUrujJDwKGAX1f7rnTF8cV2zNKX18s9BsarWRoYHEbyyG/NK+TtT x31uCTa5yO80Qzog2qJhQMIIZT6WHl6O1nHTlulwqBWZnAUuUuF+x3ot/VfoXqMPnIf0 B96fyzRBm4vu/ZVraMGhwEV4R0a3EGsiOE3hOVF278JslqMLy28v/uHI4VFb8A6uOZ8w BfbQ== MIME-Version: 1.0 X-Received: by 10.66.162.229 with SMTP id yd5mr13064108pab.4.1364708672560; Sat, 30 Mar 2013 22:44:32 -0700 (PDT) Received: by 10.68.52.233 with HTTP; Sat, 30 Mar 2013 22:44:32 -0700 (PDT) In-Reply-To: <20130331053720.GD1548@glenbarber.us> References: <20130331053720.GD1548@glenbarber.us> Date: Sun, 31 Mar 2013 01:44:32 -0400 Message-ID: Subject: Re: how to force all packets to be ipv4 not v6 From: Aryeh Friedman To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 05:44:33 -0000 On Sun, Mar 31, 2013 at 1:37 AM, Glen Barber wrote: > freebsd-net@ might have been a better choice, but... > > On Sun, Mar 31, 2013 at 01:20:17AM -0400, Aryeh Friedman wrote: > > I have a host that for ISP reasons must have a ipv6 addr as well as the > > ipv4 but the ISP does not offer external ipv6 routing but all the > commanes > > (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is > there > > anyway to force them to always use 4? > > Which version of FreeBSD? > 9.1 > > See rc.conf(5) for 'ip6addrctl_policy'; I think this is what you're > looking for. > > Glen > > From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 13:02:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 085F4806 for ; Sun, 31 Mar 2013 13:02:03 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by mx1.freebsd.org (Postfix) with ESMTP id BD829BFB for ; Sun, 31 Mar 2013 13:02:02 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id q19so838843qeb.26 for ; Sun, 31 Mar 2013 06:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=/b5Yak25XqfOkaS6pdJDim3YfiFs85b9tzfljNXAnvI=; b=ZLFwOYTBqBAMXgpU+L73oGJWDi2CAAmHTe508//xkYwH7QwNeqNicVT2vxlVEtI818 V+GjlsCMQ9lJ7wRJDGfoxyjvnQAJJnbB/uJtO59H9rJGAVxKWqXcx33PVi7nnqNu6LQz Uw6UpioPOzBS8zocR/kNDyEaJjFWm/9hTdU14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=/b5Yak25XqfOkaS6pdJDim3YfiFs85b9tzfljNXAnvI=; b=Bl/avIjILq/tydXK/INTAl79mEfpydUuZtM8oGXzEFjKJ9dSVM1FK7lQxslgoCULJQ QHYcjAnmsmGjAc4QqovJ9d83GjKrckXNIaTe+VKGcZp9k9L8bHuewttMK8N/r87fSt3j T4nE9/ZW151R83HznZ/5NcMqHsVQNWNq/7VS+JTX64yFch1LEk8VdefGfKPYwXGuVsVf CfEeyXPR9xTzY8srrjqX79Z/x6fpMYTMJIudzqR42/YdiYAd/oeb/17OPGI2sR+MoFI8 O9pwLv0zINGbDISbwms/1rXjCDKpGN9+bW1B1crcyDCS/6HCY8g1f2F9Xy4PLjFO/vgt df6w== X-Received: by 10.49.14.102 with SMTP id o6mr7115745qec.5.1364734535930; Sun, 31 Mar 2013 05:55:35 -0700 (PDT) Received: from papi ([177.98.92.183]) by mx.google.com with ESMTPS id o6sm15304927qek.3.2013.03.31.05.55.34 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 31 Mar 2013 05:55:35 -0700 (PDT) Date: Sun, 31 Mar 2013 09:57:30 -0300 From: Mario Lobo To: freebsd-hackers@freebsd.org Subject: Re: how to force all packets to be ipv4 not v6 Message-ID: <20130331095730.7c8b5e55@papi> In-Reply-To: References: Organization: BSD X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkXdaKBdU+vy1Uw0fPTbXeW/74LWlZ4HaNn9ifzXZpj+O1RxOr1MDndmtXdpqhCsaa6Jjyb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:02:03 -0000 On Sun, 31 Mar 2013 01:20:17 -0400 Aryeh Friedman wrote: > I have a host that for ISP reasons must have a ipv6 addr as well as > the ipv4 but the ISP does not offer external ipv6 routing but all the > commanes (ssh, ftp, etc.) default to ipv6 and need special options to > use 4 is there anyway to force them to always use 4? > _______________________________________________ > 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" A kick and dirty way would be to comment the line: options INET6 # IPv6 communications protocols from your kernel config and recompile. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 13:38:29 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9213BF01 for ; Sun, 31 Mar 2013 13:38:29 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0E7D5C for ; Sun, 31 Mar 2013 13:38:28 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so735479eek.36 for ; Sun, 31 Mar 2013 06:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=JIhBazyz6HngUz0XricqUoHTj57iKUoJvrmDFSWfSyY=; b=wN0eaQWxAV5cXIzOxPq1l72dFJRZeF8UagrHiVb60lzOQ4MlMjvl62SZg9tIMhl1rV p7nMHRarddMWBhSTVDl8LkZ+4cHRmRnCLZ8yRgckLw3EwWYnWssTjOyWML+h/MGLQ9ih KSvqoq+mL8Kux4woD+a+B9cE2tUYzoRGK+e/q7JiGzY4iDI1tdH02qMxU59wXacsuFqm LawtoyTs001wsm88Rk1tH+fiijStkYqz4gpb4XzpOm+I/G4H0chboHsqWz3FQ3Erxoxz rFucO+mwIgDj4dBT7VPDRkILlLA3emYCp0CBxVKRhMj6/wux3Fqyc7e3GZgM+HGU2ILZ wyCg== X-Received: by 10.14.173.196 with SMTP id v44mr27477923eel.29.1364737107884; Sun, 31 Mar 2013 06:38:27 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPS id n2sm15596280eeo.10.2013.03.31.06.38.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 31 Mar 2013 06:38:26 -0700 (PDT) Message-ID: <20130331.133829.093.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: Ports: make fails, if DESTDIR path has spaces Date: Sun, 31 Mar 2013 15:38:29 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:38:29 -0000 Under 9.0-RELEASE-p6=0D=0A=0D=0A--=0D=0A#!/bin/sh=0D=0A=0D=0A# Contains 9.0 = world=0D=0ADESTDIR=3D'/usr/TZ ONE'; export DESTDIR=0D=0A=0D=0Acd = /usr/ports/benchmarks/unixbench=0D=0A/usr/bin/make = showconfig=0D=0A--=0D=0A=0D=0A=0D=0AErrors:=0D=0A-------=0D=0A[: /usr/TZ: = unexpected operator=0D=0A=3D=3D=3D> Creating some important = subdirectories=0D=0A[: /usr/TZ: unexpected operator=0D=0A=3D=3D=3D> /tmp = subdirectory has been successfully created=0D=0A[: /usr/TZ: unexpected = operator=0D=0A=3D=3D=3D> /dev subdirectory has been successfully = created=0D=0Amktemp: mkdtemp failed on /usr/TZ: File = exists=0D=0A=3D=3D=3D> Failed to create temporary mount point=0D=0A*** = Error code 9=0D=0A=0D=0AStop in = /usr/ports/benchmarks/unixbench.=0D=0A-------=0D=0A=0D=0A=0D=0ADomagoj = Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 13:41:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17EB11AF; Sun, 31 Mar 2013 13:41:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 67DA7D87; Sun, 31 Mar 2013 13:40:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2VDel2w065115; Sun, 31 Mar 2013 16:40:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2VDel2w065115 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2VDelMq065114; Sun, 31 Mar 2013 16:40:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Mar 2013 16:40:47 +0300 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130331134047.GN3794@kib.kiev.ua> References: <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> <20130329123155.GA94024@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GclHhPKU8e6IjCj6" Content-Disposition: inline In-Reply-To: <20130329123155.GA94024@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Stanislav Sedov , Attilio Rao , freebsd-hackers@freebsd.org, Mikolaj Golub , "Robert N. M. Watson" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:41:00 -0000 --GclHhPKU8e6IjCj6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2013 at 02:31:57PM +0200, Mikolaj Golub wrote: > On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote: > > On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote: > > > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote: > > >=20 > > > > In the generic Elf 64bit draft specification I have, the notes sect= ions > > > > are specified to consists of entries, each of which is an array of = 8-byte > > > > words. I think we are right using the 8-byte alignment. > > >=20 > > > I have impression many implementations use 4-byte alignment. E.g. in > > > NetBSD: > > >=20 > > > sys/kern/core_elf32.c: > > >=20 > > > #define ELFROUNDSIZE 4 /* XXX Should it be sizeof(Elf_Word)?= */ > > > #define elfround(x) roundup((x), ELFROUNDSIZE) > > Note that this is core_elf32. I am concerned with the 64-bit cores. >=20 > core_elf64.c: >=20 > #define ELFSIZE 64 >=20 > #include "core_elf32.c" Also, the 4-bytes alignment is described in the comments in the glibc csu/abi-note.S. >=20 > > >=20 > > > Also, we have inconsistency with imgactl_elf.c/parse_notes(), which > > > uses 4-byte alignment: > > >=20 > > > note =3D (const Elf_Note *)((const char *)(note + 1) + > > > roundup2(note->n_namesz, sizeof(Elf32_Addr)) + > > > roundup2(note->n_descsz, sizeof(Elf32_Addr))); > > >=20 > > > I suppose there were no issues before, because accidentally the sizes > > > of all notes we had were 8 bytes aligned. > > Indeed, both ABI and NOINIT notes have size which is multiple of 8. > >=20 > > >=20 > > > Now, when I add new notes it will break things. I don't have strong > > > opinion, it will be ok for me to leave 8-byte alignment and fix > > > issues, just want to have strong support here :-) > > Well, while the issue is discussed and decided, you could just make > > your new notes size be multiple of 8 too. >=20 > I thought about this too. Then I need to be more caerful when > extracting stats from notes, because the length returned by > procstat_core_get() can be more than a real payload. >=20 > Ok, I will try this way. >=20 > I could add length to the note header, which is currently contains > only structsize, so it would became something like: >=20 > struct { > int structsize; > int lenght; > } >=20 > But not sure it is worth doing, especially if the forced 8-bit > alignment is a temporary mesure. No, it is definitely not worth it. I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. Every other OS and our !coredump code assumes 4-byte alignment. Does changing the putnote() to align on the 4-byte boundary cause real change in the core file notes layout ? --GclHhPKU8e6IjCj6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWDzeAAoJEJDCuSvBvK1BSegQAIzbIjOxoFIJGt0T3+dT6hVf v00PMW3xK5S0Q/5oklc6AsanLIUjEe3p9L1LHpw6EG4d2tCiJ0eK6FyMyeo4tGib Vl6xRksd8dKDBgOEq0rqy6xfrx/JlwZHMft9AiYxS8vDsMiaP7zR7QcgHo/VW9PK MY8zYyaPLlYmTg65Qh80nDDmmW+Y/Z/kohfKQdXAEtbMvx2L8rIPJ0zcOj//spIJ Hoo3Ws0uDlTtkzvVeKcbja2dC/yhW6QtewvGJayrzN7GXijZYgdR92NTlrVhF8B+ ovnAdr7fX1bXzRCiazKdQsGpuw8CFqa2svE8fPCIIjnkrG8SuiWWwa7MZwYHHMAh XZW/txrojFD89DFSCIOC6wlf+/9OX1nKz7GotWzUvXHyofO6/TxrXi3+P+UKXvYd uV81WxgoKKWPICglU+JqUq2shbQuZccGemsgOgRLYJr7XE3gmats3/Y1eWv/wOhD omIBusMN9WirvWI+3F7/B+9MXiVi05rXHcSoAVsZIsBGoFnDV6d8hIn8fjQ9KHEy Sexr1kZIRkjgcQEX3j5RN5DRj3xP6l4O7V8mdt4jQNEq/sWZNrofFHBkBrveSlrH pP56saoa02KGRVZuSN2hrGrcaoPCtQmtm3h66OrfxqieEmny7QK6xnnKtvT/ZgYn RTFjxtx0SjKP3IV6RBSg =qwCX -----END PGP SIGNATURE----- --GclHhPKU8e6IjCj6-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 15:53:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCE7CF20; Sun, 31 Mar 2013 15:53:07 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id B5823194; Sun, 31 Mar 2013 15:53:06 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id d10so760577eaj.39 for ; Sun, 31 Mar 2013 08:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=j7bLVLKmSZl4rEFkKRnYUi0ulhRmxhfLnYzK1oLwFa4=; b=sWP08neyoODp/wV7Q080wwGKGx0pEUMYNmV5ktLBHZuDDb5ctDqNYNdenyspn0eOcX NLgy0W1rm77/QEA+tIT4re4z4BG6eKK2VND6GyNucDom7lcX9FOVhIuqCCXl5KbuylCu kvt8y+6IyA2rTJqB/fubcnalDkdHbuCRf/IBaAZvZw4dyt4asq4a0z986zY2R1ER7eau ORMOhl77hVlSUM1gzUGPgft2MuIC7Ce2O95HvK32NIm6dY5xCMm71DvU2qX4h1wsx4pH EsQJ7OTg1s5eZ2GljsLDMQ6J2QlW/+ro7IzkWD1RsfijzYcX3GBGzWWl9oI7IOHYw4v9 3EQg== X-Received: by 10.14.182.72 with SMTP id n48mr28997820eem.3.1364745185765; Sun, 31 Mar 2013 08:53:05 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id q42sm16154073eem.14.2013.03.31.08.53.03 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 31 Mar 2013 08:53:04 -0700 (PDT) Sender: Mikolaj Golub Date: Sun, 31 Mar 2013 18:53:00 +0300 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130331155259.GA9867@gmail.com> References: <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> <20130329123155.GA94024@gmail.com> <20130331134047.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130331134047.GN3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , freebsd-hackers@freebsd.org, Stanislav Sedov , "Robert N. M. Watson" , Mikolaj Golub X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 15:53:07 -0000 On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote: > I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and > rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. > Every other OS and our !coredump code assumes 4-byte alignment. Thanks! > Does changing the putnote() to align on the 4-byte boundary cause > real change in the core file notes layout ? Currently, we store only 4 types of notes in a core file: #define NT_PRSTATUS 1 /* Process status. */ #define NT_FPREGSET 2 /* Floating point registers. */ #define NT_PRPSINFO 3 /* Process state info. */ #define NT_THRMISC 7 /* Thread miscellaneous info. */ I checked the sizes of structures inserted into the notes, and on amd64 they all are multiple of 8: (kgdb) p sizeof(prpsinfo_t) % 8 $1 = 0 (kgdb) p sizeof(prstatus_t) % 8 $2 = 0 (kgdb) p sizeof(prfpregset_t) % 8 $3 = 0 (kgdb) p sizeof(thrmisc_t) % 8 $4 = 0 so both 4-byte and 8-byte aligned. I believe that the patch below will not change the current core file notes layout, will make things consistent in our tree, and will make adding my procstat notes easier, if I use 4-byte alignment. Are you ok if I commit it before introducing my changes? Index: sys/kern/imgact_elf.c =================================================================== --- sys/kern/imgact_elf.c (revision 248706) +++ sys/kern/imgact_elf.c (working copy) @@ -1538,10 +1538,10 @@ __elfN(putnote)(void *dst, size_t *off, const char *off += sizeof note; if (dst != NULL) bcopy(name, (char *)dst + *off, note.n_namesz); - *off += roundup2(note.n_namesz, sizeof(Elf_Size)); + *off += roundup2(note.n_namesz, sizeof(Elf32_Size)); if (dst != NULL) bcopy(desc, (char *)dst + *off, note.n_descsz); - *off += roundup2(note.n_descsz, sizeof(Elf_Size)); + *off += roundup2(note.n_descsz, sizeof(Elf32_Size)); } static boolean_t Also, shouldn't we update then the following comment in sys/elf_common.h? /* * Note header. The ".note" section contains an array of notes. Each * begins with this header, aligned to a word boundary. Immediately * following the note header is n_namesz bytes of name, padded to the * next word boundary. Then comes n_descsz bytes of descriptor, again * padded to a word boundary. The values of n_namesz and n_descsz do * not include the padding. */ -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 16:24:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6410F8F2 for ; Sun, 31 Mar 2013 16:24:45 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9372C4 for ; Sun, 31 Mar 2013 16:24:45 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id q3so244207yhf.12 for ; Sun, 31 Mar 2013 09:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eb1OaWDd9KgO6mm93olSwT+AV2SA+GFSiy6mA3eeksM=; b=pGHfw5tg4LNo+q7r5KotTsFtGK8SRhoMUqKYsjqQ500t3wWiB7az0bCXejDHoXeEvX qmJqSFosB6KkDE70rkgVaGwE11STR85wOhgXbEmDebOXXjVW7XRCFGKB4bKBIaMG1Lww UnaXYQNs1U5wHrEZ+FLsVvd5i9jbNNp+skmJ3bXto/MRj3I9ub1Y+GkmGuiiAs0dDQQm PjtS+1XTrAXz242Z3KwnYKBK6LQ8kUkG6YfWxl4mV6Fvu76upuPrni1c556RfpN8He9h aPBq3Uajd3rF56sgwzLi4fLsfIYU26BHlhaIfvj1vuzLpRX0Vek+JzxBdJFiywRLgxVl XbTA== X-Received: by 10.236.184.6 with SMTP id r6mr6933516yhm.66.1364747084820; Sun, 31 Mar 2013 09:24:44 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id u80sm19667265yhj.5.2013.03.31.09.24.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 09:24:44 -0700 (PDT) Message-ID: <51586347.9040307@gmail.com> Date: Sun, 31 Mar 2013 11:24:39 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Ports: make fails, if DESTDIR path has spaces References: <20130331.133829.093.1@DOMY-PC> In-Reply-To: <20130331.133829.093.1@DOMY-PC> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 16:24:45 -0000 Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". You need to escape the space. On 3/31/2013 8:38 AM, rank1seeker@gmail.com wrote: > Under 9.0-RELEASE-p6 > > -- > #!/bin/sh > > # Contains 9.0 world > DESTDIR='/usr/TZ ONE'; export DESTDIR > > cd /usr/ports/benchmarks/unixbench > /usr/bin/make showconfig > -- > > > Errors: > ------- > [: /usr/TZ: unexpected operator > ===> Creating some important subdirectories > [: /usr/TZ: unexpected operator > ===> /tmp subdirectory has been successfully created > [: /usr/TZ: unexpected operator > ===> /dev subdirectory has been successfully created > mktemp: mkdtemp failed on /usr/TZ: File exists > ===> Failed to create temporary mount point > *** Error code 9 > > Stop in /usr/ports/benchmarks/unixbench. > ------- > > > Domagoj Smolèiæ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 16:29:48 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E3B29AD0 for ; Sun, 31 Mar 2013 16:29:48 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id BC83431D for ; Sun, 31 Mar 2013 16:29:48 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id k11so1742829iea.38 for ; Sun, 31 Mar 2013 09:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GhI79h4Rf3lpNZaMCpsp+QS3NV01ASyRs1X4FUMRktg=; b=lCGfTJjfXq7NGMojhKRGKgmq13p3ApL2Z5k8iv5alwGAY8fPYK8RuBn1szpR1E9HSj FGGA9PSbppJ87W3urbi7Rk0PlEvgL9onBGUfocwPXCopNxqHYLjQkgT7CPwNmhADOk3g pnCRHW4xsJ5AcG2WWVA6cmsClLmSPFDRb3fFJDUIFkSrFSLOvwxgnwTMlQmo+DYoymdq QPlYb5oAFVv2xJb7jPNfmttcGMblyx4OmoY1VthtbX1HKtjIxBc85f/vLA1UceKyzXza OJegf11RIax4SNLmMyJEJJ5q96DAFJ1GBjJaesjKmPdfB19Zocy3CICXctbboRfJ2ayc eZVw== X-Received: by 10.50.13.175 with SMTP id i15mr2417742igc.75.1364747388403; Sun, 31 Mar 2013 09:29:48 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Sun, 31 Mar 2013 09:29:18 -0700 (PDT) In-Reply-To: <20130331.133829.093.1@DOMY-PC> References: <20130331.133829.093.1@DOMY-PC> From: Chris Rees Date: Sun, 31 Mar 2013 17:29:18 +0100 X-Google-Sender-Auth: M7vfd82hwKvGaeKYXthm7g2T5J0 Message-ID: Subject: Re: Ports: make fails, if DESTDIR path has spaces To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 16:29:48 -0000 On 31 March 2013 14:38, wrote: > Under 9.0-RELEASE-p6 > > -- > #!/bin/sh > > # Contains 9.0 world > DESTDIR='/usr/TZ ONE'; export DESTDIR > > cd /usr/ports/benchmarks/unixbench > /usr/bin/make showconfig > -- > > > Errors: > ------- > [: /usr/TZ: unexpected operator > ===> Creating some important subdirectories > [: /usr/TZ: unexpected operator > ===> /tmp subdirectory has been successfully created > [: /usr/TZ: unexpected operator > ===> /dev subdirectory has been successfully created > mktemp: mkdtemp failed on /usr/TZ: File exists > ===> Failed to create temporary mount point > *** Error code 9 > > Stop in /usr/ports/benchmarks/unixbench. Yeah, don't do that. Spaces in directories will always cause problems; I suppose someone could fix it in bsd.port.mk, but it will probably break somewhere else; spaces in Make variables have a special meaning. Use an underscore if you're desperate. Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 17:09:48 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3187A12C; Sun, 31 Mar 2013 17:09:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 944AC6B5; Sun, 31 Mar 2013 17:09:47 +0000 (UTC) Received: from [89.204.138.26] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UMLlJ-0006dM-BR; Sun, 31 Mar 2013 19:09:45 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r2VG9ijj001174; Sun, 31 Mar 2013 18:09:45 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r2VG9hTf001173; Sun, 31 Mar 2013 18:09:43 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 31 Mar 2013 18:09:43 +0200 From: Matthias Apitz To: Chris Rees Subject: Re: Ports: make fails, if DESTDIR path has spaces Message-ID: <20130331160942.GA1113@tiny.Sisis.de> References: <20130331.133829.093.1@DOMY-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.138.26 Cc: rank1seeker@gmail.com, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:09:48 -0000 El día Sunday, March 31, 2013 a las 05:29:18PM +0100, Chris Rees escribió: > Yeah, don't do that. +1 > > Spaces in directories will always cause problems; I suppose someone > could fix it in bsd.port.mk, but it will probably break somewhere > else; spaces in Make variables have a special meaning. > > Use an underscore if you're desperate. Until today I thought that this, spaces in file or dir names, have been the typically attitude of Windows minded people; if it now comes to FreeBSD hackers, the world is coming to its end :-) matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 17:23:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B48604FD; Sun, 31 Mar 2013 17:23:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 273D1763; Sun, 31 Mar 2013 17:23:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2VHN1oG003725; Sun, 31 Mar 2013 20:23:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2VHN1oG003725 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2VHN14o003724; Sun, 31 Mar 2013 20:23:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Mar 2013 20:23:01 +0300 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130331172301.GO3794@kib.kiev.ua> References: <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> <20130329123155.GA94024@gmail.com> <20130331134047.GN3794@kib.kiev.ua> <20130331155259.GA9867@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dm/22yvNomxGlc+y" Content-Disposition: inline In-Reply-To: <20130331155259.GA9867@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Attilio Rao , freebsd-hackers@freebsd.org, Stanislav Sedov , "Robert N. M. Watson" , Mikolaj Golub X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:23:07 -0000 --dm/22yvNomxGlc+y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 31, 2013 at 06:53:00PM +0300, Mikolaj Golub wrote: > On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote: >=20 > > I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and > > rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. > > Every other OS and our !coredump code assumes 4-byte alignment. >=20 > Thanks! > =20 > > Does changing the putnote() to align on the 4-byte boundary cause > > real change in the core file notes layout ? >=20 > Currently, we store only 4 types of notes in a core file: >=20 > #define NT_PRSTATUS 1 /* Process status. */ > #define NT_FPREGSET 2 /* Floating point registers. */ > #define NT_PRPSINFO 3 /* Process state info. */ > #define NT_THRMISC 7 /* Thread miscellaneous info. */ >=20 > I checked the sizes of structures inserted into the notes, and on amd64 > they all are multiple of 8: >=20 > (kgdb) p sizeof(prpsinfo_t) % 8 > $1 =3D 0 > (kgdb) p sizeof(prstatus_t) % 8 > $2 =3D 0 > (kgdb) p sizeof(prfpregset_t) % 8 > $3 =3D 0 > (kgdb) p sizeof(thrmisc_t) % 8 > $4 =3D 0 >=20 > so both 4-byte and 8-byte aligned. Well, FreeBSD supports some more 64bit architectures, besides amd64. At least on powerpc64, I get prpsinfo 120 0 prstatus_t 344 0 prfpregset_t 264 0 thrmisc_t 24 0 Second column is sizeof(), third is sizeof() % 8. This is in fact not much surprising, since all ABIs define the alignment of the structure as the alignment of the most demanding member. And, because 64bit architectures have 8-byte registers, it is indeed expected that the size % 8 =3D=3D 0. >=20 > I believe that the patch below will not change the current core file > notes layout, will make things consistent in our tree, and will make > adding my procstat notes easier, if I use 4-byte alignment. >=20 > Are you ok if I commit it before introducing my changes? Yes, I believe this is the right thing to do. >=20 > Index: sys/kern/imgact_elf.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/imgact_elf.c (revision 248706) > +++ sys/kern/imgact_elf.c (working copy) > @@ -1538,10 +1538,10 @@ __elfN(putnote)(void *dst, size_t *off, const char > *off +=3D sizeof note; > if (dst !=3D NULL) > bcopy(name, (char *)dst + *off, note.n_namesz); > - *off +=3D roundup2(note.n_namesz, sizeof(Elf_Size)); > + *off +=3D roundup2(note.n_namesz, sizeof(Elf32_Size)); > if (dst !=3D NULL) > bcopy(desc, (char *)dst + *off, note.n_descsz); > - *off +=3D roundup2(note.n_descsz, sizeof(Elf_Size)); > + *off +=3D roundup2(note.n_descsz, sizeof(Elf32_Size)); > } > =20 > static boolean_t >=20 > Also, shouldn't we update then the following comment in sys/elf_common.h? >=20 > /* > * Note header. The ".note" section contains an array of notes. Each > * begins with this header, aligned to a word boundary. Immediately > * following the note header is n_namesz bytes of name, padded to the > * next word boundary. Then comes n_descsz bytes of descriptor, again > * padded to a word boundary. The values of n_namesz and n_descsz do > * not include the padding. > */ >=20 > --=20 > Mikolaj Golub --dm/22yvNomxGlc+y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWHD0AAoJEJDCuSvBvK1BOX8P/1mASCWd1ZsLzlCTRXSFHA5T ChXEWGxGEGTn66YdssR6ibISWRiNCXSqSIROyMDLl4WbDTVej9YK2seCl1b7WzDV slzWqU3TdCgP1lX4XJq53n9JbFpKgDRK/nnOLjgy8GX9r5xY3uGcxsH3lLMBI1TE UJqlEi0ebJitd1ps8UxDTTTO65Z85sx4KOcg58RuRpNfe68Dz3nt6FK1uisDnhw4 Q8GNUz0ecahrlg6rKtuuN8qDKciDBimJdPzw3k0x/sT6/sMpnwUmBbDsnZ0XoXuG XJZfYhlCd+5b2YdJ5OJhPCNg81aq38dRAFl6JH88slY4XiE/Oxch/Sxi1l/ESB6c moh8c8Z30tNozdNes+Bc3eyW8wun3ztAOXQwviaG45MINk0L0Mg8oyGTCmwB+ElY rz/x/koremF2vxTtJy3icqX9WTOJr0CRl00zT2xQLq6Vi9fjztIr2h3NV06ger1y RSoinJSVfXuXFMfSKiZeFXYKvnNW9Ew7DqDZMl9zt0C+k04gzTxQFWuZ6+v5IZSw KygvBiF99lY9EnRfuaTQnWO4yp+95SQkg235OJcZQjCWXljg6wn/uCZMhD8JDVor nXYUedeymqL2U1OC+DxpUdzMyzoiBcV84e9x/Ts/dzn1yBWxcgY9cwfUqm6zlNWO HZ6gT3+B7Jf/TDnD4dZo =/Loq -----END PGP SIGNATURE----- --dm/22yvNomxGlc+y-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 19:43:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 923945D9 for ; Sun, 31 Mar 2013 19:43:38 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9DFCD3 for ; Sun, 31 Mar 2013 19:43:38 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 1202E33C48; Sun, 31 Mar 2013 15:43:26 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 470BF39860; Sun, 31 Mar 2013 15:43:23 -0400 (EDT) From: Lowell Gilbert To: Mario Lobo Subject: Re: how to force all packets to be ipv4 not v6 References: <20130331095730.7c8b5e55@papi> Date: Sun, 31 Mar 2013 15:43:23 -0400 In-Reply-To: <20130331095730.7c8b5e55@papi> (Mario Lobo's message of "Sun, 31 Mar 2013 09:57:30 -0300") Message-ID: <44ip479wys.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org, Aryeh Friedman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 19:43:38 -0000 Mario Lobo writes: > On Sun, 31 Mar 2013 01:20:17 -0400 > Aryeh Friedman wrote: > >> I have a host that for ISP reasons must have a ipv6 addr as well as >> the ipv4 but the ISP does not offer external ipv6 routing but all the >> commanes (ssh, ftp, etc.) default to ipv6 and need special options to >> use 4 is there anyway to force them to always use 4? >> _______________________________________________ >> 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" > > A kick and dirty way would be to comment the line: > > options INET6 # IPv6 communications protocols > > from your kernel config and recompile. That breaks the "must have a ipv6 addr" requirement. The way to do this without completely disabling IPv6 used to be to configure ipv6_prefer, but that appears to have been superseded by ip6addrctl_policy. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 20:07:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9FEF082B for ; Sun, 31 Mar 2013 20:07:03 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADECD6D for ; Sun, 31 Mar 2013 20:07:03 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj8so1093649wib.13 for ; Sun, 31 Mar 2013 13:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/oka+/42nPINq4WBU8w/kB6j/08/m5f0dwi0bzqjDbk=; b=gPqPeZW6wac8kAR1aswAZNI8EawkCguAbJTVQWj1Gr6HN2nqqEJaqrJdM3nMk4nEhb tw+l9oDo663YnDfPzoPwjP8zPgb6JJVMzfJsBgLxTc+LOZ4gIxN0gT36+4ofv5oVI2Dz THPCe99a9mOez75hh3+lEGuy/PXGaO+TlYQIcv9zOJAh+P7bA7olTUV6KxiSWKBZfDS2 U9YL9KcLNFW6V7bt1j5QkIVCF3JdB1+Gx4Tyrkb6AhTctKrjh3FqKTVglIxFurA0k3CW 41yIoJ1U+/20VjqBzJeP9f/Yowea/Gtc7L9sX4vmS7MNI+Aas98gOGpgmSo/hq1DBNeu dHCQ== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr12478727wjr.33.1364760422403; Sun, 31 Mar 2013 13:07:02 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sun, 31 Mar 2013 13:07:02 -0700 (PDT) In-Reply-To: <44ip479wys.fsf@lowell-desk.lan> References: <20130331095730.7c8b5e55@papi> <44ip479wys.fsf@lowell-desk.lan> Date: Sun, 31 Mar 2013 23:07:02 +0300 Message-ID: Subject: Re: how to force all packets to be ipv4 not v6 From: Kimmo Paasiala To: Lowell Gilbert Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mario Lobo , Aryeh Friedman , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 20:07:03 -0000 If it's just for ssh(1) and scp(1) you can use ssh_config(5) to force the use of IPv4 based on the destination hostname. -Kimmo On Sun, Mar 31, 2013 at 10:43 PM, Lowell Gilbert < freebsd-lists@be-well.ilk.org> wrote: > Mario Lobo writes: > > > On Sun, 31 Mar 2013 01:20:17 -0400 > > Aryeh Friedman wrote: > > > >> I have a host that for ISP reasons must have a ipv6 addr as well as > >> the ipv4 but the ISP does not offer external ipv6 routing but all the > >> commanes (ssh, ftp, etc.) default to ipv6 and need special options to > >> use 4 is there anyway to force them to always use 4? > >> _______________________________________________ > >> 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" > > > > A kick and dirty way would be to comment the line: > > > > options INET6 # IPv6 communications protocols > > > > from your kernel config and recompile. > > That breaks the "must have a ipv6 addr" requirement. > > The way to do this without completely disabling IPv6 used to be to > configure ipv6_prefer, but that appears to have been superseded by > ip6addrctl_policy. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 04:48:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89E63199 for ; Mon, 1 Apr 2013 04:48:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 67D7577C for ; Mon, 1 Apr 2013 04:48:39 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp2so1009556pbb.20 for ; Sun, 31 Mar 2013 21:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=4GZ0Fv5h3a8uIyRxgdbuv3D78vr8q1okbTsBsO8Q9y0=; b=Ixio29gE+rx6kRSuLIs4dwBWIiRDEPwuvp2hzG85XKG2PO3d8SII+jrvBswCJSy66c xdTzFTL7XTHAZyrGhS0wa63Apx5CUQKKhAf+AfA1hN9Mnj3QOgkjPAwseyjPTgod7RrO QKmX+TS1TnjtMyJbnJHCBEBPkE62UsIkRZA9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=4GZ0Fv5h3a8uIyRxgdbuv3D78vr8q1okbTsBsO8Q9y0=; b=bjmtB+z0obICR+sWTt62apNhAvB75Dkm4stNzQC2GgSaN6QfVHA8Z82AM6rmGnYmUm LP/7j0z9OGlnH/UOwSxNzr2Sj4jL8bENWcX+t+U5kTNXTJ99EXa34RNMEAdTk7R6vDsA 7bCLU7wHEn+J72WjZ2Mbz7W/sYvK+QzSr7ziqrjzkDjMRIT6Qu76QuUYyw93SSLVG1Gk bS+r12yrBkEGdllUq3d4VxjoqdZBals2HIKdt9G7KQbuhyP1R8XJGZfl0BovYdjyi1g0 v69pP/FqmJEzxUL+UqlQiX2XgvFnyV6cdhaDLMRhTJfV5HvOXe8WbF2EUTwxzbh2RgVM B28w== X-Received: by 10.66.122.196 with SMTP id lu4mr16505157pab.129.1364791719424; Sun, 31 Mar 2013 21:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.86.34 with HTTP; Sun, 31 Mar 2013 21:48:08 -0700 (PDT) From: Eitan Adler Date: Mon, 1 Apr 2013 00:48:08 -0400 Message-ID: Subject: considering i386 as a tier 1 architecture To: freebsd-arch@freebsd.org, FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn2oLlvosPg8i+mI5NRj8dnnTxBl9t0g96lZH5sNRiakDuKuzvIO2cT2QXns7uQK1Jl1xGE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 04:48:40 -0000 Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 05:40:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6A96E4C; Mon, 1 Apr 2013 05:40:02 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 8CFE5B43; Mon, 1 Apr 2013 05:40:02 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 466C8E3F07A; Mon, 1 Apr 2013 07:30:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcF8kYO4Na37; Mon, 1 Apr 2013 07:30:42 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 72BEDE3F079; Mon, 1 Apr 2013 07:30:41 +0200 (CEST) Date: Mon, 1 Apr 2013 07:30:39 +0200 From: Joel Dahl To: Eitan Adler Subject: Re: considering i386 as a tier 1 architecture Message-ID: <20130401053039.GA82735@devbox.vnode.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 05:40:02 -0000 On Mon, Apr 01, 2013 at 12:48:08AM -0400, Eitan Adler wrote: > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only. No, it isn't. Windows Server 2008 comes in both 32 bit and 64 bit versions. Windows Server 2008 R2 is 64 bit only however. The same goes for Windows Server 2012. -- Joel From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 05:41:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D70CFFFA; Mon, 1 Apr 2013 05:41:08 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 894A1B64; Mon, 1 Apr 2013 05:41:08 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id hz11so2043273vcb.37 for ; Sun, 31 Mar 2013 22:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=azqr0HtDAA9x6f0IZpGYSI+n/GmPmiywAMzHvbV0vhs=; b=ysCSodKZD4bKYiLgpwYEDs18I+SYIyXEsRvp3gpoYnGGA0ndPGMRlEDwNQ9Z77EZ9p ZeFt+lv+SnkUSvD/jyk2zxbDnsZTeQWSc++N3dkUL+a/05T59X4yTgKlXRFUQs4izdbv CF/jHZbG4kaXscbmWlu5hUSCV5YaaG6BBmiXmYOiOgaaFQsSnVPa7pNi+FX64VtHNFsk I/6+0XZqIHIZfEchqP6WfhJnAD0c0biR65PN+/UUxS5namZA4tlVDS4xnEwTkzoKKWxV hmlY8aY+5DDEiEfGR5kIbhcVpM3bi3VHh4QMKrbuRQH40VTc06YBE25l0uv2+xgVfyBQ aX1w== MIME-Version: 1.0 X-Received: by 10.220.140.18 with SMTP id g18mr8263838vcu.54.1364794862694; Sun, 31 Mar 2013 22:41:02 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Sun, 31 Mar 2013 22:41:02 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Mar 2013 22:41:02 -0700 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Mehmet Erol Sanliturk To: Eitan Adler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 05:41:08 -0000 On Sun, Mar 31, 2013 at 9:48 PM, Eitan Adler wrote: > Hi, > > I am writing this email to discuss the i386 architecture in FreeBSD. > > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. > > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? Often times the build works for amd64 but fails for i386. > > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users > and downstream vendors no longer care about preserving ancient > hardware. > > I hope this email is enough to convince you that on this date we > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. > > -- > Eitan Adler > This idea is really very good . The FreeBSD Project man power , for me , is wasted to maintain a branch that it is NOT necessary to make it a first class branch . 1 Giga Bytes , and even 2 Giga Bytes memory chips are disappearing from the computer shops slowly . At present , there is NO any processor which is ONLY 32-bits . Not only the Windows Server , if I am not remembering incorrectly , new regular Windows ( desk top , etc. ) versions will drop 32 bits branches : They only supply 64 bits versions . By concentrating on 64 bits ( amd64 ) branch and work toward distributed processing and high performance computing for super or clustered computers or graphics chips ( cards ) is much more useful than working on 32 bits version . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 05:48:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F8AB2CD; Mon, 1 Apr 2013 05:48:28 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id D6702C18; Mon, 1 Apr 2013 05:48:27 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so1276457wib.4 for ; Sun, 31 Mar 2013 22:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k2ypdD9bWkASjyRd/I1ciEZY+JlceNNpc0sayriixCA=; b=G1PI4Efs5fQ+DHi8VhEVVtcK742gnnB4cfh2N/ppi6DWXHItwtax7n2W/zddFt6TNa jJkBAY0yEK5WDstQmNRpMPS/NyoaEcZV1KT/Q3tohTlpj/VLuq+/vfYvyOM93Qnufpy7 I1rL356L0KDWwaiJH99OmyzQ8hEEC9UIVmiyJM7mAva0LtvpbGNBoSXvXWuVBf9tdHJq 3V5T8gGO/CSkTCTBGnKFyfdy8P2ZFyA0lyo5zCET0Cb0/jIrKSM8iVooEwZofDVt8vmm LzsZyWRNJaYPOFgR+7iAO7KlJSr+Z4SiqtTmHWuv1YEWKIeFEsVG1cUD4qjK0RSSJB+R IU6g== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr8172558wiv.27.1364795306989; Sun, 31 Mar 2013 22:48:26 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sun, 31 Mar 2013 22:48:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 08:48:26 +0300 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Kimmo Paasiala To: Eitan Adler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 05:48:28 -0000 I think the only ones who are going to object are the users of embedded hardware. Some of them are still using CPUs that are only i586 equivalent. Personally I support the notion. -Kimmo On Mon, Apr 1, 2013 at 7:48 AM, Eitan Adler wrote: > Hi, > > I am writing this email to discuss the i386 architecture in FreeBSD. > > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. > > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? Often times the build works for amd64 but fails for i386. > > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users > and downstream vendors no longer care about preserving ancient > hardware. > > I hope this email is enough to convince you that on this date we > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 05:50:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1BA1476; Mon, 1 Apr 2013 05:50:41 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id AC596C37; Mon, 1 Apr 2013 05:50:41 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id DECE73B764; Mon, 1 Apr 2013 05:50:34 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 7DB8AF74FA; Mon, 1 Apr 2013 16:50:31 +1100 (EST) Date: Mon, 1 Apr 2013 16:50:31 +1100 From: Greg 'groggy' Lehey To: Eitan Adler Subject: Re: considering i386 as a tier 1 architecture Message-ID: <20130401055031.GB47589@eureka.lemis.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 05:50:41 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 1 April 2013 at 0:48:08 -0400, Eitan Adler wrote: > Hi, > > I am writing this email to discuss the i386 architecture in FreeBSD. > > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. > > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? Often times the build works for amd64 but fails for i386. > > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users > and downstream vendors no longer care about preserving ancient > hardware. > > I hope this email is enough to convince you that on this date we > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. Nice one! And only 48 minutes into the day. I've seen a number of people take it seriously. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFZICYACgkQIubykFB6QiPo5QCfbZklgxo/h4moVfwrzlmCDj3N yVwAnA2RsSCOqjI9Ot2NP8C9tdDfAKLd =eMP3 -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 05:53:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7239651; Mon, 1 Apr 2013 05:53:37 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id E9B30CD8; Mon, 1 Apr 2013 05:53:36 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so1278676wib.10 for ; Sun, 31 Mar 2013 22:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tGUA89l9lgpIC8jtd17hs1hpbja2ZhmeXPeStSgiAvA=; b=HJTE/yNreWmzsaLLfDdDCqddf5c8U+eoDhVlKpRVZa3gPrYg43omM7YNdlhw43538j RSPCNlVwOB2pp9PSPT0DZhhQwJx9AaPVPPYIfDhrG61ZD4a5uhA6kzIYbI1qrHxW0aM2 qANoGcpbJQdXV1dxJ97fn3tUF7Svwo8WJSNSaIi4LBr4W3azKbWbETvCyLD9GMulM1Ts WPjcZuJa+1t8A/W5EEipQnEkVIGcrupQxMsmFwWvIgYr66pB5KLqj1neH4ktVdv241w6 +t98YH/nLmX4AcYzYWwdXG3oER0R0GH8rzVANnjUb0JxCb4gSWsAzUTksshF7swfSnsC t2Og== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr13853005wjr.33.1364795616171; Sun, 31 Mar 2013 22:53:36 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sun, 31 Mar 2013 22:53:36 -0700 (PDT) In-Reply-To: <20130401055031.GB47589@eureka.lemis.com> References: <20130401055031.GB47589@eureka.lemis.com> Date: Mon, 1 Apr 2013 08:53:36 +0300 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Kimmo Paasiala To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset=UTF-8 Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 05:53:37 -0000 On Mon, Apr 1, 2013 at 8:50 AM, Greg 'groggy' Lehey wrote: > On Monday, 1 April 2013 at 0:48:08 -0400, Eitan Adler wrote: >> Hi, >> >> I am writing this email to discuss the i386 architecture in FreeBSD. >> >> Computers are getting faster, but also more memory intensive. I >> can not find a laptop with less than 4 or 8 GB of RAM. Modern >> browsers, such as Firefox, require a 64bit architecture and 8GB of >> RAM. A 32 bit platform is not enough now a days on systems with >> more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in >> the 1990s. Even in the embedded world ARM is going 64 bit with >> ARMv8. >> >> Secondly, the i386 port is unmaintained. Very few developers run >> it, so it doesn't get the testing it deserves. Almost every user >> post or bug report I see from a x86 compatible processor is running >> amd64. When was the last time you booted i386 outside a virtual >> machine? Often times the build works for amd64 but fails for i386. >> >> Finally, others are dropping support for i386. Windows Server 2008 >> is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users >> and downstream vendors no longer care about preserving ancient >> hardware. >> >> I hope this email is enough to convince you that on this date we >> should drop support for the i386 architecture for 10.0 to tier 2 >> and replace it with the ARM architecture as Tier 1. > > Nice one! And only 48 minutes into the day. I've seen a number of > people take it seriously. > > Greg > -- > Oh crap :P However, this discussion will not be out of place some day, may be 2 or 3 years and practicly everything will be 64-bits. -Kimmo From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 06:26:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAADEE35; Mon, 1 Apr 2013 06:26:20 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id A906AE9D; Mon, 1 Apr 2013 06:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=einjhPmIJUhHUwkm1y4kBVpOsQKZX1TOJnmKcUTNg1g=; b=jqIQdb39QDi0bLQg53yTc91D6w9z0c07dGJLTKTRcDEt16H+zTYWdtJ9BLbYdQto7rFG6ua5mhUI1VIuQANbYyaaM0lHHe5Paqqv3C+YPXgglOQOXLhDUsWgszEuFy8Tsx3+obxnzFmM3/9HcIbYtjcDhaSxOs3yVNkqtUahjY8=; Received: from [122.129.203.50] (port=54667 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UMYCB-003gNA-9e; Mon, 01 Apr 2013 00:26:19 -0600 Date: Mon, 1 Apr 2013 13:26:14 +0700 From: Erich Dollansky To: Eitan Adler Subject: Re: considering i386 as a tier 1 architecture Message-ID: <20130401132614.1252f827@X220.ovitrap.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 06:26:20 -0000 Hi, On Mon, 1 Apr 2013 00:48:08 -0400 Eitan Adler wrote: > Hi, > > I am writing this email to discuss the i386 architecture in FreeBSD. if not for the date, I just wonder, what significance it real has. Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 08:26:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 430627C7; Mon, 1 Apr 2013 08:26:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0817B86D; Mon, 1 Apr 2013 08:26:15 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id ED6FB4AC57; Mon, 1 Apr 2013 12:26:07 +0400 (MSK) Date: Mon, 1 Apr 2013 12:26:00 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <917043347.20130401122600@serebryakov.spb.ru> To: Eitan Adler Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:26:16 -0000 Hello, Eitan. You wrote 1 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 8:48:08: EA> I hope this email is enough to convince you that on this date we EA> should drop support for the i386 architecture for 10.0 to tier 2 EA> and replace it with the ARM architecture as Tier 1. A lot of people (myself included) uses FreeBSD on small "integrated" boards from Soekris, ALIX and others, equipped with low-power non-interl i386-compatible processors. Now such boards start (only start!) to migrate to Intel Atom, but not every Intel Atom platform is 64bit capable (it depends on CPU, chipset, BIOS and some other unknown conditions, but the same CPU on different boards could be and could be not 64-bit capable in practice). And these die-hard integrated mult-NIC soldered-memory soldered-CPU motherboards will work for long time. I'm using -CURRENT on my board, because I need very last WiFi, for example, and as such boards are often used as small custom routers, it is not only my case. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 08:52:06 2013 Return-Path: Delivered-To: FreeBSD-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6052B264; Mon, 1 Apr 2013 08:52:06 +0000 (UTC) (envelope-from cnst++@FreeBSD.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id E81B3A35; Mon, 1 Apr 2013 08:52:05 +0000 (UTC) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r318q4ca019732; Mon, 1 Apr 2013 01:52:04 -0700 (PDT) Message-ID: <51594AB3.4070002@FreeBSD.org> Date: Mon, 01 Apr 2013 01:52:03 -0700 From: "Constantine A. Murenin" Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 SeaMonkey/2.13.2 MIME-Version: 1.0 To: FreeBSD-current@FreeBSD.org, FreeBSD-hackers@FreeBSD.org Subject: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:52:06 -0000 Dear FreeBSD-{current,hackers}@, It is my great pleasure to announce the immediate availability of a publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross Reference. BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok. We've fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. What's up with the publicly private beta test? We're launching today in a publicly private beta. Participation in the beta is invitation-only; everyone with IPv6 is invited. We're cooperating with ISPs around the world, and in order to be able to access BXR.SU during this beta phase, you must have a special token, also known as a publicly routable IPv6-address, with proper IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but want to participate in this beta test ASAP, then ask your ISP for IPv6 ASAP! Else, if your ISP is not part of our beta rollout, you could try something like tunnelbroker.net from he.net. What's the release schedule? BXR.SU is available through IPv6 today, 2013-04-01. It is currently an IPv6-only site, with an IPv6-only glue, too. As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day. On April 4, we will temporarily enable IPv4 connectivity, for one day, to test the water. (We've heard that IPv4 has some connectivity issues related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small percentage of users (but significant in absolute terms) might not be able to access the site if an A record is published, due to the plentiful of misconfigurations out there; so, we want to take things slow, and ensure our users don't suffer from any inferior connectivity.) If things do go well (we expect IPv6/IPv4-related improvements as time goes by), we will permanently publish an A record for BXR.SU on 2013-04-14. IPv4 glue records will be published shortly thereafter, on 2013-04-24 (we don't do this today, because we're afraid that the nameservers of some ISPs are not configured correctly, and our IPv6 users won't be able to access our site otherwise, so, we think it's a good idea to take things slow and in steps). But why another OpenGrok? Over the years, there have been a number of OpenGrok installations that have made it possible to study and grok BSD code, for which we are very thankful to their maintainers. However, as a general rule, none of them have been inclusive of all BSD flavours, all of them have had rather long and hard-to-remember URLs, which also didn't really look permanent at all, and, unfortunately, many of them no longer exist today, or some new uber-inclusive services like code.metager.de have recently flourished, with an astounding 8 second (yes, eight second) delay for satisfying any single search query (hot queries are returned in as little as just under 4 seconds by metager, yet everything is nonetheless buffered, so, you get no rendering at all for those whole 4 or 8 seconds). So, we thought this had to change. So, what's the deal? It's simple. Say, someone doesn't know who PHK is. You can point them to: http://bxr.su/s?q=phk Want to see if DragonFly keeps queue.h in sync? Take a look at: http://bxr.su/d/sys/sys/queue.h Want to look at FreeBSD's queue.h, to manually compare? Just change the "d" from "/d/" (or select and replace the whole world "DragonFly" from "/DragonFly/") to "f", and you're in FreeBSD: http://bxr.su/f/sys/sys/queue.h Too many /sys/sys/? We've still got you covered, thanks to nginx: http://bxr.su/o/queue.h Anyone uses TAILQ_SWAP? Is that a new thing? Check it out: http://bxr.su/search?q=TAILQ_SWAP Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly? http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD Who's this guy writing this email anyway? Is he BXR'able? http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst Etc. Just how fast is BXR.SU? We expect that most search requests should be fulfilled (search page results generated) in well under 100ms. In my tests, and according to OpenGrok metrics at the bottom of each search page, most search pages are generated in about 30 to 50ms, so, it does seem like there's some room to spare. In addition, of course we use nginx, so, once generated at 40ms, a page should be available immediately in no time should a subsequent identical request come along within a couple of seconds or so. How does it compare with fxr.watson.org? + we're based on OpenGrok, instead of LXR + we also index userland of all BSDs, not just the kernels like the fxr + we do daily updates and re-index of all 4 BSDs - we only track -CURRENT of each BSD + the -current that we track is actually current Is this a replacement to nxr.netbsd.org? Not necessarily. We've noted that the /gnu/ and /contrib/ directories of various BSDs have been constantly giving out lots of false positives on all kinds of search queries, and they have been excluded, for both the accuracy and disc space utilisation. This only affects userland, and mostly excludes stuff that noone really cares about anyways (some exceptions were made, and this is not really in stone anyways). Otherwise, BXR.SU is much faster than the nxr -- nxr search is unbuffered, but takes several seconds on cold runs, and about half a second on hot runs. How does it compare with code.metager.de? + we're over 20000% faster (0.04s vs. 8s). 'nuff said. I welcome comments, questions and suggestions. I hope that this site will be useful to the BSD community, and will join other great and invaluable BSD-related sites that we all use and depend on. In summary, what's unique about bxr.su? * Supports all 4 BSDs * Daily updates * Short URLs, deterministic URL shortener for BSD source code * Kernel + non-gnu userland * Very fast -- most search pages generated in under 50ms * IPv6-only for now, will be dual-stacked very soon Enjoy! Constantine. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 10:39:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCAE7FC6; Mon, 1 Apr 2013 10:39:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 809451B1; Mon, 1 Apr 2013 10:39:17 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D66CFC4B1; Mon, 1 Apr 2013 10:39:15 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 83A1A946E; Mon, 1 Apr 2013 12:39:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: considering i386 as a tier 1 architecture References: Date: Mon, 01 Apr 2013 12:39:15 +0200 In-Reply-To: (Mehmet Erol Sanliturk's message of "Sun, 31 Mar 2013 22:41:02 -0700") Message-ID: <86wqsmpmb0.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 10:39:17 -0000 Mehmet Erol Sanliturk writes: > At present, there is NO any processor which is ONLY 32-bits. All the world is not a PC. There are still 32-bit x86-based embedded or small-form-factor systems, such as the soekris net5501 and net6501, which are widely used in the BSD community. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 11:08:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2889E29; Mon, 1 Apr 2013 11:08:41 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx1.freebsd.org (Postfix) with ESMTP id 741066A3; Mon, 1 Apr 2013 11:08:41 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id gf12so2178519vcb.24 for ; Mon, 01 Apr 2013 04:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=J0Rg/rEkVXgp5Zgkb0YgagSbrQP2gnt3buSkhK6R6Kw=; b=BCVxWLNPlmjhhunl4wjjLvbBVYQVVLBOR3JyABwox9k22KYgYbBFPeji79p3OhKAev F6+WculKS9fnGg1LR2LdBdBogHFpNLvvQZYeyc0Igk/tR2KDc+4DKjlCbFtOhRX1qlNu 6FnBcAgtgm0QBtjDa69+CohBXeM4SkQJEXflVnyC2AbzVmnfDPQ+0I71qd0wphwPPGfS iz7+URfwh8iQ+Fl3Mn2M3upiTIUa2emgtEMbIFPKPB9GVtklcnM7uGFPyXCWwdSEVpHS DyoBEeGDeY/7KvuatlioK24nGSCvRvJAabcJYaCYdTEU6/uCmMizLX5jEguHYPSUFNZ9 DBKw== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr7307593vdt.126.1364814515218; Mon, 01 Apr 2013 04:08:35 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 1 Apr 2013 04:08:35 -0700 (PDT) In-Reply-To: <86wqsmpmb0.fsf@ds4.des.no> References: <86wqsmpmb0.fsf@ds4.des.no> Date: Mon, 1 Apr 2013 04:08:35 -0700 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 11:08:41 -0000 On Mon, Apr 1, 2013 at 3:39 AM, Dag-Erling Sm=C3=B8rgrav wrote= : > Mehmet Erol Sanliturk writes: > > At present, there is NO any processor which is ONLY 32-bits. > > All the world is not a PC. There are still 32-bit x86-based embedded or > small-form-factor systems, such as the soekris net5501 and net6501, > which are widely used in the BSD community. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > These are special purpose systems and they are not developed by , let's say , "ordinary" users . Therefore , their developers may maintain the existing i386 branch as a specialized branch with a freedom to tailor it to more specific needs . Since I am not a developer or user of such a system , I can not say whether 25000 packages are necessary for them or not . Reducing any amount of work load which its outcome is not directly used is a contribution to the FreeBSD project by diverting such efforts to other man power or resources required areas . When costs are considered , some times 64 bit capable systems are not so expensive : As an example : From a computer shop in Turkey with many branch shops : Memory : 1 Giga Bytes chips : From $27 + VAT to $40 + VAT 4 Giga Bytes chips : From $31 + VAT to $43 + VAT There is NO reason to buy 4 x ( 1 Giga Bytes ) , when the difference is a few dollars with 4 x ( 4 Giga Bytes ) . AMD Sempron 145 AM3 2.8GHz processor is $ 34 + VAT which is 64 bits capable . As I said above , I am not able to make knowledgeable comparisons about such systems but my opinion is that these specialized systems are not so much advantageous . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 08:34:59 2013 Return-Path: Delivered-To: FreeBSD-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5400FA77; Mon, 1 Apr 2013 08:34:59 +0000 (UTC) (envelope-from cnst++@FreeBSD.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id DB8518F1; Mon, 1 Apr 2013 08:34:52 +0000 (UTC) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r318Yo3v011875; Mon, 1 Apr 2013 01:34:51 -0700 (PDT) Message-ID: <515946AA.2060703@FreeBSD.org> Date: Mon, 01 Apr 2013 01:34:50 -0700 From: "Constantine A. Murenin" Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 SeaMonkey/2.13.2 MIME-Version: 1.0 To: FreeBSD-current@FreeBSD.org, FreeBSD-hackers@FreeBSD.org Subject: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Apr 2013 11:23:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:34:59 -0000 Dear FreeBSD-{current,hackers}@, It is my great pleasure to announce the immediate availability of a publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross Reference. BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok. We've fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. What's up with the publicly private beta test? We're launching today in a publicly private beta. Participation in the beta is invitation-only; everyone with IPv6 is invited. We're cooperating with ISPs around the world, and in order to be able to access BXR.SU during this beta phase, you must have a special token, also known as a publicly routable IPv6-address, with proper IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but want to participate in this beta test ASAP, then ask your ISP for IPv6 ASAP! Else, if your ISP is not part of our beta rollout, you could try something like tunnelbroker.net from he.net. What's the release schedule? BXR.SU is available through IPv6 today, 2013-04-01. It is currently an IPv6-only site, with an IPv6-only glue, too. As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day. On April 4, we will temporarily enable IPv4 connectivity, for one day, to test the water. (We've heard that IPv4 has some connectivity issues related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small percentage of users (but significant in absolute terms) might not be able to access the site if an A record is published, due to the plentiful of misconfigurations out there; so, we want to take things slow, and ensure our users don't suffer from any inferior connectivity.) If things do go well (we expect IPv6/IPv4-related improvements as time goes by), we will permanently publish an A record for BXR.SU on 2013-04-14. IPv4 glue records will be published shortly thereafter, on 2013-04-24 (we don't do this today, because we're afraid that the nameservers of some ISPs are not configured correctly, and our IPv6 users won't be able to access our site otherwise, so, we think it's a good idea to take things slow and in steps). But why another OpenGrok? Over the years, there have been a number of OpenGrok installations that have made it possible to study and grok BSD code, for which we are very thankful to their maintainers. However, as a general rule, none of them have been inclusive of all BSD flavours, all of them have had rather long and hard-to-remember URLs, which also didn't really look permanent at all, and, unfortunately, many of them no longer exist today, or some new uber-inclusive services like code.metager.de have recently flourished, with an astounding 8 second (yes, eight second) delay for satisfying any single search query (hot queries are returned in as little as just under 4 seconds by metager, yet everything is nonetheless buffered, so, you get no rendering at all for those whole 4 or 8 seconds). So, we thought this had to change. So, what's the deal? It's simple. Say, someone doesn't know who PHK is. You can point them to: http://bxr.su/s?q=phk Want to see if DragonFly keeps queue.h in sync? Take a look at: http://bxr.su/d/sys/sys/queue.h Want to look at FreeBSD's queue.h, to manually compare? Just change the "d" from "/d/" (or select and replace the whole world "DragonFly" from "/DragonFly/") to "f", and you're in FreeBSD: http://bxr.su/f/sys/sys/queue.h Too many /sys/sys/? We've still got you covered, thanks to nginx: http://bxr.su/o/queue.h Anyone uses TAILQ_SWAP? Is that a new thing? Check it out: http://bxr.su/search?q=TAILQ_SWAP Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly? http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD Who's this guy writing this email anyway? Is he BXR'able? http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst Etc. Just how fast is BXR.SU? We expect that most search requests should be fulfilled (search page results generated) in well under 100ms. In my tests, and according to OpenGrok metrics at the bottom of each search page, most search pages are generated in about 30 to 50ms, so, it does seem like there's some room to spare. In addition, of course we use nginx, so, once generated at 40ms, a page should be available immediately in no time should a subsequent identical request come along within a couple of seconds or so. How does it compare with fxr.watson.org? + we're based on OpenGrok, instead of LXR + we also index userland of all BSDs, not just the kernels like the fxr + we do daily updates and re-index of all 4 BSDs - we only track -CURRENT of each BSD + the -current that we track is actually current Is this a replacement to nxr.netbsd.org? Not necessarily. We've noted that the /gnu/ and /contrib/ directories of various BSDs have been constantly giving out lots of false positives on all kinds of search queries, and they have been excluded, for both the accuracy and disc space utilisation. This only affects userland, and mostly excludes stuff that noone really cares about anyways (some exceptions were made, and this is not really in stone anyways). Otherwise, BXR.SU is much faster than the nxr -- nxr search is unbuffered, but takes several seconds on cold runs, and about half a second on hot runs. How does it compare with code.metager.de? + we're over 20000% faster (0.04s vs. 8s). 'nuff said. I welcome comments, questions and suggestions. I hope that this site will be useful to the BSD community, and will join other great and invaluable BSD-related sites that we all use and depend on. In summary, what's unique about bxr.su? * Supports all 4 BSDs * Daily updates * Short URLs, deterministic URL shortener for BSD source code * Kernel + non-gnu userland * Very fast -- most search pages generated in under 50ms * IPv6-only for now, will be dual-stacked very soon Enjoy! Constantine. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 09:56:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5079C667 for ; Mon, 1 Apr 2013 09:56:46 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2F97CFB9 for ; Mon, 1 Apr 2013 09:56:45 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r319jJw7027369 for ; Mon, 1 Apr 2013 03:45:19 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201304010945.r319jJw7027369@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: boot time crash in if_detach_internal() Date: Mon, 01 Apr 2013 03:45:19 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.torek.net [127.0.0.1]); Mon, 01 Apr 2013 03:45:19 -0600 (MDT) X-Mailman-Approved-At: Mon, 01 Apr 2013 11:43:00 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 09:56:46 -0000 I have been poking about with the bhyve virtualization code in FreeBSD 10-current, and managed to crash FreeBSD during its bootstrap process due to the fact that if_detach is called from boot time configuration code, before the internal domain system initialization has happened. I added the following patch to work around the problem. As the large comment notes, it might not be quite correct but it does allow the boot to proceed (of course the "dead" network device is soon a problem anyway...). The fix mirrors (more or less) the code in if_attach_internal(). Feel free to accept, ignore, or modify the patch. :-) Chris diff --git a/sys/net/if.c b/sys/net/if.c --- a/sys/net/if.c +++ b/sys/net/if.c @@ -845,6 +845,15 @@ if_purgeaddrs(ifp); + /* + * torek: it's not entirely clear to me where and how this + * should go, but if domain_init_status < 2 then there should + * be no inet, inet6, etc items, and this is where the crash + * happens during boot, so let's try this: + */ + if (domain_init_status < 2) + return; + #ifdef INET in_ifdetach(ifp); #endif From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 13:11:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6D8BC0B; Mon, 1 Apr 2013 13:11:58 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A942324A; Mon, 1 Apr 2013 13:11:58 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7CBE6C6EB; Mon, 1 Apr 2013 13:11:56 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 431929488; Mon, 1 Apr 2013 15:11:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: considering i386 as a tier 1 architecture References: <86wqsmpmb0.fsf@ds4.des.no> Date: Mon, 01 Apr 2013 15:11:55 +0200 In-Reply-To: (Mehmet Erol Sanliturk's message of "Mon, 1 Apr 2013 04:08:35 -0700") Message-ID: <86li92pf8k.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:11:59 -0000 Mehmet Erol Sanliturk writes: > Since I am not a developer or user of such a system , I can not say > whether 25000 packages are necessary for them or not. Reducing any > amount of work load which its outcome is not directly used is a > contribution to the FreeBSD project by diverting such efforts to other > man power or resources required areas. You're assuming that maintaining i386 as a tier 1 platform really *does* add significantly to our workload. You should also check your calendar :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 13:31:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95A15B0F for ; Mon, 1 Apr 2013 13:31:52 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog121.obsmtp.com (eu1sys200aog121.obsmtp.com [207.126.144.151]) by mx1.freebsd.org (Postfix) with ESMTP id DCB985E9 for ; Mon, 1 Apr 2013 13:31:51 +0000 (UTC) Received: from mail-lb0-f198.google.com ([209.85.217.198]) (using TLSv1) by eu1sys200aob121.postini.com ([207.126.147.11]) with SMTP ID DSNKUVmMKgpuygX6QgNCscb+u3qDhtJim6Nb@postini.com; Mon, 01 Apr 2013 13:31:52 UTC Received: by mail-lb0-f198.google.com with SMTP id v10so3407268lbd.9 for ; Mon, 01 Apr 2013 06:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:date:from:message-id:to:subject:reply-to :in-reply-to:x-gm-message-state; bh=46xsJaPAwaiZQ13WUVeDdt1aPeJ25vyEfMzO6zqRmXw=; b=IagOCi2Ex2ix4OnVmCImMhnKLC8lHB1M+CCB3abk7HUAh41aO1JqR3I8JVaxmAHIjH KeDVb9Gwh47tsHd5857JJrSJn2QDCRSLuve5iEsbwuCPu29E3YCudK7fS73Dpokrxmq5 pfrwU85OmgTvV2A1Pk1/q+0Hlf2uvRIS9L69YlruEv7cK7jsU7ITc9xSssI5o+G7tMhw 5wqYhxq470INDxNPnBT/cVJ3g4eafRnlYsNzrbdItpDU9jJNt1HZGjJQENITz1EhvJeL M/NoYO0RS+0KNGWwXtrWHmOpNEgnRNy8yG+2QWHMjG0Ln+0J7fadXl8+QnNDeV5yKr2p v6sQ== X-Received: by 10.180.185.197 with SMTP id fe5mr10094176wic.3.1364823081899; Mon, 01 Apr 2013 06:31:21 -0700 (PDT) X-Received: by 10.180.185.197 with SMTP id fe5mr10094166wic.3.1364823081833; Mon, 01 Apr 2013 06:31:21 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPS id g9sm15030078wix.1.2013.04.01.06.31.14 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 06:31:20 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r31DVDPd052857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Apr 2013 14:31:13 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r31DVCJw052856; Mon, 1 Apr 2013 14:31:12 +0100 (BST) (envelope-from mexas) Date: Mon, 1 Apr 2013 14:31:12 +0100 (BST) From: Anton Shterenlikht Message-Id: <201304011331.r31DVCJw052856@mech-cluster241.men.bris.ac.uk> To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, lists@eitanadler.com Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: X-Gm-Message-State: ALoCoQnjm70/Nhx9KgbMkbXRUOOqePA7lzkJTB8cSuKSip0s5SVbHaKtm+FAwB0bZVUcieahtWjDUS0nYWTF3xEdT0DNRqTr7MiJ3tS+C/r/3ngKwe1GhOy/W41cTXLfSPZjHOCluQuEMdzKwquQCoe5ytW4xzJSEwu5vBl4occEgAWYGlDbE10= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:31:52 -0000 From: Eitan Adler Date: Mon, 1 Apr 2013 00:48:08 -0400 Subject: considering i386 as a tier 1 architecture To: freebsd-arch@freebsd.org, FreeBSD Hackers should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. don't care for i386, don't use it anymore. Is ARM really ready for tier 1? Including the ports infrastructure? Installation images? Anton From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 13:35:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98EB7E16 for ; Mon, 1 Apr 2013 13:35:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB9F643 for ; Mon, 1 Apr 2013 13:35:39 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id f4so2011024oah.0 for ; Mon, 01 Apr 2013 06:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/iWDj0RlbJUh7A4soPdAbvZS1M2MqxASSyrvg7nHpr8=; b=c7esPtuByHjF3j1MefHBktkJ8TPTVbbjWs3UNEZOD7tpmP1Iyttc/u371r2RX0R/8X DNLt7qRmG3qctxJTXRMbqwGXbSu2an9Eiig1ZLdjSp+QKZNWK11Gip2PnVo1o8ZJ70O/ pU6IksjmRz76f3wZR+krTVm8xlZ6MM76BIQBjhy4QLeAnVGwvhlTzegEN0lD+L50ZPpE iwRxjPY3Axn6DO421/ySjA6jXZcZLvw7d15z3HbY7lQXnefbpeR/TacvtLDtK/YAxbUj P6QDu9mY6lAI9FOk6R70hjTSmFs1xtAH5+DdVKKMnvBi4Jojxj+81UjetULtpP/1k9nY 5Oxg== MIME-Version: 1.0 X-Received: by 10.60.28.2 with SMTP id x2mr4065190oeg.65.1364823333320; Mon, 01 Apr 2013 06:35:33 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.60.132.142 with HTTP; Mon, 1 Apr 2013 06:35:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 09:35:33 -0400 X-Google-Sender-Auth: c4zzM0BEsLjCvK20gjg53aRKo8c Message-ID: Subject: Re: the Newcons Project From: Ed Maste To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:35:39 -0000 > I would VERY much be able to have a console that looked like this in FreeBSD > > http://wiki.gentoo.org/images/7/7c/Bootsplash.png > > ... > could someone with more understanding of this, be able to tell me if the > Newcons project (when completed) is even going to do what i'm looking for? I'm not really sure what you're looking for, but I suspect newcons is orthogonal to it. Newcons won't change what is displayed, only how it is done; the primary user-facing advantages are Unicode support and better use of graphics modes. There are also some (very important) lower level infrastructural changes. -Ed From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 14:00:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BDB06EA for ; Mon, 1 Apr 2013 14:00:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id CEB4B7D3 for ; Mon, 1 Apr 2013 14:00:56 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id qd14so2341474ieb.28 for ; Mon, 01 Apr 2013 07:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=oYn5c/OLzc5K7yzMoym3Rqdpu/A9vFPOjUAYu9Zt+rI=; b=ooLTM7osTheMbQlXGD5+psMEcozRFxtVmOK01MLVKbipKyuK1bQWPhZooCpQVdMRoM U2TXGiaUOI+RXmU4LHXMEupCFobauKvtDvW0oeOJHLeDZMpP60UxHL3PI9EtQqHam/p3 SvlmFefsulYVQ/0R1HY4A8CtOlp5od9b2WoWMjFAFBEZEbU/gfVoUOaRY7dUOJfB6vJf 8uaqMAHF6ov1c2CPlSxLvtEBuaHohOlRraehGML22m1ljvPvfwOWTWzvvIIosWgRiJRd NVtgMXnD5ao3K1pYOCnHKmii/HDDDoqp4j/5tqAQefFaIfsDECvq1szXVJpazphIulhx gskg== X-Received: by 10.50.178.105 with SMTP id cx9mr3370692igc.111.1364824855658; Mon, 01 Apr 2013 07:00:55 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id vb15sm4719797igb.9.2013.04.01.07.00.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 07:00:54 -0700 (PDT) Sender: Warner Losh Subject: Re: considering i386 as a tier 1 architecture Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 1 Apr 2013 08:00:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kimmo Paasiala X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl1iDh+LH3Xqpcle6pheonuoCcFH8eaPdTFTf/roE3xDgvAfT6JjkS4cKga2zKp8hGCbMbU Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:00:57 -0000 On Mar 31, 2013, at 11:48 PM, Kimmo Paasiala wrote: > I think the only ones who are going to object are the users of = embedded > hardware. Some of them are still using CPUs that are only i586 = equivalent. >=20 > Personally I support the notion. >=20 > -Kimmo >=20 >=20 > On Mon, Apr 1, 2013 at 7:48 AM, Eitan Adler = wrote: >=20 >> Hi, >>=20 >> I am writing this email to discuss the i386 architecture in FreeBSD. >>=20 >> Computers are getting faster, but also more memory intensive. I >> can not find a laptop with less than 4 or 8 GB of RAM. Modern >> browsers, such as Firefox, require a 64bit architecture and 8GB of >> RAM. A 32 bit platform is not enough now a days on systems with >> more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in >> the 1990s. Even in the embedded world ARM is going 64 bit with >> ARMv8. Actually, that's not true. ARM is producing a 64-bit thing, but (a) it = hasn't been released yet and (b) the vast majority of all embedded arm = boards are 32-bits. >> Secondly, the i386 port is unmaintained. Very few developers run >> it, so it doesn't get the testing it deserves. Almost every user >> post or bug report I see from a x86 compatible processor is running >> amd64. When was the last time you booted i386 outside a virtual >> machine? Often times the build works for amd64 but fails for i386. I've not seen this to be the case, and I still run i386 in several = virtual machines as well as on my firewall. Running in a virtual = environment isn't good support for dropping i386, frankly. I've had the = build be broken for me about equal times for both. >> Finally, others are dropping support for i386. Windows Server 2008 >> is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users >> and downstream vendors no longer care about preserving ancient >> hardware. >>=20 >> I hope this email is enough to convince you that on this date we >> should drop support for the i386 architecture for 10.0 to tier 2 >> and replace it with the ARM architecture as Tier 1. arm can be Tier 1 without dropping i386 as Tier 1. Are there specific = bugs in i386 that haven't gone fixed for a long time? Basically, I see no benefit to this move. At least none has been = articulated. Warner= From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 14:17:06 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3657FB08; Mon, 1 Apr 2013 14:17:06 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id E8DC089C; Mon, 1 Apr 2013 14:17:05 +0000 (UTC) Received: from a91-153-126-50.elisa-laajakaista.fi (a91-153-126-50.elisa-laajakaista.fi [91.153.126.50]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 5CE261512D1; Mon, 1 Apr 2013 17:17:00 +0300 (EEST) Date: Mon, 1 Apr 2013 17:16:59 +0300 From: Jaakko Heinonen To: Greg 'groggy' Lehey Subject: Re: calendar(1) regressions Message-ID: <20130401141659.GD1973@a91-153-126-50.elisa-laajakaista.fi> References: <20121206092202.GA2182@a91-153-116-96.elisa-laajakaista.fi> <20121209221525.GC36593@eureka.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121209221525.GC36593@eureka.lemis.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, edwin@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:17:06 -0000 On 2012-12-10, Greg 'groggy' Lehey wrote: > > Unfortunately r205821 [1] has caused several regressions to calendar(1). > > Relevant PRs: > > > > bin/157718 > > bin/162211 > > bin/168785 > > bin/170930 > > > > Some regressions were fixed in summer 2011 but they are still lacking > > MFCs. > > > > Is anyone aware of possible problems that reverting calendar(1) to > > pre-r205821 version would cause? (Of course excluding the actual > > calendar files.) > > I think we fix bugs rather than revert the commits. I've had a chat > with edwin@, and I'll look at the issues Real Soon Now. Has there been any progress on this? -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 14:17:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DCB07BF4 for ; Mon, 1 Apr 2013 14:17:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by mx1.freebsd.org (Postfix) with ESMTP id B90088A9 for ; Mon, 1 Apr 2013 14:17:23 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id z10so1251094pdj.30 for ; Mon, 01 Apr 2013 07:17:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=cKWww2eRmx5bvNSBWro4sMgJpFjI0tzMRFVV3uBVCc0=; b=JBsJCHcNhAygTJFBoiCI/BpYCAkv7qksyEHxtb8lBUqmBy6Faj08XNcGhPel0BVhXz Qm/KRrDRqOCQHpEJScw6GyppKBv+r/sp3m/mKpjehPfC4a9QgYXdd7rmNDhIIUViR1FM 7ONsx0AWQy560uSi1KCStKR2RBrtaY7Z0dbvEEdQ5jNwGiHpLVrMU+9iocW6TP1zQo1R BgH4EcSidwSmadHXs8u5lX5hR0ay+r0lNO2X3BX651HLP6pJAedijJm9dxpKFsK5XB48 owZ/qYKmM6mEw4znbNi/eNXC3bVtrhHPrfgc9N5799i1s0hFqu682m88e4AEj8iD6TWB I28Q== X-Received: by 10.66.13.35 with SMTP id e3mr19248852pac.186.1364825843233; Mon, 01 Apr 2013 07:17:23 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id lb8sm15496374pab.13.2013.04.01.07.17.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 07:17:21 -0700 (PDT) Sender: Warner Losh Subject: Re: considering i386 as a tier 1 architecture Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201304011331.r31DVCJw052856@mech-cluster241.men.bris.ac.uk> Date: Mon, 1 Apr 2013 08:17:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <432EFDBB-9CE8-480A-8B6A-8171BA9F4A83@bsdimp.com> References: <201304011331.r31DVCJw052856@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmQdBWWT11O2HjZvvtwJ6iXIblSd0oOo4IEb2FY36+jdmPHQIjbojcIN+MxP3dPaaBtXX0w Cc: freebsd-hackers@freebsd.org, lists@eitanadler.com, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:17:24 -0000 On Apr 1, 2013, at 7:31 AM, Anton Shterenlikht wrote: > From: Eitan Adler > Date: Mon, 1 Apr 2013 00:48:08 -0400 > Subject: considering i386 as a tier 1 architecture > To: freebsd-arch@freebsd.org, FreeBSD Hackers = >=20 > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. >=20 > don't care for i386, don't use it anymore. >=20 > Is ARM really ready for tier 1? > Including the ports infrastructure? > Installation images? It is certainly getting close, at least for the newer armv6+ boards. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 15:36:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECEA1715; Mon, 1 Apr 2013 15:36:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id CAD90DC6; Mon, 1 Apr 2013 15:36:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F406DB91C; Mon, 1 Apr 2013 11:35:59 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: call suspend_cpus() under smp_ipi_mtx Date: Mon, 1 Apr 2013 10:52:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> In-Reply-To: <514D7A82.9000105@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304011052.18370.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 11:36:00 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:36:01 -0000 On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote: > > Looks like this issue needs more thinking and discussing. > > The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on > SMP systems). > This is for exactly the same reasons as to why we first take smp_ipi_mtx before > calling stop_cpus() in the shutdown path. Essentially one CPU could be holding > smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an > acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), > while another CPU could be with interrupts disabled (explicitly - like in the > shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. > > In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all > regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a > deadlock is quite possible. > > Some obstacles for just going ahead and making the suggested change: > > - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently > witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we > would have to make intr_table_lock and msi_lock the spin-locks as well; > - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and > currently it performs an action that requires memory allocation; again, with > interrupts disabled via intr_disable() this fact is not visible to witness, etc, > but with smp_ipi_mtx it needs to be somehow handled. > > I talked to ACPICA guys about the last issue and they told me that what is > currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts > disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and > _GTS support was removed. > > What do you think? > Thank you. Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember why we changed it to a regular mutex. It may be that there was a lock order reason for that. :( -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 15:36:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65A97812; Mon, 1 Apr 2013 15:36:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 45995DC9; Mon, 1 Apr 2013 15:36:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A259BB9B2; Mon, 1 Apr 2013 11:36:03 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: close(2) while accept(2) is blocked Date: Mon, 1 Apr 2013 11:22:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <515475C7.6010404@FreeBSD.org> In-Reply-To: <515475C7.6010404@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011122.13101.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 11:36:03 -0400 (EDT) Cc: FreeBSD Hackers , Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:36:04 -0000 On Thursday, March 28, 2013 12:54:31 pm Andriy Gapon wrote: > > So, this started as a simple question, but the answer was quite unexpected to me. > > Let's say we have an opened and listen-ed socket and let's assume that we know > that one thread is blocked in accept(2) and another thread is calling close(2). > What is going to happen? > > Turns out that practically nothing. For kernel the close call would be almost a nop. > My understanding is this: > - when socket is created, its reference count is 1 > - when accept(2) is called, fget in kernel increments the reference count (kept in > an associated struct file) > - when close(2) is called, the reference count is decremented > > The reference count is still greater than zero, so fdrop does not call fo_close. > That means that in the case of a socket soclose is not called. > > I am sure that the reference counting in this case is absolutely correct with > respect to managing kernel side structures. But I am not that it is correct with > respect to hiding the explicit close(2) call from other threads that may be > waiting on the socket. > In other words, I am not sure if fo_close is supposed to signify that there are no > uses of a file, or that userland close-d the file. Or perhaps these should be two > different methods. > > Additional note is that shutdown(2) doesn't wake up the thread in accept(2) > either. At least that's true for unix domain sockets. > Not sure if this is a bug. > > But the summary seems to be is that currently it is not possible to break a thread > out of accept(2) (at least without resorting to signals). I think you need to split the 'struct file' reference count into two different counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The fget for accept and probably most other system calls should probably be equivalent to vhold, whereas things like open/dup (and storing an fd in a cmsg) should be more like vref. close() should then be a vrele(). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 15:36:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A9C61818 for ; Mon, 1 Apr 2013 15:36:06 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 853F9DCE for ; Mon, 1 Apr 2013 15:36:06 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id B997542008 for ; Mon, 1 Apr 2013 11:26:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWdi1JTsAWvV for ; Mon, 1 Apr 2013 11:26:25 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <5159A721.60207@egr.msu.edu> Date: Mon, 01 Apr 2013 11:26:25 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: considering i386 as a tier 1 architecture References: <86wqsmpmb0.fsf@ds4.des.no> In-Reply-To: <86wqsmpmb0.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:36:06 -0000 On 04/01/13 06:39, Dag-Erling Smørgrav wrote: > Mehmet Erol Sanliturk writes: >> At present, there is NO any processor which is ONLY 32-bits. > > All the world is not a PC. There are still 32-bit x86-based embedded or > small-form-factor systems, such as the soekris net5501 and net6501, > which are widely used in the BSD community. > > DES > Just for the sake of the archives, the net6501 is 64bit: FreeBSD 9.1-STABLE #3 r245043: Fri Jan 4 11:05:39 EST 2013 root@hostname:/usr/obj/usr/src/sys/AMD64-9 amd64 CPU: Genuine Intel(R) CPU @ 1.60GHz (1600.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20661 Family = 0x6 Model = 0x26 Stepping = 1 Features=0xbfe9fbff Features2=0x40e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147352576 (2047 MB) avail memory = 2047160320 (1952 MB) MPTable: From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:02:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C35AB2DF; Mon, 1 Apr 2013 16:02:24 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 46B13F4C; Mon, 1 Apr 2013 16:02:23 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r31G25mf097481; Mon, 1 Apr 2013 18:02:05 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r31G25Ji097478; Mon, 1 Apr 2013 18:02:05 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 1 Apr 2013 18:02:05 +0200 (CEST) From: Wojciech Puchar To: Eitan Adler Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 01 Apr 2013 18:02:06 +0200 (CEST) Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:02:24 -0000 > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. what? i rarely see firefox exceed 1GB and it is already way too much IMHO. ? A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. and never was. > A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. but ALL NEW x86 computers have 64-bit instruction set. > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? now 1 server running. because it's older and not 64-bit capable. > and replace it with the ARM architecture as Tier 1. true. no need to support it as tier 1. users of older hardware usually don't want to upgrade to latest freebsd kernel and userland. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:03:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DED284D8; Mon, 1 Apr 2013 16:03:38 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6030DF70; Mon, 1 Apr 2013 16:03:38 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r31G3RtE097492; Mon, 1 Apr 2013 18:03:27 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r31G3RXs097489; Mon, 1 Apr 2013 18:03:27 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 1 Apr 2013 18:03:27 +0200 (CEST) From: Wojciech Puchar To: Mehmet Erol Sanliturk Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 01 Apr 2013 18:03:27 +0200 (CEST) Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:03:38 -0000 > that it is NOT necessary to make it a first class branch . 1 Giga Bytes , > and even 2 Giga Bytes memory chips are disappearing from the computer shops > slowly . at now 2GB RAM is smallest you can get, and intel atom is lowest end - but still 64-bit - CPU. > At present , there is NO any processor which is ONLY 32-bits . Not only the > Windows Server , if I am not remembering incorrectly , new regular Windows it should not matter what microsoft do. It is Unix. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:04:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E6DF66D for ; Mon, 1 Apr 2013 16:04:46 +0000 (UTC) (envelope-from greglmiller@gmail.com) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by mx1.freebsd.org (Postfix) with ESMTP id 2DEB5F86 for ; Mon, 1 Apr 2013 16:04:45 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so1283890pde.18 for ; Mon, 01 Apr 2013 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=fe5/tcsDeSEq5Z+ugjanPk6Ezaz4ppWg87o38BrjSzg=; b=IP13TzoHs2+t+CxNpXm/mQqaPH0zPyM1t1hpuu+Zb5RSZIDmGEI6ka6SlnpHh5k8tS oLJCAbRqZW7q/t76kRTKbFw5x6Lm1c82Mox+5A21nJaLT/bq9AYznTZdH2OjEeUCeG9W DDkSjcJd4nUPRN5QitRA+kOZVuo1pl8JHyv30qvhQzK+z7v7QUmKZMODxGgvBMt+bu7b Duu2kLEgT3RBHPpUEtwbPJVprSYYNINTCRbzUzXYvi3+jW1x71GhUpezMM70sutpn8mY VIUTrqdOgA4fHK8HThX7m/wFBlpiH7fK6xyIyXzHBM20DWW+PF0XyLKDyfm2w98qm2xA a7FQ== MIME-Version: 1.0 X-Received: by 10.68.116.169 with SMTP id jx9mr18570128pbb.94.1364832285461; Mon, 01 Apr 2013 09:04:45 -0700 (PDT) Received: by 10.70.29.165 with HTTP; Mon, 1 Apr 2013 09:04:45 -0700 (PDT) In-Reply-To: <86li92pf8k.fsf@ds4.des.no> References: <86wqsmpmb0.fsf@ds4.des.no> <86li92pf8k.fsf@ds4.des.no> Date: Mon, 1 Apr 2013 11:04:45 -0500 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Greg Miller To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:04:46 -0000 On 4/1/13, Dag-Erling Sm=F8rgrav wrote: > You're assuming that maintaining i386 as a tier 1 platform really *does* > add significantly to our workload. Indeed. We don't seem to be running into a ton of issues on this front, and I do still find my 32-bit only Atom-based netbook useful when traveling. > You should also check your calendar :) This is one of the finest pieces of April Fools' Day trolling I've seen in quite some time. I'd rank it right up there with that press release from some years ago about Microsoft's acquisition of the Roman Catholic Church. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:13:56 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF59DA61 for ; Mon, 1 Apr 2013 16:13:56 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 46A0681 for ; Mon, 1 Apr 2013 16:13:56 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id w12so990230bku.36 for ; Mon, 01 Apr 2013 09:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:subject:date:in-reply-to:references :x-mailer; bh=xeicnXjN7vM0U5cJrqNNTmlSGZX/SL8ObbWo+zyXwIg=; b=xmNciPHVKxcFH509jeiXDnr/gosE94n1cuXL2q+dRkNHH4Z98SUoERQ/fd6hpa/QeB axyuk5MtPjS2pCCtlB8FSj10wRuGaS9wUWjP+qm9/Wy4Kw++Hne3BMl3CNUd1haoecGK X2ijT9hre3BwdHXcTnQqGHV8pNdLw9jTtH0GVMIIjg/OVn6HVMWNOkXUEIhldwBlkmWe IF6tMYMlSc3yD2ZQmpsdVMmKP3QHynpPXHXZsMloekLBno7maZ38UmPoXMns6FItX3Q5 aevGqbg30ua8D/2YqPGt+n5igFS7PKhXkZDZkKzlJHkAzhGAUmykqC3L/KhlUx1cH3Ce CVRw== X-Received: by 10.204.200.75 with SMTP id ev11mr5337393bkb.70.1364832835336; Mon, 01 Apr 2013 09:13:55 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPS id n1sm3089078bkv.14.2013.04.01.09.13.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 09:13:53 -0700 (PDT) Message-ID: <20130401.161353.972.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: Re: Ports: make fails, if DESTDIR path has spaces Date: Mon, 01 Apr 2013 18:13:53 +0200 In-Reply-To: References: <20130331.133829.093.1@DOMY-PC> X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:13:56 -0000 > Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". > > You need to escape the space. This is '#!/bin/sh' scripting. Doing so "fixes" *.mk, but breaks sh => dir simply doesn't exist anymore. Matthias && Chris => *.mk is at fault here, for not supporting FreeBSD's full range of chars for dir paths Domagoj From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:30:54 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A478875 for ; Mon, 1 Apr 2013 16:30:54 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id D44AB17C for ; Mon, 1 Apr 2013 16:30:53 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so2535392ieb.29 for ; Mon, 01 Apr 2013 09:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZxhbxK4gRgQG3JmQY93v+5VSz+lcGw42D4SaNtgm7I8=; b=ucUClM3Ue0A2dlEepN+v7SIzXqfT43VQeaP72JK4UbgMlCRKy3sbf4H9bp0K03WyeX QOQm//CN4rqNNyrPN8ZvKmacLKFSCw/+aeUP73o+3ICkJFXSCORlPLqpJlg1Jqnzw2pP sxoSM+OdigolhQHe1MdmIbx2fo23w6b2ZC25K7aKa2bWX9koxM6WjKrDTip8CteSnOwS jMGyW+rQB25kO80rUnYc23bjfjx/9j6eNk89m5Q8cF9b0e5ijTMPUBstBEZLKH+BaPI/ vlzpEfAKzlnKE1GZb3FW19hNfrPVyurT7kyZjxXq9jauS8OAi1lBLRhnqldLyMAYAdlL +8zg== X-Received: by 10.50.152.132 with SMTP id uy4mr3686808igb.62.1364833853588; Mon, 01 Apr 2013 09:30:53 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Mon, 1 Apr 2013 09:30:23 -0700 (PDT) In-Reply-To: <20130401.161353.972.1@DOMY-PC> References: <20130331.133829.093.1@DOMY-PC> <20130401.161353.972.1@DOMY-PC> From: Chris Rees Date: Mon, 1 Apr 2013 17:30:23 +0100 X-Google-Sender-Auth: aKMF9_J7dlOt5raIRWjeHmotojQ Message-ID: Subject: Re: Ports: make fails, if DESTDIR path has spaces To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:30:54 -0000 On 1 April 2013 17:13, wrote: >> Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". >> >> You need to escape the space. > > This is '#!/bin/sh' scripting. > Doing so "fixes" *.mk, but breaks sh => dir simply doesn't exist anymore. > > Matthias && Chris => *.mk is at fault here, for not supporting FreeBSD's > full range of chars for dir paths As I explained before, Makefiles and sh have a strange relationship, where escaping is similar but different in weird places. Unless you are an expert, you should not use spaces in pathnames. Stop doing it; the ports system is not designed around them. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:45:27 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EAEA322E; Mon, 1 Apr 2013 16:45:27 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 6067C233; Mon, 1 Apr 2013 16:45:27 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj8so1715263wib.13 for ; Mon, 01 Apr 2013 09:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sdAITpJyHjoyXi/ZeddQtRyjkueRnu39kgdndp8Pwpo=; b=q70zzZDfavcV0yzjO5F6eV73fPEcIOiovEByrsozzr4lr4VFmJQ5FpvA0pGrTvrbSf z4x1VTcs6YERGyruXjIdGqFFgFAJc9fPzP+gDeCcR306snfXacyQ47f5c776Nxk6P1Pm tRpb8d2DcUEuju3V/pqAd0Sh2UqDDMe5jrbcCgJLPnjxq9ki52Wes/FY1buR3vJv9YNV tY7Tm5wSod06ssU+BMt2jib+TLWsUVWdSq7p0eeEevUQfcyQ81bn+0nufCdCDQRSNXEw TZUX9pDsyo4PX+8YYAYUkuahl5aymJ7TUAepqwUzm9xqtb1Ls07n0YAUhTF1/Kvj/jQz O9kQ== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr10760888wiv.27.1364834725201; Mon, 01 Apr 2013 09:45:25 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 1 Apr 2013 09:45:25 -0700 (PDT) In-Reply-To: References: <20130331.133829.093.1@DOMY-PC> <20130401.161353.972.1@DOMY-PC> Date: Mon, 1 Apr 2013 19:45:25 +0300 Message-ID: Subject: Re: Ports: make fails, if DESTDIR path has spaces From: Kimmo Paasiala To: Chris Rees Content-Type: text/plain; charset=UTF-8 Cc: rank1seeker@gmail.com, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:45:28 -0000 On Mon, Apr 1, 2013 at 7:30 PM, Chris Rees wrote: > On 1 April 2013 17:13, wrote: >>> Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". >>> >>> You need to escape the space. >> >> This is '#!/bin/sh' scripting. >> Doing so "fixes" *.mk, but breaks sh => dir simply doesn't exist anymore. >> >> Matthias && Chris => *.mk is at fault here, for not supporting FreeBSD's >> full range of chars for dir paths > > As I explained before, Makefiles and sh have a strange relationship, > where escaping is similar but different in weird places. > > Unless you are an expert, you should not use spaces in pathnames. > Stop doing it; the ports system is not designed around them. > You could work around the problem by using an external program to do all the expanding and globbing, it would guarantee that the expansions are done the same way always and special characters treated in uniform way. -Kimmo From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 16:47:53 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D3FD3D1 for ; Mon, 1 Apr 2013 16:47:53 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE8E258 for ; Mon, 1 Apr 2013 16:47:52 +0000 (UTC) Received: from [93.104.15.65] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UMhte-0004LQ-7k; Mon, 01 Apr 2013 18:47:50 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id r31Glm3i004409; Mon, 1 Apr 2013 18:47:48 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id r31GlmFr004408; Mon, 1 Apr 2013 18:47:48 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 1 Apr 2013 18:47:48 +0200 From: Matthias Apitz To: rank1seeker@gmail.com Subject: Re: Ports: make fails, if DESTDIR path has spaces Message-ID: <20130401164747.GA4314@tinyCurrent> References: <20130331.133829.093.1@DOMY-PC> <20130401.161353.972.1@DOMY-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130401.161353.972.1@DOMY-PC> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.15.65 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:47:53 -0000 El día Monday, April 01, 2013 a las 06:13:53PM +0200, rank1seeker@gmail.com escribió: > > Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". > > > > You need to escape the space. > > This is '#!/bin/sh' scripting. > Doing so "fixes" *.mk, but breaks sh => dir simply doesn't exist anymore. > > Matthias && Chris => *.mk is at fault here, for not supporting FreeBSD's > full range of chars for dir paths Feel free to fix it. I could even imagine that *.mk and a lot of tools are not UTF-8 ready and the missing blank is one of thousands chars you might miss. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 17:01:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 37CEC7CA; Mon, 1 Apr 2013 17:01:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F09AC2FD; Mon, 1 Apr 2013 17:01:27 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 631374AC58; Mon, 1 Apr 2013 21:01:25 +0400 (MSK) Date: Mon, 1 Apr 2013 21:01:18 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <944760435.20130401210118@serebryakov.spb.ru> To: Wojciech Puchar Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:01:28 -0000 Hello, Wojciech. You wrote 1 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 20:03:27: >> that it is NOT necessary to make it a first class branch . 1 Giga Bytes , >> and even 2 Giga Bytes memory chips are disappearing from the computer sh= ops >> slowly . WP> at now 2GB RAM is smallest you can get, and intel atom is lowest end - = but WP> still 64-bit - CPU. It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 18:31:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 095F6D34; Mon, 1 Apr 2013 18:31:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 72EE184D; Mon, 1 Apr 2013 18:31:32 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k14so1989963wer.27 for ; Mon, 01 Apr 2013 11:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jC1i8KF/ZfFhlPipJvbbPMYDSmdx3l1ZVl78mydk0r8=; b=YQiCb1Q5KFd4L6qtXFQ0ExYTkBHYQrFPPSrc4iiUalhmR/rbnjj2leX0aLyFH3F55m 0itNyTVJmr24hK/ND7RUypHBHF7D8OvJ8pn28dWB4pSQksoZ9PDF+vTv+lfclmwwdqRu dXMJ5/OqX7A8GbZzAk8Wb9POa46O53dBC3pirAyH/Qz4nKpPJxU0JETl7yEqP9TVdM/I e+TPJPCfrOpLTZ60+AY1cXluXgM4zlIOzR8lJXq1/QGLYtEli31P89clATnYw0U89a41 LdxtAZTS+bMc75eq9NNGcpZhrDtg3CYnNDc9i5Xdi0ZPzjoRpYrnBI9MJkXYm74ZjygY Vn6A== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr17094376wjc.0.1364841091599; Mon, 01 Apr 2013 11:31:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 1 Apr 2013 11:31:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 11:31:31 -0700 X-Google-Sender-Auth: tGjYVM4yVN8hdWQo0bGKUDPKgDQ Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:31:33 -0000 Why stop there? Noone runs FreeBSD on real hardware anymore. Except, say netflix. Let's just drop actual native hardware support and instead support only the bare minimum needed to boot inside vmware, virtualbox and xen. Anyone needing real hardware support can install NetBSD and xen. Adrian On 31 March 2013 21:48, Eitan Adler wrote: > Hi, > > I am writing this email to discuss the i386 architecture in FreeBSD. > > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. > > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? Often times the build works for amd64 but fails for i386. > > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users > and downstream vendors no longer care about preserving ancient > hardware. > > I hope this email is enough to convince you that on this date we > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 18:32:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B158AEDF; Mon, 1 Apr 2013 18:32:04 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 33DF6883; Mon, 1 Apr 2013 18:32:03 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r31IVptQ098329; Mon, 1 Apr 2013 20:31:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r31IVpjM098326; Mon, 1 Apr 2013 20:31:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 1 Apr 2013 20:31:51 +0200 (CEST) From: Wojciech Puchar To: Lev Serebryakov Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: <944760435.20130401210118@serebryakov.spb.ru> Message-ID: References: <944760435.20130401210118@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 01 Apr 2013 20:31:51 +0200 (CEST) Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:32:04 -0000 > WP> still 64-bit - CPU. > It is not exact so. Some Atoms on some motherboards with some > firmwares are 64-bit CPU. don't know of any now in shops that are not > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 18:33:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 750CDFC for ; Mon, 1 Apr 2013 18:33:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id EF8ED89A for ; Mon, 1 Apr 2013 18:33:26 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r31IXHjI098357; Mon, 1 Apr 2013 20:33:17 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r31IXHJH098354; Mon, 1 Apr 2013 20:33:17 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 1 Apr 2013 20:33:17 +0200 (CEST) From: Wojciech Puchar To: Greg Miller Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: Message-ID: References: <86wqsmpmb0.fsf@ds4.des.no> <86li92pf8k.fsf@ds4.des.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 01 Apr 2013 20:33:17 +0200 (CEST) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:33:27 -0000 >> You should also check your calendar :) > > This is one of the finest pieces of April Fools' Day trolling I've > seen in quite some time. I'd rank it right up there with that press > release from some years ago about Microsoft's acquisition of the Roman > Catholic Church. anyway Easter at 1 april for me is already a great joke :) From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 19:02:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE4F9E9C; Mon, 1 Apr 2013 19:02:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id BDC1B9C9; Mon, 1 Apr 2013 19:02:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 28F93B98D; Mon, 1 Apr 2013 15:02:00 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: extattr_set_* return type Date: Mon, 1 Apr 2013 14:24:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011424.19784.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:02:00 -0400 (EDT) Cc: mdf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:02:00 -0000 On Saturday, March 30, 2013 5:30:21 pm mdf@freebsd.org wrote: > Despite the man page correctly describing the return value for > extattr_set_*, I thought recently that they returned 0/-1 for > success/failure, not the number of bytes written, like write(2). This is > because extattr_set_* is declared as returning an int, not an ssize_t. > Both extattr_get and extattr_list return ssize_t, so this is inconsistent. > > The patch at > http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix- rmextattr-8-.patchfixes > this. It compiles but it's untested. > > I don't think any compat shims are needed, since an old application will > still sign extend and this will work (it's very unlikely anyone does > extattr_set for 2GB or more). > > If anyone actually uses extattr on 64-bit, please test a new kernel but old > userspace to be sure nothing is broken. I plan to commit this next week if > I don't hear otherwise. Hmm, the patch URL doesn't work, but please fix this. There is an old thread we are both on from Dec 2011 where I ran into the same thing. I also think we don't need compat shims. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 19:02:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFB45E9E; Mon, 1 Apr 2013 19:02:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D04929CA; Mon, 1 Apr 2013 19:02:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54EB0B990; Mon, 1 Apr 2013 15:02:02 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: helgrind (valgrind plugin) errors coming from nsdispatch(3) Date: Mon, 1 Apr 2013 14:30:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514FCEF3.8070902@rawbw.com> In-Reply-To: <514FCEF3.8070902@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011430.52414.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:02:02 -0400 (EDT) Cc: Yuri , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:02:03 -0000 On Monday, March 25, 2013 12:13:39 am Yuri wrote: > While running helgrind on my program, I observed several errors that > stem from the nsdispatch calls, see helgrind log below. > "lock order" error in helgrind is generated when some data is protected > by two mutexes, and they were locked in different order on different > occasions. > I think, mutexes in question are nss_lock and conf_lock in > lib/libc/net/nsdispatch.c > > It seems like authors of helgrind took an approach that such situation > is error prone in general, thus they point it out. > > So what would be the prevalent judgement here, is this something worth > fixing in libc, or such errors should be ignored? Hmm, try locks don't block, so if the only use of the mutex is try locks and the caller unwinds and releases the rwlock if the mutex try lock fails, no deadlock is possible. The WITNESS checker in the kernel ignores try locks when checking for lock order reversals for this reason. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 19:02:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1ACB7EB8; Mon, 1 Apr 2013 19:02:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id ED6159CB; Mon, 1 Apr 2013 19:02:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 51D65B9B8; Mon, 1 Apr 2013 15:02:04 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: preemptive kernel Date: Mon, 1 Apr 2013 14:33:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011433.23781.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:02:04 -0400 (EDT) Cc: Adrian Chadd , vasanth rao naik sabavat X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:02:05 -0000 On Friday, March 22, 2013 4:10:16 pm vasanth rao naik sabavat wrote: > Hi Adrian, > > Just to clarify, is the kernel pre-emption involuntary? > > Let say I have a kernel thread processing a huge list of entries, would > this thread get involuntarily context switched out because of kernel > preemption? > > What is the time slice after which a kernel thread can involuntarily > context switched out? > > Could you please point to the file in the source code which handles the > kernel pre-emption. In-kernel preemption is driven by interrupts, not time slices. If an interrupt arrives that awakens a higher priority thread (e.g. an interrupt thread), or if your thread awakens a thread that has higher priority (e.g. due to wakeup() or cv_signal()), then your thread will be preempted. In general time-based preemptions are only done for user threads. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 19:12:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AE926C5 for ; Mon, 1 Apr 2013 19:12:24 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBECA86 for ; Mon, 1 Apr 2013 19:12:24 +0000 (UTC) Received: from [192.168.1.2] (pool-173-77-245-118.nycmny.fios.verizon.net [173.77.245.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id C943833DB8C for ; Mon, 1 Apr 2013 19:12:21 +0000 (UTC) Message-ID: <5159DBFC.4050106@gentoo.org> Date: Mon, 01 Apr 2013 15:11:56 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130324 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: considering i386 as a tier 1 architecture References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FGGUETWEMAPTDISHVSAX" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:12:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FGGUETWEMAPTDISHVSAX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/01/2013 12:48 AM, Eitan Adler wrote: > Hi, >=20 > I am writing this email to discuss the i386 architecture in FreeBSD. >=20 > Computers are getting faster, but also more memory intensive. I > can not find a laptop with less than 4 or 8 GB of RAM. Modern > browsers, such as Firefox, require a 64bit architecture and 8GB of > RAM. A 32 bit platform is not enough now a days on systems with > more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in > the 1990s. Even in the embedded world ARM is going 64 bit with > ARMv8. >=20 > Secondly, the i386 port is unmaintained. Very few developers run > it, so it doesn't get the testing it deserves. Almost every user > post or bug report I see from a x86 compatible processor is running > amd64. When was the last time you booted i386 outside a virtual > machine? Often times the build works for amd64 but fails for i386. >=20 > Finally, others are dropping support for i386. Windows Server 2008 > is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users > and downstream vendors no longer care about preserving ancient > hardware. >=20 > I hope this email is enough to convince you that on this date we > should drop support for the i386 architecture for 10.0 to tier 2 > and replace it with the ARM architecture as Tier 1. >=20 > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Eitan, Your arguments against 32-bit are undermined by your statement that FreeBSD should replace i386 with ARM. ARM is a 32-bit architecture While there is a 64-bit version of ARM in development, there are a few issues to consider. First, none of the compilers in base support it. Second, every market that uses ARM is fine with 32-bit hardware. Many intentionally use older versions of ARM (such as ARMv5) specifically because such chips are cheaper, more power efficient and get the job done. ARMv8, the 64-bit version of ARM, is only necessary in Intel's territory, which is an area where ARM is attempting to expand. There is no reason to think that 32-bit ARM will be phased out in existing applications. In addition, the idea that others are dropping support for 32-bit hardware is somewhat exaggerated. Wikipedia states that Microsoft Windows Server 2008 runs on IA-32, which is a synonym for 32-bit x86. In addition, Apple hardware is traditionally 64-bit. They only had 32-bit support because of a brief stint with Intel's 32-bit only Yonah chip during the Intel transition. I see no problem with demoting i386 to Tier 2 status. The committers' guide specifically states: > Architectures reaching end of life may also be moved from Tier 1 > status to Tier 2 status as the availability of resources to continue > to maintain the system in a Production Quality state diminishes. Additionally, while it is true that ARM's important is increasing, you do not make a cohesive argument for ARM's promotion to Tier 1 status. The committers' guide does suggests that there must be at least 2 Tier 1 architectures, but it is not clear to me that architecture should be ARM:= > Tier 1 embedded architectures must be able to cross-build packages on > at least one other Tier 1 architecture. On that note, I imagine that this would be a decision for the FreeBSD core team to make. I am not a FreeBSD committer, so what I think probably does not carry much weight with them. ------enig2FGGUETWEMAPTDISHVSAX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRWdv+AAoJECDuEZm+6Exkeh0QAKK8zd5rBj+gET3aEnCvMoVJ 1rI0Gd+Enf2Ejmbl5cBvTLxQp7M443xxF2GmcllAs9j8g5702mL5yefxgektn0sE cJ0PNgIZ264Xqaq1y65u/+67+inCKHe9BBcub25VZ3niBdvV6sHlWBqy0qYPQudG iDPRUWV0+48fWabOXNr9eAxMDTUuRnUWO91/z13u1pwGA3lKX4KNpQLEV/Bn0BGB sev/Mwf4kyICv03z1GmhFYi1and9X9zIgDbLuIve6Hp+MDkSOtvPlP+k71HEdyWi 46BPHsvbEQaq6t01eQkG5zBl15abaKY5qKdmzNnU3C+GQGyi3+lgxiZk5K3VyZR8 CeOpaRiapcFV1HM3EpEgXEek7R0fopyjeOgAeGuieiujCZ3Ek7C9ok8THRXC5MXU WKDqADUBCDHYcbfjCA4qWrl68FFT890+gwjd5g+hhmRGsaFCPULNmSzMx5fBevoY GsaZdx2Tr9y9fosQH1Gw8nXoRkPwWB183VlCPFAn6lz5V/j66JegyDaOQgkME8Rv cv0pVDxKTXMjERJH3LpGulReINvuMff1muOHap2QOzYFWz0CoLyciIZ5sd6OecUp q8eC1DZoYEBqiuSrf0ScrxlKNqwGMziECllwlDnwkQLlIJyW+0TclHnrtTPWFxaq 5HvdjH2Iv4So5YnQsNTu =nskH -----END PGP SIGNATURE----- ------enig2FGGUETWEMAPTDISHVSAX-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 19:51:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B20166F9; Mon, 1 Apr 2013 19:51:47 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx1.freebsd.org (Postfix) with ESMTP id 66B80D1F; Mon, 1 Apr 2013 19:51:47 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id bv4so1062596qab.9 for ; Mon, 01 Apr 2013 12:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aTNy66S5LyCtx+/VIp+pze2r1lt8v0P7gM0PSsdRABY=; b=Jzs3w+CWRINnFw/DGAgzXmf1WAm5CKzGajbxs3ZCya+629ZVHplKCxpo4/vdyOGCUL faWzj2rup0Fv/BgPezkJ7CVnkXo10n9P5KRSizhuA+Bsm+SraB4q5+GigtiXagDwxKkt xbToitvl9fWx7EIjCNbXFLh3ktWABkLgaaM4lSxjjATGNmt7nwCRfk550p/eRWhXA92Y W6hBrEGdh9861iO2A0y9J+9K0h9FfWNa8plcaES/gjIARdPUiIrVUtxEUitP1rCUawgX 9zS1vx2peHUsgdjjgAwqA7C/wGgnW9pV1xovhTboKuqu63EPz/XFAo1oxXQL6LqixgVi xB8A== MIME-Version: 1.0 X-Received: by 10.224.33.14 with SMTP id f14mr13672757qad.69.1364845906591; Mon, 01 Apr 2013 12:51:46 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.253.201 with HTTP; Mon, 1 Apr 2013 12:51:46 -0700 (PDT) In-Reply-To: <201304011424.19784.jhb@freebsd.org> References: <201304011424.19784.jhb@freebsd.org> Date: Mon, 1 Apr 2013 12:51:46 -0700 X-Google-Sender-Auth: 8oGjy_nQDnvOWik8_MNXBM7BG2Y Message-ID: Subject: Re: extattr_set_* return type From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:51:47 -0000 On Mon, Apr 1, 2013 at 11:24 AM, John Baldwin wrote: > On Saturday, March 30, 2013 5:30:21 pm mdf@freebsd.org wrote: > > Despite the man page correctly describing the return value for > > extattr_set_*, I thought recently that they returned 0/-1 for > > success/failure, not the number of bytes written, like write(2). This is > > because extattr_set_* is declared as returning an int, not an ssize_t. > > Both extattr_get and extattr_list return ssize_t, so this is > inconsistent. > > > > The patch at > > > http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix- > rmextattr-8-.patchfixes > > this. It compiles but it's untested. > > > > I don't think any compat shims are needed, since an old application will > > still sign extend and this will work (it's very unlikely anyone does > > extattr_set for 2GB or more). > > > > If anyone actually uses extattr on 64-bit, please test a new kernel but > old > > userspace to be sure nothing is broken. I plan to commit this next week > if > > I don't hear otherwise. > > Hmm, the patch URL doesn't work, but please fix this. There is an old > thread > we are both on from Dec 2011 where I ran into the same thing. I also > think we > don't need compat shims. > The version in my outbox looked right; I don't know how it got mangled. http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix- rmextattr-8-.patch Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 20:04:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B824A86; Mon, 1 Apr 2013 20:04:23 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by mx1.freebsd.org (Postfix) with ESMTP id D401ADAA; Mon, 1 Apr 2013 20:04:22 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id jy17so1441891qeb.11 for ; Mon, 01 Apr 2013 13:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bfESOvNo2QgWF66FxEJQCxxbe7vhvgChN5hpEavAMME=; b=wu9sNQR0i3dGxXNTrqeoZZFbbUYaoSRglbmq1CkrMQRiwnYaq2ZBM2MEcw+56HMHDu hLJ/LqrDQQGl1maFz4uD4i6KLcYWdEXHlduJGyvDCQVRESWNQmJ4sNHhTTYGxy1/8zAt swA/P9Fksk5vhNtMaODGJpsgBOuPzqbOE6cIdqn5O/W4NBHukZrhhzg0IggAMI5kDfWv n5BsmduF2AcRjWZAvFwAj0inMGM+Deg7VQ+3cLBzeg4SdOuh9jYrJPM6EGUM7OzbcPsz b7yziimWVc5juNyrAzmCyGkWmFKdzKM0KeXVucWUSnUB/Ps360o8l/dn5xx1WFsFIozo kpZg== MIME-Version: 1.0 X-Received: by 10.229.62.200 with SMTP id y8mr2412309qch.128.1364846206610; Mon, 01 Apr 2013 12:56:46 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.253.201 with HTTP; Mon, 1 Apr 2013 12:56:46 -0700 (PDT) In-Reply-To: References: <201304011424.19784.jhb@freebsd.org> Date: Mon, 1 Apr 2013 12:56:46 -0700 X-Google-Sender-Auth: gnR38LmtGfxcR4O_6PL_Ey-M8DU Message-ID: Subject: Re: extattr_set_* return type From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:04:23 -0000 On Mon, Apr 1, 2013 at 12:51 PM, wrote: > On Mon, Apr 1, 2013 at 11:24 AM, John Baldwin wrote: > >> On Saturday, March 30, 2013 5:30:21 pm mdf@freebsd.org wrote: >> > Despite the man page correctly describing the return value for >> > extattr_set_*, I thought recently that they returned 0/-1 for >> > success/failure, not the number of bytes written, like write(2). This >> is >> > because extattr_set_* is declared as returning an int, not an ssize_t. >> > Both extattr_get and extattr_list return ssize_t, so this is >> inconsistent. >> > >> > The patch at >> > >> http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix- >> rmextattr-8-.patchfixes >> > this. It compiles but it's untested. >> > >> > I don't think any compat shims are needed, since an old application will >> > still sign extend and this will work (it's very unlikely anyone does >> > extattr_set for 2GB or more). >> > >> > If anyone actually uses extattr on 64-bit, please test a new kernel but >> old >> > userspace to be sure nothing is broken. I plan to commit this next >> week if >> > I don't hear otherwise. >> >> Hmm, the patch URL doesn't work, but please fix this. There is an old >> thread >> we are both on from Dec 2011 where I ran into the same thing. I also >> think we >> don't need compat shims. >> > > The version in my outbox looked right; I don't know how it got mangled. > > > http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix- > > rmextattr-8-.patch > And I found the old thread: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030567.html I guess my memory really does just suck. I now remember what I posted, but only after reading it again. :-) Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 20:17:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18F1C1F5; Mon, 1 Apr 2013 20:17:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id E9FB9E33; Mon, 1 Apr 2013 20:17:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DD632B91C; Mon, 1 Apr 2013 16:17:01 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Subject: Re: extattr_set_* return type Date: Mon, 1 Apr 2013 16:14:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304011614.33363.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 16:17:02 -0400 (EDT) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:17:03 -0000 On Monday, April 01, 2013 3:56:46 pm mdf@freebsd.org wrote: > On Mon, Apr 1, 2013 at 12:51 PM, wrote: > > > On Mon, Apr 1, 2013 at 11:24 AM, John Baldwin wrote: > > > >> On Saturday, March 30, 2013 5:30:21 pm mdf@freebsd.org wrote: > >> > Despite the man page correctly describing the return value for > >> > extattr_set_*, I thought recently that they returned 0/-1 for > >> > success/failure, not the number of bytes written, like write(2). This > >> is > >> > because extattr_set_* is declared as returning an int, not an ssize_t. > >> > Both extattr_get and extattr_list return ssize_t, so this is > >> inconsistent. > >> > > >> > The patch at > >> > > >> http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and- fix- > >> rmextattr-8-.patchfixes > >> > this. It compiles but it's untested. > >> > > >> > I don't think any compat shims are needed, since an old application will > >> > still sign extend and this will work (it's very unlikely anyone does > >> > extattr_set for 2GB or more). > >> > > >> > If anyone actually uses extattr on 64-bit, please test a new kernel but > >> old > >> > userspace to be sure nothing is broken. I plan to commit this next > >> week if > >> > I don't hear otherwise. > >> > >> Hmm, the patch URL doesn't work, but please fix this. There is an old > >> thread > >> we are both on from Dec 2011 where I ran into the same thing. I also > >> think we > >> don't need compat shims. > >> > > > > The version in my outbox looked right; I don't know how it got mangled. > > > > > > http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and- fix- > > > > rmextattr-8-.patch > > Somehow the space between 'patch' at the end of the URL and 'fixes' kept getting eaten. I worked it out though and your patch looks fine to me. I think we can just punt on doing symver and commit it as is. Thanks for fixing this! -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 20:21:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 356D0431; Mon, 1 Apr 2013 20:21:41 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id E5E55E68; Mon, 1 Apr 2013 20:21:40 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 4F3574AC57; Tue, 2 Apr 2013 00:21:38 +0400 (MSK) Date: Tue, 2 Apr 2013 00:21:30 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1437965352.20130402002130@serebryakov.spb.ru> To: Wojciech Puchar Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: References: <944760435.20130401210118@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:21:41 -0000 Hello, Wojciech. You wrote 1 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 22:31:51: >> It is not exact so. Some Atoms on some motherboards with some >> firmwares are 64-bit CPU. WP> don't know of any now in shops that are not Are you sure about Chinese-made MoBos with 6x1G on-board NICs and soldered memory and other such "embedded" devices? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 20:42:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0CDA9EE5 for ; Mon, 1 Apr 2013 20:42:49 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 9B42BFA5 for ; Mon, 1 Apr 2013 20:42:48 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id c10so1909092wiw.14 for ; Mon, 01 Apr 2013 13:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MRxoj7mRSyQFMNcUIyx+m8Pe5R6qeJKYVAbbr8o66iQ=; b=D5VVMjDyH7YkpRRCrf1YxQUngar0eZOiz4Fi/2rrBAYKqu2u+sJLYWRGCyqRe2pjRJ 35ugDAFHeeshLEeCQd09A5fSur4LDJsj5YeMsa5zR7KrkmA2zbZcNplGuj/R+BGH3uqH uWYuE6XSQkmwfR08Apbx+86p48kNI+yMXxmouSbBwMADuvZwV5pg3ECvVa4Hkl6AneB1 jK6M0Sc5Ix2EQS7wsDrEXeony8FSpHJ3UeMdxobzXg5/zn4ad/cYSL8zOOEY06HHhFbA j3ji7AJc1AwrbDm6QFsUdE9eGp7HFxyIN9yN9M1THU/YBU3jo7kwFq8rsbi1bn5Nzvjk +7dA== MIME-Version: 1.0 X-Received: by 10.180.108.106 with SMTP id hj10mr11941453wib.0.1364848967788; Mon, 01 Apr 2013 13:42:47 -0700 (PDT) Received: by 10.194.140.20 with HTTP; Mon, 1 Apr 2013 13:42:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 15:42:47 -0500 Message-ID: Subject: Re: the Newcons Project From: Adam Vande More To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:42:49 -0000 http://www.freebsd.org/cgi/man.cgi?query=vidcontrol&sektion=1 On Sat, Mar 30, 2013 at 2:13 AM, Sam Fourman Jr. wrote: > My understanding of this whole subject is limited, but bear with me... in > my quest to get a "cool looking console for my desktop... I found this > https://wiki.freebsd.org/Newcons > > does anyone know if someone is still actively working on the NewCons > project? or is it already committed to HEAD and i just don't realize? the > wiki is a bit confusing... > > I would VERY much be able to have a console that looked like this in > FreeBSD > > http://wiki.gentoo.org/images/7/7c/Bootsplash.png > > but if my understanding is correct, we are not at this point (yet)... even > if you pull the development source from here > > svn co svn://svn.freebsd.org/base/user/ed/newcons > > and change the kernel config like this: > > #device vga # VGA video card driver > #device sc > device vt > device vt_vga > > > could someone with more understanding of this, be able to tell me if the > Newcons project (when completed) is even going to do what i'm looking for? > > if so, exactly what things have to be done yet, in order for FreeBSD to > have a console like Gentoo? > > > -- > > Sam Fourman Jr. > _______________________________________________ > 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" > -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 1 21:14:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 323CEE9A for ; Mon, 1 Apr 2013 21:14:34 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id F2D2C1A1 for ; Mon, 1 Apr 2013 21:14:33 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wo10so2276461obc.11 for ; Mon, 01 Apr 2013 14:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LuJtrvGspIiQ8KWCx34s8cv3Vdl7M1r9sQ/cJgdSSGs=; b=k62kGGTlTqXEzL8+ZZj2KfdzAFnHlJj6aLFjSiwF6GXFClMB1TyS3beI735ToDg0iq G3lGACMhjd59Q5NX9fYH6xPtNJjf4msH8EGPHDed4XRZ07+eOsa+cdqbTluUMN+yRuje EScAfojwbOof9LxzLyRLlKEzzdMQnuFAW2V4WYKfcKyVJBZlUwE+bgkL/Efk/MjFB+OU PjOHSfb9dZHZFPuUsey6zCtp/6NKH2sKTijbYqHHDk/QzdR3BlPxXIqk+bSCDz9LgrST tXsMjht3cHMaK632iMQ6lXBtgZdr/ETMKHeb0FzzxDE5qcqNeptZejeQjRk3uVoJGq2A KIZg== X-Received: by 10.60.37.68 with SMTP id w4mr3808698oej.62.1364850873032; Mon, 01 Apr 2013 14:14:33 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id n1sm2751547obc.10.2013.04.01.14.14.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 14:14:32 -0700 (PDT) Message-ID: <5159F8B1.9010405@gmail.com> Date: Mon, 01 Apr 2013 16:14:25 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Ports: make fails, if DESTDIR path has spaces References: <20130331.133829.093.1@DOMY-PC> <20130401.161353.972.1@DOMY-PC> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:14:34 -0000 On 4/1/2013 11:45 AM, Kimmo Paasiala wrote: > On Mon, Apr 1, 2013 at 7:30 PM, Chris Rees wrote: >> On 1 April 2013 17:13, wrote: >>>> Try "DESTDIR='/usr/TZ\ ONE'; export DESTDIR". >>>> >>>> You need to escape the space. >>> >>> This is '#!/bin/sh' scripting. >>> Doing so "fixes" *.mk, but breaks sh => dir simply doesn't exist anymore. >>> >>> Matthias && Chris => *.mk is at fault here, for not supporting FreeBSD's >>> full range of chars for dir paths >> >> As I explained before, Makefiles and sh have a strange relationship, >> where escaping is similar but different in weird places. >> >> Unless you are an expert, you should not use spaces in pathnames. >> Stop doing it; the ports system is not designed around them. >> > > You could work around the problem by using an external program to do > all the expanding and globbing, it would guarantee that the expansions > are done the same way always and special characters treated in uniform > way. > > -Kimmo Or use a symbolic link to point to the named directory, probably. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 02:12:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 706C3472; Tue, 2 Apr 2013 02:12:12 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 3B790DAD; Tue, 2 Apr 2013 02:12:11 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3Zfv7R4PGLzss; Tue, 2 Apr 2013 03:12:03 +0100 (BST) Message-ID: <515A3E6C.7030404@rewt.org.uk> Date: Tue, 02 Apr 2013 03:11:56 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adrian Chadd Subject: Re: considering i386 as a tier 1 architecture References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Apr 2013 02:58:18 +0000 Cc: Eitan Adler , freebsd-arch@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 02:12:12 -0000 Adrian Chadd wrote: > Why stop there? > > Noone runs FreeBSD on real hardware anymore. Except, say netflix. > > Let's just drop actual native hardware support and instead support > only the bare minimum needed to boot inside vmware, virtualbox and > xen. > > Anyone needing real hardware support can install NetBSD and xen. > The irony being that NetBSD runs on really obscure hardware but nothing that anybody anywhere uses? ;) > > Adrian > > On 31 March 2013 21:48, Eitan Adler wrote: >> Hi, >> >> I am writing this email to discuss the i386 architecture in FreeBSD. >> >> Computers are getting faster, but also more memory intensive. I >> can not find a laptop with less than 4 or 8 GB of RAM. Modern >> browsers, such as Firefox, require a 64bit architecture and 8GB of >> RAM. A 32 bit platform is not enough now a days on systems with >> more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in >> the 1990s. Even in the embedded world ARM is going 64 bit with >> ARMv8. >> >> Secondly, the i386 port is unmaintained. Very few developers run >> it, so it doesn't get the testing it deserves. Almost every user >> post or bug report I see from a x86 compatible processor is running >> amd64. When was the last time you booted i386 outside a virtual >> machine? Often times the build works for amd64 but fails for i386. >> >> Finally, others are dropping support for i386. Windows Server 2008 >> is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users >> and downstream vendors no longer care about preserving ancient >> hardware. >> >> I hope this email is enough to convince you that on this date we >> should drop support for the i386 architecture for 10.0 to tier 2 >> and replace it with the ARM architecture as Tier 1. >> >> -- >> Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 03:39:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AC0942F for ; Tue, 2 Apr 2013 03:39:29 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id C114928F for ; Tue, 2 Apr 2013 03:39:28 +0000 (UTC) Received: by mail-yh0-f47.google.com with SMTP id z12so499336yhz.20 for ; Mon, 01 Apr 2013 20:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=BvPvchd8cNxOdSPvdAQkiZQdFmJGuIwSVOlqmLhr4fg=; b=DQ0JYhhiuIHiyHjzQ5QI2N8/6RlIiHBOEAgukX0xH1lQjYj/UnyFJ2TTQUgNAihNuU /cjO5owYVua6Gk6RlW1KAOiHPMpELnGK7jXCOw4cL2tQMfjCj7G+86ZJB2qi4DpdU2+l A83fleqATpZgAUUOCyocLrBco9zW87wAJ5Q88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=BvPvchd8cNxOdSPvdAQkiZQdFmJGuIwSVOlqmLhr4fg=; b=UiCmyKEJDV9RsEc/lcxeXa0Ra+aIM38AvIe6v6kl/mPxQNE0TmtQ/Ras7NBpwvVfjM lpShUJx9CRu3afkcIgnZkrrD8zM8SuYHJ/yZHh7gsCeXg70DoOD4lE/uR0Vffdo7NPB4 FCyLeFHg0TywxISW4bd36DYD2XtuvtFiAhVMucIscrov1Du/3Vce8kLTq3s6Q0BOmwIO Hsbxy28boo3qI5xGAnqTCUmRjzQKyYLVV5ABJUwSfhzAwFHX5WtXGuAZp1L4dPZjGoW5 VGDV7NTahQhevogfAYLiRbzaMlFWUTjBiU+ftYbiRX1Yh6m8pL8v2krHMgt1SCWyGfQa JmGg== X-Received: by 10.236.120.71 with SMTP id o47mr12937810yhh.161.1364873967721; Mon, 01 Apr 2013 20:39:27 -0700 (PDT) Received: from [192.168.2.105] (177.207.86.141.dynamic.adsl.gvt.net.br. [177.207.86.141]) by mx.google.com with ESMTPS id u33sm32133976yhn.7.2013.04.01.20.39.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 20:39:26 -0700 (PDT) Message-ID: <515A52EB.2040502@bsd.com.br> Date: Tue, 02 Apr 2013 00:39:23 -0300 From: =?ISO-8859-1?Q?Otac=EDlio?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130328 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: considering i386 as a tier 1 architecture References: <515A3E6C.7030404@rewt.org.uk> In-Reply-To: <515A3E6C.7030404@rewt.org.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkn+0/sDXarNw4+NqO5IQTjx15QMRdqrHfuwzIx+xZWnPyjdY4el+m5NvVthnMpDTl4Y70+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 03:39:29 -0000 On 01/04/2013 23:11, Joe Holden wrote: > Adrian Chadd wrote: >> Why stop there? >> >> Noone runs FreeBSD on real hardware anymore. Except, say netflix. >> I run on my personal notebook. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 08:29:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8CD6B98; Tue, 2 Apr 2013 08:29:21 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id 05DA5F27; Tue, 2 Apr 2013 08:29:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,392,1363132800"; d="scan'208";a="3106983" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Apr 2013 08:29:19 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 2 Apr 2013 09:29:18 +0100 Message-ID: <515A96DD.5030606@citrix.com> Date: Tue, 2 Apr 2013 10:29:17 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: considering i386 as a tier 1 architecture References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Eitan Adler , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:29:21 -0000 On 01/04/13 20:31, Adrian Chadd wrote: > Why stop there? > > Noone runs FreeBSD on real hardware anymore. Except, say netflix. > > Let's just drop actual native hardware support and instead support > only the bare minimum needed to boot inside vmware, virtualbox and > xen. > > Anyone needing real hardware support can install NetBSD and xen. No need for NetBSD anymore, Xen is going to integrate the Linux tree and glibc, so you can build a full distro form the Xen tree: http://blog.xen.org/index.php/2013/04/01/bringing-open-source-communities-closer-together/ From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 08:57:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8426A6CC for ; Tue, 2 Apr 2013 08:57:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 138B4F4 for ; Tue, 2 Apr 2013 08:57:09 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r328v8PO080397; Tue, 2 Apr 2013 12:57:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r328v816080396; Tue, 2 Apr 2013 12:57:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 2 Apr 2013 12:57:08 +0400 From: Gleb Smirnoff To: Chris Torek Subject: Re: boot time crash in if_detach_internal() Message-ID: <20130402085708.GI76816@FreeBSD.org> References: <201304010945.r319jJw7027369@elf.torek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201304010945.r319jJw7027369@elf.torek.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:57:10 -0000 On Mon, Apr 01, 2013 at 03:45:19AM -0600, Chris Torek wrote: C> I have been poking about with the bhyve virtualization code in C> FreeBSD 10-current, and managed to crash FreeBSD during its C> bootstrap process due to the fact that if_detach is called C> from boot time configuration code, before the internal domain C> system initialization has happened. C> C> I added the following patch to work around the problem. As C> the large comment notes, it might not be quite correct but it C> does allow the boot to proceed (of course the "dead" network C> device is soon a problem anyway...). C> C> The fix mirrors (more or less) the code in if_attach_internal(). C> Feel free to accept, ignore, or modify the patch. :-) C> C> Chris C> C> diff --git a/sys/net/if.c b/sys/net/if.c C> --- a/sys/net/if.c C> +++ b/sys/net/if.c C> @@ -845,6 +845,15 @@ C> C> if_purgeaddrs(ifp); C> C> + /* C> + * torek: it's not entirely clear to me where and how this C> + * should go, but if domain_init_status < 2 then there should C> + * be no inet, inet6, etc items, and this is where the crash C> + * happens during boot, so let's try this: C> + */ C> + if (domain_init_status < 2) C> + return; C> + C> #ifdef INET C> in_ifdetach(ifp); C> #endif Can you provide a backtrace that leads to this? -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 09:04:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E5E4ACB; Tue, 2 Apr 2013 09:04:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC8E14E; Tue, 2 Apr 2013 09:04:12 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id AEC44C441; Tue, 2 Apr 2013 09:04:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 714EB954E; Tue, 2 Apr 2013 11:04:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Wojciech Puchar Subject: Re: considering i386 as a tier 1 architecture References: <944760435.20130401210118@serebryakov.spb.ru> Date: Tue, 02 Apr 2013 11:04:04 +0200 In-Reply-To: (Wojciech Puchar's message of "Mon, 1 Apr 2013 20:31:51 +0200 (CEST)") Message-ID: <8638v9e22j.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , Lev Serebryakov , FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:04:12 -0000 Wojciech Puchar writes: > Lev Serebryakov writes: > > It is not exact so. Some Atoms on some motherboards with some > > firmwares are 64-bit CPU. > don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 09:26:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D43AC2E6; Tue, 2 Apr 2013 09:26:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 96956329; Tue, 2 Apr 2013 09:26:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 28EEA4AC57; Tue, 2 Apr 2013 13:26:04 +0400 (MSK) Date: Tue, 2 Apr 2013 13:26:03 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1241302374.20130402132603@serebryakov.spb.ru> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Subject: Re: considering i386 as a tier 1 architecture In-Reply-To: <8638v9e22j.fsf@ds4.des.no> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Wojciech Puchar , freebsd-arch@freebsd.org, FreeBSD Hackers , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:26:13 -0000 Hello, Dag-Erling. You wrote 2 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 13:04:04: DES> http://soekris.com/products/net6501.html This one is 64-bit capable according to their mailing list --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 10:11:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4C11B67; Tue, 2 Apr 2013 10:11:02 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id 71BA6781; Tue, 2 Apr 2013 10:11:02 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id kw10so228196vcb.28 for ; Tue, 02 Apr 2013 03:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=46V4rXKKd+rp6JEB5kpy7Bnz7V2QkXVxJAym3aWypu8=; b=naAARCTQ4pewK1YES+1ocxbqDYzvnDkrVe4yVWwmKIMo1zIQsDly5OAwToZJMsd78V mo0BUZ+ktul7MOJl0RuwEJS25yATdA5dnqDq2giXHAO72KELyy3d9w+yDnsQHZg9kaJi Mo3D+p4K10iczZNTEpG5CsBBpuekI3qyOw0KM5wr71lFCpi6An52QBuck0qdQ9mFhO5S 02GZL7kEpbsxX/UH3bQKf0IvkSTdNNrbpoipwRKFhBC8/hItRSl2eSf7/1uU0XI+pfSG RD9v/+jMb020iQgiDGjeV5YqHIBsJ0grGBWiU6oGv/698SFN8G8z4G3MY4Gb5SQzBb1N TvWA== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr9967475vdt.126.1364897456694; Tue, 02 Apr 2013 03:10:56 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Tue, 2 Apr 2013 03:10:56 -0700 (PDT) In-Reply-To: <8638v9e22j.fsf@ds4.des.no> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> Date: Tue, 2 Apr 2013 03:10:56 -0700 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Wojciech Puchar , freebsd-arch@freebsd.org, Lev Serebryakov , FreeBSD Hackers , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:11:03 -0000 On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm=C3=B8rgrav wrote= : > Wojciech Puchar writes: > > Lev Serebryakov writes: > > > It is not exact so. Some Atoms on some motherboards with some > > > firmwares are 64-bit CPU. > > don't know of any now in shops that are not > > http://soekris.com/products/net5501.html > http://soekris.com/products/net6501.html > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 10:13:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF46DD31; Tue, 2 Apr 2013 10:13:45 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 384A47B1; Tue, 2 Apr 2013 10:13:45 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so2944527wgg.0 for ; Tue, 02 Apr 2013 03:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PuK42h39W2ZoDLGvlDN5G5Nx6mwRhBVughQxtzvF0V8=; b=c2ebSkVmeSVr2X5T5PaXvPoV5ZtYUQ5xwK/gcg7lFFVZ8Lu3YQVxd+496xbnbruicz Te9niw+q42UjSMslzTKQrRidj1iEDAiPfj7tCBW1gAhtvEjIRIrr73tzAIdNORTXbhqF C0oyiwusvKcBBkZeQszR4kJt1udBlEM8EqywB6ADa4WmMp1NXS/6q1pFOt/u0/wLpBB8 ZVQaH/MrAb5NLjDqUdKDNh561DOPpzOe+iC1bI6nGAjaFdkQatzDNib0Eh9cYe+XJytX CG74dLRhdEUrDuYgpHQZ+r1OAeRTjgeY6rKUOhHHAzomTNDHCirQpxk6jLMuM5xRXdsf 8ijQ== MIME-Version: 1.0 X-Received: by 10.180.90.116 with SMTP id bv20mr3381183wib.32.1364897624348; Tue, 02 Apr 2013 03:13:44 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 2 Apr 2013 03:13:44 -0700 (PDT) In-Reply-To: References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> Date: Tue, 2 Apr 2013 13:13:44 +0300 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Kimmo Paasiala To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Lev Serebryakov , FreeBSD Hackers , Eitan Adler , freebsd-arch@freebsd.org, =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:13:46 -0000 On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk wrote: > On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm=C3=B8rgrav wro= te: > >> Wojciech Puchar writes: >> > Lev Serebryakov writes: >> > > It is not exact so. Some Atoms on some motherboards with some >> > > firmwares are 64-bit CPU. >> > don't know of any now in shops that are not >> >> http://soekris.com/products/net5501.html >> http://soekris.com/products/net6501.html >> >> DES >> -- >> Dag-Erling Sm=C3=B8rgrav - des@des.no >> > > > I am NOT able to understand the merit of these products with respect to > their features and PRICES . > > It is possible to assemble much more cheaper full featured PC like system= s > ( DDR3 memory , 64-bit capable processors , with a disadvantage about pow= er > requirements ) . > > Power consumption. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 10:43:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 669965A4 for ; Tue, 2 Apr 2013 10:43:57 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 001D48F3 for ; Tue, 2 Apr 2013 10:43:56 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k13so272558wgh.17 for ; Tue, 02 Apr 2013 03:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=yWfYzCyqs+ApRXil2Us9A76grMtrnhoVEF4uhW3w134=; b=cdEeezelYXTnqWJUSc3A+LUTduhHF9bXvn8PkFi//FTTBIkzYWJxuOuYx4IDdzcdl1 9qWMT0Z45AwicMR8WFwvVtL7PJegwYTTNmPnVHBrpDTsD0giRCImQDahQy/Ae0Vqjot/ CenKaqNBd56r7apaeFyxXvupLt6ONJp4dtdUnYfFDDCYm8X3j+kHVM3UcxKK1pLDJ0z2 pRhiPtGjxhMM8w8B1aYOhwI5WtudoXGUgyUb+AY+BVhj1o59GWb343HfRQuJzEtM5WMs ip+w7zUBGbm9BNLsdNhFTS2dRYzEECLObkP1eN0Q9uIzrStOYm6gpZ+hkTuiJvNbREnS NTRg== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr20667531wjr.33.1364899435849; Tue, 02 Apr 2013 03:43:55 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 2 Apr 2013 03:43:55 -0700 (PDT) In-Reply-To: <515AB309.30006@achimhut.de> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <515AB309.30006@achimhut.de> Date: Tue, 2 Apr 2013 13:43:55 +0300 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Kimmo Paasiala To: Achim Hut Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:43:57 -0000 On Tue, Apr 2, 2013 at 1:29 PM, Achim Hut wrote: > Am 02.04.2013 12:13, schrieb Kimmo Paasiala: > >> On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk >> wrote: >>> >>> On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm=C3=B8rgrav w= rote: >>> >>>> Wojciech Puchar writes: >>>>> >>>>> Lev Serebryakov writes: >>>>>> >>>>>> It is not exact so. Some Atoms on some motherboards with some >>>>>> firmwares are 64-bit CPU. >>>>> >>>>> don't know of any now in shops that are not >>>> >>>> >>>> http://soekris.com/products/net5501.html >>>> http://soekris.com/products/net6501.html >>>> >>>> DES >>>> -- >>>> Dag-Erling Sm=C3=B8rgrav - des@des.no >>>> >>> >>> >>> I am NOT able to understand the merit of these products with respect to >>> their features and PRICES . >>> >>> It is possible to assemble much more cheaper full featured PC like >>> systems >>> ( DDR3 memory , 64-bit capable processors , with a disadvantage about >>> power >>> requirements ) . >>> >>> >> >> >> Power consumption. > > > > > ...Space - Price - temperature, easy to use, no Fans, no Noise... > > I was surprised about this discussion and first thought, its some kind of > april joke. > > Everybody talks about cheap new 64 bit hardware > > But how about the hardware people are actualy using? In our datacenter we > are running (beside 64bit machines) a large amount of 32bit servers. We h= ave > a room full of spare parts, spare servers... > > And we have no reason to change them to 64bit hardware. HP, IBM, they all > run since years and i am shure, they make 5-10 more years :-) > > And we dont want to stop using FreeBSD after V9.x or so. > > Dont forget there are a lot of different people with different needs out > there. Not everybody puts his focus on a cheap desktop PC thats thrown aw= ay > after 3 years > > Achim It is in fact an April Fools Joke :D However, it does not invalidate some of the points made. ARM is going to dominate the desktop/laptop/tablet/smartphone market very soon and it would be very wise for FreeBSD to shift the focus to it as soon as possible. -Kimmo From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 10:22:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F42ECE for ; Tue, 2 Apr 2013 10:22:33 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from eris.bzerk.org (unknown [IPv6:2001:980:18dd:1:192:168:179:45]) by mx1.freebsd.org (Postfix) with ESMTP id D913A801 for ; Tue, 2 Apr 2013 10:22:32 +0000 (UTC) Received: from eris.bzerk.org (BOFH@localhost [127.0.0.1]) by eris.bzerk.org (8.14.6/8.14.5) with ESMTP id r32AMKOj029581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Apr 2013 10:22:21 GMT (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by eris.bzerk.org (8.14.6/8.14.6/Submit) id r32AMKIe029580; Tue, 2 Apr 2013 10:22:20 GMT (envelope-from mail25@bzerk.org) X-Authentication-Warning: eris.bzerk.org: bulk set sender to mail25@bzerk.org using -f Date: Tue, 2 Apr 2013 10:22:20 +0000 From: Ruben de Groot To: Mehmet Erol Sanliturk Subject: Re: considering i386 as a tier 1 architecture Message-ID: <20130402102220.GA28545@eris.bzerk.org> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-11.0 required=5.0 tests=ALL_TRUSTED,AUTHD_RELAY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eris.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (eris.bzerk.org [127.0.0.1]); Tue, 02 Apr 2013 10:22:26 +0000 (UTC) X-Mailman-Approved-At: Tue, 02 Apr 2013 10:49:50 +0000 Cc: Lev Serebryakov , FreeBSD Hackers , Eitan Adler , freebsd-arch@freebsd.org, Dag-Erling Sm??rgrav , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:22:33 -0000 On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: > On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav wrote: > > > Wojciech Puchar writes: > > > Lev Serebryakov writes: > > > > It is not exact so. Some Atoms on some motherboards with some > > > > firmwares are 64-bit CPU. > > > don't know of any now in shops that are not > > > > http://soekris.com/products/net5501.html > > http://soekris.com/products/net6501.html > > > > DES > > -- > > Dag-Erling Sm??rgrav - des@des.no > > > > > I am NOT able to understand the merit of these products with respect to > their features and PRICES . They are extremely stable and robust. > It is possible to assemble much more cheaper full featured PC like systems > ( DDR3 memory , 64-bit capable processors , with a disadvantage about power > requirements ) . You can also get much bigger portions at MacDonald than what you get in a five star restaurant. Ruben From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 10:37:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E59B365 for ; Tue, 2 Apr 2013 10:37:16 +0000 (UTC) (envelope-from achimhut@achimhut.de) Received: from mailgw.digital-impact.de (mailgw.digital-impact.de [212.48.96.8]) by mx1.freebsd.org (Postfix) with ESMTP id 558FD8A6 for ; Tue, 2 Apr 2013 10:37:15 +0000 (UTC) Received: by mailgw.digital-impact.de (Postfix, from userid 58) id A352A1E322F; Tue, 2 Apr 2013 12:29:34 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mailgw.digital-impact.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.2.5 Received: from mail.digitalimpact.org (unknown [192.168.10.2]) by mailgw.digital-impact.de (Postfix) with ESMTP id 80E571E322C; Tue, 2 Apr 2013 12:29:30 +0200 (CEST) Received: from [192.168.1.34] (hnvr-4dbd536c.pool.mediaWays.net [77.189.83.108]) by mail.digitalimpact.org (Postfix) with ESMTP id 3CC9E13A6; Tue, 2 Apr 2013 12:29:30 +0200 (CEST) Message-ID: <515AB309.30006@achimhut.de> Date: Tue, 02 Apr 2013 12:29:29 +0200 From: Achim Hut User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: considering i386 as a tier 1 architecture References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 02 Apr 2013 10:50:10 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:37:16 -0000 Am 02.04.2013 12:13, schrieb Kimmo Paasiala: > On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk > wrote: >> On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav wrote: >> >>> Wojciech Puchar writes: >>>> Lev Serebryakov writes: >>>>> It is not exact so. Some Atoms on some motherboards with some >>>>> firmwares are 64-bit CPU. >>>> don't know of any now in shops that are not >>> >>> http://soekris.com/products/net5501.html >>> http://soekris.com/products/net6501.html >>> >>> DES >>> -- >>> Dag-Erling Smørgrav - des@des.no >>> >> >> >> I am NOT able to understand the merit of these products with respect to >> their features and PRICES . >> >> It is possible to assemble much more cheaper full featured PC like systems >> ( DDR3 memory , 64-bit capable processors , with a disadvantage about power >> requirements ) . >> >> > > > Power consumption. ...Space - Price - temperature, easy to use, no Fans, no Noise... I was surprised about this discussion and first thought, its some kind of april joke. Everybody talks about cheap new 64 bit hardware But how about the hardware people are actualy using? In our datacenter we are running (beside 64bit machines) a large amount of 32bit servers. We have a room full of spare parts, spare servers... And we have no reason to change them to 64bit hardware. HP, IBM, they all run since years and i am shure, they make 5-10 more years :-) And we dont want to stop using FreeBSD after V9.x or so. Dont forget there are a lot of different people with different needs out there. Not everybody puts his focus on a cheap desktop PC thats thrown away after 3 years Achim From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 11:17:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F221B13B for ; Tue, 2 Apr 2013 11:17:22 +0000 (UTC) (envelope-from isabell@issyl0.co.uk) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id B8E1DA8E for ; Tue, 2 Apr 2013 11:17:21 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id hx10so275990vcb.33 for ; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=j4q6f/hzzi8RjgPo3d1NXqs3Jf8mhk/26YGiWcXjcOQ=; b=IKHvDrLKKhLaslytR9qoXdqaG73R+ufj1b5rPZBKQtRNrd15SODTfuYFY116ZAMaB6 /O/DegjcBOFTOtF0RGmzOO6ne0P0jyWRd+U0hVxShbGCvHbg/VHhB/fFdWilEN4cKB1e MhTjAggew2v/HwUzGU9VuT9f8Ob2eu/J/qRTHDYXtdXEOKWh5I08EeKgz8qym5CBdDEZ IUoPojpN8eaRhemdn6drNySdqO89SkolLRU8MZmBCHCnEGNKMDQ0DmPoYxAq+4pjrJEM z3YQVuUdD5abqgOMexJFoBYBwrq22wjWm1FHszMfh84isbmoRcm4OFXlKF7/UuYG1WUu +s2w== MIME-Version: 1.0 X-Received: by 10.220.155.8 with SMTP id q8mr12065231vcw.42.1364901441254; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) Sender: isabell@issyl0.co.uk Received: by 10.220.84.71 with HTTP; Tue, 2 Apr 2013 04:17:21 -0700 (PDT) X-Originating-IP: [87.246.88.161] Date: Tue, 2 Apr 2013 12:17:21 +0100 X-Google-Sender-Auth: BvPd5I1XgjbcT5mSJnXrYcYBacQ Message-ID: Subject: Call for FreeBSD 2013-Q1 status reports! From: Isabell Long To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqaVmkiQ+dvgwujBAxfGRXJy9RrbJRBiuCcUws6s6+JiMm41qs9KzcNXQY3YpFoyJbWkFL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:17:23 -0000 Hi all, On behalf of monthly@, I would like to inform you that the next submission date for the January to March quarterly status reports is April 21st, 2013 - less than a month away. They don't have to be very long - anything that lets people know what is going on inside FreeBSD is useful. Note that submission of reports is not restricted to committers - anyone who is doing anything interesting and FreeBSD-related can write one! The preferred and easiest submission method is to use the XML generator linked to from http://www.freebsd.org/news/status/status.html, with the result emailed as an attachment to monthly@FreeBSD.org. On that page, there is also a link to an XML template which can be filled out manually and attached if preferred. To enable compilation and publication of the Q1 report as soon as possible after the April 21st deadline, please be prompt with any report submissions you may have. I look forward to compiling the report for 2013 Q1. Many thanks, Isabell. (Hat: monthly@) From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 11:41:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 997D0A5F; Tue, 2 Apr 2013 11:41:49 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 59192CE3; Tue, 2 Apr 2013 11:41:49 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5A935C638; Tue, 2 Apr 2013 11:41:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 13D4D9562; Tue, 2 Apr 2013 13:41:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: considering i386 as a tier 1 architecture References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> Date: Tue, 02 Apr 2013 13:41:47 +0200 In-Reply-To: (Mehmet Erol Sanliturk's message of "Tue, 2 Apr 2013 03:10:56 -0700") Message-ID: <86y5d1cg78.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Wojciech Puchar , freebsd-arch@freebsd.org, Lev Serebryakov , FreeBSD Hackers , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:41:49 -0000 Mehmet Erol Sanliturk writes: > I am NOT able to understand the merit of these products with respect > to their features and PRICES. Please stop SHOUTING, and learn to accept and respect the fact that other people have other opinions and priorities than you do, and to stop trying to force your worldview on them. Maybe they know something you haven't learned yet. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 11:51:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31D054AC; Tue, 2 Apr 2013 11:51:16 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id C09FAD77; Tue, 2 Apr 2013 11:51:15 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so333361veb.17 for ; Tue, 02 Apr 2013 04:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7rMoQ6qtVBl2gtomkRwhW9nLhajCSgYxL+qSTq73Hd4=; b=DoeuKKE2m3bOqTO8UcssF5wRjd2SaksA/fsVgwXCDvCoEZTDldGos2sXfzS6dqUsIj 1++SfE8uF7FuQQHMotsxJomJY3L1xLAmQpnk55CarFOoLKLXeOeLJSmRYqFmsCITW9ON tGit4B1ybrh/VoWyQV4CPFfVMT60SUZpWALZBAImgnQKostpRv+hjPcsBzd8aMEaEto6 WCGDA10WLnfM0umgocu+I8jjPqmUktCWGofAabosthg69zHL+4ua4xIOGbwW7533x4Vd nU5g6wjEjxhpNa07y5041mq5+f7ZtGlf1U625zZud9hAvuM9AP0f2CLoCw6iGx/24u5I BL5Q== MIME-Version: 1.0 X-Received: by 10.52.27.17 with SMTP id p17mr10593237vdg.0.1364903475057; Tue, 02 Apr 2013 04:51:15 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Tue, 2 Apr 2013 04:51:14 -0700 (PDT) In-Reply-To: <86y5d1cg78.fsf@ds4.des.no> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <86y5d1cg78.fsf@ds4.des.no> Date: Tue, 2 Apr 2013 04:51:14 -0700 Message-ID: Subject: Re: considering i386 as a tier 1 architecture From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Wojciech Puchar , freebsd-arch@freebsd.org, Lev Serebryakov , FreeBSD Hackers , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:51:16 -0000 On Tue, Apr 2, 2013 at 4:41 AM, Dag-Erling Sm=C3=B8rgrav wrote= : > Mehmet Erol Sanliturk writes: > > I am NOT able to understand the merit of these products with respect > > to their features and PRICES. > > Please stop SHOUTING, and learn to accept and respect the fact that > other people have other opinions and priorities than you do, and to stop > trying to force your worldview on them. Maybe they know something you > haven't learned yet. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > You are right , but my idea was in affirmative sense to understand the reasons . I know that persons are using such systems with respect to some advantages other than the cost and their producers have reasons to assign such prices in a free economic structure . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 13:54:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD643464 for ; Tue, 2 Apr 2013 13:54:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 941983F2 for ; Tue, 2 Apr 2013 13:54:10 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id wz12so253977pbc.31 for ; Tue, 02 Apr 2013 06:54:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=nLwA19wamwMbCphoxWjLl76hrd6D1DfM6a53dOqqhSw=; b=TkUwO7No09h80o+bjGQuZcXJgUUSzcW1Zk8QVZck+ac2mXsabURemro30VADs04XBv kZMan0XAEog3zmsbhfrcVmFlRxBmnUH5/K7azkk3a4ATTgCEal4GhtpO76Q0vMxAfEbZ UcNrJu72oOHIzlKVLELWAD6H+VdNqCA6wc7mhSJ0ZVk/LEOJlymCxVGkVodZconyvfsn LekZwsS/XG8PFVG3J6gwqY5oVGpV0eFEV4fKBBp+7IChHS19QFJB1vHy49BW7IXUueqS LptZn4xEujbsfPaITKqsyT6aRl2yxjrMvqX8uiGFdR+eDnsBl5sdhzu2P5LPCSTVtGVe 7AOg== X-Received: by 10.66.150.165 with SMTP id uj5mr25124473pab.37.1364910849935; Tue, 02 Apr 2013 06:54:09 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id kl4sm1826476pbc.31.2013.04.02.06.54.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 06:54:08 -0700 (PDT) Sender: Warner Losh Subject: Re: considering i386 as a tier 1 architecture Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 2 Apr 2013 07:54:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4FCBC174-DF7D-4935-A09B-F9BA34185462@bsdimp.com> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> To: Mehmet Erol Sanliturk X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlgOdLvenYYl5gnAiSFTxoQ5MtjoY16JqTchjYQIv3oU5dEamnJsLvXpm6ygnu/xWK2XiXT Cc: Lev Serebryakov , FreeBSD Hackers , Eitan Adler , freebsd-arch@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:54:10 -0000 On Apr 2, 2013, at 4:10 AM, Mehmet Erol Sanliturk wrote: > On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm=F8rgrav = wrote: >=20 >> Wojciech Puchar writes: >>> Lev Serebryakov writes: >>>> It is not exact so. Some Atoms on some motherboards with some >>>> firmwares are 64-bit CPU. >>> don't know of any now in shops that are not >>=20 >> http://soekris.com/products/net5501.html >> http://soekris.com/products/net6501.html >>=20 >> DES >> -- >> Dag-Erling Sm=F8rgrav - des@des.no >>=20 >=20 >=20 > I am NOT able to understand the merit of these products with respect = to > their features and PRICES . >=20 > It is possible to assemble much more cheaper full featured PC like = systems > ( DDR3 memory , 64-bit capable processors , with a disadvantage about = power > requirements ) . Often times the power consumption is the most important bit, so much so = you sacrifice speed and memory to get the power down to fit into a small = power budget. Just because you have the ability to purchase a faster = machine for less doesn't make that faster machine suitable for the job. Warner >=20 > Thank you very much . >=20 > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 14:36:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 864DA270; Tue, 2 Apr 2013 14:36:05 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0427DE; Tue, 2 Apr 2013 14:36:04 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r32EZvX5031751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Apr 2013 16:36:02 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r32DMR8s095574; Tue, 2 Apr 2013 15:22:27 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Tue, 2 Apr 2013 15:22:27 +0200 From: Paul Schenkeveld To: freebsd-arch@freebsd.org, FreeBSD Hackers Subject: Re: considering i386 as a tier 1 architecture Message-ID: <20130402132227.GA73670@psconsult.nl> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <20130402102220.GA28545@eris.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130402102220.GA28545@eris.bzerk.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:36:05 -0000 On Tue, Apr 02, 2013 at 10:22:20AM +0000, Ruben de Groot wrote: > On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: > > On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav wrote: > > > > > Wojciech Puchar writes: > > > > Lev Serebryakov writes: > > > > > It is not exact so. Some Atoms on some motherboards with some > > > > > firmwares are 64-bit CPU. > > > > don't know of any now in shops that are not > > > > > > http://soekris.com/products/net5501.html > > > http://soekris.com/products/net6501.html > > > > > > DES > > > -- > > > Dag-Erling Sm??rgrav - des@des.no > > > > > > > > > I am NOT able to understand the merit of these products with respect to > > their features and PRICES . > > They are extremely stable and robust. > > > It is possible to assemble much more cheaper full featured PC like systems > > ( DDR3 memory , 64-bit capable processors , with a disadvantage about power > > requirements ) . > > You can also get much bigger portions at MacDonald than what you get in a > five star restaurant. Soekris boards are perhaps not five star boards but at least they have four :) Although the thread started as an april fools day prank, it's getting serious now about the value of having i386 next to amd64. I'm using quite a number of net4501/net4801/net5501/net6501 in many places just because I haven't found anything that can to the same job with the same reliability at the same low power diet for a reasonable price. For people on a tight budget with lower reliability expectations there are the PC-engines Alix boards. Except for the net6501, none of these can run amd64. Even though the net6501 can run amd64, I prefer running i386 on them (and other boards where I do not need >= 4GB of RAM or the large address space) instead of amd64 just because the system image is so much smaller, requiring less storage on your filesystem (often a small flash device), less time to upload changes over the Internet when doing remote upgrades and they are more efficient with virtual memory. Running amd64 when not really needed is just a waste of resources. There have been discussions in the past whether is would make sense to run a 32-bit userland on top of a amd64 kernel sou you can have >4GB of RAM but keep your userland relatively small. There are only few applications that really benefit from 64 bit address space, others could well be 32 bit apps. Just some random numbers to illustrate my point: i386$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc text data bss dec hex filename 111533 1048 7460 120041 1d4e9 /bin/sh 22808 572 396 23776 5ce0 /bin/ls 33098 760 3392 37250 9182 /usr/bin/find 314841 9376 18204 342421 53995 /usr/bin/cc amd64$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc text data bss dec hex filename 129371 1992 10272 141635 22943 /bin/sh 26255 1144 536 27935 6d1f /bin/ls 43464 1352 4680 49496 c158 /usr/bin/find 383330 15296 58664 457290 6fa4a /usr/bin/cc Kind regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 15:56:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1F7C784; Tue, 2 Apr 2013 15:56:37 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA3FC14; Tue, 2 Apr 2013 15:56:37 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id F16EB42C25FF; Tue, 2 Apr 2013 17:48:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 2 Apr 2013 10:47:20 -0500 (CDT) From: Bryan Venteicher To: Gleb Smirnoff Message-ID: <1227759852.2041.1364917640905.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130402085708.GI76816@FreeBSD.org> References: <201304010945.r319jJw7027369@elf.torek.net> <20130402085708.GI76816@FreeBSD.org> Subject: Re: boot time crash in if_detach_internal() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC25 (Mac)/8.0.2_GA_5569) Thread-Topic: boot time crash in if_detach_internal() Thread-Index: S9ZTAhWq2YKEhktJh+wcG+W+W7cLyQ== Cc: freebsd-hackers@freebsd.org, Chris Torek X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:56:37 -0000 Hi, ----- Original Message ----- > From: "Gleb Smirnoff" > To: "Chris Torek" > Cc: freebsd-hackers@freebsd.org > Sent: Tuesday, April 2, 2013 3:57:08 AM > Subject: Re: boot time crash in if_detach_internal() > > On Mon, Apr 01, 2013 at 03:45:19AM -0600, Chris Torek wrote: > C> I have been poking about with the bhyve virtualization code in > C> FreeBSD 10-current, and managed to crash FreeBSD during its > C> bootstrap process due to the fact that if_detach is called > C> from boot time configuration code, before the internal domain > C> system initialization has happened. > C> > C> I added the following patch to work around the problem. As > C> the large comment notes, it might not be quite correct but it > C> does allow the boot to proceed (of course the "dead" network > C> device is soon a problem anyway...). > C> > C> The fix mirrors (more or less) the code in if_attach_internal(). > C> Feel free to accept, ignore, or modify the patch. :-) > C> > C> Chris > C> > C> diff --git a/sys/net/if.c b/sys/net/if.c > C> --- a/sys/net/if.c > C> +++ b/sys/net/if.c > C> @@ -845,6 +845,15 @@ > C> > C> if_purgeaddrs(ifp); > C> > C> + /* > C> + * torek: it's not entirely clear to me where and how this > C> + * should go, but if domain_init_status < 2 then there should > C> + * be no inet, inet6, etc items, and this is where the crash > C> + * happens during boot, so let's try this: > C> + */ > C> + if (domain_init_status < 2) > C> + return; > C> + > C> #ifdef INET > C> in_ifdetach(ifp); > C> #endif > > Can you provide a backtrace that leads to this? > It is probably along the lines of ... vtnet0: cannot setup virtqueue interrupts Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x370 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8088039b stack pointer = 0x28:0xffffffff8182c4b0 frame pointer = 0x28:0xffffffff8182c550 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [ thread pid 0 tid 100000 ] Stopped at __rw_rlock+0x23b: movl 0x370(%r12),%eax db> bt Tracing pid 0 tid 100000 td 0xffffffff814fb200 __rw_rlock() at __rw_rlock+0x23b/frame 0xffffffff8182c550 in_pcbpurgeif0() at in_pcbpurgeif0+0x30/frame 0xffffffff8182c5a0 in_ifdetach() at in_ifdetach+0x1c/frame 0xffffffff8182c5d0 if_detach() at if_detach+0x19b/frame 0xffffffff8182c630 vtnet_attach() at vtnet_attach+0xb63/frame 0xffffffff8182c760 device_attach() at device_attach+0x396/frame 0xffffffff8182c7b0 vtpci_probe_and_attach_child() at vtpci_probe_and_attach_child+0x91/frame 0xffffffff8182c7f0 vtpci_attach() at vtpci_attach+0x23b/frame 0xffffffff8182c830 device_attach() at device_attach+0x396/frame 0xffffffff8182c880 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff8182c8a0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0xffffffff8182c8f0 device_attach() at device_attach+0x396/frame 0xffffffff8182c940 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff8182c960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff8182c9b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0xffffffff8182ca00 device_attach() at device_attach+0x396/frame 0xffffffff8182ca50 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff8182ca70 acpi_attach() at acpi_attach+0xdd6/frame 0xffffffff8182cb30 device_attach() at device_attach+0x396/frame 0xffffffff8182cb80 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff8182cba0 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0xffffffff8182cbd0 device_attach() at device_attach+0x396/frame 0xffffffff8182cc20 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0xffffffff8182cc50 bus_set_pass() at bus_set_pass+0x8f/frame 0xffffffff8182cc80 configure() at configure+0xa/frame 0xffffffff8182cc90 mi_startup() at mi_startup+0x118/frame 0xffffffff8182ccb0 btext() at btext+0x2c This is from neel@ for vtnet, but I recently saw the same crash at work on an igb (on 9.1 or 9-STABLE). I hadn't had time to look at it much. Not sure if the right answer is for drivers not to call ether_ifattach() until the point-of-no-failure (lots of drivers are wrong then) or initialize other parts earlier. > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 16:43:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA3D6454 for ; Tue, 2 Apr 2013 16:43:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 99E3BF3A for ; Tue, 2 Apr 2013 16:43:39 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id d10so269962qca.9 for ; Tue, 02 Apr 2013 09:43:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=lNMoZWAG+kGqJT+OfLpmBVSzV2ZtcuRpmABaEcTg3oQ=; b=OLEmyC7GC5Dx2eoHNInnNFTpgpoFLoLXwXOt6Tyc6VPwz3RG0YjIsDeD1PvgLlyGCt ea4O3TBhtXxkdP5SS96/Cm4jduAfgCr9s7DKKJqFlLujTUNtMJOSddZ8wrgzyH9ZpPVG Ayja3R4Of6H2YVAW3Prp8ywhXfAGMOqzxfOIteThWH9R9prSxFDO+Y7zxcI2Swwwe5Lp 9Tzbv1O67DdfluULV4rBYzEzJXr7MoNaMmRlOoSMA+A9M8k3ICr0B7MtpjG4hETowHmx sVOMF6HmdYObWeDNb8pO1rdFuax98L7TUV9vKhAxpXZkw/h0+PH5rb/HWZd+QLuN/oDm HQlQ== X-Received: by 10.49.117.7 with SMTP id ka7mr18267771qeb.38.1364921019154; Tue, 02 Apr 2013 09:43:39 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id fr4sm2906360qab.3.2013.04.02.09.43.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 09:43:37 -0700 (PDT) Sender: Warner Losh Subject: Re: considering i386 as a tier 1 architecture Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <610E1139-3CCC-4BDF-B15A-4B24F26D7A95@behanna.org> Date: Tue, 2 Apr 2013 10:43:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <20130402102220.GA28545@eris.bzerk.org> <20130402132227.GA73670@psconsult.nl> <610E1139-3CCC-4BDF-B15A-4B24F26D7A95@behanna.org> To: Chris BeHanna X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkbgmfbITkIomoadHc2f8xWbnV8YwZW4/xNzZRLSk+9VtTLsTzkrKWiCqfTJ/3IOVIAKkOW Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:43:39 -0000 On Apr 2, 2013, at 10:27 AM, Chris BeHanna wrote: > Goodness gracious, did no one see the date on the original post? >=20 > What's the limit on this fishing hole? Three internet Trolls, two wise old owls and a april fool in a pear tree = from the looks of it. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 16:35:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A92C424B; Tue, 2 Apr 2013 16:35:35 +0000 (UTC) (envelope-from chris@behanna.org) Received: from alayta.pair.com (alayta.pair.com [209.68.4.24]) by mx1.freebsd.org (Postfix) with ESMTP id 87677EE1; Tue, 2 Apr 2013 16:35:35 +0000 (UTC) Received: from tourmalet.ticom-geo.com (unknown [64.132.190.26]) by alayta.pair.com (Postfix) with ESMTPSA id EC406D9843; Tue, 2 Apr 2013 12:27:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: considering i386 as a tier 1 architecture From: Chris BeHanna In-Reply-To: <20130402132227.GA73670@psconsult.nl> Date: Tue, 2 Apr 2013 11:27:30 -0500 Content-Transfer-Encoding: 7bit Message-Id: <610E1139-3CCC-4BDF-B15A-4B24F26D7A95@behanna.org> References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <20130402102220.GA28545@eris.bzerk.org> <20130402132227.GA73670@psconsult.nl> To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Tue, 02 Apr 2013 16:57:47 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:35:35 -0000 Goodness gracious, did no one see the date on the original post? What's the limit on this fishing hole? -- Chris BeHanna chris@behanna.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 16:35:40 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76A9E24E; Tue, 2 Apr 2013 16:35:40 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 426B2EE4; Tue, 2 Apr 2013 16:35:39 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r32GZWiO034822; Tue, 2 Apr 2013 10:35:32 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id r32GZWuj034821; Tue, 2 Apr 2013 10:35:32 -0600 (MDT) (envelope-from torek) Date: Tue, 2 Apr 2013 10:35:32 -0600 (MDT) From: Chris Torek Message-Id: <201304021635.r32GZWuj034821@elf.torek.net> To: glebius@FreeBSD.org Subject: Re: boot time crash in if_detach_internal() In-Reply-To: <20130402085708.GI76816@FreeBSD.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.torek.net [127.0.0.1]); Tue, 02 Apr 2013 10:35:33 -0600 (MDT) X-Mailman-Approved-At: Tue, 02 Apr 2013 16:58:02 +0000 Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:35:40 -0000 >Can you provide a backtrace that leads to this? Sure. In case it's not obvious, the __rw_rlock at the top of the trace is working on a lock that has never been initialized (the first of the two ipv4 PCBs). Chris Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2: Sun Mar 31 01:32:38 MDT 2013 torek@dev.torek.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3292.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0x8fa3ab7f Features2=0xa1bae217 AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 472559616 (450 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded; using insecure entropy ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-16 on motherboard module_register_init: MOD_LOAD (vesa, 0xffffffff80c38e80, 0) error 19 kbd0 at kbdmux0 acpi0: on motherboard atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: no PRT entry for 0.31.INTA virtio_pci0: port 0x2000-0x201f at device 1.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x18020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 00:a0:98:36:6d:e8 virtio_pci0: exhausted all interrupt allocation attempts vtnet0: cannot setup virtqueue interrupts Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808894bb stack pointer = 0x28:0xffffffff818434b0 frame pointer = 0x28:0xffffffff81843550 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [ thread pid 0 tid 100000 ] Stopped at __rw_rlock+0x23b: movl 0x378(%r12),%eax db> bt Tracing pid 0 tid 100000 td 0xffffffff8150d370 __rw_rlock() at __rw_rlock+0x23b/frame 0xffffffff81843550 in_pcbpurgeif0() at in_pcbpurgeif0+0x30/frame 0xffffffff818435a0 in_ifdetach() at in_ifdetach+0x1c/frame 0xffffffff818435d0 if_detach() at if_detach+0x19b/frame 0xffffffff81843630 vtnet_attach() at vtnet_attach+0xb63/frame 0xffffffff81843760 device_attach() at device_attach+0x396/frame 0xffffffff818437b0 vtpci_probe_and_attach_child() at vtpci_probe_and_attach_child+0x91/frame 0xffffffff818437f0 vtpci_attach() at vtpci_attach+0x23b/frame 0xffffffff81843830 device_attach() at device_attach+0x396/frame 0xffffffff81843880 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff818438a0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0xffffffff818438f0 device_attach() at device_attach+0x396/frame 0xffffffff81843940 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81843960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff818439b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0xffffffff81843a00 device_attach() at device_attach+0x396/frame 0xffffffff81843a50 bus_generic_attach() at bus_generic_attach+0x4a/frame 0xffffffff81843a70 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 16:50:24 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9893979B; Tue, 2 Apr 2013 16:50:24 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id ED416F77; Tue, 2 Apr 2013 16:50:23 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r32GoF5C034891; Tue, 2 Apr 2013 10:50:15 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id r32GoFKO034890; Tue, 2 Apr 2013 10:50:15 -0600 (MDT) (envelope-from torek) Date: Tue, 2 Apr 2013 10:50:15 -0600 (MDT) From: Chris Torek Message-Id: <201304021650.r32GoFKO034890@elf.torek.net> To: bryanv@daemoninthecloset.org, glebius@FreeBSD.org Subject: Re: boot time crash in if_detach_internal() In-Reply-To: <1227759852.2041.1364917640905.JavaMail.root@daemoninthecloset.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.torek.net [127.0.0.1]); Tue, 02 Apr 2013 10:50:15 -0600 (MDT) X-Mailman-Approved-At: Tue, 02 Apr 2013 16:58:12 +0000 Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:50:24 -0000 >Not sure if the right answer is for drivers not to call ether_ifattach() >until the point-of-no-failure (lots of drivers are wrong then) or >initialize other parts earlier. The other "obvious" method is to rearrange the sysinit priorities (/sys/sys/kernel.h) so that all network domains are initialized before invoking the device configuration code -- moving SI_SUB_PROTO* before SI_CONFIGURE -- but presumably this idea was tried and rejected earlier and hence the code in ether_ifattach to check the same global variable. Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 18:03:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC91528E for ; Tue, 2 Apr 2013 18:03:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7C45FA for ; Tue, 2 Apr 2013 18:03:30 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-245-181.lns20.per2.internode.on.net [121.45.245.181]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r32HwDx4061065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Apr 2013 10:58:16 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <515B1C30.5080703@freebsd.org> Date: Wed, 03 Apr 2013 01:58:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: gary mazzaferro Subject: Re: Need advice on sys5 shm and zero copy sockets References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:03:31 -0000 On 2/8/13 4:22 AM, gary mazzaferro wrote: > Hi, > > I was told to post this question here (Ken Merry), it would be a good > place to get some help. I'm not sure this is doable without a kernel > module, which I don't want to add. > > I'll explain what I'm attempting.. > > I'm designing a high speed rest motor for cloud execution environment. > > 1) I'd like to eliminate copy from the tcp stack to the application(s). > > 2) I'm also sharing the buffers across processes and jails. So I'd > like to preserve the zero-copy in a msg pipe/unix socket > > 3) Some buffers will go to disk file systems. > > > Wish list: > 4) I'd like it to work with sctp because I like it for local networking :) > > 5) I'd like to provision memory pools on a per > application/connection/ip port basis. > > Ultimate Goal: > 6) Additionally, I'm injecting "code" from a foreign process into the > workflow of another process (state machine). The connection between > them will be a signal and shared state information. > > I'm assuming item (6) is a separate issue, but it may impact the direction.. > > I've tried shm with zero copy sockets with linux and it just will not work !! > > BTW, I'm returning to freebsd after far too many years > > cheers, > gary > _______________________________________________ > 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" > > this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk->process, process->network and network->disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 18:11:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D3BE9CB; Tue, 2 Apr 2013 18:11:42 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2F496BD6; Tue, 2 Apr 2013 18:11:42 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 116851A3CD6; Tue, 2 Apr 2013 11:11:34 -0700 (PDT) Message-ID: <515B1F4C.9030001@mu.org> Date: Tue, 02 Apr 2013 11:11:24 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Paul Schenkeveld Subject: Re: considering i386 as a tier 1 architecture References: <944760435.20130401210118@serebryakov.spb.ru> <8638v9e22j.fsf@ds4.des.no> <20130402102220.GA28545@eris.bzerk.org> <20130402132227.GA73670@psconsult.nl> In-Reply-To: <20130402132227.GA73670@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:11:42 -0000 As far I can tell it's now April 2nd in all time zones. Can we now end this thread? thank you, -Alfred On 4/2/13 6:22 AM, Paul Schenkeveld wrote: > On Tue, Apr 02, 2013 at 10:22:20AM +0000, Ruben de Groot wrote: >> On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: >>> On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav wrote: >>> >>>> Wojciech Puchar writes: >>>>> Lev Serebryakov writes: >>>>>> It is not exact so. Some Atoms on some motherboards with some >>>>>> firmwares are 64-bit CPU. >>>>> don't know of any now in shops that are not >>>> http://soekris.com/products/net5501.html >>>> http://soekris.com/products/net6501.html >>>> >>>> DES >>>> -- >>>> Dag-Erling Sm??rgrav - des@des.no >>>> >>> >>> I am NOT able to understand the merit of these products with respect to >>> their features and PRICES . >> They are extremely stable and robust. >> >>> It is possible to assemble much more cheaper full featured PC like systems >>> ( DDR3 memory , 64-bit capable processors , with a disadvantage about power >>> requirements ) . >> You can also get much bigger portions at MacDonald than what you get in a >> five star restaurant. > Soekris boards are perhaps not five star boards but at least they have > four :) > > Although the thread started as an april fools day prank, it's getting > serious now about the value of having i386 next to amd64. > > I'm using quite a number of net4501/net4801/net5501/net6501 in many > places just because I haven't found anything that can to the same job > with the same reliability at the same low power diet for a reasonable > price. > > For people on a tight budget with lower reliability expectations there > are the PC-engines Alix boards. Except for the net6501, none of these > can run amd64. > > Even though the net6501 can run amd64, I prefer running i386 on them > (and other boards where I do not need >= 4GB of RAM or the large address > space) instead of amd64 just because the system image is so much smaller, > requiring less storage on your filesystem (often a small flash device), > less time to upload changes over the Internet when doing remote upgrades > and they are more efficient with virtual memory. Running amd64 when not > really needed is just a waste of resources. > > There have been discussions in the past whether is would make sense to > run a 32-bit userland on top of a amd64 kernel sou you can have >4GB of > RAM but keep your userland relatively small. There are only few > applications that really benefit from 64 bit address space, others could > well be 32 bit apps. > > Just some random numbers to illustrate my point: > > i386$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc > > text data bss dec hex filename > 111533 1048 7460 120041 1d4e9 /bin/sh > 22808 572 396 23776 5ce0 /bin/ls > 33098 760 3392 37250 9182 /usr/bin/find > 314841 9376 18204 342421 53995 /usr/bin/cc > > amd64$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc > > text data bss dec hex filename > 129371 1992 10272 141635 22943 /bin/sh > 26255 1144 536 27935 6d1f /bin/ls > 43464 1352 4680 49496 c158 /usr/bin/find > 383330 15296 58664 457290 6fa4a /usr/bin/cc > > Kind regards, > > Paul Schenkeveld > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 2 19:31:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE8F5274; Tue, 2 Apr 2013 19:31:27 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id EF2A72CF; Tue, 2 Apr 2013 19:31:26 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id v10so845899lbd.30 for ; Tue, 02 Apr 2013 12:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OXPAvzPeG3/alHQrSJEi/0Mf0C1lyvKgeCY4Hh1hBVY=; b=BFNFn24yJgNOz2S1+MENLhros+4fvq6oTQ3g9opmAQbivQiHHrQsK94ycOOAkz+C3a sRSlGHAqFOPUUI2Pv7gjVZPDL3lJlX/nQOCCYqWUkVBpMpjTyrX6MzIYgwMGRL9+vVfK eG3p+MWj+AsrOomrYk/h9Cba304twBnBK6IZ7+svzb2eU0dEodyE9IyyQIrKCxkk6iFe yFl/yJizzM7Dbg0hopJq4y1rNbdBYWMASPw20swW84S/t/1B8H3J+Ggwn9GS5EIcG/aN 3McybX3D8GFNkyN2Qtes3wzQ1TgbnCNEbFaERUZ0lVjjepdjKtFfydrQrv/JreDVUrJi 3Rag== MIME-Version: 1.0 X-Received: by 10.152.46.12 with SMTP id r12mr8446468lam.15.1364931079828; Tue, 02 Apr 2013 12:31:19 -0700 (PDT) Received: by 10.112.138.33 with HTTP; Tue, 2 Apr 2013 12:31:19 -0700 (PDT) In-Reply-To: <201304011433.23781.jhb@freebsd.org> References: <201304011433.23781.jhb@freebsd.org> Date: Tue, 2 Apr 2013 15:31:19 -0400 Message-ID: Subject: Re: preemptive kernel From: vasanth rao naik sabavat To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:31:27 -0000 Thanks John, That is helpful. On Mon, Apr 1, 2013 at 2:33 PM, John Baldwin wrote: > On Friday, March 22, 2013 4:10:16 pm vasanth rao naik sabavat wrote: > > Hi Adrian, > > > > Just to clarify, is the kernel pre-emption involuntary? > > > > Let say I have a kernel thread processing a huge list of entries, would > > this thread get involuntarily context switched out because of kernel > > preemption? > > > > What is the time slice after which a kernel thread can involuntarily > > context switched out? > > > > Could you please point to the file in the source code which handles the > > kernel pre-emption. > > In-kernel preemption is driven by interrupts, not time slices. If an > interrupt arrives that awakens a higher priority thread (e.g. an interrupt > thread), or if your thread awakens a thread that has higher priority (e.g. > due > to wakeup() or cv_signal()), then your thread will be preempted. > > In general time-based preemptions are only done for user threads. > > -- > John Baldwin > -- Thanks, Vasanth From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 3 03:07:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC8F0A2C for ; Wed, 3 Apr 2013 03:07:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8C872F32 for ; Wed, 3 Apr 2013 03:07:35 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-245-181.lns20.per2.internode.on.net [121.45.245.181]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3337VYj062695 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Apr 2013 20:07:33 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <515B9CF0.2060808@freebsd.org> Date: Wed, 03 Apr 2013 11:07:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: gary mazzaferro Subject: Re: Need advice on sys5 shm and zero copy sockets References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 03:07:35 -0000 On 2/8/13 4:22 AM, gary mazzaferro wrote: > Hi, > > I was told to post this question here (Ken Merry), it would be a good > place to get some help. I'm not sure this is doable without a kernel > module, which I don't want to add. > > I'll explain what I'm attempting.. > > I'm designing a high speed rest motor for cloud execution environment. > > 1) I'd like to eliminate copy from the tcp stack to the application(s). > > 2) I'm also sharing the buffers across processes and jails. So I'd > like to preserve the zero-copy in a msg pipe/unix socket > > 3) Some buffers will go to disk file systems. > > > Wish list: > 4) I'd like it to work with sctp because I like it for local networking :) > > 5) I'd like to provision memory pools on a per > application/connection/ip port basis. > > Ultimate Goal: > 6) Additionally, I'm injecting "code" from a foreign process into the > workflow of another process (state machine). The connection between > them will be a signal and shared state information. > > I'm assuming item (6) is a separate issue, but it may impact the direction.. > > I've tried shm with zero copy sockets with linux and it just will not work !! > > BTW, I'm returning to freebsd after far too many years > > cheers, > gary > _______________________________________________ > 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" > > this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk->process, process->network and network->disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 3 03:39:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39D17E0; Wed, 3 Apr 2013 03:39:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 9E37D120; Wed, 3 Apr 2013 03:39:18 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id c10so3189605wiw.2 for ; Tue, 02 Apr 2013 20:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vdc3E4hiHpHvMVHIQMGWZoodcbvrLnNYKaQ2akCm7c8=; b=Ur1jXuDFI630Rf96ojKv3oJJFuri6d0co+GPS4X1OhsXY8zvYNrDlAky7hjHw7IBJw AXHZvBMyumP7L8Mdu9jSUsfA2UtTNFLIY44dNhPdEgTVtlyG9MATXtK5pYMbdnz27DvY yqMUbPMhoKLr5Cb+qj+VSCCu8MrUAGHNwdn5BKiWuFJySipQLX3aUtaCdQaY2VET/tBO xYKto4Mrbw6PWd6LNgDhozON5v0TtwH+nYEEP0HyFZWINDKCb4EC0fSL2kx9ykUmr+rD z/KwWE/LH2JBaFbegZUA+8LCpzkMpu9iBWcJ0Vf06SiM2UqtBr+oos2A6LHbT85lwal3 Pang== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr8493wjb.24.1364960357742; Tue, 02 Apr 2013 20:39:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 2 Apr 2013 20:39:17 -0700 (PDT) In-Reply-To: <515B9CF0.2060808@freebsd.org> References: <515B9CF0.2060808@freebsd.org> Date: Tue, 2 Apr 2013 20:39:17 -0700 X-Google-Sender-Auth: 4Q6pp5oYJHCjyiqpLmCBH0Zv8kY Message-ID: Subject: Re: Need advice on sys5 shm and zero copy sockets From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, gary mazzaferro X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 03:39:19 -0000 On 2 April 2013 20:07, Julian Elischer wrote: > this sound somewhat like what I did back in the 90s with BSD4.3 > unfortunately it was not done with TCP (or sctp of course) > > what we did was to create a special shared memeory device driver. > Then we added ioctls to the disk driver layer to write named > blocks of memory from that device to the raw device (we didin't use a > filesystem). Funny that. I have to do something like this for this software radio NIC, that does a hundred or so megabytes a second of DMA. Eek. Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 3 08:48:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF1051C4 for ; Wed, 3 Apr 2013 08:48:27 +0000 (UTC) (envelope-from emorrasg@yahoo.es) Received: from nm14-vm0.bullet.mail.ird.yahoo.com (nm14-vm0.bullet.mail.ird.yahoo.com [77.238.189.193]) by mx1.freebsd.org (Postfix) with SMTP id 1B5ABD87 for ; Wed, 3 Apr 2013 08:48:26 +0000 (UTC) Received: from [77.238.189.51] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 03 Apr 2013 08:45:08 -0000 Received: from [217.146.189.106] by tm4.bullet.mail.ird.yahoo.com with NNFMP; 03 Apr 2013 08:45:08 -0000 Received: from [127.0.0.1] by smtp122.mail.ird.yahoo.com with NNFMP; 03 Apr 2013 08:45:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1364978708; bh=ZZaJFebpDC3+nvD4rd6RmvU90RxaeE8pbGsJmiQY5Tg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; b=s3SCP4rSQ64MorfBANzh6Gu8rXQr22H+5TQHt35v5LOGLO7p7ilzwmPUCidW6w6T4uZivdJSI+f6sTyqpBa0GB2HgyjH5bbjwatwarOMEsXijt1Ls8aPrwzavnhLL1LNDHpjEIcLDeDVZGT6q8aUBY0xZKZHmARIPH6EQdlsa/k= X-Yahoo-Newman-Id: 954604.24170.bm@smtp122.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Js1SxhcVM1lZYKlLEXBLK73.jjDB6iZNknSKfcB7by4ZG.t mID.xMfddTv5YptMRr0W5W0c8W9_fierH4YNn120BpJ4xp6A8NmQ.kMUs8tr qFaL5iuLp0CHLRol1h1CxydWEBN7x0YS_WYSmiHZp_DTviJWxZQJ1y74dR9x 4gSzjxyyQXCjCoylrgkJ9bySUCkhQCeCfhB5JWSuoAH8RtZeCrafYbGXhCIJ sA359zsfOe7Y9glyZYI7qOpS3Zb3LDvxAXoGYloQhmNrsKuVs9mqODEE9S1B X22DlB9m8qjR5Sb8IQSHfK9RRlNFCTwyqjckCG.QTC_A.80jgirGoaxCGduh TJgkl4uZR7wCCyArPxuo.wFyZMunpjxRtNyzPz2Y9sfn8z3IMgJvtPZLvLPe B5Y5v1AsGKm8- X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR X-Rocket-Received: from camibar.emorras.eu (emorrasg@85.219.45.142 with plain) by smtp122.mail.ird.yahoo.com with SMTP; 03 Apr 2013 01:45:08 -0700 PDT Date: Wed, 3 Apr 2013 10:10:59 +0200 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: Need advice on sys5 shm and zero copy sockets Message-Id: <20130403101059.5d61f06251308cfb57df62ed@yahoo.es> In-Reply-To: <515B1C30.5080703@freebsd.org> References: <515B1C30.5080703@freebsd.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 08:48:27 -0000 Don't have original message, i reply to a reply sorry. > On 2/8/13 4:22 AM, gary mazzaferro wrote: > > Hi, > > > > I was told to post this question here (Ken Merry), it would be a good > > place to get some help. I'm not sure this is doable without a kernel > > module, which I don't want to add. > > > > I'll explain what I'm attempting.. > > > > I'm designing a high speed rest motor for cloud execution environment. > > > > 1) I'd like to eliminate copy from the tcp stack to the application(s). > > > > 2) I'm also sharing the buffers across processes and jails. So I'd > > like to preserve the zero-copy in a msg pipe/unix socket > > > > 3) Some buffers will go to disk file systems. > > > > > > Wish list: > > 4) I'd like it to work with sctp because I like it for local networking :) > > > > 5) I'd like to provision memory pools on a per > > application/connection/ip port basis. > > > > Ultimate Goal: > > 6) Additionally, I'm injecting "code" from a foreign process into the > > workflow of another process (state machine). The connection between > > them will be a signal and shared state information. > > > > I'm assuming item (6) is a separate issue, but it may impact the direction.. > > > > I've tried shm with zero copy sockets with linux and it just will not work !! > > > > BTW, I'm returning to freebsd after far too many years > > > > cheers, > > gary For question (1) Are you using secure rest with TLS/SSL? Does your rest implementation uses openssl? If yes to both, then you don't need to use tcp. SSL already does all the work tcp does, resending lost/damaged packets and reordering received packets, so you can use plain udp without much pain. Openssl has since 0.9.8 this capability implemented with udp, don't remember if udplite. Check RFC 6347 HTH --- --- Eduardo Morras From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 3 19:05:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 225761B3; Wed, 3 Apr 2013 19:05:39 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFD685E; Wed, 3 Apr 2013 19:05:37 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id o10so788455eaj.23 for ; Wed, 03 Apr 2013 12:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=1yW498TD/Gkzhd61z50I0itddKhoGMSRjY0vOcHiJSQ=; b=j8uDmkMytdr0mfEuwZsu76F+9VK0gGCLPl+SiTzAm0jYiZRW35eA8iwu6huqjcImcL 7b38o1WqGELsOExjaj5HtKAgqpptfnWctnSBcE96Xw2cM4KuuVPiyC9i/GcwXZXTIW+U 7jpRNWnZ+TaGNnuhAoSpbJk2v+KBITnUo8IBxZ4fFqP6haBNu+DtTy8hKoFa9steZdBv bYMMbtECDiNaoJJRQqNA6panlgyB7ab8hQHy2BEBYiJuIiDhJ6aDNAgqwz7e5YuP61KW SMnCkEaDpY1QEhev7csPi70oD/vqsCp88gq5VAjcMLPh/EmvO95nHtT21CXe6MAEbxx2 QVxQ== X-Received: by 10.15.43.132 with SMTP id x4mr5509450eev.31.1365015937205; Wed, 03 Apr 2013 12:05:37 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id r4sm8826428eeo.12.2013.04.03.12.05.35 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 03 Apr 2013 12:05:36 -0700 (PDT) Sender: Mikolaj Golub Date: Wed, 3 Apr 2013 22:05:33 +0300 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130403190532.GA4184@gmail.com> References: <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> <20130329123155.GA94024@gmail.com> <20130331134047.GN3794@kib.kiev.ua> <20130331155259.GA9867@gmail.com> <20130331172301.GO3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130331172301.GO3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:05:39 -0000 The updated patch set: http://people.freebsd.org/~trociny/procstat_core.4.patch It includes changes discussed with Kostik. New NT_PROCSTAT_PSSTRINGS and NT_PROCSTAT_AUXV notes are added. libprocstat(3) is extended with functions to retrieve env, args and auxv (so the patch that started this thread a couple of months ago has been merged to this patch set too). procstat(1) is fully converted to work only via libprocstat(3), all its options are supported for core dumps, except kernel stacks, which are not useful in this case. It looks for me to be in a good shape now and I am planning to start committing things in a week or two, after some additional testing, if there is no objections or other suggestions. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 4 17:06:16 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53E1D1A6; Thu, 4 Apr 2013 17:06:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B353175; Thu, 4 Apr 2013 17:06:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11401; Thu, 04 Apr 2013 20:06:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DB305.70908@FreeBSD.org> Date: Thu, 04 Apr 2013 20:06:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, FreeBSD Hackers Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> In-Reply-To: <20130330161434.GG76354@funkthat.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:06:16 -0000 on 30/03/2013 18:14 John-Mark Gurney said the following: > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... > > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. > > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... > > I think I remeber another thread about this from a year or two ago, > but I couldn't find it... If someone finds it, posting a link would > be nice.. > I wish to abstract as much as possible from how an application may use, misuse or even abuse the close+xxxx interaction. But I think that the behavior that provides more information / capabilities is preferable over the behavior that does not. E.g. your example above does not apply to a utility that has only two threads. The "three threads" problem can also be solved if all the threads cooperate. But as I've said. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 4 17:34:03 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B8E0A63; Thu, 4 Apr 2013 17:34:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C70332B8; Thu, 4 Apr 2013 17:34:01 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11680; Thu, 04 Apr 2013 20:34:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DB988.1080100@FreeBSD.org> Date: Thu, 04 Apr 2013 20:34:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> <201304011052.18370.jhb@freebsd.org> In-Reply-To: <201304011052.18370.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:34:03 -0000 on 01/04/2013 17:52 John Baldwin said the following: > Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember > why we changed it to a regular mutex. It may be that there was a lock order reason > for that. :( I came up with the following patch: http://people.freebsd.org/~avg/intr_table_lock.diff Please note the witness change. Part of it is to prepare for smp_ipi_mtx -> intr_table_lock order, but I also had to move "entropy harvest mutex" because it is used with msleep_spin. Also intr_table_lock interacts with "sched lock". This seems to work without problems or any warnings with WITNESS && !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the relevant code paths. P.S. Looking through history it seems that in r169391 intr_table_lock was changed from a spinlock to a sx lock (later it was changed to the current mutex). The commit message explains why spinlock was not needed, but it doesn't seem to say why it was unacceptable: > Minor fixes and tweaks to the x86 interrupt code: - Split the intr_table_lock into an sx lock used for most things, and a spin lock to protect intrcnt_index. Originally I had this as a spin lock so interrupt code could use it to lookup sources. However, we don't actually do that because it would add a lot of overhead to interrupts, and if we ever do support removing interrupt sources, we can use other means to safely do so w/o locking in the interrupt handling code. - Replace is_enabled (boolean) with is_handlers (a count of handlers) to determine if a source is enabled or not. This allows us to notice when a source is no longer in use. When that happens, we now invoke a new PIC method (pic_disable_intr()) to inform the PIC driver that the source is no longer in use. The I/O APIC driver frees the APIC IDT vector when this happens. The MSI driver no longer needs to have a hack to clear is_enabled during msi_alloc() and msix_alloc() as a result of this change as well. - Add an apic_disable_vector() to reset an IDT vector back to Xrsvd to complement apic_enable_vector() and use it in the I/O APIC and MSI code when freeing an IDT vector. - Add a new nexus hook: nexus_add_irq() to ask the nexus driver to add an IRQ to its irq_rman. The MSI code uses this when it creates new interrupt sources to let the nexus know about newly valid IRQs. Previously the msi_alloc() and msix_alloc() passed some extra stuff back to the nexus methods which then added the IRQs. This approach is a bit cleaner. - Change the MSI sx lock to a mutex. If we need to create new sources, drop the lock, create the required number of sources, then get the lock and try the allocation again. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 4 17:43:21 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2387D5F; Thu, 4 Apr 2013 17:43:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A4B85331; Thu, 4 Apr 2013 17:43:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11825; Thu, 04 Apr 2013 20:43:18 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DBBB5.70505@FreeBSD.org> Date: Thu, 04 Apr 2013 20:43:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <201304011122.13101.jhb@freebsd.org> In-Reply-To: <201304011122.13101.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, office@FreeBSD.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:43:21 -0000 on 01/04/2013 18:22 John Baldwin said the following: > I think you need to split the 'struct file' reference count into two different > counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The > fget for accept and probably most other system calls should probably be equivalent > to vhold, whereas things like open/dup (and storing an fd in a cmsg) should be > more like vref. close() should then be a vrele(). This model makes perfect sense. Unfortunately, ENOTIME to work on this. Meanwhile I am using the following patch specific to local domain sockets, accept(2) and shutdown(2). Turns out that the problematic application does both shutdown(RDWR) and close(2), but that doesn't help on FreeBSD. BTW, this is the application: http://thread.gmane.org/gmane.os.freebsd.devel.office/1754 The patch does help. Author: Andriy Gapon Date: Thu Mar 28 20:08:13 2013 +0200 [test!] uipc_shutdown: use soisdisconnected instead of socantsendmore So that in addition to disabling sends we also wake up threads blocked in accept (on so_timeo in general). diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index 9b60eab..e93d46c 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -1074,7 +1074,7 @@ uipc_shutdown(struct socket *so) UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - socantsendmore(so); + soisdisconnected(so); unp_shutdown(unp); UNP_PCB_UNLOCK(unp); UNP_LINK_WUNLOCK(); -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 4 21:20:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93315C38 for ; Thu, 4 Apr 2013 21:20:55 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6ADEFE13 for ; Thu, 4 Apr 2013 21:20:55 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rq13so1647465pbb.6 for ; Thu, 04 Apr 2013 14:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:content-type:date:message-id :mime-version:x-mailer; bh=UjujpOejz8HlkIzr/xmiw+hWh9dYSPyHGA6CaqUGg50=; b=CdlLcUc+PbEEYBR24WqUz5LP/1TWSVOhcmoAeHMVCwYgiVORFAcq/l99H7K+T2fKGO wjEx7ZP7AbWFHttqTga7qLkuRdcny4n4vH5jmonCXpgD/L4HBcIR6yvTWCkBEq9EhFfS QMPYy0aXrY+rdmwXlqwD5PcqWNpKpWlmFraq4ylXErgI87BVbGDCfqTv9VY1h+hf6Zgz ISu1Ubt1/3QxDODJxY6vSBo9T2YpvNCz+GTTRdzWHAeOsQ0PkvxXcdqbkrvifVO/VoKW upClC+U9lxAzhV6mPsrQUuTF+0Ziu6ajNDB3OALOkXcuwu5dBqJ2ahb8upZH6SMtBOBw 0bgw== X-Received: by 10.68.143.167 with SMTP id sf7mr11017074pbb.21.1365110449014; Thu, 04 Apr 2013 14:20:49 -0700 (PDT) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com. [209.131.62.116]) by mx.google.com with ESMTPS id qh4sm12902408pac.8.2013.04.04.14.20.46 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 14:20:47 -0700 (PDT) Subject: extend printf(9) %b format to allow 0 bits set From: Sean Bruno To: freebsd-hackers Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jFOVTSqVq3pJcG5Xa1dE" Date: Thu, 04 Apr 2013 14:20:45 -0700 Message-ID: <1365110445.1404.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:20:55 -0000 --=-jFOVTSqVq3pJcG5Xa1dE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A small patch from my wanderings today for your review. This patch to kvprintf() allows me to set a %b format string of: "\20\0unset\1ONESET\2TWOSET" In the case that the variable being compared has the value of 0, it will display "0x0" http://people.freebsd.org/~sbruno/subr_prf.txt Sean --=-jFOVTSqVq3pJcG5Xa1dE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRXe6tAAoJEBkJRdwI6BaHHs4H/3Qc5WCCo7sgULKE62x8nIYw sKPauUoHVN4qimAMSV+boDPRbg1Ta1ZsNlb2QCIgIhDXE7tyzYYCjXm993c1KWXy AN4vxzg4XAs5Z5MNN67olwHlY1LNRrajCxrgfQgYETk5KDqB+vp822TY3H3oG3w6 lBZ9jx0xKrIw0kznVaeVNxN32bN+DCcM/zO1fQKt4XjUH2+iM+Vc2Sgc5YejIIC5 6fR540zu0u/G1lLZEMXuVxGUaYSSvBtrXV+OF4aoi1HQ9nqJ44lbpmptHNAA9Qce 7A/XvQ8oh1xQyn38M3WkHKPHsUCnyBUCngz0IQDQOzp3QVau52F5Jo+VmAFdNf8= =/EqN -----END PGP SIGNATURE----- --=-jFOVTSqVq3pJcG5Xa1dE-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 4 21:33:09 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AAF490; Thu, 4 Apr 2013 21:33:09 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by mx1.freebsd.org (Postfix) with ESMTP id 313BDEAD; Thu, 4 Apr 2013 21:33:09 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id z10so1664480pdj.30 for ; Thu, 04 Apr 2013 14:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=6ZjQ1sKxyFcqp20W39tle19I76nll1canOpBC631wEY=; b=qTGR/iAwdjz1MoFMeBXeh3JLfX1h62DaXWYjvQ65BkPo54j4xcaq7RbDdSGOZbmyGs gCZVNrCTr9r3qvtZGo6R4n+hBsIRMV0FeAa8qtpk8U2LiYU+EEO5+2G+2EZ5DcC/G1Lg FUOzsp8qVqAFwfO384uNFLhnvS/0clc1EMHz+atM3F6oIyF2QH2XNFDnd5R05qRTNhi5 EImqxYdrQEzgncTZiSWUNLoCmSHbP5psT+x4EU5NWVBG/KIU35c++VDBBEEmD8N8T50k GY9IuZK018ZPvA6X0JlI27gakCB8z5TVdIX3cKxmQ2JP067P8e0Tckuza4gylIF/NJTZ bg1Q== X-Received: by 10.68.134.71 with SMTP id pi7mr3394769pbb.205.1365111183801; Thu, 04 Apr 2013 14:33:03 -0700 (PDT) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com. [209.131.62.116]) by mx.google.com with ESMTPS id hp1sm12955356pac.3.2013.04.04.14.33.01 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 14:33:02 -0700 (PDT) Subject: Re: CFR: FireWire: Don't allow a tlabel to reference an xfer after free From: Sean Bruno To: Will Andrews In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3FK8TUAnM9kThpvm28+b" Date: Thu, 04 Apr 2013 14:33:00 -0700 Message-ID: <1365111180.1404.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: Alexander Kabaev , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:33:09 -0000 --=-3FK8TUAnM9kThpvm28+b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2013-03-28 at 11:25 -0600, Will Andrews wrote: > Diff: http://people.freebsd.org/~will/patches/fix-fwmem-use-after-free.di= ff >=20 > >From the commit log: >=20 > FireWire: Don't allow a tlabel to reference an xfer after free. > =09 > sys/dev/firewire/firewire.c: > - fw_xfer_unload(): Since we are about to free this xfer, call > fw_tl_free() to remove the xfer from its tlabel's list, if > it has a tlabel. > - In every occasion when a xfer is removed from a tlabel's list, > reset xfer->tl to -1 while holding fc->tlabel_lock, so that the > xfer isn't mis-identified as belonging to a tlabel. >=20 >=20 > Thanks, > --Will. > _______________________________________________ Ack. Looks like a valid commit. sean --=-3FK8TUAnM9kThpvm28+b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRXfGMAAoJEBkJRdwI6BaH6lYH/2+bSKUqX+NqebUk3JOyHtH2 Z+OpeZu7gsl+/+btIH+QEfQ3BAd4viFUBFLo9hoP9xIB9t0Sty2LZVhCtAAoYrcP kPqoCo4n/wkSTc6sfq3MAkT1KRguK/Fr/r25Mx1kS/6osX8ECy400tZemG7bYEZC 17p+2MXghTx6uZ9aML3rPWLGsgVETL3paaPyUx4+wZN8uzV2xbNU9r/g88mTDtB4 qxFb72Al+/ip5LChY41KKtpqjiUKSl0VPXXU+OwBX1/Yow2gHGK1BsH1J1B9uzFI DpNCArfd7pH664V9AaH5VUsnz+t+tYYRst51x54wK29UFY82Ew46nkzlAT4dpAQ= =94tn -----END PGP SIGNATURE----- --=-3FK8TUAnM9kThpvm28+b-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 5 20:32:25 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A8399FC; Fri, 5 Apr 2013 20:32:25 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 12FD8C14; Fri, 5 Apr 2013 20:32:25 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0D1703592EE; Fri, 5 Apr 2013 22:32:23 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id DF9DE2848C; Fri, 5 Apr 2013 22:32:22 +0200 (CEST) Date: Fri, 5 Apr 2013 22:32:22 +0200 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130405203222.GB10840@stack.nl> References: <515475C7.6010404@FreeBSD.org> <201304011122.13101.jhb@freebsd.org> <515DBBB5.70505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515DBBB5.70505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, office@FreeBSD.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:32:25 -0000 On Thu, Apr 04, 2013 at 08:43:17PM +0300, Andriy Gapon wrote: > on 01/04/2013 18:22 John Baldwin said the following: > > I think you need to split the 'struct file' reference count into two > > different counts similar to the how we have vref/vrele vs > > vhold/vdrop for vnodes. The fget for accept and probably most other > > system calls should probably be equivalent to vhold, whereas things > > like open/dup (and storing an fd in a cmsg) should be more like > > vref. close() should then be a vrele(). > This model makes perfect sense. > Unfortunately, ENOTIME to work on this. This looks like it can work but I don't know whether it's worth the trouble. > Meanwhile I am using the following patch specific to local domain > sockets, accept(2) and shutdown(2). Turns out that the problematic > application does both shutdown(RDWR) and close(2), but that doesn't > help on FreeBSD. > BTW, this is the application: > http://thread.gmane.org/gmane.os.freebsd.devel.office/1754 > The patch does help. > Author: Andriy Gapon > Date: Thu Mar 28 20:08:13 2013 +0200 > > [test!] uipc_shutdown: use soisdisconnected instead of socantsendmore > > So that in addition to disabling sends we also wake up threads blocked > in accept (on so_timeo in general). > > diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c > index 9b60eab..e93d46c 100644 > --- a/sys/kern/uipc_usrreq.c > +++ b/sys/kern/uipc_usrreq.c > @@ -1074,7 +1074,7 @@ uipc_shutdown(struct socket *so) > > UNP_LINK_WLOCK(); > UNP_PCB_LOCK(unp); > - socantsendmore(so); > + soisdisconnected(so); > unp_shutdown(unp); > UNP_PCB_UNLOCK(unp); > UNP_LINK_WUNLOCK(); I think this patch makes shutdown(SHUT_WR) on unix domain sockets act like shutdown(SHUT_RDWR), i.e. receives are incorrectly denied. The below patch also makes shutdown(SHUT_RDWR) abort a blocking accept on a unix domain socket, but it should work for all domains: Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 248873) +++ sys/kern/uipc_socket.c (working copy) @@ -2428,9 +2428,11 @@ soshutdown(struct socket *so, int how) sorflush(so); if (how != SHUT_RD) { error = (*pr->pr_usrreqs->pru_shutdown)(so); + wakeup(&so->so_timeo); CURVNET_RESTORE(); return (error); } + wakeup(&so->so_timeo); CURVNET_RESTORE(); return (0); } A blocking accept (and some other operations) is waiting on &so->so_timeo. Once it wakes up, it will detect the SBS_CANTRCVMORE bit. A spurious wakeup on so->so_timeo appears harmless (sleep retried) except when lingering on close (SO_LINGER) so this should be fairly safe. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 6 17:14:48 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD91BD22; Sat, 6 Apr 2013 17:14:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2C278D; Sat, 6 Apr 2013 17:14:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA04486; Sat, 06 Apr 2013 20:14:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UOWhR-0006CP-70; Sat, 06 Apr 2013 20:14:45 +0300 Message-ID: <51605804.8080906@FreeBSD.org> Date: Sat, 06 Apr 2013 20:14:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Baldwin Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> <201304011052.18370.jhb@freebsd.org> <515DB988.1080100@FreeBSD.org> In-Reply-To: <515DB988.1080100@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 17:14:48 -0000 on 04/04/2013 20:34 Andriy Gapon said the following: > This seems to work without problems or any warnings with WITNESS && > !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the > relevant code paths. > > P.S. Looking through history it seems that in r169391 intr_table_lock > was changed from a spinlock to a sx lock (later it was changed to the current > mutex). The commit message explains why spinlock was not needed, but it doesn't > seem to say why it was unacceptable: Hmm, looks like I missed the elephant. apic_free_vector is called with intr_table_lock held and it calls sched_bind(). I need to re-think all of think from the scratch... -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 6 18:11:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6A5D523; Sat, 6 Apr 2013 18:11:55 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3A29BC; Sat, 6 Apr 2013 18:11:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r36IBluH064656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Apr 2013 11:11:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r36IBlIm064655; Sat, 6 Apr 2013 11:11:47 -0700 (PDT) (envelope-from jmg) Date: Sat, 6 Apr 2013 11:11:47 -0700 From: John-Mark Gurney To: Bakul Shah Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130406181147.GJ76354@funkthat.com> Mail-Followup-To: Bakul Shah , freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> <20130330202249.F218BB82A@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130330202249.F218BB82A@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 06 Apr 2013 11:11:48 -0700 (PDT) Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 18:11:55 -0000 Bakul Shah wrote this message on Sat, Mar 30, 2013 at 13:22 -0700: > On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney wrote: > > > > As someone else pointed out in this thread, if a userland program > > depends upon this behavior, it has a race condition in it... > > > > Thread 1 Thread 2 Thread 3 > > enters routine to read > > enters routine to close > > calls close(3) > > open() returns 3 > > does read(3) for orignal fd > > > > How can the original threaded program ensure that thread 2 doesn't > > create a new fd in between? So even if you use a lock, this won't > > help, because as far as I know, there is no enter read and unlock > > mutex call yet... > > It is worse. Consider: > > fd = open(file,...); > read(fd, ...); > > No guarantee read() gets data from the same opened file! > Another thread could've come along, closed fd and pointed it > to another file. So nothing is safe. Might as well stop using > threads, right?! Nope, you need your threads to cooperate w/ either locks or some ownership mechanism like token passing... As long as only one thread own the fd, you won't have troubles... > We are talking about cooperative threads where you don't have > to assume the worst case. Here not being notified on a close Multiple people have said when threads cooperate without locks, but no one has given a good example where they do... The cases you list below are IMO special (and extreme) cases... We were talking about "cooperating" threads in a general purpose langage like Java where you can not depend upon your other threads doing limited amount of work... > event can complicate things. As an example, I have done > something like this in the past: A frontend process validating > TCP connections and then passing on valid TCP connections to > another process for actual service (via sendmsg() over a unix > domain). All the worker threads in service process can do a > recvmsg() on the same fd. They process whatever tcp connection > they get. Now what happens when the frontend process is > restarted for some reason? All the worker threads need to > eventually reconnect to a new unix domain posted by the new > frontend process. You can handle this multiple ways but > terminating all the blocking syscalls on the now invalid fd is > the simplest solution from a user perspective. This'd make an interesting race... Not sure if it could happen, but close(), closes the receiving fd, but another thread is in the process of receiving an fd and puts the new fd in the close of the now closed unix domain socket... I can draw a more detailed diagram if you want.. > > I decided long ago that this is only solvable by proper use of locking > > and ensuring that if you call close (the syscall), that you do not have > > any other thread that may use the fd. It's the close routine's (not > > syscall) function to make sure it locks out other threads and all other > > are out of the code path that will use the fd before it calls close.. > > If you lock before close(), you have to lock before every > other syscall on that fd. That complicates userland coding and > slows down things when this can be handled more simply in the > kernel. There is "ownership" that can be passed, such as via kqueue _ONESHOT w/ multiple threads which allows you to avoid locking and only one thread ever owns the fd... > Another usecase is where N worker threads all accept() on the > same fd. Single threading using a lock defeats any performance > gain. In this case you still need to do something special since what happens if one of the worker threads opens a file and/or listen/accept socket as part of it's work? Thread 1 Thread 2 Thread 3 about to call accept but after flag check sets flag that close is going to be called accept connect process connection close listen'd socket open socket as part of processing gets same fd calls listen on socket calls accept on socket And there we have it, a race condition... You can't always guarantee what your worker threads do, if you can, it's good, but we need to make sure that beginner programs don't get into traps like these... They can easily make the mistake of saying, well, since close kicks all my threads out, I'll just do that instead of making sure that they don't have a race condition... > > If someone could describe how this new eject a person from read could > > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > > we're just moving the race around, and letting people think that they > > have solved the problem when they haven't... > > In general it just makes sense to notify everyone waiting on > something that the situation has changed and they are going to > have to wait forever. The kernel should already have the > necessary information about which threads are sleeping on a > fd. Wake them all up. On being awakened they see that the fd > is no longer valid and all return with a count of data already > read or -1 and EBADF. Doing the equivalent in userland is > complicated. > > Carl has pointed out how BSD and Linux have required a > workaround compared to Solaris and OS X (in Java and IIRC, the > Go runtime). Seems like we have a number of usecases and this > is something worth fixing. I would like to know how a general purpose high level language like Java can avoid all the races that I brought up w/o locking the fd and, as you basicly said earlier, w/o the threads cooperating... To me it doesn't seem possible... Now if someone could explain it, I'd love to be proved wrong as it'd improve my knowlege of concurent systems... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."