From owner-freebsd-arch@FreeBSD.ORG Sun Nov 16 23:15:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72B2BCA8 for ; Sun, 16 Nov 2014 23:15:36 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51FF78B2 for ; Sun, 16 Nov 2014 23:15:35 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1B91E193964 for ; Sun, 16 Nov 2014 23:15:35 +0000 (UTC) Subject: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-C7v6HDBKpNCYvEOmQBzc" Date: Sun, 16 Nov 2014 15:15:33 -0800 Message-ID: <1416179733.1098.1200.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 23:15:36 -0000 --=-C7v6HDBKpNCYvEOmQBzc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and CC=3D/nxb-bin/usr/bin/cc Yet, while monitoring, I still see the ports build process using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 I don't see this on armv6 when building in a jail + qemu. I'm trying to understand what is missing from our gcc toolchain here that is causing the builds to ignore my directives. sean --=-C7v6HDBKpNCYvEOmQBzc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUaTAUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k95YH/3U8z7aGL6hPCd3jqAK5QKMG VbxqFGymLq4f4R0LolD9eohINTP4A2yzGgsoz0QjeY47uU0Xew5AqJIhwPTFc9uE 84gnToFldjJAHpe1UMsEVfDW+jklK4OOYHJeLAysLSNp4VWXGa6QNCPaGDj1gTnW dwbFKuzd6Js7fd8D/iGUVU8ZNSEWyF3VrDDC1aWvFZvV6+KSo/xUZn/sjfmZwUKe Vvv0f9TceQA3q/XejmLOJOQEFyBACLavCXMK5XRx9gETfVTrvd+lM3zN5ZOh+2AY UPhB9nLWsV142/wtWv5YAG63l4pU4YGjGin579nl7HS4L+lSGMI8zbrE166rrso= =xajf -----END PGP SIGNATURE----- --=-C7v6HDBKpNCYvEOmQBzc-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 16 23:36:05 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A881C739; Sun, 16 Nov 2014 23:36:05 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7245CA91; Sun, 16 Nov 2014 23:36:05 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kq14so2104615pab.20 for ; Sun, 16 Nov 2014 15:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=McFk+VeP4UZ45MIdQolNE6vjxhjyzlsDn6WENoW6ijA=; b=rJuLRXIzQEOKlRky9S2releXJNOtrnWoZmE7XaAZlHmsC82FF8L2i6gBzfj+2lmdGB 1y6AMOhx7v1PEg0w6oXBIYXc//YHbdN9vLmMSQ4I9Pg5YKHSiTfQv4n46S7uTL4BJcM2 ZT+4janoWICpL19D1dcT+wn1ypZ/HGgaUmz1tmQGFMljh9MG2trppnJHbzbFCZtCdR31 bjdDteTAPCXKhK/d+XX/rt5/f/+GOvM12ORHGgzSgoyNcs9Z5whjZC9okpF4lT+Y9KZX FIWSYsCciqAkdylKS01zwS5guTr5noqjNyzc8GHQn5CCGN/BWe8a5MWmW3A4rKetOYel 6pUA== X-Received: by 10.70.43.176 with SMTP id x16mr25480198pdl.31.1416180964714; Sun, 16 Nov 2014 15:36:04 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id xn4sm13193767pab.9.2014.11.16.15.36.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 15:36:04 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2D6A05A7-0FCE-478C-AEF1-4D61DFF711C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Garrett Cooper In-Reply-To: <1416179733.1098.1200.camel@bruno> Date: Sun, 16 Nov 2014 15:36:03 -0800 Message-Id: <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> References: <1416179733.1098.1200.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 23:36:05 -0000 --Apple-Mail=_2D6A05A7-0FCE-478C-AEF1-4D61DFF711C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 16, 2014, at 15:15, Sean Bruno wrote: > I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and > CC=3D/nxb-bin/usr/bin/cc >=20 > Yet, while monitoring, I still see the ports build process > using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >=20 > I don't see this on armv6 when building in a jail + qemu. >=20 > I'm trying to understand what is missing from our gcc toolchain here > that is causing the builds to ignore my directives. It all kinds of boils down to this bug with the configuration of our = base system copy of gcc: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192394 . The prefixing/sysroot isn=92t being setup properly, which means that you = have to use $PATH to tell gcc and friends which tool you want to use = (which make buildworld, etc does). One way to fix this (if we used = autoconf in the base system build) would be to reconfigure it with a = particular sysroot: $ ./configure --help | grep -A 3 sysroot --with-build-sysroot=3Dsysroot use sysroot as the system root during the = build --with-sysroot=3DDIR Search for usr/lib, usr/include, et al, within = DIR. --with-gnu-ld assume the C compiler uses GNU ld default=3Dno --with-libiconv-prefix[=3DDIR] search for libiconv in DIR/include and = DIR/lib --without-libiconv-prefix don't search for libiconv in includedir = and libdir $ svn info configure | grep ^URL: URL: svn+ssh://ngie@svn.freebsd.org/base/head/contrib/gcc/configure I believe clang is smart enough to compile/link because it is setup to = grok multiple formats, but I=92ll defer to the clang team to = definitively state whether or not that=92s the case. Thanks! --Apple-Mail=_2D6A05A7-0FCE-478C-AEF1-4D61DFF711C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUaTTjAAoJEMZr5QU6S73eN/IH/izZ0W+aWsLOLrSZsLeFYRgA DLKnZ24aSynyStdPzowUaisET5G8T/Pd5ccN3C2AgtugpW3B77niLggj0JyTOowZ gowt4K0rg+1kmA7d/nuMQG84lkcanJ2nU/7PZMpDPGr7aYUzQMRih7TzBGdLkcPf TxAfh3wdqv60U8E7c3UMma964ASxuciSZqFvpViVZV8fNt6Lm9GcDRhDJVSIAzZ5 nuDXntD6JTVHppt93uKJdkRpBhW8rOios5hzTav+tdmCtYAqIWV2wpHoRSALkhjD nR4yoaLa1ADZL19cwgwZ0192s2eZ4EAZrVeH9eLWbWExoWNCmqnX36lxcv4cxxk= =ir13 -----END PGP SIGNATURE----- --Apple-Mail=_2D6A05A7-0FCE-478C-AEF1-4D61DFF711C5-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 16 23:42:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C355181F for ; Sun, 16 Nov 2014 23:42:56 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A09ABB58 for ; Sun, 16 Nov 2014 23:42:55 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id AFEA3193964; Sun, 16 Nov 2014 23:42:54 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Garrett Cooper In-Reply-To: <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> References: <1416179733.1098.1200.camel@bruno> <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-W3/JMude3f8dCFyi6TKF" Date: Sun, 16 Nov 2014 15:42:53 -0800 Message-ID: <1416181373.1098.1201.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 23:42:56 -0000 --=-W3/JMude3f8dCFyi6TKF Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable > It all kinds of boils down to this bug with the configuration of our base= system copy of gcc: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D19= 2394 . >=20 > The prefixing/sysroot isn=A2t being setup properly, which means that you = have to use $PATH to tell gcc and friends which tool you want to use (which= make buildworld, etc does). One way to fix this (if we used autoconf in th= e base system build) would be to reconfigure it with a particular sysroot: >=20 > $ ./configure --help | grep -A 3 sysroot > --with-build-sysroot=3Dsysroot > use sysroot as the system root during the build > --with-sysroot=3DDIR Search for usr/lib, usr/include, et al, within DIR= . > --with-gnu-ld assume the C compiler uses GNU ld default=3Dno > --with-libiconv-prefix[=3DDIR] search for libiconv in DIR/include and = DIR/lib > --without-libiconv-prefix don't search for libiconv in includedir a= nd libdir > $ svn info configure | grep ^URL: > URL: svn+ssh://ngie@svn.freebsd.org/base/head/contrib/gcc/configure >=20 > I believe clang is smart enough to compile/link because it is setup to gr= ok multiple formats, but I=A2ll defer to the clang team to definitively sta= te whether or not that=A2s the case. >=20 > Thanks! In my scenario, I'm using the native-xtools target, which may/may not be doing this? If you understand make-foo, can you look at the target and see if this is DTRT? sean --=-W3/JMude3f8dCFyi6TKF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUaTZ9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5knk0H/RckUKrgbzDcZB7S4PY9+Y3p ULmeUNPC2YsusB8iJTj4ymn5YLxG5jk84gsssNsTJA+8YWvXNis1VfQpAI2YQWv9 kTZZJkxqrLqdS3kuoaoXdH0u6GrloBbMXCL/hv0H1yOvarP8MaIJP5M3qBJPebDm 0ayWb4+38JZ8FlToVav9vHfSI0DdQRNUIE9LVKn60D6hdmPJpBiN7lc61doL6aoG auNsvFiNPnDSnTllluMmmg46emjYXxigRMpPmvA8+D/sMI/CuDMyITIdZtVY/SqW 8u7oR0vg1NNkA5KqCbLGYwlomQ1ZxDV8SdfOOyMeiKDfoxMrXkDU4+MIDIuTtX4= =AQnm -----END PGP SIGNATURE----- --=-W3/JMude3f8dCFyi6TKF-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 00:01:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3946919A for ; Mon, 17 Nov 2014 00:01:12 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06978CFC for ; Mon, 17 Nov 2014 00:01:11 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so20965699pab.36 for ; Sun, 16 Nov 2014 16:01:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=BpYAGtJFLb+ODUIcG3bjqWf/cN/YiP/+WeA4IPoQsAE=; b=Ysvphwom/oNUGusIE8EcC72NsdLS+IupN7zO7nrp6loAkB/v6ZcL7/THFXFuRFk71o 1IkWEk5ofNu6H8uEQ0y9GOPVSAPCsLKmz5InfiRu+klr3jQSj7Zlw+Y7XnBJR3iFptqz 1HzLYXW/ZT6L9zmzQ6Y3i61/BrXnsF6Xlap5yKvElSTpU1ftHBjBfj/P/sKAq6viHpYJ /D+ivSUTHkUNAd7XBGhB6wsrDLoRFBCwcMMU5OKC58HahUqElmxh87+HNpL0nyJ+94oe wSHOxqvtXk74SvvEIb54aa6mbQOwhdAAMynBgczxeSKXHwwPwDROOVmH7RdOnynyDWMz lgig== X-Gm-Message-State: ALoCoQn226oAoNRR+vERIU6UfcWqgI6bz+sUPuct91IbpkeKsa+7VvuU9Pa4iCBwwLj0UvfRr8K0 X-Received: by 10.70.126.194 with SMTP id na2mr26114083pdb.39.1416182471002; Sun, 16 Nov 2014 16:01:11 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id id2sm33237569pbb.65.2014.11.16.16.01.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 16:01:10 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_748C79DF-EEBB-4E94-A68F-3677CC817DEA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Warner Losh In-Reply-To: <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> Date: Sun, 16 Nov 2014 17:01:01 -0700 Message-Id: References: <1416179733.1098.1200.camel@bruno> <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1878.6) Cc: sbruno@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:01:12 -0000 --Apple-Mail=_748C79DF-EEBB-4E94-A68F-3677CC817DEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 16, 2014, at 4:36 PM, Garrett Cooper = wrote: > On Nov 16, 2014, at 15:15, Sean Bruno wrote: >=20 >> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and >> CC=3D/nxb-bin/usr/bin/cc >>=20 >> Yet, while monitoring, I still see the ports build process >> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >>=20 >> I don't see this on armv6 when building in a jail + qemu. >>=20 >> I'm trying to understand what is missing from our gcc toolchain here >> that is causing the builds to ignore my directives. >=20 > It all kinds of boils down to this bug with the configuration of our = base system copy of gcc: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192394 . I=92ve never seen this happen in the decade or so I=92ve been doing = cross builds. I=92ve seen gcc breakage, but always from stupid C or C++ = tricks, not from how we have things setup. > The prefixing/sysroot isn=92t being setup properly, which means that = you have to use $PATH to tell gcc and friends which tool you want to use = (which make buildworld, etc does). One way to fix this (if we used = autoconf in the base system build) would be to reconfigure it with a = particular sysroot: >=20 > $ ./configure --help | grep -A 3 sysroot > --with-build-sysroot=3Dsysroot > use sysroot as the system root during the = build > --with-sysroot=3DDIR Search for usr/lib, usr/include, et al, within = DIR. > --with-gnu-ld assume the C compiler uses GNU ld default=3Dno > --with-libiconv-prefix[=3DDIR] search for libiconv in DIR/include = and DIR/lib > --without-libiconv-prefix don't search for libiconv in includedir = and libdir > $ svn info configure | grep ^URL: > URL: svn+ssh://ngie@svn.freebsd.org/base/head/contrib/gcc/configure The native-xtools builds should be setup to use the right binaries. I = don=92t think this is sean=92s problem. Warner --Apple-Mail=_748C79DF-EEBB-4E94-A68F-3677CC817DEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUaTq+AAoJEGwc0Sh9sBEA8agQAIhc/TRjvQ8+uCU/bYipiRjz L1jhzW9J7as48Ob3N2nMS5CVrFY/GZ18i+Dq4JsBKHKGoo6C7e5ELMJ+ZRHjEEAb T1WVCTzYDTAwj3+6JDhcgynTYdpeb8BhZmckwceaSuKWRyQCpcmqdKbqva5dgix8 +X/u+hmRET9/fde3HZfINqDeeKB3wUsOZvT1dQMxn9VRYnx0H9lsrxhrc+Y5KyhH U4NYTY8FfPsjPYEaTaJ1+TevszvvtACc3cS/eT4Ocu7A9W9oGxtB8ximj9BpzlYA pOkjf3b56dlEuU4O9wMW+Ukhkb4i/z0CEReyRPaeZKc3LdY67MDpqXF+1ytBkZhc O52APjZ+ma1XiZ9ibnnvedvxLQVw+tE2S2u41PrDa6peOUWMTTVWD5IYOy9FeugN m9EBUMV9AB263KvzatM0ARfpj883ar+eDl8/4jhUMxoru/kCQU9EpayRB9xIbED6 aY4JTyu1r+CyRsvgynA+fSXFpBPrTJKu8YZW6qEn4sE8idwy8QEiwd/27Wo2V9T9 8b7cx3BTm0egBjzvgtp5MDbZc6KOwJ/erPZNZvddBmhjRpWXPqGtE5dP1n8ZKRDe EnD1TnqiOItonV0gpjPi6x12MeManSB9UhT2IwEUZkiJTOCsaLPFMnV4LWEJVC2l /UuaBj/haZz0NioPumt5 =L8ke -----END PGP SIGNATURE----- --Apple-Mail=_748C79DF-EEBB-4E94-A68F-3677CC817DEA-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 00:03:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 089983E6 for ; Mon, 17 Nov 2014 00:03:08 +0000 (UTC) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDA75D0D for ; Mon, 17 Nov 2014 00:03:07 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id z10so2725043pdj.26 for ; Sun, 16 Nov 2014 16:03:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0a5FeE7sG/nRoiDvWbPSBuoygj5tsefynpW4Y7X9/p0=; b=m2N9VjZm3BuUw54sg44syoXFMQRA62lr3cNIj64QGonZWP2xdUwYBebCXqVE72ew1w 3BINp0N8DVn7RMZsj2i2ugjFK9bAelWujoOWRq63xi9tVI0GVfF5GfSFiUbHoCeNkAYd TfIr3kCWRG1Gx8mAcj6lmYhfTTBvD8fM1VQInxeiOEXhLES9bBd3VbV9WpbgAZ3BBijZ fc9JO2owQZR8i3/NPb6hdphOEmiCQeRr44ZHrew2jxgJ4Oa5KA0ZbWH30Cwto72faIPK rHqmuAvj6gbXXw4FCsdduO/9S9t0Ukn59mc1U5JujmG9QZuCxy6D/KpXndjPZY5x8IK+ ovBQ== X-Gm-Message-State: ALoCoQnfTWBF1Lvc7bzaL2CCzeNJ1/x52ARymGmECyDFRCpf7jwLsStL3gPiMgaKDT5ZMcasrOtv X-Received: by 10.69.31.138 with SMTP id km10mr26174063pbd.6.1416182145547; Sun, 16 Nov 2014 15:55:45 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id ir2sm33244979pbc.57.2014.11.16.15.55.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 15:55:44 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_DC40AC5C-82E5-42E9-A118-1089F57F5147"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Warner Losh In-Reply-To: <1416179733.1098.1200.camel@bruno> Date: Sun, 16 Nov 2014 16:55:36 -0700 Message-Id: <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> References: <1416179733.1098.1200.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:03:08 -0000 --Apple-Mail=_DC40AC5C-82E5-42E9-A118-1089F57F5147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 16, 2014, at 4:15 PM, Sean Bruno wrote: > I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and > CC=3D/nxb-bin/usr/bin/cc >=20 > Yet, while monitoring, I still see the ports build process > using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >=20 > I don't see this on armv6 when building in a jail + qemu. >=20 > I'm trying to understand what is missing from our gcc toolchain here > that is causing the builds to ignore my directives. Let=92s start with the first question: How are you seeing this? Warner --Apple-Mail=_DC40AC5C-82E5-42E9-A118-1089F57F5147 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUaTl5AAoJEGwc0Sh9sBEAncYP/1HZmQtJQOGlYatFTvHqwJn+ A+e8m/viKag7wvrNyWXmbfqHaisGjN3zgZLlY0jv+zwrSRg+MA8ukq3nGF7XCUih 8fHku6XEK1v9t55Y+/TOWh3B3xw2OjPQDKY0gzVMbRs8TiGT3T7RNqaK2TFOjmZZ P8md+AWcHuTwD/7SHw2HjsYYPLcotgwzTaXNQegMlDF0UEnz6y8qTTmOIzMEWr9A K0h5gDaVOLSr6wIzD8HQL1cPsPdrGqU5XcY4ZJrGWWMAzmHeif0kObD+EtHcep0o ikuDiTzyvdXM8kprRsk62Y9MED08cZSi1GpA0rRvuVZUoBXQZWF2KWSOC+Xm5zJa KGzy7Li/YfryaxG4PAlo5/iAhu4/lwOteBijUQ4wNzAFqCQvg29RdY5n+jEuz4Is MRf26+ZHs3CptSaOFHRtnd6l5PuH/GOrN6tdsq1ENStLJLj02ks4vsbYmBqMhBJ4 EiHQ5OJs/G3lCdZFcl+XgwJS6ntW1AmFx8hF455NZYWjOxwxhuI+tzBRkNb7IOET z1Q3KpWVHYHfeuAhNfZe2qdS5yJdgdNqwHuHJIHhv6C+4xKzCJWApBunCiFA0kud PwjgMN670WmSeNnMAtNHlZljdIU+VhMwxoWqfn/0WlVcUaMdxHEbqnd0d74QtNd/ qmsqw7SfIpxPIUDwooGh =JywB -----END PGP SIGNATURE----- --Apple-Mail=_DC40AC5C-82E5-42E9-A118-1089F57F5147-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 00:10:57 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4A658BB for ; Mon, 17 Nov 2014 00:10:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2B61D54 for ; Mon, 17 Nov 2014 00:10:57 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 01E05193964; Mon, 17 Nov 2014 00:10:56 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Q6oPpeQSDDCg0/W7hJuS" Date: Sun, 16 Nov 2014 16:10:55 -0800 Message-ID: <1416183055.1098.1205.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:10:58 -0000 --=-Q6oPpeQSDDCg0/W7hJuS Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: > On Nov 16, 2014, at 4:15 PM, Sean Bruno wrote: >=20 > > I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and > > CC=3D/nxb-bin/usr/bin/cc > >=20 > > Yet, while monitoring, I still see the ports build process > > using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 > >=20 > > I don't see this on armv6 when building in a jail + qemu. > >=20 > > I'm trying to understand what is missing from our gcc toolchain here > > that is causing the builds to ignore my directives. >=20 > Let=A2s start with the first question: How are you seeing this? >=20 > Warner >=20 Setup a qemu-user enabled jail for mips based on head. Start poudriere building audio/speex (nice, short depend chain). While all this is running, I have a "ps auwxxx|grep qemu" running that catches some of the invocations of qemu that are happening. When running a mips jail I see the tool chain being invoked, partially, from /usr/bin instead of /nxb-bin/usr/bin. http://dpaste.com/12SD5TE This is just a primitive profile attempt on my part. This shows that qemu is being invoked *a lot* to get cc1 and as running via emulation. sean --=-Q6oPpeQSDDCg0/W7hJuS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUaT0PXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kUGYH+QG9lb5/LuRqmzKil/BDoZcL bG1T/Ow6obTzyGF1/jwYsNi2zT6E/v8bw8+xPZ3XKT0QW7i0b9+l5SUZ0/Bms5Xj 59wZ6xDHxwW1/ZpnG15vvwy6kkGOQw+5jt63cH5boXVGjcvrr7zwJWYuRopoj6Rp cKgBTmRLz+hw1DsuhYwV3kuK/QCDjDn/c7E10lRZx7VWJyWgpNplWBc20bcofttV ddRMBZzrCAhOop/ZqhAQHMFPU15O7kYLsKrj7Mu/ST79Y3Icjc+NA4eO/Zdbav3B 7tdzckABxLgD124+BlrviIKMlZxUK+uvl6LOhjuYBdksZl1Ch+INT5oC+Yce/LQ= =U2gh -----END PGP SIGNATURE----- --=-Q6oPpeQSDDCg0/W7hJuS-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 00:15:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE64ACD7 for ; Mon, 17 Nov 2014 00:15:33 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE8ABE10 for ; Mon, 17 Nov 2014 00:15:33 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kq14so2149400pab.34 for ; Sun, 16 Nov 2014 16:15:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dB7ycqj1Xf6atwtrhQ7Tbe/2ajnSW3hjkzSuBgchRE8=; b=DszMrUjsbpvd3CXLw1XPIgAZi+IVr1e80li0GzBDVvkFBZUgoxlGr56usmXi34LciB Z3sNo3g6q6gtLA3vHy8tQyz2Q8rWOTfTo34tb81mq4AkWK/jb8vhd4GdkW79bwZmXJLj YPUJiGM7vDb/hFZj7M2bWHGF4akAC0kuwPtU0s80gh/cN/wYmbZWWGNbUYjsul68PE3h hRwOf7f/derBdBRkskCKp4pA23D0n5zaB4HgfoyoXfxjSsK+phFc0tzFFwSMumtkydY6 bdKrobT65mU4cvQxeYVcnnqkaoPp2yYj2kLeqzEzxu97FK4/SMS6KS4V5lwrwTAih3bw Hhfw== X-Gm-Message-State: ALoCoQkGwPUwj2P5999l0dNvLGL/+kkvcYMWB+f9gIaO7ZTiYRHRRpeKwBJx5yR+LnHouIvBZHPN X-Received: by 10.66.191.135 with SMTP id gy7mr25748724pac.95.1416183327675; Sun, 16 Nov 2014 16:15:27 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id p2sm15683065pda.7.2014.11.16.16.15.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 16:15:27 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_8C41A38A-E961-436B-8FC9-C03DE57BFE0E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Warner Losh In-Reply-To: <1416183055.1098.1205.camel@bruno> Date: Sun, 16 Nov 2014 17:15:19 -0700 Message-Id: <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:15:34 -0000 --Apple-Mail=_8C41A38A-E961-436B-8FC9-C03DE57BFE0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On Nov 16, 2014, at 5:10 PM, Sean Bruno wrote: > On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: >> On Nov 16, 2014, at 4:15 PM, Sean Bruno = wrote: >>=20 >>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and >>> CC=3D/nxb-bin/usr/bin/cc >>>=20 >>> Yet, while monitoring, I still see the ports build process >>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >>>=20 >>> I don't see this on armv6 when building in a jail + qemu. >>>=20 >>> I'm trying to understand what is missing from our gcc toolchain here >>> that is causing the builds to ignore my directives. >>=20 >> Let=A2s start with the first question: How are you seeing this? >>=20 >> Warner >>=20 >=20 >=20 > Setup a qemu-user enabled jail for mips based on head. Start = poudriere > building audio/speex (nice, short depend chain). >=20 > While all this is running, I have a "ps auwxxx|grep qemu" running that > catches some of the invocations of qemu that are happening. When > running a mips jail I see the tool chain being invoked, partially, > from /usr/bin instead of /nxb-bin/usr/bin. >=20 > http://dpaste.com/12SD5TE >=20 > This is just a primitive profile attempt on my part. This shows that > qemu is being invoked *a lot* to get cc1 and as running via emulation. If you are building ports, chances are those settings won=A2t do what = you think they will. Do you have build logs I could look at? Warner --Apple-Mail=_8C41A38A-E961-436B-8FC9-C03DE57BFE0E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUaT4XAAoJEGwc0Sh9sBEAacwP/0UCJg+vP4BmLk9pvme9rx9Z PUeSC6kSTVVv3IKbZ9VqbcI3AVjGYxEkfSJpCxNm+s/ML1KV4YA598sHuFVAc/9v cJhtrSHWHe8wYKSasIDxD4MFSUt4djP2U4fcmQf4I4JV9ccuH91wd3/3iDdRWOmU zNX0JhVeqLowmYp3QYAkBVlAanKM1Xcm7Un7NO6pgEW4VaeVL0o+mgmldQrz/qTd O3bHz1HboPLpyAw58r9KgMA6gfMnDk3VQA+c6KeaONhzf3PXo+EVmdggco1Yryqj kT2qrFTDcvXxAPeKzS41tpb1eE/5HPJS55UCWek59Wfxnksk8tgRIB+whaNBDPcP UfA9BkmnDwIcNUtz8OUMLnBYwFn9+MFFttM+9Rsq/rQSQy3laVldbY5Wq7Yfi79Z e0vaAtGVY8+3CiT/u/ZTogY8bv2VyyetSo2MN6mCQFY5vze6sPf+HIOxUk1eYSSb 7KF3ibVtwNKEdF/WxFd0N6+qEHJs/vHN0PwyMchXr+vxE15wKsMMJ7u6VzGar4eY aZWM2jI0V9NsWKCcDlMrlfbQClTRP7skHj2TorsllJN4LJriT9uONR/vgbwRQGhh hL/cLIkl4fDv2iD5eGnMDb3xirL3gJXLpHtGohjB4oxNakk+yoeahFaLeGDK6lS4 +S+/sFrIItq3kreEMOZJ =PeTh -----END PGP SIGNATURE----- --Apple-Mail=_8C41A38A-E961-436B-8FC9-C03DE57BFE0E-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 00:17:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C59DF2C for ; Mon, 17 Nov 2014 00:17:06 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17BB5E2D for ; Mon, 17 Nov 2014 00:17:05 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 35680193964; Mon, 17 Nov 2014 00:17:05 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OnPw+aZAChXd5rHo6+zN" Date: Sun, 16 Nov 2014 16:17:03 -0800 Message-ID: <1416183423.1098.1206.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:17:06 -0000 --=-OnPw+aZAChXd5rHo6+zN Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable On Sun, 2014-11-16 at 17:15 -0700, Warner Losh wrote: > On Nov 16, 2014, at 5:10 PM, Sean Bruno wrote: >=20 > > On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: > >> On Nov 16, 2014, at 4:15 PM, Sean Bruno wrote= : > >>=20 > >>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and > >>> CC=3D/nxb-bin/usr/bin/cc > >>>=20 > >>> Yet, while monitoring, I still see the ports build process > >>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 > >>>=20 > >>> I don't see this on armv6 when building in a jail + qemu. > >>>=20 > >>> I'm trying to understand what is missing from our gcc toolchain here > >>> that is causing the builds to ignore my directives. > >>=20 > >> Let=A2s start with the first question: How are you seeing this? > >>=20 > >> Warner > >>=20 > >=20 > >=20 > > Setup a qemu-user enabled jail for mips based on head. Start poudriere > > building audio/speex (nice, short depend chain). > >=20 > > While all this is running, I have a "ps auwxxx|grep qemu" running that > > catches some of the invocations of qemu that are happening. When > > running a mips jail I see the tool chain being invoked, partially, > > from /usr/bin instead of /nxb-bin/usr/bin. > >=20 > > http://dpaste.com/12SD5TE > >=20 > > This is just a primitive profile attempt on my part. This shows that > > qemu is being invoked *a lot* to get cc1 and as running via emulation. >=20 > If you are building ports, chances are those settings won=A2t do what you= think they will. Do you have build logs I could look at? >=20 > Warner Last attempt was here: http://crack.ysv.freebsd.org/build.html?mastername=3D11-mips-test-11-mips-t= est&build=3D2014-10-29_14h04m18s sean --=-OnPw+aZAChXd5rHo6+zN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUaT5/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5knmoIAJ1ywXsiQl1MlQTeTyg9QRW7 zq3VOizfbVw4Xj8ldGfaBbJjDtQqngB5aDrbbwqlTZz5/ifAe63V5szPysfkURB+ TAy1E0d96OZk9pch/U5OIjIFms8O6NhEJ1FyIZ5dEAg7kZB0Uf8EZrdPtqM0KUY/ 2sA2RgkBUFe+oa3SdTayTq3RTjtXLSAiGXwPyS3HhU6wSUwLVdCYfCwQamolTNJt e5PC62WINjLZDfgdKILp/zKsJ4NsQv2fsXY9lnVlS3O8SmQ4YYtz10YtBQA20IUT d+NOzkTGwyQRO9RzDEKuE60eXxlVtomiYsynSmWWep9TfsYAZ606/w3RQMTC2b8= =FN19 -----END PGP SIGNATURE----- --=-OnPw+aZAChXd5rHo6+zN-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 02:58:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1510B271 for ; Mon, 17 Nov 2014 02:58:28 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E62DFE10 for ; Mon, 17 Nov 2014 02:58:27 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7E728193964; Mon, 17 Nov 2014 02:58:26 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AUfuMhfzoDlt9zZq1TMY" Date: Sun, 16 Nov 2014 18:58:24 -0800 Message-ID: <1416193104.1098.1207.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 02:58:28 -0000 --=-AUfuMhfzoDlt9zZq1TMY Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable On Sun, 2014-11-16 at 17:15 -0700, Warner Losh wrote: > On Nov 16, 2014, at 5:10 PM, Sean Bruno wrote: >=20 > > On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: > >> On Nov 16, 2014, at 4:15 PM, Sean Bruno wrote= : > >>=20 > >>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and > >>> CC=3D/nxb-bin/usr/bin/cc > >>>=20 > >>> Yet, while monitoring, I still see the ports build process > >>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 > >>>=20 > >>> I don't see this on armv6 when building in a jail + qemu. > >>>=20 > >>> I'm trying to understand what is missing from our gcc toolchain here > >>> that is causing the builds to ignore my directives. > >>=20 > >> Let=A2s start with the first question: How are you seeing this? > >>=20 > >> Warner > >>=20 > >=20 > >=20 > > Setup a qemu-user enabled jail for mips based on head. Start poudriere > > building audio/speex (nice, short depend chain). > >=20 > > While all this is running, I have a "ps auwxxx|grep qemu" running that > > catches some of the invocations of qemu that are happening. When > > running a mips jail I see the tool chain being invoked, partially, > > from /usr/bin instead of /nxb-bin/usr/bin. > >=20 > > http://dpaste.com/12SD5TE > >=20 > > This is just a primitive profile attempt on my part. This shows that > > qemu is being invoked *a lot* to get cc1 and as running via emulation. >=20 > If you are building ports, chances are those settings won=A2t do what you= think they will. Do you have build logs I could look at? >=20 > Warner More verbose output, not super useful. Except that the configure output shows that /nxb-bin/usr/bin/cc wants to use /usr/bin/ld ... I think this means we're not setting up the build flags for gcc correctly? http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37m39s= /logs/speex-1.2.r1_7,1.log sean --=-AUfuMhfzoDlt9zZq1TMY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUaWRQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kpjIH/Ri5dzjsLnuqpQdo9L/lIqDQ j7Ys/WVgZVkrSdoZ1+OqBe+EJJ2XH5TyzJ4bmyke0XpT6gTZiTCr4EBA6cweV2l4 ACXcMZ53pD8pNmYVH+niESBiI/e7kf89ZuTbhacmX3uDzsuAVGlxPyQLYyfkFg/h wzvSQhLQA39qffV19t3orQVP8WzbH1nY3sRAl71YWf+ozZamZBjte+gixcMKCoGn 5VzaqCtd7sHNgH1LQqxpDVK1FebGSuWPiv9N/+lxGeDfhewyDQIIwxISZ155Gzc7 FEzT2keBxQLemWUhRE2wzj12P2bSyykLhp/jNAlkEmrkx0ja1u0A0CRgE6ekxbc= =f2Rp -----END PGP SIGNATURE----- --=-AUfuMhfzoDlt9zZq1TMY-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 07:46:35 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E49A8FC9; Mon, 17 Nov 2014 07:46:34 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DEE9C62; Mon, 17 Nov 2014 07:46:34 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id 10so15204176lbg.7 for ; Sun, 16 Nov 2014 23:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4D2Q1NBEuceahcHQqKbIR7QdoXqzHuxlVhcNZsXbwiQ=; b=zVDesiR8Pp86l8ArcFpf/Ha9qmNOJSTHAgYtrRwxqj+QBdWCqtgtChXfXyKoO4E41V Hr1CHXtRFK0CkXiV/KW2iO7tTHZntcGQ1njy4ubYWYRcv9MOAXsJa/QtfWICOwOwLupj pz2T8778wGGjaX7GtJWCtBFfHUReXomDqqeakAz6fxMINLd2gWnyTYJFJpIjTxDc/OnT DKI+KbB0K+1f8cfO/5BluFz7Kz84TOHS8Dls9rNN9+FwLDvdPQG9ZppSj1hcJVWPReQw 0pxTgELge3VhWtCSDjX25OpWyqN6Kf9TdUfVPYNO/W60JoOS4tU7Hd51CMxEjfWSjHUv M+kw== MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr1410596lbc.98.1416210392299; Sun, 16 Nov 2014 23:46:32 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sun, 16 Nov 2014 23:46:32 -0800 (PST) Date: Sun, 16 Nov 2014 23:46:32 -0800 X-Google-Sender-Auth: 7fMsckax5obPRoH-ujZxjGQN9sg Message-ID: Subject: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: freebsd-arch , FreeBSD Net , "freebsd-virtualization@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 07:46:35 -0000 Hi, PROPOSAL ========== I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH ====== Index: sys/conf/NOTES =================================================================== --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +options VIMAGE +options VNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS ======== (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly "wishmaster" have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN =========== (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? Thanks. -- Craig From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 10:52:43 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEE83774 for ; Mon, 17 Nov 2014 10:52:43 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B27C1C4 for ; Mon, 17 Nov 2014 10:52:43 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so7258529pad.29 for ; Mon, 17 Nov 2014 02:52:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8bhg6n5X6fesgjx7UXlu97Bw/dCCjvVZ3ZD7LwM5eHo=; b=JZFFioN3HWw4Y8hNNlgxF4XnNac4LAolFZinjOizBg/2Z0exGWCaVvS/lyQtrZrBfa GUxY8JrRALkpkCNJMsSrux3M0YXG/yNqBQT1rGe3XfcEdkUEbkyRek7mhVlsQU3ZW/cC 2Ymf0UJ0EApUJ7f4E5La71iC2reW3sqAloEreI4dsvKRkftaBIj8bh/0az2fJGGy4+lU cj2fzCdIucsopTl+ZkWCyYIwIzIV9d8TMTsYkc1K8hreGvzu9h2N82n1eR4XfPHpI3jG YjKXqyiITUluWBye9k9bx/Ud7AMK+Nh172A2reBt3bX6Dp1Ue4GohmQhI7BElKBNqAKc gvwQ== X-Gm-Message-State: ALoCoQlpOWXhgtPsPVMb1/hVisOd8Miu+GHchIimy7MwFpM51UHIn6tyAGbliw/nRIXs4eZDar3X X-Received: by 10.70.45.233 with SMTP id q9mr28994074pdm.24.1416221562692; Mon, 17 Nov 2014 02:52:42 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id w5sm34834043pds.25.2014.11.17.02.52.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 02:52:41 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_B3F433B6-AB72-4EB3-82CE-CC64D3C9492C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Warner Losh In-Reply-To: <1416193104.1098.1207.camel@bruno> Date: Mon, 17 Nov 2014 03:52:33 -0700 Message-Id: References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 10:52:43 -0000 --Apple-Mail=_B3F433B6-AB72-4EB3-82CE-CC64D3C9492C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1253 On Nov 16, 2014, at 7:58 PM, Sean Bruno wrote: > On Sun, 2014-11-16 at 17:15 -0700, Warner Losh wrote: >> On Nov 16, 2014, at 5:10 PM, Sean Bruno = wrote: >>=20 >>> On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: >>>> On Nov 16, 2014, at 4:15 PM, Sean Bruno = wrote: >>>>=20 >>>>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and >>>>> CC=3D/nxb-bin/usr/bin/cc >>>>>=20 >>>>> Yet, while monitoring, I still see the ports build process >>>>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >>>>>=20 >>>>> I don't see this on armv6 when building in a jail + qemu. >>>>>=20 >>>>> I'm trying to understand what is missing from our gcc toolchain = here >>>>> that is causing the builds to ignore my directives. >>>>=20 >>>> Let=92s start with the first question: How are you seeing this? >>>>=20 >>>> Warner >>>>=20 >>>=20 >>>=20 >>> Setup a qemu-user enabled jail for mips based on head. Start = poudriere >>> building audio/speex (nice, short depend chain). >>>=20 >>> While all this is running, I have a "ps auwxxx|grep qemu" running = that >>> catches some of the invocations of qemu that are happening. When >>> running a mips jail I see the tool chain being invoked, partially, >>> from /usr/bin instead of /nxb-bin/usr/bin. >>>=20 >>> http://dpaste.com/12SD5TE >>>=20 >>> This is just a primitive profile attempt on my part. This shows = that >>> qemu is being invoked *a lot* to get cc1 and as running via = emulation. >>=20 >> If you are building ports, chances are those settings won=92t do what = you think they will. Do you have build logs I could look at? >>=20 >> Warner >=20 >=20 > More verbose output, not super useful. Except that the configure = output > shows that /nxb-bin/usr/bin/cc wants to use /usr/bin/ld ... I think = this > means we're not setting up the build flags for gcc correctly? >=20 > = http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37m39= s/logs/speex-1.2.r1_7,1.log Perhaps. But when I wrote those targets, I assumed they=92d replace the = target-native binaries with host-native binaries, now that I think about = it, rather than live in a side directory. You=92d need to make CC be = something more like CC=3D$PATH/usr/bin/cc -B$PATH/lib/exec or some such. Is there a good reason to not replace the binaries? I noticed you = keeping them separate, but wasn=92t sure if that was just a =93well, = that=92s what the target does=94 thing or a =93I had to do it because X=94= thing. Warner --Apple-Mail=_B3F433B6-AB72-4EB3-82CE-CC64D3C9492C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUadNxAAoJEGwc0Sh9sBEA9a4P/iEdibt8dPpNkEW/YTxsiApj g8dx25DC7PEy7hZsFN3TCYHsi6cXrS/su8G4DW3/wCB1o4TBPiNYCwbem2R+610J mazJVGZ4vG6P9R21GhmlaJyH0ih95HLOnZuLErDWQ1MYXRQzzfalWejSm2duswFN 7HB2aJGrQ5mNSRhyveyxkC75Y4387o63HQHHDjIriFISxJFDpektL/wzMcOd01Ds anUakexFQfdzyUDKRN4mOhFqFYjK1eQ/+TvGnSRVLgAFJf9jBxED6SZcQo8TA1OV O7wtdtDe3KnPa06McMo7iCZ8AYLXDMmT2d+7e2CtLxDTR4qck7+iYQuLflwqNXhK YwamsBwlmq7uKfLk7FPeviYuba01+AmRzgoDVTeWE0WvAlyDc3fmKYh3aCKHs6sC l6SDMYbD8FXTSQnURvWkXGSxheFu1W9YT2dNqMWKtxYky87/OT0OrS6koYTwuqE1 ChSNf9Qo6owvXI5u5kWrZ2E0icQfsAxdFoxNAmyEgJcX+5W2rgBGe9940Z0Q/18f 3LEMl8xKicMXJn4wSlA3KUh7hTkTJKUI7TyK0nlhpuwPIPmRkrVy1onno29T7P4B 3AiTdnG0B8wjXczvvdfruN2Jqhc65Lylz4bLjFjqRB9ih+DgvkDLbq6IANdwXLF+ bdZ94/VPc11YnNd2jW/N =iNcH -----END PGP SIGNATURE----- --Apple-Mail=_B3F433B6-AB72-4EB3-82CE-CC64D3C9492C-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 11:02:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5C54960 for ; Mon, 17 Nov 2014 11:02:50 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7366B315 for ; Mon, 17 Nov 2014 11:02:50 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id p10so1676532pdj.39 for ; Mon, 17 Nov 2014 03:02:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LoaI3nAt93fTZvdmmEn2YhsbR0P0/uMmmTNQfu/MLWw=; b=FNGRnJYyr2izP5AhOPGqND1ndJhLnahOypuEyoHBiyNhWPVRp5BdhCfDryzlVPpe+S 7m+d+j7f806JAlJwRq0guF8p4brUXNqKrPW6pl9EnT8/+RbTXbU5RafCsDlg/YxleDR9 /+jb2ZU/9iMkIZ3/CAp2pgiLqAoY6NPRZlffzoQobzoGl9opANWSZhm96ijjwQ+D5mP7 mw+z/hyaxq3rrrCUqaTRM6NOK52/FqJ+9cL0qgoO5IUlCb70GLE9gilBc9rwqpo7S/UY /DbQ3/cqsjLPUyyLrFcur9SvicQEWTmlHlp+n8U9Pdz3D0kbboSicI9JOonFVZ6Vy8go uKOg== X-Gm-Message-State: ALoCoQmun3ORZNJ7i2a97q0jXfYSyIJdn2K8p9RDEvIoZefbT1TSUBR6nvs8CuBA7EYVuoyNSD/n X-Received: by 10.70.63.9 with SMTP id c9mr29020132pds.104.1416222169244; Mon, 17 Nov 2014 03:02:49 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id h1sm34979301pat.6.2014.11.17.03.02.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 03:02:48 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Warner Losh In-Reply-To: Date: Mon, 17 Nov 2014 04:02:38 -0700 Message-Id: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 11:02:50 -0000 --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 17, 2014, at 12:46 AM, Craig Rodrigues = wrote: > Hi, >=20 > PROPOSAL > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I would like to get feedback on the following proposal. > In the head branch (CURRENT), I would like to enable > VIMAGE with this commit: >=20 >=20 > PATCH > =3D=3D=3D=3D=3D=3D >=20 > Index: sys/conf/NOTES > =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/conf/NOTES (revision 274300) > +++ sys/conf/NOTES (working copy) > @@ -784,8 +784,8 @@ > device mn # Munich32x/Falc54 Nx64kbit/sec cards. >=20 > # Network stack virtualization. > -#options VIMAGE > -#options VNET_DEBUG # debug for VIMAGE > +options VIMAGE > +options VNET_DEBUG # debug for VIMAGE >=20 > # > # Network interfaces: >=20 >=20 >=20 > I would like to enable VIMAGE for the following reasons: >=20 > REASONS > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > (1) VIMAGE cannot be enabled off to the side in a separate library or > kernel module. When enabled, it is a kernel ABI incompatible = change. > This has impact on 3rd party code such as the kernel modules > which come with VirtualBox. > So the time to do it in CURRENT is now, otherwise we can't = consider > doing it until FreeBSD-12 timeframe, which is quite a while = away. >=20 > (2) VIMAGE is used in some 3rd party products, such as FreeNAS. > These 3rd party products are mostly happy with VIMAGE, > but sometimes they encounter problems, and FreeBSD doesn't > see these problems because it is disabled by default. >=20 > (3) Most of the major subsystems like ipfw and pf have been fixed for > VIMAGE, and the only > way to shake out the last few issues is to make it the default = and > get feedback from the community. ipfilter still needs to be > VIMAGE-ified. >=20 >=20 > (4) Not everyone uses bhyve. FreeBSD jails are an excellent = virtualization > platform for FreeBSD. Jails are still very popular and > performant. VIMAGE makes jails even better by allowing per-jail > network stacks. >=20 > (5) Olivier Cochard-Labbe has provided good network performance = results > in VIMAGE vs. non-VIMAGE kernels: >=20 >=20 > = https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >=20 > (6) Certain people like Vitaly "wishmaster" have = been > running VIMAGE > jails in a production environment for quite a while, and would = like > to see it > be the default. >=20 >=20 > ACTION PLAN > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > (1) Coordinate/communicate with portmgr, since this has kernel ABI > implications >=20 > (2) Work with clusteradm@, and try to get a test instance of one of = the > PF firewalls in the cluster working with a VIMAGE enabled = kernel. >=20 > (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO > and > = https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=3Dvimage%20or%20= vnet > and try to clean things up. Get help from net@ developers to = do > this. And if these don=92t get cleaned up? > (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help = from > the ipfilter maintainers for this and some net@ developers. And if this doesn=92t happen? > (5) Enable VIMAGE by default in CURRENT on January 5, 2015. > This will *not* be enabled in STABLE. >=20 > What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I = don=92t see that in the action plan. Without it, we=92re enabling an = option that has know, serious issue making 11 potentially a more = unstable release. Warner --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUadXPAAoJEGwc0Sh9sBEAvYAP/iwf6hIRHekLe0WOXLKpmJJG 5Do3lUbWaKSsUMPQUVhrZCEqaktFvNl3KXREGz3vIYir6/VKUD9pHm2aKWHaH4Dh ug7BwaGnX0F+Lrs+ztE09oqkMM2e/IRYPlpXFtBkfYssSEPTVekWu5nyCeJ2/bfC fyobYns+3PvpfoLSo9NZolDT5FwwuireoAJcpQ8XDXzdRd94IQOxoXw3OZSI+uig yP076NgBxe0hfVsREUU4NoPEsmWX5EW9RXO4PcucnvoovPsUj5eGECIinpeKr+70 k9+qyhZfvuUg1bgwy33Xn+r1mVj7BYpLb2RLERfsf5C154r0ULAEzkszo16T+B8x e+JajoSRxQtjpw7VQtZLKmLzJk1xfKbndL1bKEmmq3BNyOU6U8lsb1cbQ/WamxBp SbRlx/h9viK9xIyZ0lpqtkvn5zeTSHTG6BTQMdI4e5t02lmsNB3kSE3ioMyCCNSI 5UOlDPRolosCWfyswWkLA47JE54x938SQdRcSSDXhxCCTeXRXMlyNTH0MtQKx1Ui vfINNqg95ohsLjtfdFvGKpJNTJ7t0glvtnkusNvcZc/45aO0n3s4wN8qIo+J10WA kryjtn2OyaeBL2x961vE91r3OBBH+s6RcywbLH4gfA3Lu+ACP7hI93CunwXDO80D vItyld7BvOsjk+e7pdkA =NjCp -----END PGP SIGNATURE----- --Apple-Mail=_F38375C2-112A-4E06-9440-FCEC35A46B7E-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 11:20:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00847E4A; Mon, 17 Nov 2014 11:20:21 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C2B7640; Mon, 17 Nov 2014 11:20:21 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 22EF3153408; Mon, 17 Nov 2014 12:20:13 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfIreQrOjHzi; Mon, 17 Nov 2014 12:20:01 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4226E153416; Mon, 17 Nov 2014 12:20:01 +0100 (CET) Message-ID: <5469D9E1.2060400@digiware.nl> Date: Mon, 17 Nov 2014 12:20:01 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> In-Reply-To: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 11:20:22 -0000 On 17-11-2014 12:02, Warner Losh wrote: > > On Nov 17, 2014, at 12:46 AM, Craig Rodrigues > wrote: > >> Hi, >> >> PROPOSAL ========== I would like to get feedback on the following >> proposal. In the head branch (CURRENT), I would like to enable >> VIMAGE with this commit: >> >> >> PATCH ====== >> >> Index: sys/conf/NOTES >> =================================================================== >> >> --- sys/conf/NOTES (revision 274300) >> +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device >> mn # Munich32x/Falc54 Nx64kbit/sec cards. >> >> # Network stack virtualization. -#options VIMAGE -#options >> VNET_DEBUG # debug for VIMAGE +options VIMAGE +options >> VNET_DEBUG # debug for VIMAGE >> >> # # Network interfaces: >> >> >> >> I would like to enable VIMAGE for the following reasons: >> >> REASONS ======== >> >> (1) VIMAGE cannot be enabled off to the side in a separate library >> or kernel module. When enabled, it is a kernel ABI incompatible >> change. This has impact on 3rd party code such as the kernel >> modules which come with VirtualBox. So the time to do it in CURRENT >> is now, otherwise we can't consider doing it until FreeBSD-12 >> timeframe, which is quite a while away. >> >> (2) VIMAGE is used in some 3rd party products, such as FreeNAS. >> These 3rd party products are mostly happy with VIMAGE, but >> sometimes they encounter problems, and FreeBSD doesn't see these >> problems because it is disabled by default. >> >> (3) Most of the major subsystems like ipfw and pf have been fixed >> for VIMAGE, and the only way to shake out the last few issues is to >> make it the default and get feedback from the community. ipfilter >> still needs to be VIMAGE-ified. >> >> >> (4) Not everyone uses bhyve. FreeBSD jails are an excellent >> virtualization platform for FreeBSD. Jails are still very popular >> and performant. VIMAGE makes jails even better by allowing >> per-jail network stacks. >> >> (5) Olivier Cochard-Labbe has provided good network performance >> results in VIMAGE vs. non-VIMAGE kernels: >> >> >> https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >> >> >> (6) Certain people like Vitaly "wishmaster" have been >> running VIMAGE jails in a production environment for quite a while, >> and would like to see it be the default. >> >> >> ACTION PLAN =========== >> >> (1) Coordinate/communicate with portmgr, since this has kernel >> ABI implications >> >> (2) Work with clusteradm@, and try to get a test instance of one >> of the PF firewalls in the cluster working with a VIMAGE enabled >> kernel. >> >> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and >> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet >> >> and try to clean things up. Get help from net@ developers to do >> this. > > And if these don’t get cleaned up? > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help >> from the ipfilter maintainers for this and some net@ developers. > > And if this doesn’t happen? > >> (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This >> will *not* be enabled in STABLE. >> >> What do people think? > > How do you plan to address the problems seen by FreeNAS in #2 above? > I don’t see that in the action plan. Without it, we’re enabling an > option that has know, serious issue making 11 potentially a more > unstable release. Hi Warner, I think I understand your critique, but then on the other hand I wonder where the reluctance is.... As I read it, things are going to be enabled in CURRENT only (for the time). Which is exactly for the reasons you worry about: Is it going to be reliable enough?? But for that it needs exposure... So I would expect it to be turned off as a default IF things are not in a stable state that warrants a default enabling of the options. Things need to move forward, and taking this step is going to be required.. Otherwise I see a big risk of bit-rot somewhere down in the dungeons. --Willem Jan From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 11:43:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5506A9D8; Mon, 17 Nov 2014 11:43:02 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 078F7961; Mon, 17 Nov 2014 11:43:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3928125D388C; Mon, 17 Nov 2014 11:42:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C81F6C770D8; Mon, 17 Nov 2014 11:42:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id noVUGNh3OCde; Mon, 17 Nov 2014 11:42:53 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 17AE1C77042; Mon, 17 Nov 2014 11:42:47 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: <5469D9E1.2060400@digiware.nl> Date: Mon, 17 Nov 2014 11:42:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 11:43:02 -0000 On 17 Nov 2014, at 11:20 , Willem Jan Withagen wrote: > I think I understand your critique, but then on the other hand I = wonder > where the reluctance is.... As I read it, things are going to be = enabled > in CURRENT only (for the time). Which is exactly for the reasons you > worry about: Is it going to be reliable enough?? No, the answer to that still is =93no=94 in it=92s current state and we = know that. I think one of the main problems is that no one has been able to pull = the thing to the end in the last three years. Why should it happen within 6 = weeks now? I think it would be a really good idea to do that but the current TODO = list, I think, is by far not sufficing. There=92s a second problem we=92ll hit in that same timeframe: general = network stack breakage; we=92ll hit the times when we=92ll not be sure if = things broke because of VIMAGE or are also broken in the normal network stack. = There=92ll be a lot of regression test writing and debugging to be done. That all said, I=92d like to see it happen as well, but I=92d love to = have a lot of the issues being addressed first before putting a date on it to = enable it in GENERIC in HEAD. /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 12:20:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB8053F9; Mon, 17 Nov 2014 12:20:18 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91BC9CED; Mon, 17 Nov 2014 12:20:18 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so3794260pdb.0 for ; Mon, 17 Nov 2014 04:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c8x9u3CyLCK2VvNSWu71vDi7wnfxMZLbZuM6EAhJdpI=; b=yQb9Ed2tqjZWbDvNJAVk7dCiLwBUY5YcJinZfHSRCwE5zHqfPV9wLyfJKnCvv9hcUd hvnFkZqhryUhu1uJdfzJw+mDwiDyiASxtYh7wsXWQSgTIqfRGZwSAdEl+f+YiY5Dwf6E IuZULtqEBd8rM+aB4uy81V6+hoodSuK8Ihhz+kg0FX4CVmdHwf7ZegF3xSB1AMYstI7i invFKvr9b0QWcjUDzmJ3bl6Cm0wQVuPFMDpIYG+YjHiefgWLjJUzFo5xvGuNMax1kfoH RQ4vVWnp47+MW4J9oglGwPD5T3bOhGbif2Nh73rIcuOZyTAtgadGUuGvIBFKp52spwPI aXjw== X-Received: by 10.66.157.39 with SMTP id wj7mr4175358pab.117.1416226818100; Mon, 17 Nov 2014 04:20:18 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id c4sm35025868pdh.53.2014.11.17.04.20.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 04:20:17 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_637AA305-32A8-474A-B2DA-8FDD364A94F8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Garrett Cooper In-Reply-To: <1416193104.1098.1207.camel@bruno> Date: Mon, 17 Nov 2014 04:20:15 -0800 Message-Id: <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 12:20:18 -0000 --Apple-Mail=_637AA305-32A8-474A-B2DA-8FDD364A94F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1253 On Nov 16, 2014, at 18:58, Sean Bruno wrote: > On Sun, 2014-11-16 at 17:15 -0700, Warner Losh wrote: >> On Nov 16, 2014, at 5:10 PM, Sean Bruno = wrote: >>=20 >>> On Sun, 2014-11-16 at 16:55 -0700, Warner Losh wrote: >>>> On Nov 16, 2014, at 4:15 PM, Sean Bruno = wrote: >>>>=20 >>>>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and >>>>> CC=3D/nxb-bin/usr/bin/cc >>>>>=20 >>>>> Yet, while monitoring, I still see the ports build process >>>>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >>>>>=20 >>>>> I don't see this on armv6 when building in a jail + qemu. >>>>>=20 >>>>> I'm trying to understand what is missing from our gcc toolchain = here >>>>> that is causing the builds to ignore my directives. >>>>=20 >>>> Let=92s start with the first question: How are you seeing this? >>>>=20 >>>> Warner >>>>=20 >>>=20 >>>=20 >>> Setup a qemu-user enabled jail for mips based on head. Start = poudriere >>> building audio/speex (nice, short depend chain). >>>=20 >>> While all this is running, I have a "ps auwxxx|grep qemu" running = that >>> catches some of the invocations of qemu that are happening. When >>> running a mips jail I see the tool chain being invoked, partially, >>> from /usr/bin instead of /nxb-bin/usr/bin. >>>=20 >>> http://dpaste.com/12SD5TE >>>=20 >>> This is just a primitive profile attempt on my part. This shows = that >>> qemu is being invoked *a lot* to get cc1 and as running via = emulation. >>=20 >> If you are building ports, chances are those settings won=92t do what = you think they will. Do you have build logs I could look at? >=20 > More verbose output, not super useful. Except that the configure = output > shows that /nxb-bin/usr/bin/cc wants to use /usr/bin/ld ... I think = this > means we're not setting up the build flags for gcc correctly? >=20 > = http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37m39= s/logs/speex-1.2.r1_7,1.log That=92s my guess too, based on the configure output from libffi. ... "LD=3D/usr/bin/ld" "NM=3D/usr/bin/nm -B" "RANLIB=3Dranlib=94 ... The easiest path forward would be to set TOOLS_PREFIX in Makefile.inc1 = to an appropriate prefix (see XMAKE in Makefile.inc1, etc). I suspect if = you add this variable to NXBENV and tweak it appropriately, things will = just work. Cheers! --Apple-Mail=_637AA305-32A8-474A-B2DA-8FDD364A94F8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUaef/AAoJEMZr5QU6S73eGYgH/2eyIcc5PxKBmgHrGUV8elA8 3Rs8YXXr12WyAnj9aQV+fjB+AeLJLZXbykov4wjg6r++YASVsxbGaSSY7lpoSGuc 3T0WIyTqAunikNRNzlY5arJ80BnyIO19Nf1ZNwJNImPCUvWJ8uIKF9ATPXR12Bkm lIqCxkwM0VJH8JDMILlrpTCY47/HNCyIiwnyzbf/sesde1JaVMYxJtsKopTjv2le GsZOfrAsA3j/8xgCspYbS5bJa9QdhZ6mNb80tK+mmwwptdLJRBhA11+NyjcLEpnH S9K63Aa9rxior2g/V1X55KW9US4kwWyhOgxHwy6CTS8voVpUsoKcsyxatDOoxHE= =6pmp -----END PGP SIGNATURE----- --Apple-Mail=_637AA305-32A8-474A-B2DA-8FDD364A94F8-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 12:27:32 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2A7B5AB; Mon, 17 Nov 2014 12:27:31 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9E2BD28; Mon, 17 Nov 2014 12:27:31 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so3803604pdb.0 for ; Mon, 17 Nov 2014 04:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q2HZkvTvXX8FOVg48t6ruDkhBDTYyz7H9MWIwlGzXjc=; b=Hr1KLhFT/ci01bh0XYFis3IfNmj9F836y5A37WY5ybTPes4+WUPQGqw164B2WxgQ5F 3IEG5o0JzgdvnqpNNoyS3QgdHzyLxIuZVQJSb/GWKSll5u/JI4VNy9aSWBGVfsHYIP2s fu1R/aSnexvWhtIHCIffg+87Bv3RKxVdstn4ysYbSVrrI/ivGYxlNybKkojo7ZbYmDTQ GFKc+sgulVN+EjgpTbj6W0Lst77rsRwIQYF/Qq7xjdjdgD/+mmhlT8jGcDdqAEjU9dYS +DuEQehE3hB2byl1yeAOFgvalVUyeOb4mcdGX6Wp8fIbNpLUnCzlCbvGnOCrP0QnNWBX SQaA== X-Received: by 10.68.68.226 with SMTP id z2mr28916091pbt.107.1416227251320; Mon, 17 Nov 2014 04:27:31 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:59da:de8a:308b:f2b? ([2601:8:ab80:7d6:59da:de8a:308b:f2b]) by mx.google.com with ESMTPSA id hy15sm8849902pad.11.2014.11.17.04.27.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 04:27:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_65506A37-AD99-4E0A-B0FA-F9D4E31046A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Garrett Cooper In-Reply-To: Date: Mon, 17 Nov 2014 04:27:29 -0800 Message-Id: <25214F2D-5B60-480E-906C-EDE19F2CE3AB@gmail.com> References: <1416179733.1098.1200.camel@bruno> <735BCED8-EBC1-4B65-AA34-1866ECDF3070@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Cc: sbruno@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 12:27:32 -0000 --Apple-Mail=_65506A37-AD99-4E0A-B0FA-F9D4E31046A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 16, 2014, at 16:01, Warner Losh wrote: > On Nov 16, 2014, at 4:36 PM, Garrett Cooper = wrote: >=20 >> On Nov 16, 2014, at 15:15, Sean Bruno wrote: >>=20 >>> I have set make.conf to use AS=3D/nxb-bin/usr/bin/as and >>> CC=3D/nxb-bin/usr/bin/cc >>>=20 >>> Yet, while monitoring, I still see the ports build process >>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1 >>>=20 >>> I don't see this on armv6 when building in a jail + qemu. >>>=20 >>> I'm trying to understand what is missing from our gcc toolchain here >>> that is causing the builds to ignore my directives. >>=20 >> It all kinds of boils down to this bug with the configuration of our = base system copy of gcc: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192394 . >=20 > I=92ve never seen this happen in the decade or so I=92ve been doing = cross builds. I=92ve seen gcc breakage, but always from stupid C or C++ = tricks, not from how we have things setup. There are a lot of nifty features in the binutils/gcc configuration that = we don=92t tweak, for better or for worse. -sysroot is one item (that I = brought up before), but it=92s not Sean=92s problem. Still, it needs to = be fixed because we still ship gcc today on the tier-2/-3 platforms and = I=92ve hit bugs in the past where it picks up the wrong headers with = gcc, but not clang. >> The prefixing/sysroot isn=92t being setup properly, which means that = you have to use $PATH to tell gcc and friends which tool you want to use = (which make buildworld, etc does). One way to fix this (if we used = autoconf in the base system build) would be to reconfigure it with a = particular sysroot: >>=20 >> $ ./configure --help | grep -A 3 sysroot >> --with-build-sysroot=3Dsysroot >> use sysroot as the system root during the = build >> --with-sysroot=3DDIR Search for usr/lib, usr/include, et al, within = DIR. >> --with-gnu-ld assume the C compiler uses GNU ld default=3Dno >> --with-libiconv-prefix[=3DDIR] search for libiconv in DIR/include = and DIR/lib >> --without-libiconv-prefix don't search for libiconv in includedir = and libdir >> $ svn info configure | grep ^URL: >> URL: svn+ssh://ngie@svn.freebsd.org/base/head/contrib/gcc/configure >=20 > The native-xtools builds should be setup to use the right binaries. I = don=92t think this is sean=92s problem. Correct (as I noted in my later reply). The thing is that we override = PREFIX with binutils/gcc and there aren=92t really any blatant comments = in the source code pointing out why things are being done that way. You = have to use svn blame and svn log to find the right commit that = describes the feature. Cheers! ------------------------------------------------------------------------ r55220 | obrien | 1999-12-29 06:42:46 -0800 (Wed, 29 Dec 1999) | 6 lines Allow the specification of a prefix for gcc to find all the various = bits. If one wishes to anchor the compiler toolchain tree somewhere other than = /, all one needs to do is set "TOOLS_PREFIX" to a different rooting. Submitted by: marcel (in a different format and reworked by me) --Apple-Mail=_65506A37-AD99-4E0A-B0FA-F9D4E31046A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUaemxAAoJEMZr5QU6S73eU10H/0TRgoBA4hRLI2MMFOPd+gKD QZNd22P3XqyMJPOQblfP5BQEs3+bZoe5CiA1lsV7D/axV8P1ArqyJokYhq0fLy/0 vSq/GlMvHn5gLihF3+MvqZqs1so130DJJpGAmN64MRRAtg0cshjbFR/vM+8Yh4/O KUxk1OgQhkfMqwmE/WYj0QJrOYrEXVapTGZ+3WzDgFOczfwZKkvk83hLcZFARV1X r4IsJHMKrZR6NqrVQSqnxOPr1b0D6Vq6kCZ9Z5A6K8afhHU86z/cydgY7IsmTgt2 0lpfM/UJRxSFbn4+nJwU65YHBM2Bn10ijXvQkg4elt7pEjUp9mYYXr5+05w8bo0= =yNCT -----END PGP SIGNATURE----- --Apple-Mail=_65506A37-AD99-4E0A-B0FA-F9D4E31046A7-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 12:42:51 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C932B87; Mon, 17 Nov 2014 12:42:51 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 916F1EFF; Mon, 17 Nov 2014 12:42:50 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A6FBC153448; Mon, 17 Nov 2014 13:42:46 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh6hyyq0wydl; Mon, 17 Nov 2014 13:42:37 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 9A4C4153413; Mon, 17 Nov 2014 13:42:37 +0100 (CET) Message-ID: <5469ED3D.2060307@digiware.nl> Date: Mon, 17 Nov 2014 13:42:37 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 12:42:51 -0000 On 17-11-2014 12:42, Bjoern A. Zeeb wrote: > On 17 Nov 2014, at 11:20 , Willem Jan Withagen wrote: > >> I think I understand your critique, but then on the other hand I wonder >> where the reluctance is.... As I read it, things are going to be enabled >> in CURRENT only (for the time). Which is exactly for the reasons you >> worry about: Is it going to be reliable enough?? > > No, the answer to that still is “no” in it’s current state and we know that. > > I think one of the main problems is that no one has been able to pull the > thing to the end in the last three years. Why should it happen within 6 weeks now? > > I think it would be a really good idea to do that but the current TODO list, > I think, is by far not sufficing. > > There’s a second problem we’ll hit in that same timeframe: general network > stack breakage; we’ll hit the times when we’ll not be sure if things broke > because of VIMAGE or are also broken in the normal network stack. There’ll > be a lot of regression test writing and debugging to be done. > > > That all said, I’d like to see it happen as well, but I’d love to have a lot > of the issues being addressed first before putting a date on it to enable > it in GENERIC in HEAD. Hi Bjoern, The constraints as you put them are indeed rather tight. There is little to be done about it. I was not aware of the fact that 11.0 is planned for release in such short time. Somewhere in the back op my head is: planning is start release cycle around Q2 2015. And I took the liberty to add some testing & QA time to that, so I expect it after summer holidays in 2015. Now I admit: I don't write code for this, nor do I have the knowledge to so. But do run CURRENT to test exactly all these visualization options... Have not (yet) found a requirement to put VIMAGE to good use, so I never switched it on. The down side of all this, is that if we cannot turn it on during the 11-STABLE lifetime. Then it is going to take a full version release cycle to make it to the front. Which I find a pity, since it misses the opportunity for FreeBSD to add another distinctive element to their visualization possibilities. I prefer not to take this into a debate about the way things should go. Over time I've seen too many of these discussions turn in to shouting wars/bikesheds/and what not.... So given the fact I'm not going to do it, I'll leave the rest of the discussion to those that are actual doing all the work... (for which already 20 year of thanks) --WjW From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 15:37:19 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED9E8CC5; Mon, 17 Nov 2014 15:37:19 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA91485E; Mon, 17 Nov 2014 15:37:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id BE9C5A982; Mon, 17 Nov 2014 15:37:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 07A301B9C; Mon, 17 Nov 2014 16:37:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Willem Jan Withagen Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> <5469ED3D.2060307@digiware.nl> Date: Mon, 17 Nov 2014 16:37:17 +0100 In-Reply-To: <5469ED3D.2060307@digiware.nl> (Willem Jan Withagen's message of "Mon, 17 Nov 2014 13:42:37 +0100") Message-ID: <86lhn96doy.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Craig Rodrigues , "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@freebsd.org" , FreeBSD Net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 15:37:20 -0000 Willem Jan Withagen writes: > The constraints as you put them are indeed rather tight. There is little > to be done about it. I was not aware of the fact that 11.0 is planned > for release in such short time. It isn't. ISTR that the target is 2015Q4. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 17:25:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7B06A7A for ; Mon, 17 Nov 2014 17:25:47 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3403982 for ; Mon, 17 Nov 2014 17:25:47 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7BA83193964; Mon, 17 Nov 2014 17:25:46 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-A1K7Yq7WJd8qyZQElHBC" Date: Mon, 17 Nov 2014 09:25:45 -0800 Message-ID: <1416245145.1248.4.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 17:25:47 -0000 --=-A1K7Yq7WJd8qyZQElHBC Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable > >> If you are building ports, chances are those settings won=FFt do what = you think they will. Do you have build logs I could look at? > >>=20 > >> Warner > >=20 > >=20 > > More verbose output, not super useful. Except that the configure outpu= t > > shows that /nxb-bin/usr/bin/cc wants to use /usr/bin/ld ... I think thi= s > > means we're not setting up the build flags for gcc correctly? > >=20 > > http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37= m39s/logs/speex-1.2.r1_7,1.log >=20 > Perhaps. But when I wrote those targets, I assumed they=FFd replace the t= arget-native binaries with host-native binaries, now that I think about it,= rather than live in a side directory. You=FFd need to make CC be something= more like CC=3D$PATH/usr/bin/cc -B$PATH/lib/exec or some such. >=20 > Is there a good reason to not replace the binaries? I noticed you keeping= them separate, but wasn=FFt sure if that was just a =B4well, that=FFs what= the target does=A1 thing or a =B4I had to do it because X=A1 thing. >=20 > Warner Currently, there is no reason I don't just replace the ld/as/cc and friends in the jail with the ones from the target. I was only keeping them seperate out of a desire to make the jail "feel" cleaner. I've already violated this by hardlinking a bunch of files in the jail with my latest updates to poudriere. Frankly, there's just no way to corral all of the various scripts and tools in all of our ports tree to play nice without burning ports to the ground and doing a rearchitecture pass. sean --=-A1K7Yq7WJd8qyZQElHBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUai+ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kQl0IAI4h9cfMQ35x3kLIWiW/rEe0 uG/y1TuzKTLsDwc3e/uxQwb0MKhsXgXKTEkBc0teXAFCcppiWicb0/1vIo4jYSE5 1caC4q4Xxp2YFR8P+9hoPEGTJSqZpBTQ6KAjXBWu8hwGXkiFEFNMRmVUhqtyoHfJ rZKgAfdqo+O1o+t3C4ICjvIR+bacAKULmDjzwtESYz0fDhL1pdMEjmj8xEtvFuM5 rTq5011MKvo7GOrhUtAcXjvCsH9aITJBUUqq1e0dqndJ9bPb8S5SJNlgsRdmnLOs KVoyS/aIbvNy8TSs7pRmURlV/0Epz+dpB045eHaYhOGkGmqsXay255G5q7e/QGM= =ft6d -----END PGP SIGNATURE----- --=-A1K7Yq7WJd8qyZQElHBC-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 17:47:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8DFAF99; Mon, 17 Nov 2014 17:47:53 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 9D325B9E; Mon, 17 Nov 2014 17:47:53 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 177B7341F872; Mon, 17 Nov 2014 09:47:53 -0800 (PST) Message-ID: <546A34C8.6060004@freebsd.org> Date: Mon, 17 Nov 2014 09:47:52 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> In-Reply-To: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 17:47:53 -0000 On 11/17/14, 3:02 AM, Warner Losh wrote: > On Nov 17, 2014, at 12:46 AM, Craig Rodrigues wrote: > >> Hi, >> >> PROPOSAL >> ========== >> I would like to get feedback on the following proposal. >> In the head branch (CURRENT), I would like to enable >> VIMAGE with this commit: >> >> >> PATCH >> ====== >> >> Index: sys/conf/NOTES >> =================================================================== >> --- sys/conf/NOTES (revision 274300) >> +++ sys/conf/NOTES (working copy) >> @@ -784,8 +784,8 @@ >> device mn # Munich32x/Falc54 Nx64kbit/sec cards. >> >> # Network stack virtualization. >> -#options VIMAGE >> -#options VNET_DEBUG # debug for VIMAGE >> +options VIMAGE >> +options VNET_DEBUG # debug for VIMAGE >> >> # >> # Network interfaces: >> >> >> >> I would like to enable VIMAGE for the following reasons: >> >> REASONS >> ======== >> >> (1) VIMAGE cannot be enabled off to the side in a separate library or >> kernel module. When enabled, it is a kernel ABI incompatible change. >> This has impact on 3rd party code such as the kernel modules >> which come with VirtualBox. >> So the time to do it in CURRENT is now, otherwise we can't consider >> doing it until FreeBSD-12 timeframe, which is quite a while away. >> >> (2) VIMAGE is used in some 3rd party products, such as FreeNAS. >> These 3rd party products are mostly happy with VIMAGE, >> but sometimes they encounter problems, and FreeBSD doesn't >> see these problems because it is disabled by default. >> >> (3) Most of the major subsystems like ipfw and pf have been fixed for >> VIMAGE, and the only >> way to shake out the last few issues is to make it the default and >> get feedback from the community. ipfilter still needs to be >> VIMAGE-ified. >> >> >> (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization >> platform for FreeBSD. Jails are still very popular and >> performant. VIMAGE makes jails even better by allowing per-jail >> network stacks. >> >> (5) Olivier Cochard-Labbe has provided good network performance results >> in VIMAGE vs. non-VIMAGE kernels: >> >> >> https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html >> >> (6) Certain people like Vitaly "wishmaster" have been >> running VIMAGE >> jails in a production environment for quite a while, and would like >> to see it >> be the default. >> >> >> ACTION PLAN >> =========== >> >> (1) Coordinate/communicate with portmgr, since this has kernel ABI >> implications >> >> (2) Work with clusteradm@, and try to get a test instance of one of the >> PF firewalls in the cluster working with a VIMAGE enabled kernel. >> >> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >> and >> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet >> and try to clean things up. Get help from net@ developers to do >> this. > And if these don’t get cleaned up? If they are not cleaned/stable up by 11-RELEASE then we turn it off. That is simple. > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >> the ipfilter maintainers for this and some net@ developers. > And if this doesn’t happen? Well we do have 2 other firewalls in the kernel to pick, but we do need VIMAGE so I will let you draw your own conclusions. -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 17:56:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1076368 for ; Mon, 17 Nov 2014 17:56:02 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 765A3C83 for ; Mon, 17 Nov 2014 17:56:02 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 52AF5193964; Mon, 17 Nov 2014 17:56:01 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: Garrett Cooper In-Reply-To: <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Qqt28R7ILJyt1cOGHUfk" Date: Mon, 17 Nov 2014 09:56:00 -0800 Message-ID: <1416246960.1248.22.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 17:56:02 -0000 --=-Qqt28R7ILJyt1cOGHUfk Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable > > http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37= m39s/logs/speex-1.2.r1_7,1.log >=20 > That=FFs my guess too, based on the configure output from libffi. >=20 > ... > "LD=3D/usr/bin/ld" "NM=3D/usr/bin/nm -B" "RANLIB=3Dranlib=A1 > ... >=20 > The easiest path forward would be to set TOOLS_PREFIX in Makefile.inc1 to= an appropriate prefix (see XMAKE in Makefile.inc1, etc). I suspect if you = add this variable to NXBENV and tweak it appropriately, things will just wo= rk. >=20 > Cheers! This does indeed point gcc to the right tool chain. However, it immediately fails as it cannot find a crt1.o in /nxb-bin ... as we don't want to use an amd64 version we want to use the jail crt1.o sean configure:3154: result: /nxb-bin/usr/bin/cc configure:3383: checking for C compiler version configure:3392: /nxb-bin/usr/bin/cc --version >&5 cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3403: $? =3D 0 configure:3392: /nxb-bin/usr/bin/cc -v >&5 Using built-in specs. Target: mips-undermydesk-freebsd Configured with: FreeBSD/mips system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] configure:3403: $? =3D 0 configure:3392: /nxb-bin/usr/bin/cc -V >&5 cc: '-V' option must have argument configure:3403: $? =3D 1 configure:3392: /nxb-bin/usr/bin/cc -qversion >&5 cc: unrecognized option '-qversion' cc: No input files specified configure:3403: $? =3D 1 configure:3423: checking whether the C compiler works configure:3445: /nxb-bin/usr/bin/cc -O2 -pipe -fno-strict-aliasing conftest.c >&5 /nxb-bin/usr/bin/ld: crt1.o: No such file: No such file or directory configure:3449: $? =3D 1 configure:3487: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "pkg" | #define PACKAGE_TARNAME "pkg" | #define PACKAGE_VERSION "1.3.8" | #define PACKAGE_STRING "pkg 1.3.8" | #define PACKAGE_BUGREPORT "https://github.com/freebsd/pkg" | #define PACKAGE_URL "" | #define PACKAGE "pkg" | #define VERSION "1.3.8" | /* end confdefs.h. */ |=20 | int | main () | { |=20 | ; | return 0; | } configure:3492: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8': configure:3495: error: C compiler cannot create executables See `config.log' for more details --=-Qqt28R7ILJyt1cOGHUfk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUajawXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kar4H/R6xa3H/LYb9aaLhhHLRQhKB 1nw+1Eb6V3eqLoQ/wvQsji9eUxfkNiiHssvv6czedeubN4M0VFIHR85X1cUV5cmu HjX+iwZkeHopJFiUS+GXTOC9U6ED7LYvUHxO9ACx/RwBVfV/LojRhP2DLQI9L44Z S9M7xqfrnlb0GBfMM8HCZj94wWqWwnp/AAsgo1qBdvnzvEMGFe9gBReamjLws50x y8XIIVUrkV4esCYpfEbD2qnz7/PYg8Q+yCCOq1p49R3qnawmEtOjeoXIjORgIJPC ldCX1WC0S+Gioh5S8ytBx1RGGfVs3ib4RhoRJhUJ1XMfyJt7hrlaq0hpJFkB1G4= =TGGi -----END PGP SIGNATURE----- --=-Qqt28R7ILJyt1cOGHUfk-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 18:09:30 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D41E07D6; Mon, 17 Nov 2014 18:09:30 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D03FDC9; Mon, 17 Nov 2014 18:09:30 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id fp1so5460902pdb.29 for ; Mon, 17 Nov 2014 10:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=f6m0HQ21ELSMX8BIAXsufY/tOglrAYvrU0y4pPNMM80=; b=ZD+RkG2z7doRori3sKjwr2tZFPU7sAjdTDwIhegV3zs6RI9HE9750bRb+zUD4AjfZ0 P4gefA/GcDAif9exPo1fzov2LI8PKIkvIDwgRJe0RvQ6+ozt1Lpoh+rVNpt1Tf3/fIWM B54gf7bRjZ9oKr1+yNFv5+JAzXGDfJNLxfxRmONnNfncKt6xL1pGfKWQ5lybCxqHxKPD TRYWtHQplYhDeGebzXhdS6MgdEGnlHDTQfkb1r3gr3XKUXVMSHBy/BBloGO/DteZAgNJ sztRuhuCrMr+l4ZqmtIev4z54RRb4xJvQzFf2WUubxFGGfjH8/k7X2+l+K32wAmr1eDH ysWg== X-Received: by 10.66.90.230 with SMTP id bz6mr5466526pab.125.1416247770188; Mon, 17 Nov 2014 10:09:30 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:b50c:fbb5:98df:415b? ([2601:8:ab80:7d6:b50c:fbb5:98df:415b]) by mx.google.com with ESMTPSA id qh4sm35638567pbb.35.2014.11.17.10.09.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 10:09:29 -0800 (PST) References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> <1416246960.1248.22.camel@bruno> Mime-Version: 1.0 (1.0) In-Reply-To: <1416246960.1248.22.camel@bruno> Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: mips misbehaving, not respecting make.conf Date: Mon, 17 Nov 2014 10:09:27 -0800 To: "sbruno@freebsd.org" Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 18:09:30 -0000 > On Nov 17, 2014, at 09:56, Sean Bruno wrote: >=20 >>> http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37m= 39s/logs/speex-1.2.r1_7,1.log >>=20 >> That=81Ls my guess too, based on the configure output from libffi. >>=20 >> ... >> "LD=3D/usr/bin/ld" "NM=3D/usr/bin/nm -B" "RANLIB=3Dranlib=81h >> ... >>=20 >> The easiest path forward would be to set TOOLS_PREFIX in Makefile.inc1 to= an appropriate prefix (see XMAKE in Makefile.inc1, etc). I suspect if you a= dd this variable to NXBENV and tweak it appropriately, things will just work= . >>=20 >> Cheers! >=20 >=20 > This does indeed point gcc to the right tool chain. However, it > immediately fails as it cannot find a crt1.o in /nxb-bin ... as we don't > want to use an amd64 version we want to use the jail crt1.o *plays sad trombone* Yeah, there are probably some other components like that and libgcc that nee= d appropriate pathing ;/. I'll need to dig around gnu/ to see whether or not= that's possible.= From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 20:57:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E39DABA4; Mon, 17 Nov 2014 20:57:10 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F220392; Mon, 17 Nov 2014 20:57:10 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id DFFD9153416; Mon, 17 Nov 2014 21:57:05 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFBhL4hyRQjE; Mon, 17 Nov 2014 21:57:04 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2] (unknown [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPS id B4137153413; Mon, 17 Nov 2014 21:57:04 +0100 (CET) References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <5469D9E1.2060400@digiware.nl> <5469ED3D.2060307@digiware.nl> <86lhn96doy.fsf@nine.des.no> In-Reply-To: <86lhn96doy.fsf@nine.des.no> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <17C50DD9-B155-478C-B5E1-61F0A01616EC@digiware.nl> X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: RFC: Enabling VIMAGE in GENERIC Date: Mon, 17 Nov 2014 21:57:12 +0100 To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Craig Rodrigues , "Bjoern A. Zeeb" , freebsd-arch , "freebsd-virtualization@freebsd.org" , FreeBSD Net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 20:57:11 -0000 Op 17 nov. 2014 om 16:37 heeft Dag-Erling Sm=C3=B8rgrav het vol= gende geschreven: > Willem Jan Withagen writes: >> The constraints as you put them are indeed rather tight. There is little >> to be done about it. I was not aware of the fact that 11.0 is planned >> for release in such short time. >=20 > It isn't. ISTR that the target is 2015Q4. >=20 So even further in the future than what I expected. But still, somebody(tm) needs to do the actual work. So they get the say. --WjW= From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 21:47:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E6A296 for ; Mon, 17 Nov 2014 21:47:02 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3C43B37 for ; Mon, 17 Nov 2014 21:47:02 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id rd3so9469549pab.21 for ; Mon, 17 Nov 2014 13:46:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DJ44Th3m1tifZgp1uFsb5NZ70AMCHuqpz+MZQSt3+wQ=; b=FazviUpMG2faP1Cs6YZXJt6puE9hbMFesNwANcxFUTFMI6yxq9RavSXBIK6YoISzIS 3qPdUc7hWSDEs/+VLulISdZqdpIKKNPuO7abfVb9MTW+7/4PhXuZ8takqKlsBiHOe/i0 uClndTlXYzlFPdQ74Si1EuMkRJ6evjEtpz8JmMqFHw4PTcBLMYKjHRL6k3EHfJuUUsHv zWZnqlvAhFJV8QmF/jSRhODsVvZqu+ZaZ5Qywl8QzmKAWJXOL2sKDrsVUuwNgQNeAxDy z2lqS0DLpvT5hl0w5tJE7dxd7vqWPAfvgI3PNiKYkAeqlxly/BOj/IZsbu9Xhn4AuK+D oNkA== X-Gm-Message-State: ALoCoQkZRv4GJsfL8gLAtCIqG+VrLggcZagsvV4MarDiKQ0SPGWr2hnqLRB8IOCOdTb/uCFgQW9D X-Received: by 10.68.57.225 with SMTP id l1mr11018910pbq.87.1416260815900; Mon, 17 Nov 2014 13:46:55 -0800 (PST) Received: from lgwl-achen.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id hc10sm11566283pbd.78.2014.11.17.13.46.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 13:46:55 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_202D21B5-08EE-450C-BC44-254A4ED15CA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips misbehaving, not respecting make.conf From: Warner Losh In-Reply-To: <1416246960.1248.22.camel@bruno> Date: Mon, 17 Nov 2014 14:46:43 -0700 Message-Id: References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> <1416246960.1248.22.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: Garrett Cooper , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 21:47:02 -0000 --Apple-Mail=_202D21B5-08EE-450C-BC44-254A4ED15CA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 17, 2014, at 10:56 AM, Sean Bruno wrote: >=20 >>> = http://crack.ysv.freebsd.org/data/11-mips-test-default/2014-11-17_02h37m39= s/logs/speex-1.2.r1_7,1.log >>=20 >> That=B4s my guess too, based on the configure output from libffi. >>=20 >> ... >> "LD=3D/usr/bin/ld" "NM=3D/usr/bin/nm -B" "RANLIB=3Dranlib=94 >> ... >>=20 >> The easiest path forward would be to set TOOLS_PREFIX in = Makefile.inc1 to an appropriate prefix (see XMAKE in Makefile.inc1, = etc). I suspect if you add this variable to NXBENV and tweak it = appropriately, things will just work. >>=20 >> Cheers! >=20 >=20 > This does indeed point gcc to the right tool chain. However, it > immediately fails as it cannot find a crt1.o in /nxb-bin ... as we = don't > want to use an amd64 version we want to use the jail crt1.o This is one of the many reasons I expected you to copy these binaries over the native ones rather than have them in a side tree. Warner > sean >=20 > configure:3154: result: /nxb-bin/usr/bin/cc > configure:3383: checking for C compiler version > configure:3392: /nxb-bin/usr/bin/cc --version >&5 > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. >=20 > configure:3403: $? =3D 0 > configure:3392: /nxb-bin/usr/bin/cc -v >&5 > Using built-in specs. > Target: mips-undermydesk-freebsd > Configured with: FreeBSD/mips system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > configure:3403: $? =3D 0 > configure:3392: /nxb-bin/usr/bin/cc -V >&5 > cc: '-V' option must have argument > configure:3403: $? =3D 1 > configure:3392: /nxb-bin/usr/bin/cc -qversion >&5 > cc: unrecognized option '-qversion' > cc: No input files specified > configure:3403: $? =3D 1 > configure:3423: checking whether the C compiler works > configure:3445: /nxb-bin/usr/bin/cc -O2 -pipe -fno-strict-aliasing > conftest.c >&5 > /nxb-bin/usr/bin/ld: crt1.o: No such file: No such file or directory > configure:3449: $? =3D 1 > configure:3487: result: no > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "pkg" > | #define PACKAGE_TARNAME "pkg" > | #define PACKAGE_VERSION "1.3.8" > | #define PACKAGE_STRING "pkg 1.3.8" > | #define PACKAGE_BUGREPORT "https://github.com/freebsd/pkg" > | #define PACKAGE_URL "" > | #define PACKAGE "pkg" > | #define VERSION "1.3.8" > | /* end confdefs.h. */ > |=20 > | int > | main () > | { > |=20 > | ; > | return 0; > | } > configure:3492: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8': > configure:3495: error: C compiler cannot create executables > See `config.log' for more details >=20 --Apple-Mail=_202D21B5-08EE-450C-BC44-254A4ED15CA7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUamzEAAoJEGwc0Sh9sBEAK1EQANL29dG1g+kJCdLjUacrv+d2 TsyQecEMgV5xEBkfawAG5iV7anvXPbG8oFMrY91xovFO2hFCTfWPhNf8lVg8i9AT L/l3r7I9W4N6z6TNPWq7fbbz9dmyeMDA0Sqn+GIWzECN2l7PeTOfxhNLbH+k7stP OdeaQDnJ0RMPp9QsUpo9iB4SCyQCZfLTi3ld5LjigSJQ0hV7YDFvyeWesmCRaAP4 PJCHqR3Fa+0S/dSX9U/X0KYzm2cbYIEEYrVa1vlfzyrfVH+iu7At2jw/7nw+TOfi jisdjDZ3hzwhFTxZKOHNQeh+YQFMUdv3Cf2XLUwQQWlCHlhQBy9pWyY1KD5aMKfp mYA11DMTfIFgqsw910qyBHqDwAn9TyojVwVaNK8sL7kHWbQ2pKSwQ63SSvz72MzT E++L9bf1tLeYbezqCoubNddtJIZPL9z6+aG5aPOASWWhvHsDWfjI5cNBcltcJaDg Qp8xyAs89gEm+Qq/0qn0LKMwT7s9K0r2Z2jvmhM+7qKetdMlouqyeuOCYjBVIki5 B1C3NPuUfI1qYY2S91REaCDJi8CJxEnXmWolFKne20c/4V6JNY28d1DppI8Quk6F uUUJJtNzkb12wAbp8PlCqvRXWRlBC/fPilUnpPB0x+W2WI4yq4HOfASie1Vaqe3X 9XB+Whj0nO2maOgdj8Ax =ATl/ -----END PGP SIGNATURE----- --Apple-Mail=_202D21B5-08EE-450C-BC44-254A4ED15CA7-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 17 23:15:30 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20709BDA; Mon, 17 Nov 2014 23:15:30 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 07380751; Mon, 17 Nov 2014 23:15:29 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 83FBD22140; Mon, 17 Nov 2014 15:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1416266129; x=1416280529; bh=6A6TxCCEqUd3RS+cQhEMBxWFrpb7mhGPJYjt7VkeGYA=; h=Date:From:Reply-To:To:CC:Subject; b=bz2nO15w7YUAwtEo3NsnX+BMD5asfrTDKrEBCDj0/KtwAGYJgALoPcojhKVu5u1Dk aWV9yr8h4D7N44KfjQxFKhpSj8z1WNzyvEq4SqK8jGtm91t6xowOg1fDpqPrgiwDK8 TtaQUrJsdkDyYaY+dYl4jLvbGY35kyDVn4nUHsc8= Message-ID: <546A8191.3090208@delphij.net> Date: Mon, 17 Nov 2014 15:15:29 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: "freebsd-arch@FreeBSD.org Arch" Subject: kernel linker: Overriding a driver shipped with kernel via module? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: re , huishao@microsoft.com, "weh@microsoft.com >> Wei Hu" , "Jun Fang \(Wicresoft\)" , kyliel@microsoft.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 23:15:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Right now one can declare version for a module by doing something like: MODULE_VERSION(module_name, module_version); Sometimes, it may be desirable for a vendor to release a new driver that overrides the driver shipped with the kernel itself. However, it seems that the MODULE_VERSION facility would just refuse the module when preloaded with kernel. Looking at some other vendor drivers, they are using a slightly different module name to overcome this limitation. Is that the only way to do it? Thanks in advance! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUaoGRAAoJEJW2GBstM+nsNF8QAK3iPIddWAsxVd49wuPvYh13 0Xn1pJOAQy5TqbPsqMUpdpGnfIhIX6fIfkxNeiZQdCHSBVePOHBn9kuhkosl6ENk xKzB7wT2bJOs/TOVV+EykmPU0/YfoTMnPL8EAeEuEs2S5QSBbcZX2axzsd8D0Bvp aKBgz5g5L4Bu5NNZ0k44x5Bp8lN22GXCD/13cy44AbW4IScPdZUQw19o3o7mnQvB 9h+4xUzArSqcGxbGdRNrBC+rSfo9uSyUk29FNWGsJo9/7FUygoU7YeU+6uTlaPfO nj7X3UDr+ed4WXyMMMnOlBG6lfmf03MEI57lVjJNrpkrcNQsfCBhvmupNStM9ouk fIVZGGLXIZLK848pUzDDuYTHsrC+fKPQYYVvsg3u3WOBNNQU2Kf59hmNY8EztaHw apd+XmUDh7IqP6xBxLt0f0Yc8T7oq4YYqVKd8kFJ8Illx+Fqj+tR7SMTkHkNHD9M /h5mZ8B5d0xN23n/uzljLibgIhLYTwRzuR4nMiO6yrKWuDKwORt75VMGTRIhrfm5 tE/vrcEgnNtmblzMh3JfSERYbP1H1n2h9r0S+8xunSJtpC/tB7hJ+X2wGN6zqLMR 7ENvOzE3gzE9KSA+XHv8SvwCLrcYvANeCl483zrnD+1YLFMZuvIzDVGe0WutamOn zMyoNwHMlf3cBl7rdtFF =j99P -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 18 12:45:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C834C92C; Tue, 18 Nov 2014 12:45:56 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AF3DF7F; Tue, 18 Nov 2014 12:45:56 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqiAC-000P0U-Jl; Tue, 18 Nov 2014 16:45:44 +0400 Date: Tue, 18 Nov 2014 16:45:44 +0400 From: Slawa Olhovchenkov To: d@delphij.net Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141118124544.GA95731@zxy.spb.ru> References: <546A8191.3090208@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A8191.3090208@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , "freebsd-arch@FreeBSD.org Arch" , re X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 12:45:56 -0000 On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > Right now one can declare version for a module by doing something like: > > MODULE_VERSION(module_name, module_version); > > Sometimes, it may be desirable for a vendor to release a new driver > that overrides the driver shipped with the kernel itself. However, it > seems that the MODULE_VERSION facility would just refuse the module > when preloaded with kernel. > > Looking at some other vendor drivers, they are using a slightly > different module name to overcome this limitation. Is that the only > way to do it? I think now time to move to modulated kernel and load all drivers currently present in GENERIC as modules (via loader.conf). From owner-freebsd-arch@FreeBSD.ORG Tue Nov 18 22:22:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D72AB28; Tue, 18 Nov 2014 22:22:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64271C99; Tue, 18 Nov 2014 22:22:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 41BE8B9B0; Tue, 18 Nov 2014 17:22:32 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: suspending threads before devices Date: Tue, 18 Nov 2014 17:21:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> In-Reply-To: <20141115180014.GK17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411181721.56505.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Nov 2014 17:22:32 -0500 (EST) Cc: Jung-uk Kim , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 22:22:33 -0000 On Saturday, November 15, 2014 1:00:15 pm Konstantin Belousov wrote: > On Sat, Nov 15, 2014 at 05:05:10PM +0200, Andriy Gapon wrote: > > On 15/11/2014 12:58, Konstantin Belousov wrote: > > > On Fri, Nov 14, 2014 at 11:10:45PM +0200, Andriy Gapon wrote: > > >> On 22/03/2012 16:14, Konstantin Belousov wrote: > > >>> I already noted this to Jung-uk, I think that current suspend handling > > >>> is (somewhat) wrong. We shall not stop other CPUs for suspension when > > >>> they are executing some random kernel code. Rather, CPUs should be safely > > >>> stopped at the kernel->user boundary, or at sleep point, or at designated > > >>> suspend point like idle loop. > > >>> > > >>> We already are engaged into somewhat doubtful actions like restoring of %cr2, > > >>> since we might, for instance, preemt page fault handler with suspend IPI. > > >> > > >> I recently revisited this issue in the context of some suspend+resume problems > > >> that I am having with radeonkms driver. What surprised me is that the driver's > > >> suspend code has no synchronization whatsoever with its other code paths. So, I > > >> looked first at the Linux code and then at the illumos code to see how suspend > > >> is implemented there. > > >> As far as I can see, those kernels do exactly what you suggest that we do. > > >> Before suspending devices they first suspend all threads except for one that > > >> initiates the suspend. For userland threads a signal-like mechanism is used to > > >> put them in a state similar to SIGSTOP-ed one. With the kernel threads > > >> mechanisms are different between the kernels. Also, illumos freezes kernel > > >> threads after suspending the devices, not before. > > >> > > >> I think that we could start with only the userland threads initially. Do you > > >> think the SIGSTOP-like approach would be hard to implement for us? > > > We have most, if not all, parts of the stopping code > > > already implemented. I mean the single-threading code, see > > > thread_single(SINGLE_BOUNDARY). The code ensures that other threads in > > > the current process are stopped either at the kernel->user boundary, or > > > at the safe kernel sleep point. > > > > > > This is not immediately applicable, since the caller is supposed to be > > > a thread in the suspended process, but modifications to allow external > > > process to do the same are really small comparing with the complexity > > > of the code. I suspect that all what is needed is change of > > > while/if (remaining != 1) > > > to > > > while/if ((p == curproc && remaining != 1) || > > > (p != curproc && remaining != 0)) > > > together with explicit passing of struct proc *p to thread_single. > > > > Thank you for the pointer! > > I think that maybe even more changes are required for that code to be usable for > > suspending. E.g. maybe a different p_flag bit should be used, because I think > > that we would like to avoid interaction between the process level suspend and > > the global suspend. I.e. the global suspend might encounter a multi-threaded > > process in a single thread mode and would need to suspend its remaining thread. > > Thread which is a p_singlethread, is not at the safe point; in other > words, a process which is under the singlethreading, should prevent > the system from entering sleep state. The singlethreading is the > temporal state anyway, it is established during exec() or exit(), so > it is fine to wait for in-process singlethreading to end before outer > singlethreading is done. > > Anyway, this requires real coding to experiment. I started looking at > it since I did somewhat related changes now. I would certainly like a way to quiesce threads before entering the real suspend path. I would also like to cleanly unmount filesystems during suspend as well and the thread issue is a prerequisite for that. However, reusing "stop at boundary" may not be quite correct because you probably don't want to block suspend because you have an NFS request that is retrying due to a down NFS server. For NFS I think you want any threads asleep to just not get a chance to run again until after resume completes. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:15:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09089F3; Wed, 19 Nov 2014 00:15:25 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B184C9E8; Wed, 19 Nov 2014 00:15:24 +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 sAJ0FBmg068410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2014 16:15:11 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAJ0FA2n068408; Tue, 18 Nov 2014 16:15:10 -0800 (PST) (envelope-from jmg) Date: Tue, 18 Nov 2014 16:15:10 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119001510.GM24601@funkthat.com> Mail-Followup-To: Slawa Olhovchenkov , d@delphij.net, "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang (Wicresoft)" , "freebsd-arch@FreeBSD.org Arch" , re References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141118124544.GA95731@zxy.spb.ru> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Tue, 18 Nov 2014 16:15:12 -0800 (PST) Cc: "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , re , "freebsd-arch@FreeBSD.org Arch" , d@delphij.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:15:25 -0000 Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > Right now one can declare version for a module by doing something like: > > > > MODULE_VERSION(module_name, module_version); > > > > Sometimes, it may be desirable for a vendor to release a new driver > > that overrides the driver shipped with the kernel itself. However, it > > seems that the MODULE_VERSION facility would just refuse the module > > when preloaded with kernel. > > > > Looking at some other vendor drivers, they are using a slightly > > different module name to overcome this limitation. Is that the only > > way to do it? > > I think now time to move to modulated kernel and load all drivers > currently present in GENERIC as modules (via loader.conf). This becomes slightly more difficult for storage drivers which must be loaded at boot time so the you can mount root from it... But yes, we are interested in methods to make it easier/more automatic for modules to be loaded to support the hardware that is present in a system... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:27:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E13A6888; Wed, 19 Nov 2014 00:27:25 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99EA0B24; Wed, 19 Nov 2014 00:27:25 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xqt78-000AXN-Qr; Wed, 19 Nov 2014 04:27:18 +0400 Date: Wed, 19 Nov 2014 04:27:18 +0400 From: Slawa Olhovchenkov To: d@delphij.net, "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang (Wicresoft)" , "freebsd-arch@FreeBSD.org Arch" , re Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119002718.GP9763@zxy.spb.ru> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141119001510.GM24601@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:27:26 -0000 On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > Right now one can declare version for a module by doing something like: > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > that overrides the driver shipped with the kernel itself. However, it > > > seems that the MODULE_VERSION facility would just refuse the module > > > when preloaded with kernel. > > > > > > Looking at some other vendor drivers, they are using a slightly > > > different module name to overcome this limitation. Is that the only > > > way to do it? > > > > I think now time to move to modulated kernel and load all drivers > > currently present in GENERIC as modules (via loader.conf). > > This becomes slightly more difficult for storage drivers which must > be loaded at boot time so the you can mount root from it... But yes, > we are interested in methods to make it easier/more automatic for > modules to be loaded to support the hardware that is present in a > system... When loader can load kernel -- loader can load driver module, this is not Linux (but yes, loader need plugable and stackable framework for access FS -- currenly booting from ZFS over gstripe not allowed). From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:36:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07C9AA24; Wed, 19 Nov 2014 00:36:46 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1B74C0E; Wed, 19 Nov 2014 00:36:45 +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 sAJ0aWPr068634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2014 16:36:33 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAJ0aWPt068633; Tue, 18 Nov 2014 16:36:32 -0800 (PST) (envelope-from jmg) Date: Tue, 18 Nov 2014 16:36:32 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119003632.GN24601@funkthat.com> Mail-Followup-To: Slawa Olhovchenkov , d@delphij.net, "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang (Wicresoft)" , "freebsd-arch@FreeBSD.org Arch" , re References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141119002718.GP9763@zxy.spb.ru> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Tue, 18 Nov 2014 16:36:33 -0800 (PST) Cc: "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , re , "freebsd-arch@FreeBSD.org Arch" , d@delphij.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:36:46 -0000 Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 +0400: > On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > > > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > > > Right now one can declare version for a module by doing something like: > > > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > > that overrides the driver shipped with the kernel itself. However, it > > > > seems that the MODULE_VERSION facility would just refuse the module > > > > when preloaded with kernel. > > > > > > > > Looking at some other vendor drivers, they are using a slightly > > > > different module name to overcome this limitation. Is that the only > > > > way to do it? > > > > > > I think now time to move to modulated kernel and load all drivers > > > currently present in GENERIC as modules (via loader.conf). > > > > This becomes slightly more difficult for storage drivers which must > > be loaded at boot time so the you can mount root from it... But yes, > > we are interested in methods to make it easier/more automatic for > > modules to be loaded to support the hardware that is present in a > > system... > > When loader can load kernel -- loader can load driver module, this is > not Linux (but yes, loader need plugable and stackable framework for > access FS -- currenly booting from ZFS over gstripe not allowed). That isn't the only issue.. another issue is identifing the correct kernel module(s) to load at boot... iirc, you cannot unload a kernel module loaded at boot time... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:46:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29FC3C8A; Wed, 19 Nov 2014 00:46:14 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D60B2CEC; Wed, 19 Nov 2014 00:46:13 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqtPM-000An4-Kq; Wed, 19 Nov 2014 04:46:08 +0400 Date: Wed, 19 Nov 2014 04:46:08 +0400 From: Slawa Olhovchenkov To: d@delphij.net, "weh@microsoft.com >> Wei Hu" , kyliel@microsoft.com, huishao@microsoft.com, "Jun Fang (Wicresoft)" , "freebsd-arch@FreeBSD.org Arch" , re Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119004608.GQ9763@zxy.spb.ru> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141119003632.GN24601@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:46:14 -0000 On Tue, Nov 18, 2014 at 04:36:32PM -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 +0400: > > On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > > > > > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > > > > > Right now one can declare version for a module by doing something like: > > > > > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > > > that overrides the driver shipped with the kernel itself. However, it > > > > > seems that the MODULE_VERSION facility would just refuse the module > > > > > when preloaded with kernel. > > > > > > > > > > Looking at some other vendor drivers, they are using a slightly > > > > > different module name to overcome this limitation. Is that the only > > > > > way to do it? > > > > > > > > I think now time to move to modulated kernel and load all drivers > > > > currently present in GENERIC as modules (via loader.conf). > > > > > > This becomes slightly more difficult for storage drivers which must > > > be loaded at boot time so the you can mount root from it... But yes, > > > we are interested in methods to make it easier/more automatic for > > > modules to be loaded to support the hardware that is present in a > > > system... > > > > When loader can load kernel -- loader can load driver module, this is > > not Linux (but yes, loader need plugable and stackable framework for > > access FS -- currenly booting from ZFS over gstripe not allowed). > > That isn't the only issue.. another issue is identifing the correct > kernel module(s) to load at boot... iirc, you cannot unload a kernel At first time load all drivers, currenly present in GENERIC kernel. > module loaded at boot time... This is module depended. Some modules can't be unloaded (independently of load time). From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 00:59:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BFBFFE for ; Wed, 19 Nov 2014 00:59:18 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C0FDDE0E for ; Wed, 19 Nov 2014 00:59:18 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 814252291F; Tue, 18 Nov 2014 16:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1416358758; x=1416373158; bh=7qjDjZNSlrIQT1W/y7iWhDw+UMw+5Bl6V81cSuQbv98=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=IvYrJCdBJTjdubjg8bnaBtdZNT73IM6JsqCun9AoIx7oz5w5uWsR3XNOROUWThouC E51IEIAY69mSHp36uFHfHLUuAhWQH40MyPXFcTHXOtfx39M0Z5AC8h7/sfZbQCPegX 65y3emH2yGdLL+CG7Er+aWnF/NvkuDkNcinp/WAA= Message-ID: <546BEB66.6050909@delphij.net> Date: Tue, 18 Nov 2014 16:59:18 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Slawa Olhovchenkov , d@delphij.net, "freebsd-arch@FreeBSD.org Arch" Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> In-Reply-To: <20141119003632.GN24601@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:59:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/14 16:36, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 > +0400: >> On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney >> wrote: >> >>> Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at >>> 16:45 +0400: >>>> On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: >>>> >>>>> Right now one can declare version for a module by doing >>>>> something like: >>>>> >>>>> MODULE_VERSION(module_name, module_version); >>>>> >>>>> Sometimes, it may be desirable for a vendor to release a >>>>> new driver that overrides the driver shipped with the >>>>> kernel itself. However, it seems that the MODULE_VERSION >>>>> facility would just refuse the module when preloaded with >>>>> kernel. >>>>> >>>>> Looking at some other vendor drivers, they are using a >>>>> slightly different module name to overcome this limitation. >>>>> Is that the only way to do it? >>>> >>>> I think now time to move to modulated kernel and load all >>>> drivers currently present in GENERIC as modules (via >>>> loader.conf). >>> >>> This becomes slightly more difficult for storage drivers which >>> must be loaded at boot time so the you can mount root from >>> it... But yes, we are interested in methods to make it >>> easier/more automatic for modules to be loaded to support the >>> hardware that is present in a system... >> >> When loader can load kernel -- loader can load driver module, >> this is not Linux (but yes, loader need plugable and stackable >> framework for access FS -- currenly booting from ZFS over gstripe >> not allowed). > > That isn't the only issue.. another issue is identifing the > correct kernel module(s) to load at boot... iirc, you cannot unload > a kernel module loaded at boot time... Actually the loader can unload everything ("unload"), and after that you would have to load them back individually. The challenge is that having the same code in multiple modules would incur more I/Os (because the need to visit more file system structures, etc.) and possibly slightly more memory. In loader stage, I/Os would be slow and doing so would slow down boot. A way to mitigate this is to compress the modules, but that would break a few applications like DTrace which needs to be taught to read compressed modules. It would be, however, a win if we could strip down the kernel significantly and only load the _required_ modules that are sufficient to support the kernel to start /etc/rc, where we can load additional modules on demand (via devd for instance) because this would reduce I/O at loader stage. I think we need to teach loader to determine which storage drivers and possibly NFS and network devices to load. On FreeNAS we have moved many of non-essential modules to after boot stage but please please consider opening a new thread on this topic as they have nothing to do with our kernel linker module version support... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUa+tmAAoJEJW2GBstM+ns470P/RFgzwEpQABzheEW/NmZ1I+y jPPhKYmbG8pgEhr6S0JeuROLfoocFVI9JkO+4R5M8prEnHUWyfyNyz9oYJ8om3rk 31zmnHRX7nb5szlSRsbXHNNrqFIlNnTWLaCpNn6r7PINYdoUfj8IOv7buDOTFgPf WNQzG2yAsMztbOjmOk7U87BwvN97Ko+k+lLuqfsODnjqiBngrR95utTnnAdyQoOf azydh6gcdXars0ci0xPTKEnm7CcuRK/xU1LNGUUD3CUYVFpQ1o4noXBDJsSzVcbk g/SSrL2voIf6VF+8RKc4Q3CG5e2v35DpPoOP/Jf4kAkhtab3Nyu4pYtDAnsoTVFq JL3wt7Uik/RUw+dDOBhGWtM3rzwPNL2zEGkYP5QtIb2Xe+KkTCWQJHyq1+XhavmI cbvYywzBXHI/JF7Y4LyVkV8q8ZPrBfSlBmOtjdC1IA5P7rmSIZzoso2/uwv2w2Rj 4vZ7o5MExR0sZdV8klWzbenMGhx/wdzjAxZ4rD5fE3bvCGNaXQ+gzVDHCbzyD4pq kS0oAZVSDfv2zrKMowvEkPHrUmjuJ1IsFLi51raSTDSKLwfjVKjI5qVwxi3isPMb ZZRk/bu6XsJ+sd0ODhy3kTXiFK+NfUwMeryngRUuh5yBVF1xkYnZ/7z7bLzIIgzI mZvxLgylFYdwnEu0kiHd =xhPp -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 01:16:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EED3F4AD; Wed, 19 Nov 2014 01:16:27 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEB91F97; Wed, 19 Nov 2014 01:16:27 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xqtsf-0004Y3-Bq; Wed, 19 Nov 2014 01:16:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAJ1GMxc007013; Tue, 18 Nov 2014 18:16:22 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ILMIxJL4vlhR5otiOl2+n X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20141119003632.GN24601@funkthat.com> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Nov 2014 18:16:21 -0700 Message-ID: <1416359781.1147.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: re , kyliel@microsoft.com, "freebsd-arch@FreeBSD.org Arch" , huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , d@delphij.net, Slawa Olhovchenkov , "weh@microsoft.com >> Wei Hu" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 01:16:28 -0000 On Tue, 2014-11-18 at 16:36 -0800, John-Mark Gurney wrote: > Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 +0400: > > On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > > > > > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > > > > > Right now one can declare version for a module by doing something like: > > > > > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > > > that overrides the driver shipped with the kernel itself. However, it > > > > > seems that the MODULE_VERSION facility would just refuse the module > > > > > when preloaded with kernel. > > > > > > > > > > Looking at some other vendor drivers, they are using a slightly > > > > > different module name to overcome this limitation. Is that the only > > > > > way to do it? > > > > > > > > I think now time to move to modulated kernel and load all drivers > > > > currently present in GENERIC as modules (via loader.conf). > > > > > > This becomes slightly more difficult for storage drivers which must > > > be loaded at boot time so the you can mount root from it... But yes, > > > we are interested in methods to make it easier/more automatic for > > > modules to be loaded to support the hardware that is present in a > > > system... > > > > When loader can load kernel -- loader can load driver module, this is > > not Linux (but yes, loader need plugable and stackable framework for > > access FS -- currenly booting from ZFS over gstripe not allowed). > > That isn't the only issue.. another issue is identifing the correct > kernel module(s) to load at boot... iirc, you cannot unload a kernel > module loaded at boot time... > You can do a kldunload on a module that was loaded by loader(8) and it will be unlinked from the kernel in terms of symbol resolution, but the memory cannot be freed. You can then load and unload the same module again as much as you want, it just won't re-occupy the original address, and the original memory is lost forever (but considering the size of most modules, that's not such a big deal). -- Ian From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 03:07:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AEEBA18; Wed, 19 Nov 2014 03:07:33 +0000 (UTC) Received: from mail1.bur200.uecomm.net.au (mail1.bur200.uecomm.net.au [218.185.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD6FD22; Wed, 19 Nov 2014 03:07:32 +0000 (UTC) Received: from mail.flexibledrive.com.au (unknown [115.186.196.106]) by mail1.bur200.uecomm.net.au (Postfix) with ESMTP id 7BE89D400; Wed, 19 Nov 2014 14:07:28 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.flexibledrive.com.au (Postfix) with ESMTP id D8BA3E6C0D; Wed, 19 Nov 2014 14:07:27 +1100 (EST) X-Virus-Scanned: amavisd-new at fdrive.com.au Received: from mail.flexibledrive.com.au ([127.0.0.1]) by localhost (mail.flexibledrive.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J42y4+f5yYhY; Wed, 19 Nov 2014 14:07:19 +1100 (EST) Received: from ws-pross.vv.fda (ws-pross.vv.fda [192.168.50.199]) by mail.flexibledrive.com.au (Postfix) with ESMTPS id 64597E623B; Wed, 19 Nov 2014 14:07:19 +1100 (EST) Date: Wed, 19 Nov 2014 14:07:18 +1100 (AEDT) From: Peter Ross X-X-Sender: petros@linux-vic-05.vv.fda To: Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 03:07:33 -0000 On Sun, 16 Nov 2014, Craig Rodrigues wrote: > (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization > platform for FreeBSD. Jails are still very popular and > performant. VIMAGE makes jails even better by allowing per-jail > network stacks. I am using jails and VIMAGE for ca. 4 years, btw. On the other side of the fence (see Linux) containers became quite popular with Docker and are also used for process management and separation (systemd e.g.) Just to add this as a motivation for using jails and possibly VIMAGE, from a sysadmin perspective. Regards Peter From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 03:28:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01086F50; Wed, 19 Nov 2014 03:28:07 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70949F09; Wed, 19 Nov 2014 03:28:07 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id s18so7259758lam.15 for ; Tue, 18 Nov 2014 19:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AaS3LXE8s4tueoBKaQu1DRvqPKO2t73RzBNcmRfqN5A=; b=R8KqIplC7EQjD9z4qWUFT6jo0oqhB/n9huMPO5v5gLKJSy9RlI2HWYfr197Lpxj5sz Qr/JjME0F2/ruHHZ8SP8USg+3YtaSniqPTlMgsgInhNeL2ODZB/CHMz6UXrYkZOlCzeE I0PJfg51NYlRBehYRLBiBjWehY/0D4rnc//1CP+rpSG+YS2CWhFnEwWAFnzL8TJNfUY0 rAEjAkKmJtdGegmcq5dlL+aMmLTtJ7XMzDcbCK0PQ263W+nFfJCYY+1bIwnvPfWHL38I EJdaI+BNaStA2C7W8UEm0IeRXMrY/LTUdZevILgvTyuqDLfCo4S2sToZYd5K/9CuSm5L 2Zkg== MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr2928817lbb.52.1416367685372; Tue, 18 Nov 2014 19:28:05 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Tue, 18 Nov 2014 19:28:05 -0800 (PST) In-Reply-To: <546A34C8.6060004@freebsd.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> Date: Tue, 18 Nov 2014 19:28:05 -0800 X-Google-Sender-Auth: TTScpdATYtYmx9Wo88nvuv4WoVY Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alfred Perlstein , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 03:28:08 -0000 On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein wrote: > > On 11/17/14, 3:02 AM, Warner Losh wrote: > >> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues >> wrote: >> >> >>> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >>> and >>> https://bugs.freebsd.org/bugzilla/buglist.cgi? >>> quicksearch=vimage%20or%20vnet >>> and try to clean things up. Get help from net@ developers to >>> do >>> this. >>> >> And if these don't get cleaned up? >> > If they are not cleaned/stable up by 11-RELEASE then we turn it off. That > is simple. > Yes, I agree with Alfred that we can turn VIMAGE back off before 11-RELEASE if things don't get cleaned up. We have approximately until the end of 2015, so that gives us time. > > >> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >>> the ipfilter maintainers for this and some net@ developers. >>> >> And if this doesn't happen? >> > > Well we do have 2 other firewalls in the kernel to pick, but we do need > VIMAGE so I will let you draw your own conclusions. > Again, I agree with Alfred on this. Darren Reed originally imported ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a while. Cy Schubert has recently expressed interest in ipfilter and has committed some fixes in the past year, but has not fixed the VIMAGE problems ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ). I can take an initial effort at trying to fix VIMAGE + ipfilter. In the past, I've delved into areas I'm not so familiar with in order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or guidance, that will be great. A lot of bug fixes have gone into VIMAGE in the past 2 years, and I have received multiple reports of people using it in production environments. See the latest post by Peter Ross. To flush out the last few issues and corner cases, I think we need to turn VIMAGE on by default and get feedback and help from the FreeBSD user community and developers to identify and fix the problems. We have about 1 year until 11-RELEASE, so I think it is OK to do this. I would also add two items to my action plan. (6) Ask clusteradm to run one of the machines they use for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide feedback. (7) Ask for help with testing from companies who have more involvement with the network stack. Two of the people in the CC: line of this e-mail work for such places. :) -- Craig -- Craig From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 03:43:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A694F50F for ; Wed, 19 Nov 2014 03:43:20 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71583133 for ; Wed, 19 Nov 2014 03:43:20 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so7343366pdb.14 for ; Tue, 18 Nov 2014 19:43:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=s34g/PTgG0UWcVtZTtinal9HrPwQcOcbdjMrcUPFeT8=; b=S6WKsSyDlrvqG+PnSjb7W+/whjA2/fpDLsYYs+M50PJaOg9wF+vV/PW4tANwvvGsKq Alw22tlfn6Kxnwpm6o7RxZkKWZ3nbo3jRepVM7W3SzGiU0jwa/B8XqKLuyjoB8ufzKh7 7YZ5ecqkOl6B1P/I6TQKi+jC8IqP7Jlt9vOoldQDuD+yWhDSKI8nMN8b+su+94bai6Ml 7M4bOvpeX1WSnHMVwTIO4YbiDVNhxlr56oUW5Cf+ioQ6o6AvqqX+o/CSkPscihJIun4A dhI9OIm9d7GcQXNWghm1JS22quraSMuhr8urb9a3lnBEdKHb3HkJQwsHga6Rgtt1FVk6 fBwg== X-Gm-Message-State: ALoCoQmAu3bvbQNuQ6KkJEh1OFZj7Hfm6QcgdEP2RmrqdGYSiFs7aC1M9ItwsGZeB8tr2tJaXMVq X-Received: by 10.70.126.134 with SMTP id my6mr42532476pdb.14.1416368594711; Tue, 18 Nov 2014 19:43:14 -0800 (PST) Received: from lgmac-zdu.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id oe10sm280846pdb.66.2014.11.18.19.43.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Nov 2014 19:43:13 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D0699E9D-0B0A-4746-B966-7F61F1A5F7E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: suspending threads before devices From: Warner Losh In-Reply-To: <201411181721.56505.jhb@freebsd.org> Date: Tue, 18 Nov 2014 20:43:09 -0700 Message-Id: <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> <201411181721.56505.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: Konstantin Belousov , Andriy Gapon , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 03:43:20 -0000 --Apple-Mail=_D0699E9D-0B0A-4746-B966-7F61F1A5F7E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 18, 2014, at 3:21 PM, John Baldwin wrote: > On Saturday, November 15, 2014 1:00:15 pm Konstantin Belousov wrote: >> On Sat, Nov 15, 2014 at 05:05:10PM +0200, Andriy Gapon wrote: >>> On 15/11/2014 12:58, Konstantin Belousov wrote: >>>> On Fri, Nov 14, 2014 at 11:10:45PM +0200, Andriy Gapon wrote: >>>>> On 22/03/2012 16:14, Konstantin Belousov wrote: >>>>>> I already noted this to Jung-uk, I think that current suspend = handling >>>>>> is (somewhat) wrong. We shall not stop other CPUs for suspension = when >>>>>> they are executing some random kernel code. Rather, CPUs should = be safely >>>>>> stopped at the kernel->user boundary, or at sleep point, or at = designated >>>>>> suspend point like idle loop. >>>>>>=20 >>>>>> We already are engaged into somewhat doubtful actions like = restoring of %cr2, >>>>>> since we might, for instance, preemt page fault handler with = suspend IPI. >>>>>=20 >>>>> I recently revisited this issue in the context of some = suspend+resume problems >>>>> that I am having with radeonkms driver. What surprised me is that = the driver's >>>>> suspend code has no synchronization whatsoever with its other code = paths. So, I >>>>> looked first at the Linux code and then at the illumos code to see = how suspend >>>>> is implemented there. >>>>> As far as I can see, those kernels do exactly what you suggest = that we do. >>>>> Before suspending devices they first suspend all threads except = for one that >>>>> initiates the suspend. For userland threads a signal-like = mechanism is used to >>>>> put them in a state similar to SIGSTOP-ed one. With the kernel = threads >>>>> mechanisms are different between the kernels. Also, illumos = freezes kernel >>>>> threads after suspending the devices, not before. >>>>>=20 >>>>> I think that we could start with only the userland threads = initially. Do you >>>>> think the SIGSTOP-like approach would be hard to implement for us? >>>> We have most, if not all, parts of the stopping code >>>> already implemented. I mean the single-threading code, see >>>> thread_single(SINGLE_BOUNDARY). The code ensures that other threads = in >>>> the current process are stopped either at the kernel->user = boundary, or >>>> at the safe kernel sleep point. >>>>=20 >>>> This is not immediately applicable, since the caller is supposed to = be >>>> a thread in the suspended process, but modifications to allow = external >>>> process to do the same are really small comparing with the = complexity >>>> of the code. I suspect that all what is needed is change of >>>> while/if (remaining !=3D 1) >>>> to >>>> while/if ((p =3D=3D curproc && remaining !=3D 1) || >>>> (p !=3D curproc && remaining !=3D 0)) >>>> together with explicit passing of struct proc *p to thread_single. >>>=20 >>> Thank you for the pointer! >>> I think that maybe even more changes are required for that code to = be usable for >>> suspending. E.g. maybe a different p_flag bit should be used, = because I think >>> that we would like to avoid interaction between the process level = suspend and >>> the global suspend. I.e. the global suspend might encounter a = multi-threaded >>> process in a single thread mode and would need to suspend its = remaining thread. >>=20 >> Thread which is a p_singlethread, is not at the safe point; in other >> words, a process which is under the singlethreading, should prevent >> the system from entering sleep state. The singlethreading is the >> temporal state anyway, it is established during exec() or exit(), so >> it is fine to wait for in-process singlethreading to end before outer >> singlethreading is done. >>=20 >> Anyway, this requires real coding to experiment. I started looking = at >> it since I did somewhat related changes now. >=20 > I would certainly like a way to quiesce threads before entering the = real suspend > path. I would also like to cleanly unmount filesystems during suspend = as well and > the thread issue is a prerequisite for that. However, reusing "stop = at boundary" > may not be quite correct because you probably don't want to block = suspend because > you have an NFS request that is retrying due to a down NFS server. = For NFS I > think you want any threads asleep to just not get a chance to run = again until > after resume completes. I=92m almost certain you don=92t want to =93unmount=94 the filesystems. = This would invalidate all open file handles and would be mondo-bado, and would only succeed if = you forced this issue due to all the open references. Perhaps you=92re being = imprecise. I think you want to pause all the user land threads, sync the = filesystems, which should mark them as clean and allow for the battery to drain w/o too much = trouble. It would also mean that all the threads that start up again won=92t have to = reopen files, etc. Once you=92ve done this, you can proceed to kernel threads and suspending the = hardware. Filesystems implemented in userland, however, would be a problem. As = would logging to stable media once the suspend begins (since you=92d have already = suspended syslogd and even if you hand=92t, you=92d then be dirtying the very disks you = want to keep clean). There=92s currently hooks into devd that would need attention that are (were?) = used to put the video mode into a state that one can resume from. And then there=92s CardBus / PC Card which detach the devices since they = power them down. They could easily be changed to not detach the devices (but they have to = power them down to avoid interrupt storms), but then all the attachments would need to = ensure that their =91resume=92 routines did everything that attached did to initialize the = hardware. And the only way to know if you=92re suspended and resumed with hardware that=92s the same = type, but different that would need to be treated differently than hardware that=92s the same = type but actually the same. The device interface would likely need to grow a UUID function that = would be the hash of the network cards MAC or the disks=92 serial number (Swapping CF cards while = suspended today is completely safe since we force a detach, if that were to be fixed, it = could be come dangerous as the new disk is unlikely to be a bitwise copy of the old). This = functionality would need to live in the driver level, not the bus level, because PCI Config space doesn=92t= have the MAC, nor does it have enough knowledge to know about serial numbers. PC Card CIS = space doesn=92t typically have a serial number (a vanishingly small number of cards have = it, 99%+ or more don=92t). Oh, and it doesn=92t help that the disk isn=92t a direct child = of the PC Card bus, but a child of a child (possibly without any device_t in the case of CAM devices). Oh, = did I mention that PC Card and Cardbus hot plug require kernel threads to be active during suspend = / resume to work properly in some rare cases that time has deserted from my memory. And then there=92s USB, which implemented things differently and = possibly unsafely. I haven=92t looked into that in as much detail as I have PC Card and Cardbus. Warner --Apple-Mail=_D0699E9D-0B0A-4746-B966-7F61F1A5F7E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUbBHNAAoJEGwc0Sh9sBEAFDMQAO0LoVHTr+4yzegb6yHZKZ1g L9hMLYJizHd+zGaOOBilTx7Dms3MTg2wPuO9csYtQoor3Y1G97slP/DRDajwvrtg Go4LYLilTPtZ4WIVt3UGxj+ntxAJx9syRqzcLu5sptIH55s8t03HE1HRRrmbhtmk bn9XPNVbfxll2uVVDDyho2rq8Go+G5j2N3x88g6uH5E1/mInYzH56L7nOSTdT6o4 TpAyFVXYjxm2PpljImKLu4HyP2cKFiJS7JlIOZu9jfLCojlIf+tp2+6EbgvHB6HF zW6NhCYzC0YKTZdytYAakuSdMFV5DmEdKV47krE24DCY1f027MOtgtyvwWQUsH0Y ScHLCRhnaz40JDcevDgT4o9KoLV1/ad9iwK/sZQXM68ekwLhIQKMZBULoocF1PLA huh3PUfjnrZ8SPLcx56M61quYpcxGRytK23dK2dWUIw2taVOJh/cK2X5gJzRwDID jjdNZQPdVqNUPix6RM9SSXmgIQQwXPwGgnexrfhro8dC2H4QS40s2UbBf2RUkuck +1r0BHDUI4BbaCCTiUa5eCZg1BX9Tdd/oDLj8pzGFj2gVBATP12Fkoi/RX3aWY6t mKxcUQQa7FzWdK0ZYnBBQHGiCuHF10x7t3vafRdmnpcjfrawsWPXcCaEC6KACNux hkL4oyW5MUapGkAolVzq =2vDO -----END PGP SIGNATURE----- --Apple-Mail=_D0699E9D-0B0A-4746-B966-7F61F1A5F7E0-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 04:10:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43180779 for ; Wed, 19 Nov 2014 04:10:12 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10D9333D for ; Wed, 19 Nov 2014 04:10:11 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fb1so634993pad.41 for ; Tue, 18 Nov 2014 20:10:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=F/phn/AxAIRGLjG/WwDMzYlxA+NhEUcM9pWk5ofluGg=; b=IsO+oD5RQxVfhGyBVBXaH5a+oknCFnh4Quxb8BRKdpo5ixoPyq6V8I0A8kNDhzXHHw BZ5s7L5Am8Tzz315wEjuMhdxnQWsN5KxvHv2yi7Ia2xrg2++j1VHiNk1LXPecWK2dPQh ZEQlYeu+J0xMy2FWArThqY83auMS+M78TyLI2hamKq6I5C+UctCdfZ4wJJFzIgMxd0L3 DNZXHcX2mbvAcHs6iZ3zKTwtvETbl5t8r4XuYiFAs4O9VZqrzW+Y8Idji+3kVP4bAovO ddJSfa+CsSCyGtffB2jez6S2i7NWI8dQrqNLbTTP2xitZYJktfaHldH2/znUnuY4SWID BIJg== X-Gm-Message-State: ALoCoQkmiscO/WBRaANTwJtn5PnnmDH4LUGRjVOqOAd7/yWkfGAwtZbmeWkdT4uh3bajdsxqhRuS X-Received: by 10.66.240.71 with SMTP id vy7mr42801726pac.89.1416370211136; Tue, 18 Nov 2014 20:10:11 -0800 (PST) Received: from lgmac-zdu.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id dj1sm435192pbb.48.2014.11.18.20.10.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Nov 2014 20:10:10 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_BC8DC997-BA9E-4704-8ECE-49E27B8D31E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? From: Warner Losh In-Reply-To: <546BEB66.6050909@delphij.net> Date: Tue, 18 Nov 2014 21:10:02 -0700 Message-Id: <7F7BC412-A7E3-4848-B284-92C3FB7EC1DE@bsdimp.com> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> <546BEB66.6050909@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arch@FreeBSD.org Arch" , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 04:10:12 -0000 --Apple-Mail=_BC8DC997-BA9E-4704-8ECE-49E27B8D31E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 18, 2014, at 5:59 PM, Xin Li wrote: > It would be, however, a win if we could strip down the kernel > significantly and only load the _required_ modules that are sufficient > to support the kernel to start /etc/rc, where we can load additional > modules on demand (via devd for instance) because this would reduce > I/O at loader stage. I think we need to teach loader to determine > which storage drivers and possibly NFS and network devices to load. For years on my laptop, I ran a stripped kernel and only loaded ata.ko and friends from the boot loader (I can=92t recall if I had to compile = in syscons and atakbd or if I loaded them). I dynamically loaded the rest, but the way I did it was extremely hackish and ugly (I used nomatch stuff that I added to whenever I found new hardware to a file I always appended to). You don=92t need to load any network junk for the laptop case in the = boot loader unless you are a weird mutant that networks boots the stuff. Warner --Apple-Mail=_BC8DC997-BA9E-4704-8ECE-49E27B8D31E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUbBgaAAoJEGwc0Sh9sBEANdgP/1w2Uel3V0k9PfFKl/gAXUnU 7OP0o8VoY0PGJvvJI7MbBrKdj9/jffk+pO/xev6p2sSvjTjHp4k/woGcUhaerkpR BGUjGvZfOoYn5eycSkddbZPqiT2BKG8g8bSrSq7dMfDpj97Gn74ZLnvgQzhHTFt/ LoRt7z60L3ITn+4339JymhjLRG+UmMjuDlGzPHUwNE+2EcCpdXj8WSxvACFiEpVv nrBO9RZdBkvJy0f3husxwhMu/aktFILkY/XdtQr5x8xCFoxvqE/eoWJuSXwBhla3 RaZKpPtF/nURFpfwlzExDxZvFipxqbpxuV7pJj0HkSowaQbZhSR9+QtDy58nfBjD OOdMapQ3G88mvLF+rvH3TDIaHFMx9p3rMP1PKPaIddTf2GWG+fxPXE3uiwXcOtCB OvWa7MFksGpm1J1iUWy+VYjXm2Wc0fLqQDrTDwA2giZ/Ha7y6awPrVjdex/03hlH sb2G2VoNjJGjuEhEIRR1TtmJvPdhEFj7tfnG8PmzRqZ89nf0mrVMO1adhNZdDhkk Tjkpwu97S57h2BL/mZJPm9Oq5/9Ol1bhRWC7lq2tBS75nnGhhk6lXURhaWvmSbAT AOqL9U/LzprCAKaaA8fMgPa1sZljgku4KtF7OM3NUGMrD/qhyzxL/13sqVRkub/v NjgHeIcRz3J+ExD2rNer =DRs+ -----END PGP SIGNATURE----- --Apple-Mail=_BC8DC997-BA9E-4704-8ECE-49E27B8D31E4-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 06:14:40 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4237C341 for ; Wed, 19 Nov 2014 06:14:40 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1683BFA for ; Wed, 19 Nov 2014 06:14:39 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAJ6ETIV088770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Nov 2014 22:14:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <546C3540.1080709@freebsd.org> Date: Wed, 19 Nov 2014 14:14:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> In-Reply-To: <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 06:14:40 -0000 On 11/19/14, 11:43 AM, Warner Losh wrote: > I’m almost certain you don’t want to “unmount” the filesystems. This > would invalidate all open file handles and would be mondo-bado, and > would only succeed if you forced this issue due to all the open > references. Perhaps you’re being imprecise. I think you want to > pause all the user land threads, sync the filesystems, which should > mark them as clean and allow for the battery to drain w/o too much > trouble. I believe that is what is meant.. Terry Lambert was always pushing for this, though what he wanted was for the file systems to mark themselves clean after a certain amount of idle time, even without suspend. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 08:59:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 631BD48B for ; Wed, 19 Nov 2014 08:59:50 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CDA6628 for ; Wed, 19 Nov 2014 08:59:50 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xr174-000IP6-Nj; Wed, 19 Nov 2014 12:59:46 +0400 Date: Wed, 19 Nov 2014 12:59:46 +0400 From: Slawa Olhovchenkov To: d@delphij.net Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119085946.GA68953@zxy.spb.ru> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> <546BEB66.6050909@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546BEB66.6050909@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 08:59:50 -0000 On Tue, Nov 18, 2014 at 04:59:18PM -0800, Xin Li wrote: > >>> This becomes slightly more difficult for storage drivers which > >>> must be loaded at boot time so the you can mount root from > >>> it... But yes, we are interested in methods to make it > >>> easier/more automatic for modules to be loaded to support the > >>> hardware that is present in a system... > >> > >> When loader can load kernel -- loader can load driver module, > >> this is not Linux (but yes, loader need plugable and stackable > >> framework for access FS -- currenly booting from ZFS over gstripe > >> not allowed). > > > > That isn't the only issue.. another issue is identifing the > > correct kernel module(s) to load at boot... iirc, you cannot unload > > a kernel module loaded at boot time... > > Actually the loader can unload everything ("unload"), and after that > you would have to load them back individually. > > The challenge is that having the same code in multiple modules would > incur more I/Os (because the need to visit more file system > structures, etc.) and possibly slightly more memory. In loader stage, > I/Os would be slow and doing so would slow down boot. A way to Some time ago Andrey V. Elsukov do some improvement at this point (cashe improvement in loader). Now initialising and waiting USB stack need more time that loading multiple modules. > mitigate this is to compress the modules, but that would break a few > applications like DTrace which needs to be taught to read compressed > modules. > > It would be, however, a win if we could strip down the kernel > significantly and only load the _required_ modules that are sufficient > to support the kernel to start /etc/rc, where we can load additional > modules on demand (via devd for instance) because this would reduce > I/O at loader stage. I think we need to teach loader to determine > which storage drivers and possibly NFS and network devices to load. This is next step. First step -- switch to modulated kernel (we can't switch to modulated kenel between minor releases and need switch before freeze 11.0) From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 09:00:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12BD1754; Wed, 19 Nov 2014 09:00:47 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC195641; Wed, 19 Nov 2014 09:00:46 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xr17z-000IXx-TP; Wed, 19 Nov 2014 13:00:43 +0400 Date: Wed, 19 Nov 2014 13:00:43 +0400 From: Slawa Olhovchenkov To: Ian Lepore Subject: Re: kernel linker: Overriding a driver shipped with kernel via module? Message-ID: <20141119090043.GB68953@zxy.spb.ru> References: <546A8191.3090208@delphij.net> <20141118124544.GA95731@zxy.spb.ru> <20141119001510.GM24601@funkthat.com> <20141119002718.GP9763@zxy.spb.ru> <20141119003632.GN24601@funkthat.com> <1416359781.1147.74.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416359781.1147.74.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: re , kyliel@microsoft.com, "weh@microsoft.com >> Wei Hu" , John-Mark Gurney , huishao@microsoft.com, "Jun Fang \(Wicresoft\)" , "freebsd-arch@FreeBSD.org Arch" , d@delphij.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 09:00:47 -0000 On Tue, Nov 18, 2014 at 06:16:21PM -0700, Ian Lepore wrote: > On Tue, 2014-11-18 at 16:36 -0800, John-Mark Gurney wrote: > > Slawa Olhovchenkov wrote this message on Wed, Nov 19, 2014 at 04:27 +0400: > > > On Tue, Nov 18, 2014 at 04:15:10PM -0800, John-Mark Gurney wrote: > > > > > > > Slawa Olhovchenkov wrote this message on Tue, Nov 18, 2014 at 16:45 +0400: > > > > > On Mon, Nov 17, 2014 at 03:15:29PM -0800, Xin Li wrote: > > > > > > > > > > > Right now one can declare version for a module by doing something like: > > > > > > > > > > > > MODULE_VERSION(module_name, module_version); > > > > > > > > > > > > Sometimes, it may be desirable for a vendor to release a new driver > > > > > > that overrides the driver shipped with the kernel itself. However, it > > > > > > seems that the MODULE_VERSION facility would just refuse the module > > > > > > when preloaded with kernel. > > > > > > > > > > > > Looking at some other vendor drivers, they are using a slightly > > > > > > different module name to overcome this limitation. Is that the only > > > > > > way to do it? > > > > > > > > > > I think now time to move to modulated kernel and load all drivers > > > > > currently present in GENERIC as modules (via loader.conf). > > > > > > > > This becomes slightly more difficult for storage drivers which must > > > > be loaded at boot time so the you can mount root from it... But yes, > > > > we are interested in methods to make it easier/more automatic for > > > > modules to be loaded to support the hardware that is present in a > > > > system... > > > > > > When loader can load kernel -- loader can load driver module, this is > > > not Linux (but yes, loader need plugable and stackable framework for > > > access FS -- currenly booting from ZFS over gstripe not allowed). > > > > That isn't the only issue.. another issue is identifing the correct > > kernel module(s) to load at boot... iirc, you cannot unload a kernel > > module loaded at boot time... > > > > You can do a kldunload on a module that was loaded by loader(8) and it > will be unlinked from the kernel in terms of symbol resolution, but the > memory cannot be freed. You can then load and unload the same module > again as much as you want, it just won't re-occupy the original address, > and the original memory is lost forever (but considering the size of > most modules, that's not such a big deal). Some modules can't be unloaded anyway: netgraph, for example. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 10:16:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ADBEBBC; Wed, 19 Nov 2014 10:16:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08613E89; Wed, 19 Nov 2014 10:16:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAJAG5wJ003706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 12:16:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAJAG5wJ003706 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAJAG5fE003705; Wed, 19 Nov 2014 12:16:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Nov 2014 12:16:05 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: suspending threads before devices Message-ID: <20141119101605.GB17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> <201411181721.56505.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411181721.56505.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Jung-uk Kim , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:16:10 -0000 On Tue, Nov 18, 2014 at 05:21:56PM -0500, John Baldwin wrote: > I would certainly like a way to quiesce threads before entering the > real suspend path. I would also like to cleanly unmount filesystems > during suspend as well and the thread issue is a prerequisite for > that. However, reusing "stop at boundary" may not be quite correct > because you probably don't want to block suspend because you have an > NFS request that is retrying due to a down NFS server. For NFS I think > you want any threads asleep to just not get a chance to run again > until after resume completes. It was already correctly described why unmount is not an option at suspend. We could consider suspending filesystems, but if usermode threads are going to be stopped, it makes no sense. Just syncing filesystems, as in VFS_SYNC(), should be enough. WRT TFD_SBDRY, I do not think that we should enforce stopping at usermode boundary for the suspend. VFCF_SBDRY prevents lock cascade on the live system, there is cannot be more stopped threads for whole-system suspension. I.e., the global thread stopping should ignore the TDF_BOUNDARY flag. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 12:08:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DD28988; Wed, 19 Nov 2014 12:08:16 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0400EC86; Wed, 19 Nov 2014 12:08:16 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xr02N-00044f-0h; Wed, 19 Nov 2014 11:50:51 +0400 Message-ID: <546C8812.2070904@FreeBSD.org> Date: Wed, 19 Nov 2014 16:07:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Craig Rodrigues , FreeBSD Net Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:08:16 -0000 On 19.11.2014 07:28, Craig Rodrigues wrote: > On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein > wrote: > >> On 11/17/14, 3:02 AM, Warner Losh wrote: >> >>> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues >>> wrote: >>> >>> >>>> (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO >>>> and >>>> https://bugs.freebsd.org/bugzilla/buglist.cgi? >>>> quicksearch=vimage%20or%20vnet >>>> and try to clean things up. Get help from net@ developers to >>>> do >>>> this. >>>> >>> And if these don't get cleaned up? >>> >> If they are not cleaned/stable up by 11-RELEASE then we turn it off. That >> is simple. >> > Yes, I agree with Alfred that we can turn VIMAGE back off before > 11-RELEASE if things don't get cleaned up. > We have approximately until the end of 2015, so that gives > us time. > > > >> >>> (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from >>>> the ipfilter maintainers for this and some net@ developers. >>>> >>> And if this doesn't happen? >>> >> Well we do have 2 other firewalls in the kernel to pick, but we do need >> VIMAGE so I will let you draw your own conclusions. >> > > Again, I agree with Alfred on this. Darren Reed originally imported > ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a > while. Cy Schubert has recently expressed interest in ipfilter and has > committed some fixes in the past year, but has not fixed the VIMAGE problems > ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ). > I can take an initial effort at trying to fix VIMAGE + ipfilter. > In the past, I've delved into areas I'm not so familiar with in > order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or > guidance, that will be great. > > A lot of bug fixes have gone into VIMAGE in the past 2 years, > and I have received multiple reports of people using it in production > environments. See the latest post by Peter Ross. > > To flush out the last few issues and corner cases, I think we > need to turn VIMAGE on by default and get feedback and help from > the FreeBSD user community and developers to identify and fix the problems. Can we have some wiki/man/docs on how particular subsystem should interact with VNET first? This can probably help to make proper vnet fixes in less number of attempts :) For example, even attach/detach is handled differently in different places: tcp_subr.c: /* Skip initialization of globals for non-default instances. */ if (!IS_DEFAULT_VNET(curvnet)) return; in6_rmx.c: /* * Initialize our routing tree. */ static VNET_DEFINE(int, _in6_rt_was_here); #define V__in6_rt_was_here VNET(_in6_rt_was_here) if (V__in6_rtwas_here == 0) { callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE); in6_mtutimo(curvnet); /* kick off timeout first time */ V__in6_rt_was_here = 1; } return (1); } It would be great to get a bit more details on the following (at least from my point of view): * what is the proper procedure of handling non-default VNET attach/detach (locking mostly) * how can one properly cache needed VNET context (e.g. is it safe just to save "struct vnet *" pointer) and is this right thing to do at all? * Is it safe to to CURVNET_SET without holding any VNET locks ? P.S. I'm not against VIMAGE in any kind, I think we really should move forward towards making it stable. However, "just turn it on" concept with a bunch of known (and unresolved issues) is not the best thing IMO. > > We have about 1 year until 11-RELEASE, so I think it is OK to do this. > > I would also add two items to my action plan. > > > (6) Ask clusteradm to run one of the machines they use > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide > feedback. > > (7) Ask for help with testing from companies who have more involvement > with the network stack. Two of the people in the CC: line of this > e-mail work for such places. :) > > -- > Craig > > > -- > Craig > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 12:22:10 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FBF4C42; Wed, 19 Nov 2014 12:22:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA9A5E04; Wed, 19 Nov 2014 12:22:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAJCM06e038892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 14:22:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAJCM06e038892 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAJCM0GZ038891; Wed, 19 Nov 2014 14:22:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Nov 2014 14:22:00 +0200 From: Konstantin Belousov To: arch@freebsd.org Subject: PROC_SLOCK usage reduction Message-ID: <20141119122200.GD17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:22:10 -0000 The process has two locks which ensure required stability for the struct proc during the process lifetime: process mutex and process spinlock. Both locks serve a lot of purposes, which causes contention and somewhat difficult to understand code. The contention is mostly known for process mutex. There were several proposals to change process mutex to rwlock, to allow read mode to provide more parallelism when modifications are not needed. IMO this is wrong start, since to get effect from read mode, enough of the lock owners must be converted to read lock, which is complicated due to overloading of single lock for many purposes. First action should be split of the lock into more fine-grained domains. The process mutex is big and complex, I decided to start with the simpler and more contained process spinlock. AFAIS, there are following uses of it: - Threads lifetime cycle, in particular, counting of the threads in the process, and interlocking with process mutex and thread lock. The main reason of this is that turnstile locks are after thread locks, so you e.g. cannot unlock blockable mutex (think process mutex) while owning thread lock. - Virtual and profiling itimers, since the timers activation is done from the clock interrupt context. - Profiling code (profil(2)), for similar reason. - Resource usage accounting. Need for the spinlock there is subtle, my understanding is that spinlock blocks context switching for the current thread, which prevents td_runtime and similar fields from changing (updates are done at the mi_switch()). I split the process spinlock according to the description above. I think that the interlocking with the process lock might be reduced, but this is subject of further work. For now, the patch in the mail provides the milestone for simpler case. It was tested by Peter Holm, who endured previous attempts as well. diff --git a/sys/compat/linux/linux_misc.c b/sys/compat/linux/linux_misc.c index 4433e18..93dd80d 100644 --- a/sys/compat/linux/linux_misc.c +++ b/sys/compat/linux/linux_misc.c @@ -690,9 +690,9 @@ linux_times(struct thread *td, struct linux_times_args *args) if (args->buf != NULL) { p = td->td_proc; PROC_LOCK(p); - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &utime, &stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); calccru(p, &cutime, &cstime); PROC_UNLOCK(p); diff --git a/sys/compat/svr4/svr4_misc.c b/sys/compat/svr4/svr4_misc.c index 9e9b020..cef1b48 100644 --- a/sys/compat/svr4/svr4_misc.c +++ b/sys/compat/svr4/svr4_misc.c @@ -864,9 +864,9 @@ svr4_sys_times(td, uap) p = td->td_proc; PROC_LOCK(p); - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &utime, &stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); calccru(p, &cutime, &cstime); PROC_UNLOCK(p); @@ -1277,9 +1277,9 @@ loop: pid = p->p_pid; status = p->p_xstat; ru = p->p_ru; - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &ru.ru_utime, &ru.ru_stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); PROC_UNLOCK(p); sx_sunlock(&proctree_lock); @@ -1304,9 +1304,9 @@ loop: pid = p->p_pid; status = W_STOPCODE(p->p_xstat); ru = p->p_ru; - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &ru.ru_utime, &ru.ru_stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); PROC_UNLOCK(p); if (((uap->options & SVR4_WNOWAIT)) == 0) { @@ -1328,9 +1328,9 @@ loop: pid = p->p_pid; ru = p->p_ru; status = SIGCONT; - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &ru.ru_utime, &ru.ru_stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); PROC_UNLOCK(p); if (((uap->options & SVR4_WNOWAIT)) == 0) { diff --git a/sys/fs/procfs/procfs_status.c b/sys/fs/procfs/procfs_status.c index a97e0a9..5a00ee1 100644 --- a/sys/fs/procfs/procfs_status.c +++ b/sys/fs/procfs/procfs_status.c @@ -125,9 +125,9 @@ procfs_doprocstatus(PFS_FILL_ARGS) if (p->p_flag & P_INMEM) { struct timeval start, ut, st; - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &ut, &st); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); start = p->p_stats->p_start; timevaladd(&start, &boottime); sbuf_printf(sb, " %jd,%ld %jd,%ld %jd,%ld", diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index a065b75..e903f4c 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -603,9 +603,9 @@ proc0_post(void *dummy __unused) sx_slock(&allproc_lock); FOREACH_PROC_IN_SYSTEM(p) { microuptime(&p->p_stats->p_start); - PROC_SLOCK(p); + PROC_STATLOCK(p); rufetch(p, &ru); /* Clears thread stats */ - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); p->p_rux.rux_runtime = 0; p->p_rux.rux_uticks = 0; p->p_rux.rux_sticks = 0; diff --git a/sys/kern/kern_clock.c b/sys/kern/kern_clock.c index 79a294d..6aa3523 100644 --- a/sys/kern/kern_clock.c +++ b/sys/kern/kern_clock.c @@ -432,16 +432,16 @@ hardclock_cpu(int usermode) flags = 0; if (usermode && timevalisset(&pstats->p_timer[ITIMER_VIRTUAL].it_value)) { - PROC_SLOCK(p); + PROC_ITIMLOCK(p); if (itimerdecr(&pstats->p_timer[ITIMER_VIRTUAL], tick) == 0) flags |= TDF_ALRMPEND | TDF_ASTPENDING; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } if (timevalisset(&pstats->p_timer[ITIMER_PROF].it_value)) { - PROC_SLOCK(p); + PROC_ITIMLOCK(p); if (itimerdecr(&pstats->p_timer[ITIMER_PROF], tick) == 0) flags |= TDF_PROFPEND | TDF_ASTPENDING; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } thread_lock(td); sched_tick(1); @@ -520,18 +520,18 @@ hardclock_cnt(int cnt, int usermode) flags = 0; if (usermode && timevalisset(&pstats->p_timer[ITIMER_VIRTUAL].it_value)) { - PROC_SLOCK(p); + PROC_ITIMLOCK(p); if (itimerdecr(&pstats->p_timer[ITIMER_VIRTUAL], tick * cnt) == 0) flags |= TDF_ALRMPEND | TDF_ASTPENDING; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } if (timevalisset(&pstats->p_timer[ITIMER_PROF].it_value)) { - PROC_SLOCK(p); + PROC_ITIMLOCK(p); if (itimerdecr(&pstats->p_timer[ITIMER_PROF], tick * cnt) == 0) flags |= TDF_PROFPEND | TDF_ASTPENDING; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } thread_lock(td); sched_tick(cnt); diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 1e4c095..21daee1 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -614,7 +614,9 @@ exit1(struct thread *td, int rv) /* * Save our children's rusage information in our exit rusage. */ + PROC_STATLOCK(p); ruadd(&p->p_ru, &p->p_rux, &p->p_stats->p_cru, &p->p_crux); + PROC_STATUNLOCK(p); /* * Make sure the scheduler takes this thread out of its tables etc. @@ -990,8 +992,6 @@ proc_to_reap(struct thread *td, struct proc *p, idtype_t idtype, id_t id, return (0); } - PROC_SLOCK(p); - if (siginfo != NULL) { bzero(siginfo, sizeof(*siginfo)); siginfo->si_errno = 0; @@ -1038,7 +1038,9 @@ proc_to_reap(struct thread *td, struct proc *p, idtype_t idtype, id_t id, if (wrusage != NULL) { rup = &wrusage->wru_self; *rup = p->p_ru; + PROC_STATLOCK(p); calcru(p, &rup->ru_utime, &rup->ru_stime); + PROC_STATUNLOCK(p); rup = &wrusage->wru_children; *rup = p->p_stats->p_cru; @@ -1046,10 +1048,10 @@ proc_to_reap(struct thread *td, struct proc *p, idtype_t idtype, id_t id, } if (p->p_state == PRS_ZOMBIE) { + PROC_SLOCK(p); proc_reap(td, p, status, options); return (-1); } - PROC_SUNLOCK(p); PROC_UNLOCK(p); return (1); } diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c index 467ae1c..e7d85e9 100644 --- a/sys/kern/kern_mutex.c +++ b/sys/kern/kern_mutex.c @@ -970,6 +970,9 @@ mutex_init(void) blocked_lock.mtx_lock = 0xdeadc0de; /* Always blocked. */ mtx_init(&proc0.p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); mtx_init(&proc0.p_slock, "process slock", NULL, MTX_SPIN | MTX_RECURSE); + mtx_init(&proc0.p_statmtx, "pstatl", NULL, MTX_SPIN); + mtx_init(&proc0.p_itimmtx, "pitiml", NULL, MTX_SPIN); + mtx_init(&proc0.p_profmtx, "pprofl", NULL, MTX_SPIN); mtx_init(&devmtx, "cdev", NULL, MTX_DEF); mtx_lock(&Giant); } diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 495139f..009ccce 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -228,6 +228,9 @@ proc_init(void *mem, int size, int flags) bzero(&p->p_mtx, sizeof(struct mtx)); mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN | MTX_RECURSE); + mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN); + mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN); + mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN); cv_init(&p->p_pwait, "ppwait"); cv_init(&p->p_dbgwait, "dbgwait"); TAILQ_INIT(&p->p_threads); /* all threads in proc */ @@ -872,11 +875,11 @@ fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp) kp->ki_fibnum = p->p_fibnum; kp->ki_start = p->p_stats->p_start; timevaladd(&kp->ki_start, &boottime); - PROC_SLOCK(p); + PROC_STATLOCK(p); rufetch(p, &kp->ki_rusage); kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); calcru(p, &kp->ki_rusage.ru_utime, &kp->ki_rusage.ru_stime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); calccru(p, &kp->ki_childutime, &kp->ki_childstime); /* Some callers want child times in a single value. */ kp->ki_childtime = kp->ki_childstime; @@ -944,7 +947,7 @@ fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp, int preferthread) PROC_LOCK_ASSERT(p, MA_OWNED); if (preferthread) - PROC_SLOCK(p); + PROC_STATLOCK(p); thread_lock(td); if (td->td_wmesg != NULL) strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); @@ -1030,7 +1033,7 @@ fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp, int preferthread) kp->ki_sigmask = td->td_sigmask; thread_unlock(td); if (preferthread) - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); } /* diff --git a/sys/kern/kern_racct.c b/sys/kern/kern_racct.c index 84fa312..05becea 100644 --- a/sys/kern/kern_racct.c +++ b/sys/kern/kern_racct.c @@ -1129,11 +1129,11 @@ racctd(void) microuptime(&wallclock); timevalsub(&wallclock, &p->p_stats->p_start); - PROC_SLOCK(p); + PROC_STATLOCK(p); FOREACH_THREAD_IN_PROC(p, td) ruxagg(p, td); runtime = cputick2usec(p->p_rux.rux_runtime); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); #ifdef notyet KASSERT(runtime >= p->p_prev_runtime, ("runtime < p_prev_runtime")); diff --git a/sys/kern/kern_resource.c b/sys/kern/kern_resource.c index 037a257..1c7e4c6 100644 --- a/sys/kern/kern_resource.c +++ b/sys/kern/kern_resource.c @@ -619,11 +619,11 @@ lim_cb(void *arg) */ if (p->p_cpulimit == RLIM_INFINITY) return; - PROC_SLOCK(p); + PROC_STATLOCK(p); FOREACH_THREAD_IN_PROC(p, td) { ruxagg(p, td); } - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); if (p->p_rux.rux_runtime > p->p_cpulimit * cpu_tickrate()) { lim_rlimit(p, RLIMIT_CPU, &rlim); if (p->p_rux.rux_runtime >= rlim.rlim_max * cpu_tickrate()) { @@ -825,7 +825,7 @@ calcru(struct proc *p, struct timeval *up, struct timeval *sp) uint64_t runtime, u; PROC_LOCK_ASSERT(p, MA_OWNED); - PROC_SLOCK_ASSERT(p, MA_OWNED); + PROC_STATLOCK_ASSERT(p, MA_OWNED); /* * If we are getting stats for the current process, then add in the * stats that this thread has accumulated in its current time slice. @@ -857,7 +857,7 @@ rufetchtd(struct thread *td, struct rusage *ru) uint64_t runtime, u; p = td->td_proc; - PROC_SLOCK_ASSERT(p, MA_OWNED); + PROC_STATLOCK_ASSERT(p, MA_OWNED); THREAD_LOCK_ASSERT(td, MA_OWNED); /* * If we are getting stats for the current thread, then add in the @@ -991,11 +991,11 @@ kern_getrusage(struct thread *td, int who, struct rusage *rup) break; case RUSAGE_THREAD: - PROC_SLOCK(p); + PROC_STATLOCK(p); thread_lock(td); rufetchtd(td, rup); thread_unlock(td); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); break; default: @@ -1042,7 +1042,7 @@ ruxagg_locked(struct rusage_ext *rux, struct thread *td) { THREAD_LOCK_ASSERT(td, MA_OWNED); - PROC_SLOCK_ASSERT(td->td_proc, MA_OWNED); + PROC_STATLOCK_ASSERT(td->td_proc, MA_OWNED); rux->rux_runtime += td->td_incruntime; rux->rux_uticks += td->td_uticks; rux->rux_sticks += td->td_sticks; @@ -1072,7 +1072,7 @@ rufetch(struct proc *p, struct rusage *ru) { struct thread *td; - PROC_SLOCK_ASSERT(p, MA_OWNED); + PROC_STATLOCK_ASSERT(p, MA_OWNED); *ru = p->p_ru; if (p->p_numthreads > 0) { @@ -1093,10 +1093,10 @@ rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up, struct timeval *sp) { - PROC_SLOCK(p); + PROC_STATLOCK(p); rufetch(p, ru); calcru(p, up, sp); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); } /* diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index ec084ed..ea076b9 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -470,6 +470,9 @@ thread_exit(void) PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_OUT); #endif PROC_UNLOCK(p); + PROC_STATLOCK(p); + thread_lock(td); + PROC_SUNLOCK(p); /* Do the same timestamp bookkeeping that mi_switch() would do. */ new_switchtime = cpu_ticks(); @@ -484,9 +487,8 @@ thread_exit(void) td->td_ru.ru_nvcsw++; ruxagg(p, td); rucollect(&p->p_ru, &td->td_ru); + PROC_STATUNLOCK(p); - thread_lock(td); - PROC_SUNLOCK(p); td->td_state = TDS_INACTIVE; #ifdef WITNESS witness_thread_exit(td); diff --git a/sys/kern/kern_time.c b/sys/kern/kern_time.c index e8430e4..1ee80f0 100644 --- a/sys/kern/kern_time.c +++ b/sys/kern/kern_time.c @@ -276,10 +276,10 @@ get_process_cputime(struct proc *targetp, struct timespec *ats) uint64_t runtime; struct rusage ru; - PROC_SLOCK(targetp); + PROC_STATLOCK(targetp); rufetch(targetp, &ru); runtime = targetp->p_rux.rux_runtime; - PROC_SUNLOCK(targetp); + PROC_STATUNLOCK(targetp); cputick2timespec(runtime, ats); } @@ -328,17 +328,17 @@ kern_clock_gettime(struct thread *td, clockid_t clock_id, struct timespec *ats) break; case CLOCK_VIRTUAL: PROC_LOCK(p); - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &user, &sys); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); PROC_UNLOCK(p); TIMEVAL_TO_TIMESPEC(&user, ats); break; case CLOCK_PROF: PROC_LOCK(p); - PROC_SLOCK(p); + PROC_STATLOCK(p); calcru(p, &user, &sys); - PROC_SUNLOCK(p); + PROC_STATUNLOCK(p); PROC_UNLOCK(p); timevaladd(&user, &sys); TIMEVAL_TO_TIMESPEC(&user, ats); @@ -698,9 +698,9 @@ kern_getitimer(struct thread *td, u_int which, struct itimerval *aitv) timevalsub(&aitv->it_value, &ctv); } } else { - PROC_SLOCK(p); + PROC_ITIMLOCK(p); *aitv = p->p_stats->p_timer[which]; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } return (0); } @@ -782,10 +782,10 @@ kern_setitimer(struct thread *td, u_int which, struct itimerval *aitv, aitv->it_value.tv_usec != 0 && aitv->it_value.tv_usec < tick) aitv->it_value.tv_usec = tick; - PROC_SLOCK(p); + PROC_ITIMLOCK(p); *oitv = p->p_stats->p_timer[which]; p->p_stats->p_timer[which] = *aitv; - PROC_SUNLOCK(p); + PROC_ITIMUNLOCK(p); } return (0); } diff --git a/sys/kern/subr_prof.c b/sys/kern/subr_prof.c index cedfc1b..3d87ff9 100644 --- a/sys/kern/subr_prof.c +++ b/sys/kern/subr_prof.c @@ -421,12 +421,12 @@ sys_profil(struct thread *td, struct profil_args *uap) } PROC_LOCK(p); upp = &td->td_proc->p_stats->p_prof; - PROC_SLOCK(p); + PROC_PROFLOCK(p); upp->pr_off = uap->offset; upp->pr_scale = uap->scale; upp->pr_base = uap->samples; upp->pr_size = uap->size; - PROC_SUNLOCK(p); + PROC_PROFUNLOCK(p); startprofclock(p); PROC_UNLOCK(p); @@ -466,15 +466,15 @@ addupc_intr(struct thread *td, uintfptr_t pc, u_int ticks) if (ticks == 0) return; prof = &td->td_proc->p_stats->p_prof; - PROC_SLOCK(td->td_proc); + PROC_PROFLOCK(td->td_proc); if (pc < prof->pr_off || (i = PC_TO_INDEX(pc, prof)) >= prof->pr_size) { - PROC_SUNLOCK(td->td_proc); + PROC_PROFUNLOCK(td->td_proc); return; /* out of range; ignore */ } addr = prof->pr_base + i; - PROC_SUNLOCK(td->td_proc); + PROC_PROFUNLOCK(td->td_proc); if ((v = fuswintr(addr)) == -1 || suswintr(addr, v + ticks) == -1) { td->td_profil_addr = pc; td->td_profil_ticks = ticks; @@ -509,15 +509,15 @@ addupc_task(struct thread *td, uintfptr_t pc, u_int ticks) } p->p_profthreads++; prof = &p->p_stats->p_prof; - PROC_SLOCK(p); + PROC_PROFLOCK(p); if (pc < prof->pr_off || (i = PC_TO_INDEX(pc, prof)) >= prof->pr_size) { - PROC_SUNLOCK(p); + PROC_PROFUNLOCK(p); goto out; } addr = prof->pr_base + i; - PROC_SUNLOCK(p); + PROC_PROFUNLOCK(p); PROC_UNLOCK(p); if (copyin(addr, &v, sizeof(v)) == 0) { v += ticks; diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fac0915..7fe5962 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -148,6 +148,8 @@ struct pargs { * q - td_contested lock * r - p_peers lock * t - thread lock + * u - process stat lock + * w - process timer lock * x - created at fork, only changes during single threading in exec * y - created at first aio, doesn't change until exit or exec at which * point we are single-threaded and only curthread changes it @@ -183,14 +185,14 @@ struct turnstile; * userland asks for rusage info. Backwards compatibility prevents putting * this directly in the user-visible rusage struct. * - * Locking for p_rux: (cj) means (j) for p_rux and (c) for p_crux. + * Locking for p_rux: (cu) means (u) for p_rux and (c) for p_crux. * Locking for td_rux: (t) for all fields. */ struct rusage_ext { - uint64_t rux_runtime; /* (cj) Real time. */ - uint64_t rux_uticks; /* (cj) Statclock hits in user mode. */ - uint64_t rux_sticks; /* (cj) Statclock hits in sys mode. */ - uint64_t rux_iticks; /* (cj) Statclock hits in intr mode. */ + uint64_t rux_runtime; /* (cu) Real time. */ + uint64_t rux_uticks; /* (cu) Statclock hits in user mode. */ + uint64_t rux_sticks; /* (cu) Statclock hits in sys mode. */ + uint64_t rux_iticks; /* (cu) Statclock hits in intr mode. */ uint64_t rux_uu; /* (c) Previous user time in usec. */ uint64_t rux_su; /* (c) Previous sys time in usec. */ uint64_t rux_tu; /* (c) Previous total time in usec. */ @@ -512,6 +514,9 @@ struct proc { LIST_ENTRY(proc) p_sibling; /* (e) List of sibling processes. */ LIST_HEAD(, proc) p_children; /* (e) Pointer to list of children. */ struct mtx p_mtx; /* (n) Lock for this struct. */ + struct mtx p_statmtx; /* Lock for the stats */ + struct mtx p_itimmtx; /* Lock for the virt/prof timers */ + struct mtx p_profmtx; /* Lock for the profiling */ struct ksiginfo *p_ksi; /* Locked by parent proc lock */ sigqueue_t p_sigqueue; /* (c) Sigs not delivered to a td. */ #define p_siglist p_sigqueue.sq_signals @@ -523,7 +528,7 @@ struct proc { u_int p_swtick; /* (c) Tick when swapped in or out. */ struct itimerval p_realtimer; /* (c) Alarm timer. */ struct rusage p_ru; /* (a) Exit information. */ - struct rusage_ext p_rux; /* (cj) Internal resource usage. */ + struct rusage_ext p_rux; /* (cu) Internal resource usage. */ struct rusage_ext p_crux; /* (c) Internal child resource usage. */ int p_profthreads; /* (c) Num threads in addupc_task. */ volatile int p_exitthreads; /* (j) Number of threads exiting */ @@ -609,6 +614,18 @@ struct proc { #define PROC_SUNLOCK(p) mtx_unlock_spin(&(p)->p_slock) #define PROC_SLOCK_ASSERT(p, type) mtx_assert(&(p)->p_slock, (type)) +#define PROC_STATLOCK(p) mtx_lock_spin(&(p)->p_statmtx) +#define PROC_STATUNLOCK(p) mtx_unlock_spin(&(p)->p_statmtx) +#define PROC_STATLOCK_ASSERT(p, type) mtx_assert(&(p)->p_statmtx, (type)) + +#define PROC_ITIMLOCK(p) mtx_lock_spin(&(p)->p_itimmtx) +#define PROC_ITIMUNLOCK(p) mtx_unlock_spin(&(p)->p_itimmtx) +#define PROC_ITIMLOCK_ASSERT(p, type) mtx_assert(&(p)->p_itimmtx, (type)) + +#define PROC_PROFLOCK(p) mtx_lock_spin(&(p)->p_profmtx) +#define PROC_PROFUNLOCK(p) mtx_unlock_spin(&(p)->p_profmtx) +#define PROC_PROFLOCK_ASSERT(p, type) mtx_assert(&(p)->p_profmtx, (type)) + /* These flags are kept in p_flag. */ #define P_ADVLOCK 0x00001 /* Process may hold a POSIX advisory lock. */ #define P_CONTROLT 0x00002 /* Has a controlling terminal. */ diff --git a/sys/sys/resourcevar.h b/sys/sys/resourcevar.h index 1a35a9e..b1e33f3 100644 --- a/sys/sys/resourcevar.h +++ b/sys/sys/resourcevar.h @@ -47,21 +47,22 @@ * Locking key: * b - created at fork, never changes * c - locked by proc mtx - * j - locked by proc slock * k - only accessed by curthread + * w - locked by proc itim lock + * w2 - locked by proc prof lock */ struct pstats { #define pstat_startzero p_cru struct rusage p_cru; /* Stats for reaped children. */ - struct itimerval p_timer[3]; /* (j) Virtual-time timers. */ + struct itimerval p_timer[3]; /* (w) Virtual-time timers. */ #define pstat_endzero pstat_startcopy #define pstat_startcopy p_prof struct uprof { /* Profile arguments. */ - caddr_t pr_base; /* (c + j) Buffer base. */ - u_long pr_size; /* (c + j) Buffer size. */ - u_long pr_off; /* (c + j) PC offset. */ - u_long pr_scale; /* (c + j) PC scaling. */ + caddr_t pr_base; /* (c + w2) Buffer base. */ + u_long pr_size; /* (c + w2) Buffer size. */ + u_long pr_off; /* (c + w2) PC offset. */ + u_long pr_scale; /* (c + w2) PC scaling. */ } p_prof; #define pstat_endcopy p_start struct timeval p_start; /* (b) Starting time. */ From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 12:53:48 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2ED9669 for ; Wed, 19 Nov 2014 12:53:48 +0000 (UTC) Received: from mail.issei-syoji.co.jp (mail.issei-syoji.co.jp [203.143.100.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3A44D164 for ; Wed, 19 Nov 2014 12:53:47 +0000 (UTC) Received: from SRVPEETERS (unknown [91.183.125.209]) by mail.issei-syoji.co.jp (Postfix) with ESMTP id 4613930877B for ; Wed, 19 Nov 2014 21:53:44 +0900 (JST) From: "Charles Benneth" Subject: Re: Product Inquiry To: freebsd-arch@freebsd.org MIME-Version: 1.0 Reply-To: elliota234@live.co.uk Date: Wed, 19 Nov 2014 13:53:54 +0100 Message-Id: <20141119125345.4613930877B@mail.issei-syoji.co.jp> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:53:48 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Good day, My Name is Mr Charles Bennett the Sales Manager off tong heer thiala= nd co LTD I Am Interested in some of your product could you kindly sen= d me your full catalog of products with clear photos, and list of FOB = prices in USD with prices,competitive prices for serious starting. Wai= ting your quick response. Best Regards TONG HEER ( EXPORT ) CO. LTD. Amata Nakorn Industrial Estate 700/553, Moo 7, T.Don Hua Roh, A.Maung,= Chonburi, 20000, Thailand Tel :+66 38 454 537-9 Fax :+66 38 454 327 From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 12:58:05 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8FBAAAE; Wed, 19 Nov 2014 12:58:04 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1361F3; Wed, 19 Nov 2014 12:58:03 +0000 (UTC) Received: from x23 (31.147.125.196) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Nov 2014 13:56:50 +0100 Date: Wed, 19 Nov 2014 13:56:51 +0100 From: Marko Zec To: "Alexander V. Chernikov" Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119135651.789c6766@x23> In-Reply-To: <546C8812.2070904@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.125.196] Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:58:05 -0000 On Wed, 19 Nov 2014 16:07:46 +0400 "Alexander V. Chernikov" wrote: ... > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? > This can probably help to make proper vnet fixes in less number of > attempts :) > > For example, even attach/detach is handled differently in different > places: > > tcp_subr.c: > /* Skip initialization of globals for non-default instances. > */ if (!IS_DEFAULT_VNET(curvnet)) > return; > in6_rmx.c: > /* > * Initialize our routing tree. > */ > static VNET_DEFINE(int, _in6_rt_was_here); > #define V__in6_rt_was_here VNET(_in6_rt_was_here) > > if (V__in6_rtwas_here == 0) { > callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE); > in6_mtutimo(curvnet); /* kick off timeout first > time */ V__in6_rt_was_here = 1; > } > > return (1); > } > > It would be great to get a bit more details on the following (at > least from my point of view): > * what is the proper procedure of handling non-default VNET > attach/detach (locking mostly) In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to invoke per-subsystem ctors / dtors on per-vnet basis. > * how can one properly cache needed VNET context (e.g. is it safe > just to save "struct vnet *" pointer) and is this right thing to do > at all? Caching a VNET context should be avoided, as it yields similar problems as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs which may disappear by the time the mbuf gets dequeued. > * Is it safe to to CURVNET_SET without holding any VNET locks ? Yes, if the VNET context is derived from some of the arguments in the current call graph. > P.S. I'm not against VIMAGE in any kind, I think we really should > move forward towards making it stable. > However, "just turn it on" concept with a bunch of known (and > unresolved issues) is not the best thing IMO. > > > > We have about 1 year until 11-RELEASE, so I think it is OK to do > > this. > > > > I would also add two items to my action plan. > > > > > > (6) Ask clusteradm to run one of the machines they use > > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and > > provide feedback. > > > > (7) Ask for help with testing from companies who have more > > involvement with the network stack. Two of the people in the CC: > > line of this e-mail work for such places. :) > > > > -- > > Craig > > > > > > -- > > Craig > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 14:05:41 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64E92E2A; Wed, 19 Nov 2014 14:05:41 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1F2BAE; Wed, 19 Nov 2014 14:05:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6BC1725D37D1; Wed, 19 Nov 2014 14:05:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 723E2C76FD7; Wed, 19 Nov 2014 14:05:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id wJgvp_sLs7Mu; Wed, 19 Nov 2014 14:05:35 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3DD82C76FCE; Wed, 19 Nov 2014 14:05:32 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 19 Nov 2014 14:05:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <362F742A-BA6F-483A-947C-62D4C5510F31@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 14:05:41 -0000 On 19 Nov 2014, at 03:28 , Craig Rodrigues wrote: >=20 > (6) Ask clusteradm to run one of the machines they use > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide > feedback. For people to use pf with VIMAGE we first MUST have the security fix = imported that I pointed out a couple of times in the past. It won=92t matter on the firewalls with just a VIMAGE enabled kernel but = using VIMAGE + pf inside a jail (once that really works if it doesn=92t = already) will allow everyone how can administer pf inside the jail to = take over the entire machine otherwise. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 19:21:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F891E32; Wed, 19 Nov 2014 19:21:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 746BD77F; Wed, 19 Nov 2014 19:21:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B32C1B93C; Wed, 19 Nov 2014 14:21:15 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: suspending threads before devices Date: Wed, 19 Nov 2014 14:08:20 -0500 Message-ID: <1580793.3ynJAbfVom@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Nov 2014 14:21:15 -0500 (EST) Cc: Konstantin Belousov , Andriy Gapon , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:21:17 -0000 On Tuesday, November 18, 2014 08:43:09 PM Warner Losh wrote: > On Nov 18, 2014, at 3:21 PM, John Baldwin wrote: > > I would certainly like a way to quiesce threads before entering the= real > > suspend path. I would also like to cleanly unmount filesystems dur= ing > > suspend as well and the thread issue is a prerequisite for that.=20= > > However, reusing "stop at boundary" may not be quite correct becaus= e you > > probably don't want to block suspend because you have an NFS reques= t that > > is retrying due to a down NFS server. For NFS I think you want any= > > threads asleep to just not get a chance to run again until after re= sume > > completes. >=20 > I=E2=80=99m almost certain you don=E2=80=99t want to =E2=80=9Cunmount= =E2=80=9D the filesystems. This would > invalidate all open file handles and would be mondo-bado, and would o= nly > succeed if you forced this issue due to all the open references. Perh= aps > you=E2=80=99re being imprecise. Yes, there should have been quotes around unmount. I want a=20 VFS_SUSPEND/VFS_RESUME that for local filesystems (e.g. UFS) does the o= n-disk=20 equivalent of unmount. (Flush dirty buffers and mark filesystem as cle= an.) =20 You really want this for S4 and even for S3 so you don't have to fsck i= f=20 resume fails. BTW, I think for network or userland filesystems you jus= t punt=20 on this (i.e. VFS_SUSPEND is a no-op or best-effort at most) --=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 19:59:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05387AAE; Wed, 19 Nov 2014 19:59:25 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC1EFB99; Wed, 19 Nov 2014 19:59:23 +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 sAJJxNJG080874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 11:59:23 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAJJxNGh080873; Wed, 19 Nov 2014 11:59:23 -0800 (PST) (envelope-from jmg) Date: Wed, 19 Nov 2014 11:59:23 -0800 From: John-Mark Gurney To: "Alexander V. Chernikov" Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119195923.GS24601@funkthat.com> Mail-Followup-To: "Alexander V. Chernikov" , Craig Rodrigues , FreeBSD Net , Alfred Perlstein , Warner Losh , "freebsd-virtualization@freebsd.org" , freebsd-arch References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546C8812.2070904@FreeBSD.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Wed, 19 Nov 2014 11:59:23 -0800 (PST) Cc: Craig Rodrigues , "freebsd-virtualization@freebsd.org" , FreeBSD Net , Alfred Perlstein , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:59:25 -0000 Alexander V. Chernikov wrote this message on Wed, Nov 19, 2014 at 16:07 +0400: > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? Yes, we need a man page talking about this feature first, how to enable it, compile it into the kernel, how to manage it, what subsystems it interacts w/, what sysctl nodes it provides, etc. W/o man page(s) the feature is not complete. $ man -k vnet revnetgroup(8) - generate reverse netgroup data $ man -k vimage XvCreateImage(3), XvShmCreateImage(3) - create an XvImage XvPutImage(3), XvShmPutImage(3) - display an XvImage hmm.. nope... jail has something about vnets, but not nearly enough to be useful... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 22:15:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29AD1675; Wed, 19 Nov 2014 22:15:36 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7D25E06; Wed, 19 Nov 2014 22:15:34 +0000 (UTC) X-AuditID: 1209190f-f79cb6d000005422-54-546d1552ba61 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.87.21538.2551D645; Wed, 19 Nov 2014 17:10:26 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sAJMAPZi006095; Wed, 19 Nov 2014 17:10:26 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAJMAN7g001385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Nov 2014 17:10:25 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAJMANhQ010243; Wed, 19 Nov 2014 17:10:23 -0500 (EST) Date: Wed, 19 Nov 2014 17:10:23 -0500 (EST) From: Benjamin Kaduk To: John Baldwin Subject: Re: suspending threads before devices In-Reply-To: <1580793.3ynJAbfVom@ralph.baldwin.cx> Message-ID: References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> <1580793.3ynJAbfVom@ralph.baldwin.cx> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrRskmhticOuSoMXs6dOYLPYeuc7s wOQx49N8lgDGKC6blNSczLLUIn27BK6MS1uWsRTsYK34tfA2ewPjSpYuRk4OCQETicvHjzJD 2GISF+6tZ+ti5OIQEpjNJHFuylomCGcjo8Tb55fZQKqEBA4xSdw5mgGRaGCU2HL6Hlg7i4C2 xJftLUwgNpuAisTMNxuBGjg4RASUJKZ+UwMJMwtYSixdcJ4RxBYW0JOYemcrmM0pYCQx4/Ez VhCbV8BRomnaSmaI+dsYJQ5fXw1WJCqgI7F6/xQWiCJBiZMzn7BADNWSWD59G8sERsFZSFKz kKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECA5QSf4djN8OKh1iFOBg VOLhffE2O0SINbGsuDL3EKMkB5OSKG/Er5wQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK87Jy5 IUK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8t4WBGgWLUtNTK9Iy c0oQ0kwcnCDDeYCG24mADC8uSMwtzkyHyJ9i1OVoaXrbyyTEkpeflyolzqsEUiQAUpRRmgc3 B5ZYXjGKA70lzMsBUsUDTEpwk14BLWECWjJnQybIkpJEhJRUA2OJ/a2kzfcY4zXWC69c7Ljf /Evbdp7frmm/HDv0BIz12qqZa2Y+Ozzz0IfuF56zn9SpTF7z9JzzrOmSMpP5WD8zfjwreUK4 dct7Qzs1QzFxrfo/aVdPMmg9e/+h58yU1xumP9Jr/WzI6m8nl8DOo7g36MVlb4PilJ8/Jz5/ GvXYQvXmKjnLmFlKLMUZiYZazEXFiQAay9zUBwMAAA== Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 22:15:36 -0000 On Wed, 19 Nov 2014, John Baldwin wrote: > Yes, there should have been quotes around unmount. I want a > VFS_SUSPEND/VFS_RESUME that for local filesystems (e.g. UFS) does the on-disk > equivalent of unmount. (Flush dirty buffers and mark filesystem as clean.) > You really want this for S4 and even for S3 so you don't have to fsck if > resume fails. BTW, I think for network or userland filesystems you just punt > on this (i.e. VFS_SUSPEND is a no-op or best-effort at most) Well, some network filesystems have things that could be done in this vein, but that would have to be at the filesystem layer, not in the VFS, I think. (E.g., OpenAFS has "disconnected mode".) -Ben From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 23:14:07 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87CB18F2; Wed, 19 Nov 2014 23:14:07 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D3367C; Wed, 19 Nov 2014 23:14:06 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so1370883lbv.24 for ; Wed, 19 Nov 2014 15:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=BrzUgkBksN2yvMlbd+anLBQC1tHhDjVGNHLtzyXveRw=; b=ityUjPieOr8zRykYuLY39pBz1+JT9t62I4AZT10rFx3b6123hrKH5u0Dt4O/6rWZVG q5HcJb0OiNp63OCu/gOgAC4DvqC59aCtjF+euW2y2d5o2sJhywjF88rxSBtGBJiamzna 75sX+IusRNTWMulaaufKQhNE0Bpjjewujgk8du05cq4sS/57CvBj5C5QrombybsezPt7 S5lA9WFDEF22udNQEjt8oQuyloBkhMlVI/gsc9pIqoA+2GTirRQyuaxWs24qspHR8I5K VsDv60zqIJtjFYPU8fd+lyTTFFZe0V0RhZT/8kpIlJNrg53/vyYzVxOQqp3cKKcujggk AJ+Q== MIME-Version: 1.0 X-Received: by 10.112.169.106 with SMTP id ad10mr44624026lbc.13.1416438843958; Wed, 19 Nov 2014 15:14:03 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 19 Nov 2014 15:14:03 -0800 (PST) In-Reply-To: <20141119195923.GS24601@funkthat.com> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> Date: Wed, 19 Nov 2014 15:14:03 -0800 X-Google-Sender-Auth: XhhWaC7yBsuP3aIDpEKdaZYuYv0 Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: Marko Zec , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:14:07 -0000 On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney wrote: > > Yes, we need a man page talking about this feature first, how to enable > it, compile it into the kernel, how to manage it, what subsystems it > interacts w/, what sysctl nodes it provides, etc. > Marko, Do you have any text which can be put into a vnet(9) man page? It doesn't have to be perfect, but just something that we can start from. I tried looking at some of the notes and presentations that you have done on VIMAGE: https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles but didn't see anything that could be readily turned into a man page. -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 00:33:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17068FA0; Thu, 20 Nov 2014 00:33:26 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5F3AEB3; Thu, 20 Nov 2014 00:33:25 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1DC3725D3A05; Thu, 20 Nov 2014 00:33:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BD343C76FE5; Thu, 20 Nov 2014 00:33:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id voukIar2mHY2; Thu, 20 Nov 2014 00:33:11 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 35A8CC76FCE; Thu, 20 Nov 2014 00:33:09 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 20 Nov 2014 00:33:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , Marko Zec , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 00:33:26 -0000 On 19 Nov 2014, at 23:14 , Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney = wrote: >=20 >>=20 >> Yes, we need a man page talking about this feature first, how to = enable >> it, compile it into the kernel, how to manage it, what subsystems it >> interacts w/, what sysctl nodes it provides, etc. >>=20 >=20 > Marko, >=20 > Do you have any text which can be put into a vnet(9) man page? > It doesn't have to be perfect, but just something that we can start = from. >=20 > I tried looking at some of the notes and presentations that you have = done > on VIMAGE: > = https://wiki.freebsd.org/?action=3Dfullsearch&context=3D180&value=3DVIMAGE= &titlesearch=3DTitles >=20 > but didn=92t see anything that could be readily turned into a man = page. https://people.freebsd.org/~bz/20100530-02.vnet.9.html The man page should be in that perforce branch you converted to github. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 08:48:35 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9FAF1C7; Thu, 20 Nov 2014 08:48:35 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99B65637; Thu, 20 Nov 2014 08:48:35 +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 sAK8mXIY090654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 00:48:33 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAK8mXaT090653; Thu, 20 Nov 2014 00:48:33 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 00:48:33 -0800 From: John-Mark Gurney To: Adrian Chadd Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141120084832.GE24601@funkthat.com> Mail-Followup-To: Adrian Chadd , arch@FreeBSD.org References: <201411200552.sAK5qnXP063073@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411200552.sAK5qnXP063073@svn.freebsd.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Thu, 20 Nov 2014 00:48:33 -0800 (PST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 08:48:35 -0000 Adrian Chadd wrote this message on Thu, Nov 20, 2014 at 05:52 +0000: > Author: adrian > Date: Thu Nov 20 05:52:48 2014 > New Revision: 274739 > URL: https://svnweb.freebsd.org/changeset/base/274739 > > Log: > Include a random device. > > Modified: > head/sys/mips/conf/MALTA > > Modified: head/sys/mips/conf/MALTA > ============================================================================== > --- head/sys/mips/conf/MALTA Thu Nov 20 05:31:41 2014 (r274738) > +++ head/sys/mips/conf/MALTA Thu Nov 20 05:52:48 2014 (r274739) > @@ -68,3 +68,4 @@ device miibus > device bpf > device md > device uart > +device random Should we make random standard now? We don't live in the 90's anymore, and a system really can't function w/o randomness anymore... I'm fine w/ making the various random mixers options, but the core random infrastructure and /dev/u?random should be standard now... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 10:08:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41001F26; Thu, 20 Nov 2014 10:08:26 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF9F0F23; Thu, 20 Nov 2014 10:08:25 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id f15so544924lbj.27 for ; Thu, 20 Nov 2014 02:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ekyEPaGHxvs0/gVvVYUMMOj/Eb6uRdJcntP4d89m2Zk=; b=Al/dYUuZsJbQ4Yq0ciaxa4DnUg79Dsw5Mm1nKaZzOaA0t1F02fp1iR+goz2g5nbzBU nzW4uwz7rfyWn0YBlPfQ81PmNlarv9mYj83Bw2osXoFnSevfDPybLB+yfiVAtbAyuKoo dt4xIXAL2M5un/Q5mCRbS7V+1RdWLCTn0+YbXw65JCcMO7EUZgLl5r+xyKUwMh8P9qVc F13eIrLvDCIsiDqkwV5d9zaIVFnq7tHXODzki0mlaojgoqT11w5EzjEchEoM1OYuxpAr rS2lruwkUQ6BpJ9fghe6E3qRjRoweYVC29qhZadQ6mrUV/n2sT88M39Ku6YwiKF8OncN PMoA== MIME-Version: 1.0 X-Received: by 10.152.179.1 with SMTP id dc1mr1227131lac.88.1416478103851; Thu, 20 Nov 2014 02:08:23 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 02:08:23 -0800 (PST) In-Reply-To: <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> Date: Thu, 20 Nov 2014 02:08:23 -0800 X-Google-Sender-Auth: jAvs6Val3Yu-p9qKy2mJbwKpEtk Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Marko Zec , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 10:08:26 -0000 On Wed, Nov 19, 2014 at 4:33 PM, Bjoern A. Zeeb wrote: > > > https://people.freebsd.org/~bz/20100530-02.vnet.9.html > > The man page should be in that perforce branch you converted to github. > Thank you for pointing that out. It is indeed in github: https://github.com/rodrigc/bz-vimage/tree/master/share/man/man9 I committed it to HEAD: https://lists.freebsd.org/pipermail/svn-src-all/2014-November/095037.html I used the textproc/igor port ( http://www.wonkity.com/~wblock/igor/ ) to check the syntax of the man page. It's a great new utility written by wblock@ and I encourage anyone creating or modifying man pages should run it. -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 11:04:48 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACCF8F99 for ; Thu, 20 Nov 2014 11:04:48 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 02AB8844 for ; Thu, 20 Nov 2014 11:04:47 +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 NAA12240; Thu, 20 Nov 2014 13:06:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XrPXZ-000602-Dv; Thu, 20 Nov 2014 13:04:45 +0200 Message-ID: <546DCA96.7040807@FreeBSD.org> Date: Thu, 20 Nov 2014 13:03:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua> <54666FD5.6080705@FreeBSD.org> <20141115105819.GJ17068@kib.kiev.ua> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> In-Reply-To: <20141115180014.GK17068@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 11:04:48 -0000 On 15/11/2014 20:00, Konstantin Belousov wrote: > Anyway, this requires real coding to experiment. I started looking at > it since I did somewhat related changes now. Good news :) Thanks a lot! -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 14:28:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1145B8B3; Thu, 20 Nov 2014 14:28:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60D19DF; Thu, 20 Nov 2014 14:28:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAKES7sq054818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 16:28:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAKES7sq054818 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAKES6ex054817; Thu, 20 Nov 2014 16:28:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 20 Nov 2014 16:28:06 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: suspending threads before devices Message-ID: <20141120142806.GJ17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> <1580793.3ynJAbfVom@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1580793.3ynJAbfVom@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Andriy Gapon , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 14:28:18 -0000 On Wed, Nov 19, 2014 at 02:08:20PM -0500, John Baldwin wrote: > On Tuesday, November 18, 2014 08:43:09 PM Warner Losh wrote: > > On Nov 18, 2014, at 3:21 PM, John Baldwin wrote: > > > I would certainly like a way to quiesce threads before entering the real > > > suspend path. I would also like to cleanly unmount filesystems during > > > suspend as well and the thread issue is a prerequisite for that. > > > However, reusing "stop at boundary" may not be quite correct because you > > > probably don't want to block suspend because you have an NFS request that > > > is retrying due to a down NFS server. For NFS I think you want any > > > threads asleep to just not get a chance to run again until after resume > > > completes. > > > > I???m almost certain you don???t want to ???unmount??? the filesystems. This would > > invalidate all open file handles and would be mondo-bado, and would only > > succeed if you forced this issue due to all the open references. Perhaps > > you???re being imprecise. > > Yes, there should have been quotes around unmount. I want a > VFS_SUSPEND/VFS_RESUME that for local filesystems (e.g. UFS) does the on-disk > equivalent of unmount. (Flush dirty buffers and mark filesystem as clean.) > You really want this for S4 and even for S3 so you don't have to fsck if > resume fails. BTW, I think for network or userland filesystems you just punt > on this (i.e. VFS_SUSPEND is a no-op or best-effort at most) I think I will use MNT_LOCAL for start. Filesystems would come out clean, but still marked mounted. We cannot avoid fsck, e.g. due to unlinked opened files. I think it is fine to guarantee that the volume is in best-possible persistent state, i.e. no filesystem structure damage could happen if resume failed, but fsck might be still needed. VFS_SYNC() would do this. Below is the prototyped patch for global process suspension. There is debugging sysctl debug.total_stop, which demonstrates the KPI, also I used it for light testing. It successfully survived suspend/resume of usermode threads in multiuser with mt processes running. diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 7ae7d4e..19c33b6 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -289,7 +289,7 @@ kern_execve(td, args, mac_p) args->endp - args->begin_envv); if (p->p_flag & P_HADTHREADS) { PROC_LOCK(p); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p, SINGLE_BOUNDARY)) { PROC_UNLOCK(p); exec_free_args(args); return (ERESTART); /* Try again later. */ @@ -308,9 +308,9 @@ kern_execve(td, args, mac_p) * force other threads to suicide. */ if (error == 0) - thread_single(SINGLE_EXIT); + thread_single(p, SINGLE_EXIT); else - thread_single_end(); + thread_single_end(p, SINGLE_BOUNDARY); PROC_UNLOCK(p); } if ((td->td_pflags & TDP_EXECVMSPC) != 0) { diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 1e4c095..b58e830 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -206,7 +206,7 @@ exit1(struct thread *td, int rv) * re-check all suspension request, the thread should * either be suspended there or exit. */ - if (!thread_single(SINGLE_EXIT)) + if (!thread_single(p, SINGLE_EXIT)) break; /* diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 62f43ba..80d7f82 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -317,7 +317,7 @@ fork_norfproc(struct thread *td, int flags) if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p1, SINGLE_BOUNDARY)) { PROC_UNLOCK(p1); return (ERESTART); } @@ -348,7 +348,7 @@ fail: if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - thread_single_end(); + thread_single_end(p1, SINGLE_BOUNDARY); PROC_UNLOCK(p1); } return (error); diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 495139f..9f28ae5 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2893,3 +2893,114 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_OSREL, osrel, CTLFLAG_RW | static SYSCTL_NODE(_kern_proc, KERN_PROC_SIGTRAMP, sigtramp, CTLFLAG_RD | CTLFLAG_MPSAFE, sysctl_kern_proc_sigtramp, "Process signal trampoline location"); + +void +proc_stop_total(void) +{ + struct proc *cp, *p; + int r; + bool restart, met_stopped, did_stop; + + cp = curproc; +allproc_loop: + sx_xlock(&allproc_lock); + met_stopped = did_stop = restart = false; + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & (P_KTHREAD | P_SYSTEM | + P_TOTAL_STOP)) != 0) { + PROC_UNLOCK(p); + continue; + } + if (P_SHOULDSTOP(p)) { + /* + * Stopped processes are only tolerated when + * there is no other processes which might + * continue them. + */ + met_stopped = true; + PROC_UNLOCK(p); + continue; + } + _PHOLD(p); + sx_xunlock(&allproc_lock); + r = thread_single(p, SINGLE_TOTAL); + if (r != 0) + restart = true; + else + did_stop = true; + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } + sx_xunlock(&allproc_lock); + if (restart || (met_stopped && did_stop)) { + kern_yield(PRI_USER); + goto allproc_loop; + } +} + +void +proc_resume_total(void) +{ + struct proc *cp, *p; + + cp = curproc; + sx_xlock(&allproc_lock); + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & P_TOTAL_STOP) != 0) { + sx_xunlock(&allproc_lock); + _PHOLD(p); + thread_single_end(p, SINGLE_TOTAL); + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } else { + PROC_UNLOCK(p); + } + } + sx_xunlock(&allproc_lock); +} + +#define TOTAL_STOP_DEBUG 1 +#ifdef TOTAL_STOP_DEBUG +volatile static int ts_resume; + +static int +sysctl_debug_total_stop(SYSCTL_HANDLER_ARGS) +{ + int error, val; + + val = 0; + ts_resume = 0; + error = sysctl_handle_int(oidp, &val, 0, req); + if (error != 0 || req->newptr == NULL) + return (error); + if (val != 0) { + proc_stop_total(); + while (ts_resume == 0) + ; + proc_resume_total(); + } + return (0); +} + +SYSCTL_PROC(_debug, OID_AUTO, total_stop, CTLTYPE_INT | CTLFLAG_RW | + CTLFLAG_MPSAFE, (void *)&ts_resume, 0, sysctl_debug_total_stop, "I", + ""); +#endif diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 5cdc2ce..eb00129 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2919,7 +2919,7 @@ sigexit(td, sig) * XXX If another thread attempts to single-thread before us * (e.g. via fork()), we won't get a dump at all. */ - if ((sigprop(sig) & SA_CORE) && (thread_single(SINGLE_NO_EXIT) == 0)) { + if ((sigprop(sig) & SA_CORE) && thread_single(p, SINGLE_NO_EXIT) == 0) { p->p_sig = sig; /* * Log signals which would cause core dumps diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index ec084ed..92643d5 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -64,6 +64,7 @@ __FBSDID("$FreeBSD$"); SDT_PROVIDER_DECLARE(proc); SDT_PROBE_DEFINE(proc, , , lwp__exit); +static void thread_suspend_switch_ext(struct thread *td, struct proc *p); /* * thread related storage. @@ -446,7 +447,7 @@ thread_exit(void) if (p->p_numthreads == p->p_suspcount) { thread_lock(p->p_singlethread); wakeup_swapper = thread_unsuspend_one( - p->p_singlethread); + p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -575,13 +576,20 @@ calc_remaining(struct proc *p, int mode) remaining = p->p_numthreads; else if (mode == SINGLE_BOUNDARY) remaining = p->p_numthreads - p->p_boundary_count; - else if (mode == SINGLE_NO_EXIT) + else if (mode == SINGLE_NO_EXIT || mode == SINGLE_TOTAL) remaining = p->p_numthreads - p->p_suspcount; else panic("calc_remaining: wrong mode %d", mode); return (remaining); } +static int +remain_for_mode(int mode) +{ + + return (mode == SINGLE_TOTAL ? 0 : 1); +} + /* * Enforce single-threading. * @@ -596,19 +604,20 @@ calc_remaining(struct proc *p, int mode) * any sleeping threads that are interruptable. (PCATCH). */ int -thread_single(int mode) +thread_single(struct proc *p, int mode) { struct thread *td; struct thread *td2; - struct proc *p; int remaining, wakeup_swapper; td = curthread; - p = td->td_proc; + KASSERT((mode == SINGLE_TOTAL && td->td_proc != p) || + (mode != SINGLE_TOTAL && td->td_proc == p), + ("mode %d proc %p curproc %p", mode, p, td->td_proc)); mtx_assert(&Giant, MA_NOTOWNED); PROC_LOCK_ASSERT(p, MA_OWNED); - if ((p->p_flag & P_HADTHREADS) == 0) + if ((p->p_flag & P_HADTHREADS) == 0 && mode != SINGLE_TOTAL) return (0); /* Is someone already single threading? */ @@ -625,11 +634,13 @@ thread_single(int mode) else p->p_flag &= ~P_SINGLE_BOUNDARY; } + if (mode == SINGLE_TOTAL) + p->p_flag |= P_TOTAL_STOP; p->p_flag |= P_STOPPED_SINGLE; PROC_SLOCK(p); p->p_singlethread = td; remaining = calc_remaining(p, mode); - while (remaining != 1) { + while (remaining != remain_for_mode(mode)) { if (P_SHOULDSTOP(p) != P_STOPPED_SINGLE) goto stopme; wakeup_swapper = 0; @@ -643,7 +654,8 @@ thread_single(int mode) case SINGLE_EXIT: if (TD_IS_SUSPENDED(td2)) wakeup_swapper |= - thread_unsuspend_one(td2); + thread_unsuspend_one(td2, + p); if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR)) wakeup_swapper |= @@ -653,17 +665,20 @@ thread_single(int mode) if (TD_IS_SUSPENDED(td2) && !(td2->td_flags & TDF_BOUNDARY)) wakeup_swapper |= - thread_unsuspend_one(td2); + thread_unsuspend_one(td2, + p); if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR)) wakeup_swapper |= sleepq_abort(td2, ERESTART); break; + case SINGLE_TOTAL: case SINGLE_NO_EXIT: if (TD_IS_SUSPENDED(td2) && !(td2->td_flags & TDF_BOUNDARY)) wakeup_swapper |= - thread_unsuspend_one(td2); + thread_unsuspend_one(td2, + p); if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR)) wakeup_swapper |= @@ -687,7 +702,7 @@ thread_single(int mode) /* * Maybe we suspended some threads.. was it enough? */ - if (remaining == 1) + if (remaining == remain_for_mode(mode)) break; stopme: @@ -695,7 +710,10 @@ stopme: * Wake us up when everyone else has suspended. * In the mean time we suspend as well. */ - thread_suspend_switch(td); + if (mode == SINGLE_TOTAL) + thread_suspend_switch_ext(td, p); + else + thread_suspend_switch(td); remaining = calc_remaining(p, mode); } if (mode == SINGLE_EXIT) { @@ -821,7 +839,7 @@ thread_suspend_check(int return_instead) if (p->p_numthreads == p->p_suspcount + 1) { thread_lock(p->p_singlethread); wakeup_swapper = - thread_unsuspend_one(p->p_singlethread); + thread_unsuspend_one(p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -882,6 +900,27 @@ thread_suspend_switch(struct thread *td) PROC_SLOCK(p); } +static void +thread_suspend_switch_ext(struct thread *td, struct proc *p) +{ + + KASSERT(!TD_IS_SUSPENDED(td), ("already suspended")); + PROC_LOCK_ASSERT(p, MA_OWNED); + PROC_SLOCK_ASSERT(p, MA_OWNED); + PROC_UNLOCK(p); + thread_lock(td); + td->td_flags &= ~TDF_NEEDSUSPCHK; + TD_SET_SUSPENDED(td); + sched_sleep(td, 0); + PROC_SUNLOCK(p); + DROP_GIANT(); + mi_switch(SW_VOL | SWT_SUSPEND, NULL); + thread_unlock(td); + PICKUP_GIANT(); + PROC_LOCK(p); + PROC_SLOCK(p); +} + void thread_suspend_one(struct thread *td) { @@ -897,15 +936,16 @@ thread_suspend_one(struct thread *td) } int -thread_unsuspend_one(struct thread *td) +thread_unsuspend_one(struct thread *td, struct proc *p) { - struct proc *p = td->td_proc; - PROC_SLOCK_ASSERT(p, MA_OWNED); THREAD_LOCK_ASSERT(td, MA_OWNED); KASSERT(TD_IS_SUSPENDED(td), ("Thread not suspended")); TD_CLR_SUSPENDED(td); - p->p_suspcount--; + if (td->td_proc == p) { + PROC_SLOCK_ASSERT(p, MA_OWNED); + p->p_suspcount--; + } return (setrunnable(td)); } @@ -925,7 +965,7 @@ thread_unsuspend(struct proc *p) FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } @@ -936,9 +976,12 @@ thread_unsuspend(struct proc *p) * threading request. Now we've downgraded to single-threaded, * let it continue. */ - thread_lock(p->p_singlethread); - wakeup_swapper = thread_unsuspend_one(p->p_singlethread); - thread_unlock(p->p_singlethread); + if (p->p_singlethread->td_proc == p) { + thread_lock(p->p_singlethread); + wakeup_swapper = thread_unsuspend_one( + p->p_singlethread, p); + thread_unlock(p->p_singlethread); + } } if (wakeup_swapper) kick_proc0(); @@ -948,16 +991,14 @@ thread_unsuspend(struct proc *p) * End the single threading mode.. */ void -thread_single_end(void) +thread_single_end(struct proc *p, int mode) { struct thread *td; - struct proc *p; int wakeup_swapper; - td = curthread; - p = td->td_proc; PROC_LOCK_ASSERT(p, MA_OWNED); - p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY); + p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY | + P_TOTAL_STOP); PROC_SLOCK(p); p->p_singlethread = NULL; wakeup_swapper = 0; @@ -967,11 +1008,11 @@ thread_single_end(void) * on the process. The single threader must be allowed * to continue however as this is a bad place to stop. */ - if ((p->p_numthreads != 1) && (!P_SHOULDSTOP(p))) { + if (p->p_numthreads != remain_for_mode(mode) && !P_SHOULDSTOP(p)) { FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fac0915..161223b 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -635,7 +635,7 @@ struct proc { #define P_SINGLE_BOUNDARY 0x400000 /* Threads should suspend at user boundary. */ #define P_HWPMC 0x800000 /* Process is using HWPMCs */ #define P_JAILED 0x1000000 /* Process is in jail. */ -#define P_UNUSED1 0x2000000 +#define P_TOTAL_STOP 0x2000000 /* Stopped in proc_stop_total. */ #define P_INEXEC 0x4000000 /* Process is in execve(). */ #define P_STATCHILD 0x8000000 /* Child process stopped or exited. */ #define P_INMEM 0x10000000 /* Loaded into memory. */ @@ -696,6 +696,7 @@ struct proc { #define SINGLE_NO_EXIT 0 #define SINGLE_EXIT 1 #define SINGLE_BOUNDARY 2 +#define SINGLE_TOTAL 3 #ifdef MALLOC_DECLARE MALLOC_DECLARE(M_PARGS); @@ -899,6 +900,8 @@ struct proc *proc_realparent(struct proc *child); void proc_reap(struct thread *td, struct proc *p, int *status, int options); void proc_reparent(struct proc *child, struct proc *newparent); struct pstats *pstats_alloc(void); +void proc_stop_total(void); +void proc_resume_total(void); void pstats_fork(struct pstats *src, struct pstats *dst); void pstats_free(struct pstats *ps); int securelevel_ge(struct ucred *cr, int level); @@ -945,8 +948,8 @@ void thread_exit(void) __dead2; void thread_free(struct thread *td); void thread_link(struct thread *td, struct proc *p); void thread_reap(void); -int thread_single(int how); -void thread_single_end(void); +int thread_single(struct proc *p, int how); +void thread_single_end(struct proc *p, int how); void thread_stash(struct thread *td); void thread_stopped(struct proc *p); void childproc_stopped(struct proc *child, int reason); @@ -957,7 +960,7 @@ void thread_suspend_switch(struct thread *); void thread_suspend_one(struct thread *td); void thread_unlink(struct thread *td); void thread_unsuspend(struct proc *p); -int thread_unsuspend_one(struct thread *td); +int thread_unsuspend_one(struct thread *td, struct proc *p); void thread_wait(struct proc *p); struct thread *thread_find(struct proc *p, lwpid_t tid); From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 17:33:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35E1B610; Thu, 20 Nov 2014 17:33:42 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 7C59C706; Thu, 20 Nov 2014 17:33:40 +0000 (UTC) Message-ID: <546E25D1.7020900@FreeBSD.org> Date: Thu, 20 Nov 2014 20:33:05 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, "freebsd-net@freebsd.org" Subject: [RFC] add macros for ifnet statistic accounting Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:33:42 -0000 Hi All, we already did some changes in network stack in head/, that made ability for merging changes into stable branches much harder. What you think about adding the following macro to head/: --- if_var.h (revision 274736) +++ if_var.h (working copy) @@ -111,6 +111,10 @@ typedef enum { IFCOUNTERS /* Array size. */ } ift_counter; +#define IFSTAT_ADD(ifp, name, value) \ + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) + typedef struct ifnet * if_t; typedef void (*if_start_fn_t)(if_t); And then make a direct commit to stable/* branches like this: --- if_var.h (revision 274750) +++ if_var.h (working copy) @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* #define V_link_pfil_hook VNET(link_pfil_hook) #endif /* _KERNEL */ +#define IFSTAT_ADD(ifp, name, value) \ + IFSTAT_ ## name ## _ADD(ifp, value) +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) + +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets += (inc) +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors += (inc) +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets += (inc) +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors += (inc) +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += (inc) +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes += (inc) +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes += (inc) +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts += (inc) +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts += (inc) +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops += (inc) +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto += (inc) + /* * Structure defining a queue for a network interface. */ This can make merging a little bit easier, at least for generic code in the network stack. -- WBR, Andrey V. Elsukov From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 17:38:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5510D8AD; Thu, 20 Nov 2014 17:38:15 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC6F9CD7; Thu, 20 Nov 2014 17:38:14 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k14so4327879wgh.23 for ; Thu, 20 Nov 2014 09:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q50DR4LGOujL0xdyTYIedS3eA7gTH85frbwPt9RIlkc=; b=EPgtGo7yIsB5sI7cFEUl0gniTrZohTnH1rQFzNPqkXivhqYgj/4w7/+SMr8c6Coe3g LSbtvw3TBxHFMB9ufOVYuVrCZOPharJYVSzusEM0wN05aCMoHu/s4f7p2UijVHbLOiRX jpeGbsVhGtVnvppv5JMgAErCCqnn223yrlclizFFT15RxbdM1hWWAFHF8Irvt7G3usEV ZJ1N083pGbGuMQBFNe0Xd5EZjX1U69I/jLNwh8aMuSrU3iznZGdOPKcBnA4mzeCr0Z7V GA9B96FFsiXnXSRhtF635bf6RciRf3XTyxLY+ovART/i3LY3JJivDXmFrw8S2nerLgbf uFiw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr72135090wjz.20.1416505093204; Thu, 20 Nov 2014 09:38:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 20 Nov 2014 09:38:13 -0800 (PST) In-Reply-To: <546E25D1.7020900@FreeBSD.org> References: <546E25D1.7020900@FreeBSD.org> Date: Thu, 20 Nov 2014 09:38:13 -0800 X-Google-Sender-Auth: hw_kjtOUwa-S-BmMEWPQyxWsnx4 Message-ID: Subject: Re: [RFC] add macros for ifnet statistic accounting From: Adrian Chadd To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:38:15 -0000 I like accessor things like this. It'll make the general porting of things across places more feasible. +1 from me. -adrian On 20 November 2014 09:33, Andrey V. Elsukov wrote: > Hi All, > > we already did some changes in network stack in head/, that made ability > for merging changes into stable branches much harder. > > What you think about adding the following macro to head/: > > --- if_var.h (revision 274736) > +++ if_var.h (working copy) > @@ -111,6 +111,10 @@ typedef enum { > IFCOUNTERS /* Array size. */ > } ift_counter; > > +#define IFSTAT_ADD(ifp, name, value) \ > + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) > +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) > + > typedef struct ifnet * if_t; > > typedef void (*if_start_fn_t)(if_t); > > > And then make a direct commit to stable/* branches like this: > > --- if_var.h (revision 274750) > +++ if_var.h (working copy) > @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* > #define V_link_pfil_hook VNET(link_pfil_hook) > #endif /* _KERNEL */ > > +#define IFSTAT_ADD(ifp, name, value) \ > + IFSTAT_ ## name ## _ADD(ifp, value) > +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) > + > +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets += (inc) > +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors += (inc) > +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets += (inc) > +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors += (inc) > +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += (inc) > +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes += (inc) > +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes += (inc) > +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts += (inc) > +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts += (inc) > +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops += (inc) > +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ > +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto += (inc) > + > /* > * Structure defining a queue for a network interface. > */ > > This can make merging a little bit easier, at least for generic code in > the network stack. > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > 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-arch@FreeBSD.ORG Thu Nov 20 18:07:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F58DA53; Thu, 20 Nov 2014 18:07:36 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A46BED2; Thu, 20 Nov 2014 18:07:35 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hz20so2821554lab.20 for ; Thu, 20 Nov 2014 10:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=tFFKI6JR2xalCMzQyjPJ2FLLwUoR7ngwdpMvbVZZIZs=; b=yZlm9h4q1MmPeMw8SfFWYUKOfPdckoeyhVFGSubIGhb0uLYP7iQHmS1+vYSd1WNERz kJXNhoRtqtX8GRdxIThApc5I0NfRNzF1yFcJpgr7D2U8Bct22h8f157iY8odCzJ0MEuI /OVjiWp1RKPT2WoOmY6ZOEts7C4izzX54H10PfElmBCapYvqvKHTIHUVALUpN3FBkFWk alb/QS82HVqRli1J2IUGxy/lFWbS0jAgARvKxMjcq16Kooo3Xu2h/YjcHUyscO9XT+rd 1OOdPbrdrGUwQC0Z0nAkziENGCMPtogPl0BCC9dwlQNZBDPoZBq0MbjrLNf9tRGmKFTg UwwQ== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr12556323lbb.47.1416506853187; Thu, 20 Nov 2014 10:07:33 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Thu, 20 Nov 2014 10:07:33 -0800 (PST) Date: Thu, 20 Nov 2014 10:07:33 -0800 X-Google-Sender-Auth: FuQzAL6KAc12PdfjdXlO_eFU5Lo Message-ID: Subject: VIMAGE + pf security fix? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 18:07:36 -0000 On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > > For people to use pf with VIMAGE we first MUST have the security fix > imported that I pointed out a couple of times in the past. > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 I see the security issue mentioned, but I can't find the patch that fixes the problem. Where is the patch? Thanks. -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 19:32:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D520717F for ; Thu, 20 Nov 2014 19:32:36 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF5C0A3 for ; Thu, 20 Nov 2014 19:32:36 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id C04D3193964 for ; Thu, 20 Nov 2014 19:32:35 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch In-Reply-To: References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> <1416246960.1248.22.camel@bruno> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MafKulHa2/+dxLlid6QL" Date: Thu, 20 Nov 2014 11:32:34 -0800 Message-ID: <1416511954.7423.28.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 19:32:36 -0000 --=-MafKulHa2/+dxLlid6QL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > This is one of the many reasons I expected you to copy these > binaries over the native ones rather than have them in a side tree. >=20 > Warner Been trying to resolve the linking issues when copying the native-xtools tool chain target binaries into my chroots. I don't think binutils is getting setup correctly to handle the final linking as I see a lot of crt1.o errors, bison being the most obvious here. https://people.freebsd.org/~sbruno/bison_config_log.txt It looks like the linking stage is trying to assemble amd64 here? configure:8450: checking lex library configure:8464: cc -std=3Dgnu99 -o conftest -pipe -G0 -g -fno-strict-alias= ing -I/usr/local/include -D_THREAD_SAFE -L/usr/local/lib conftest.c >&5 /usr/lib/crt1.o: In function `__start': crt1.c:(.text+0x190): undefined reference to `main' crt1.c:(.text+0x194): undefined reference to `main' configure:8464: $? =3D 1 configure: failed program w sean --=-MafKulHa2/+dxLlid6QL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUbkHSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kaR4IAJT1qvEqMpFTp7QgAD7J2WDa gf0/zvoIDX8b7UtR+m3357J3/1J6tSrFkX/21zPeW7mTe31oDFDbGgLiSmY0YP1u ll9W/31805q8tlPijN+h4Gko/9Vh1LsJT4zfgDttlIfGKySbxOuRENJctt3TkgqJ yAeSOS23+ZgJAkI8SHtwyM9+Qo8FsjekWROahvfW/5eMz9+bNyISXgeb/2B/IOpS +wMazhrAWq5zK7arv4rlc11hpCN1Vc6HU8PzXT4mnnoKFFYI02BxWia+wA/tb0M6 xFxl9swFfbdo7DDfrgxoJwnbBcWozUHhBdOaPGIDTmHzic9lpaUBLItdpTkEsp0= =yn0Q -----END PGP SIGNATURE----- --=-MafKulHa2/+dxLlid6QL-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 21:12:01 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 312DB667 for ; Thu, 20 Nov 2014 21:12:01 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C824D51 for ; Thu, 20 Nov 2014 21:12:00 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id F1954193964 for ; Thu, 20 Nov 2014 21:11:58 +0000 (UTC) Subject: Re: mips misbehaving, not respecting make.conf From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch In-Reply-To: <1416511954.7423.28.camel@bruno> References: <1416179733.1098.1200.camel@bruno> <2A2AD781-06B3-4450-9631-D83822016D0B@bsdimp.com> <1416183055.1098.1205.camel@bruno> <7C1D8D61-0486-4783-A3E2-73189AE83023@bsdimp.com> <1416193104.1098.1207.camel@bruno> <80ABD62A-DF08-4CF6-A4C6-B2AFC6E3CF21@gmail.com> <1416246960.1248.22.camel@bruno> <1416511954.7423.28.camel@bruno> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AOn8xvdX1HJ8it4ML4dq" Date: Thu, 20 Nov 2014 13:11:57 -0800 Message-ID: <1416517917.7423.31.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 21:12:01 -0000 --=-AOn8xvdX1HJ8it4ML4dq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2014-11-20 at 11:32 -0800, Sean Bruno wrote: > > This is one of the many reasons I expected you to copy these > > binaries over the native ones rather than have them in a side tree. > >=20 > > Warner >=20 > Been trying to resolve the linking issues when copying the native-xtools > tool chain target binaries into my chroots. I don't think binutils is > getting setup correctly to handle the final linking as I see a lot of > crt1.o errors, bison being the most obvious here. >=20 > https://people.freebsd.org/~sbruno/bison_config_log.txt >=20 > It looks like the linking stage is trying to assemble amd64 here? >=20 > configure:8450: checking lex library > configure:8464: cc -std=3Dgnu99 -o conftest -pipe -G0 -g -fno-strict-ali= asing -I/usr/local/include -D_THREAD_SAFE -L/usr/local/lib conftest.c >&= 5 > /usr/lib/crt1.o: In function `__start': > crt1.c:(.text+0x190): undefined reference to `main' > crt1.c:(.text+0x194): undefined reference to `main' > configure:8464: $? =3D 1 > configure: failed program w >=20 > sean Simply abusing the path in login.conf, profile and cshrc things will manifest this for me, e.g. placing /nxb-bin/bin /nxb-bin/usr/bin etc first in path variables. I don't think this is directly related to my copying of the native-xtools target binaries into the jail. sean --=-AOn8xvdX1HJ8it4ML4dq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUblkdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kIBgIAKhEpUocUQTb2hHqp3Pi3/fR d0kw4oI5mkg/tBSRHlRPLDKJP0tATm0qXoHoW+W3sbzJAxFXGBnXNq2cYjsv2wfM 85XuKyes017gfj2uw2bugj+RJu4C2IAcaTmqGsciCvrRsLFsw0Sks3dGX6UA/ssZ AC/cxdhgwiF717dQj1VUPVnhLyYyjaBzM1WqPqhPCsQt8hqKg0WNrbmLlI/Wl4+2 P1vBBVDyAWa2aSU8MC0qAeDixjDLjl5fcYceNubue/xECIbPg7QVa9xiLsgraIMp fszV5Ft3TOgiPFI72JMx3VPNNkdbMgT5m57nbImPipPnFMKJw6DedYvBjH968K4= =oSGz -----END PGP SIGNATURE----- --=-AOn8xvdX1HJ8it4ML4dq-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 21:32:32 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E969C2E4 for ; Thu, 20 Nov 2014 21:32:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C52BDF71 for ; Thu, 20 Nov 2014 21:32:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BF10AB968 for ; Thu, 20 Nov 2014 16:32:30 -0500 (EST) From: John Baldwin To: arch@freebsd.org Subject: I'd like to axe some drivers Date: Thu, 20 Nov 2014 16:31:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201411201631.27556.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Nov 2014 16:32:30 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 21:32:32 -0000 I'm >< close to removing timeout/untimeout from the tree. As part of this I have updated several older drivers to use callout(9), but most of those patches were untested. Keeping old code around that no one uses does add future work as tree-wide API changes are made as well as things like locking (note that several of these drivers weren't locked until I recently changed them). To that end, here is my short list of things that I think we can bid farewell to in 11. Note that many of these are for ISA devices. asr(4): This is a driver for a set of older Adaptec PCI RAID adapters. This driver is _really_ crufty and is the only thing I didn't convert to callout(9) because it has no notion of software state for a given request. It is also 32-bit only since it stuff kernel pointers into 32 bit fields in hardware-defined structures. mcd(4): This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in the manpage, this driver is only useful as a backend to cdcontrol to play audio CDs since it doesn't use DMA, so its data performance is "abysmal" (and that was true in the mid 90's). scd(4): Similar to mcd(4), this is a pre-ATAPI ISA CD-ROM adapter. (Note that the more-popular matcd(4) driver that was used for the CD-ROM controller on certain SoundBlaster cards was removed in 2002.) si(4): This is a driver for an older ISA/EISA/PCI multiport serial card. It doesn't use bus_space. It was hacked up to use new tty, but still uses Giant. I have a partial set of outstanding patches to this to fix it to use bus_space, but when I sent them out for testing on current and stable, no one replied. wds(4): This is an ISA SCSI HBA that does not use DMA (only PIO). I actually had one of these a long time ago to use with a SCSI ZIP drive. Even if I still have it in a box somewhere, I'm not digging it out. wl(4): This is a driver for an ancient pre-802.11 wireless adapter. It also includes wlconfig(8). Warner promises he won't test any patches for this. It's older and slower than wi(4) and that driver hasn't really worked in years. (One could make the case for axing an(4) and wi(4) as well, but I'm just pushing for wl(4).) spic(4): At one point the Sony VAIO was "the" cool laptop, and this driver controlled the "jogdial" found on it and presented it as a mouse. This is a tiny driver and is less invasive in terms of future maintenance than others perhaps, but my recent calls for testing on current@ and stable@ found no takers. It's a fairly obscure device and not one that exists on any recently shipped hardware. ie(4): Unfortunately, someone actually found one of these and tested it several years ago when I added locking to it. It is the only ISA NIC driver that doesn't have a pccard attachment (you can in theory still use a pccard NIC in a cardbus slot (though not ExpressCard)). This also only does 10Mb using PIO (no DMA). It doesn't use bus_space. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:07:54 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C6FF1EE; Thu, 20 Nov 2014 22:07:54 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD093EE; Thu, 20 Nov 2014 22:07:53 +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 sAKM7quI098957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 14:07:53 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAKM7qHh098956; Thu, 20 Nov 2014 14:07:52 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 14:07:52 -0800 From: John-Mark Gurney To: John Baldwin Subject: Re: I'd like to axe some drivers Message-ID: <20141120220752.GI24601@funkthat.com> Mail-Followup-To: John Baldwin , arch@freebsd.org References: <201411201631.27556.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411201631.27556.jhb@freebsd.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Thu, 20 Nov 2014 14:07:53 -0800 (PST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:07:54 -0000 John Baldwin wrote this message on Thu, Nov 20, 2014 at 16:31 -0500: > I'm >< close to removing timeout/untimeout from the tree. As part of this I > have updated several older drivers to use callout(9), but most of those > patches were untested. Keeping old code around that no one uses does add > future work as tree-wide API changes are made as well as things like locking > (note that several of these drivers weren't locked until I recently changed > them). To that end, here is my short list of things that I think we can bid > farewell to in 11. Note that many of these are for ISA devices. > > asr(4): This is a driver for a set of older Adaptec PCI RAID adapters. This > driver is _really_ crufty and is the only thing I didn't convert to > callout(9) because it has no notion of software state for a given > request. It is also 32-bit only since it stuff kernel pointers into > 32 bit fields in hardware-defined structures. > > mcd(4): This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > the manpage, this driver is only useful as a backend to cdcontrol to > play audio CDs since it doesn't use DMA, so its data performance is > "abysmal" (and that was true in the mid 90's). > > scd(4): Similar to mcd(4), this is a pre-ATAPI ISA CD-ROM adapter. (Note > that the more-popular matcd(4) driver that was used for the CD-ROM > controller on certain SoundBlaster cards was removed in 2002.) > > si(4): This is a driver for an older ISA/EISA/PCI multiport serial card. > It doesn't use bus_space. It was hacked up to use new tty, but > still uses Giant. I have a partial set of outstanding patches to > this to fix it to use bus_space, but when I sent them out for > testing on current and stable, no one replied. > > wds(4): This is an ISA SCSI HBA that does not use DMA (only PIO). I > actually had one of these a long time ago to use with a SCSI > ZIP drive. Even if I still have it in a box somewhere, I'm not > digging it out. > > wl(4): This is a driver for an ancient pre-802.11 wireless adapter. It > also includes wlconfig(8). Warner promises he won't test any > patches for this. It's older and slower than wi(4) and that driver > hasn't really worked in years. (One could make the case for axing > an(4) and wi(4) as well, but I'm just pushing for wl(4).) > > spic(4): At one point the Sony VAIO was "the" cool laptop, and this driver > controlled the "jogdial" found on it and presented it as a mouse. > This is a tiny driver and is less invasive in terms of future > maintenance than others perhaps, but my recent calls for testing > on current@ and stable@ found no takers. It's a fairly obscure > device and not one that exists on any recently shipped hardware. > > ie(4): Unfortunately, someone actually found one of these and tested it > several years ago when I added locking to it. It is the only ISA > NIC driver that doesn't have a pccard attachment (you can in theory > still use a pccard NIC in a cardbus slot (though not ExpressCard)). > This also only does 10Mb using PIO (no DMA). It doesn't use > bus_space. I'm fine w/ removing these... Should we do some house cleaning on amd64's GENERIC too? amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are clearly not going to be used on these machines... My recommended list to remove: ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, sn, xe All of these are modules, so if someone really needs them, they can load the module... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:30:09 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B532872A; Thu, 20 Nov 2014 22:30:09 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9401D84E; Thu, 20 Nov 2014 22:30:09 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1F1D1193964; Thu, 20 Nov 2014 22:30:08 +0000 (UTC) Subject: Re: I'd like to axe some drivers From: Sean Bruno Reply-To: sbruno@freebsd.org To: John Baldwin In-Reply-To: <201411201631.27556.jhb@freebsd.org> References: <201411201631.27556.jhb@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-25XQrqgvBa/aiLHs1b/n" Date: Thu, 20 Nov 2014 14:30:06 -0800 Message-ID: <1416522606.7423.36.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:30:09 -0000 --=-25XQrqgvBa/aiLHs1b/n Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2014-11-20 at 16:31 -0500, John Baldwin wrote: > To that end, here is my short list of things that I think we can bid=20 > farewell to in 11. Note that many of these are for ISA devices.=20 In case there aren't enough people saying "do it", my +1 goes here. sean --=-25XQrqgvBa/aiLHs1b/n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUbmtuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kRqQH/2j2llGajkbd6APosem9sAcd svghqgwS20IhewD4/b4UmCQNDYWuAHuVhGWAEtXewtt8tn6dTf4USMMwDYRYw84h 41K8tY9lr8XpUmPvmjUh2tsw6TTSjzpQaVpGDfn7LzhSq1wMcpZ0da4i7D1syOEN 19Jayob4/CUmUyOLXsCdNafX3ew1nMrtBIT2YmREsJsN90WySbmnTnillY44hoQS 6zYUqOXwLz7gD+VRnPV9XXWR26uqBMp0Kd/IVtldb4nav24/eFUkb4mnL/wnBvtS kYjoGlE3SAf/AYOunp4yD8WWMcl/9FeXTdxbrwAANW5/VDC0TFs21+/U99mHFGM= =V1bH -----END PGP SIGNATURE----- --=-25XQrqgvBa/aiLHs1b/n-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:31:03 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 926347E3 for ; Thu, 20 Nov 2014 22:31:03 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63B2F85E for ; Thu, 20 Nov 2014 22:31:03 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id w10so3920929pde.33 for ; Thu, 20 Nov 2014 14:31:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jQ3NYB56NqxkiMVpViMDIGbTj6EO2B9u/28DIN/jijQ=; b=Ptzt9ESNvDpqbHhwKZlab00SMWUL6qFkPEBcBX3QN1NQtadJx0yb75pzwMxOgst9C3 4MhB60KhBKSiSj35fhs1CcZL/TwZVtKQCqUMik1APPmVS6R25UkFcuSRZo2++TU70kg1 2tGXwVvPeB4HqwQddI/CVe9ri8kXHoll+6+JaUi75p7jvBy6QpIschZP65T4Po39tzOJ /EcArwNbrKnEebdrN/17xpczzTKFYQtEWs3+BUwsKLguzuV6ydJMA6rMj4XCGekSJs7I 6rVElbA3N9RlH5O9emAT1MOr2MEkb789EDu88wWl4jphUs4/RauvToLxylwuIVRrvdxD fZdQ== X-Gm-Message-State: ALoCoQmftPoVyMsIw3Gb+AUd/6kow6wwTcWVnJg/KqmQT3HX1uO0tSfxvKZOQ+neY2pNFR+xtUEF X-Received: by 10.70.96.193 with SMTP id du1mr1226999pdb.136.1416522662530; Thu, 20 Nov 2014 14:31:02 -0800 (PST) Received: from [10.64.27.119] ([69.53.236.236]) by mx.google.com with ESMTPSA id vz8sm2981314pac.1.2014.11.20.14.31.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 14:31:01 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_BBC83AAA-CBAD-4477-929E-074EBEA5BC37"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I'd like to axe some drivers From: Warner Losh In-Reply-To: <201411201631.27556.jhb@freebsd.org> Date: Thu, 20 Nov 2014 15:30:57 -0700 Message-Id: References: <201411201631.27556.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:31:03 -0000 --Apple-Mail=_BBC83AAA-CBAD-4477-929E-074EBEA5BC37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 tl;dr: kill everything on your list. Notes. On Nov 20, 2014, at 2:31 PM, John Baldwin wrote: > wl(4): This is a driver for an ancient pre-802.11 wireless adapter. = It > also includes wlconfig(8). Warner promises he won't test = any > patches for this. It's older and slower than wi(4) and that = driver > hasn't really worked in years. (One could make the case for = axing > an(4) and wi(4) as well, but I'm just pushing for wl(4).) I had this driver working. In FreeBSD 4.2. I discontinued using this = card back in the 90=92s. I discarded this cards themselves a couple of years ago. It doesn=92t interoperate with anything except itself. Comparisons = to wi(4) aren=92t really relevant.This is ancient hardware, of limited use = to all but a few arcane people that hasn=92t likely be run in a real system since before the US knew about Monica... > ie(4): Unfortunately, someone actually found one of these and = tested it > several years ago when I added locking to it. It is the only = ISA > NIC driver that doesn't have a pccard attachment (you can in = theory > still use a pccard NIC in a cardbus slot (though not = ExpressCard)). > This also only does 10Mb using PIO (no DMA). It doesn't use > bus_space. No PC Cards using this chip were ever made that I could discover (and I tried very hard). Not having enough users that care enough to update it to the latest thing, nor to test it, etc speaks volumes. It=92s = hardware that=92s not relevant enough to generate in the 15 years that they=92ve been = around. Other ISA and PC Card drivers have had those fixes done, but we=92re not talking about them. ie(4) should be retired. Warner --Apple-Mail=_BBC83AAA-CBAD-4477-929E-074EBEA5BC37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUbmuhAAoJEGwc0Sh9sBEA34wP/0f9j7Huc5MOjRgn/1aMH6lD gQ43T3XFVHicjNMxIQCBz8PDBWTSrTfb1IYJ2RSUik9l6C7Be1+26qdo8WyrCSUK ce4b8IqfHWXkrwyLRwkcOvIzNVuYihJJLMH6y28FKc1eZ9Hx5k/YS5jro+Fk+41L D4qf+xPaky95v8hvVh5+zhNZOU2msmye4DOHP93YDOF2NM1oq1NxQEz1f6tNgZw5 N5ifAy6HWIgYo2jon35v5YPUHpZCd4cuJu9Fv4SwAAkz8gxc4lNv3K4x4DOI8Ops ZuHb81GWj/Bte5oL6IfgXD/xU5b4iR4u4Tc0ISHcCS2eSuG+ZqkHXYbpAJjm44cx ofnzunfkzlAo+svH/MkxXS5ASlc7ibvYQqY1IYDAVg0O6kRqC0esQLWFhqL0VMth sd/I6jZ3lF1lR8lmajOtxPecJLieJABQcQpfENggvRKaYXIOYs3VwWOH515H2a8E mo+KZi3YOIDCairyGcmGHjlw3tPhcoq8Po2lLmnXnxdZ4nJmsEtIKeZ4SVIU/N4t SdUil9B1hzLXTsh+KQaAdrn+F7AdxP/XPbT6bPeh04qhxPABLUAIEDPvHS0uP1Pd +6nUxXJ2mQeEkOEyRyeXtC+fQZOkQVYKSf5HaTOAeMx4Nx6NgjcSb7X8NrzIuaYY YH0g3X4N2wnAfTmsPEIc =ccKY -----END PGP SIGNATURE----- --Apple-Mail=_BBC83AAA-CBAD-4477-929E-074EBEA5BC37-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:37:16 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6257495B for ; Thu, 20 Nov 2014 22:37:16 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 326E8935 for ; Thu, 20 Nov 2014 22:37:16 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id fp1so3905054pdb.15 for ; Thu, 20 Nov 2014 14:37:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iKyK2HwSXdOSYr/w6n8CJWSmYn1ISdQvbdPNV55+ZK0=; b=NTZCHXX5skwpbwBnkGUMeoUrkvfj7LVweP2RnMYeRR1yz46zY097t4d8ThuLZnLxzT HgIavbieh/B1+2cnZcFy5PbHgwj5N3mycHBiTjiW8HZaqHzO/wo6G7Pv83M+gRglyIsZ E9i/FRTiXx2qA+Fxm2Owzw3RsTOka2vBpqTEsZ8jP7SoR8E0qqwTkCPlGdOovotQhjBH hEyH/ZB9CT8f7vl8dMXuKX+HNQSofSs8jjWb56B5LqzRMb3DyXHGlOEyX56FXsXeEhRM gDv/KTOmeNNlgFsSu/sU8m47/hFtPMtQpOzc4pUnEdMDKHqWBvWcoyGbtxkAHXPLTpNj WtrA== X-Gm-Message-State: ALoCoQk6vw6wqTWHypRi8Z1/FDz8wZ19wo3jU0vERswZkDu6tGUpXFUDKKvNeOPBj1kB12UWFrDi X-Received: by 10.68.68.197 with SMTP id y5mr1385154pbt.82.1416523035376; Thu, 20 Nov 2014 14:37:15 -0800 (PST) Received: from [10.64.27.119] ([69.53.236.236]) by mx.google.com with ESMTPSA id px9sm2914808pbb.84.2014.11.20.14.37.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 14:37:14 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C482C710-CB01-4158-AE8A-D63219028179"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I'd like to axe some drivers From: Warner Losh In-Reply-To: <20141120220752.GI24601@funkthat.com> Date: Thu, 20 Nov 2014 15:37:10 -0700 Message-Id: <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:37:16 -0000 --Apple-Mail=_C482C710-CB01-4158-AE8A-D63219028179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 20, 2014, at 3:07 PM, John-Mark Gurney wrote: > I'm fine w/ removing these... Should we do some house cleaning on > amd64's GENERIC too? >=20 > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > clearly not going to be used on these machines... >=20 > My recommended list to remove: > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, > sn, xe All the PC Card ones (cs, ed, ex, ep, fe, sn, xe) are no brainers to = remove from GENERIC. hme is a Sparc-centric card, so can go. The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. Older = 64-bit laptops have only CardBus, and some have these built-in. Since these = types of systems are rare, and rarely NFS boot, having them as modules is = likely fine. Of the others, only pcn may be relevant enough to stay. At one time it = was in there because one of the virtualization programs (qemu? virtual box?) = had that as its default network config. Warner --Apple-Mail=_C482C710-CB01-4158-AE8A-D63219028179 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUbm0WAAoJEGwc0Sh9sBEAa/cP/jhK2R08n/CQLGvDukmkQx4+ iekvuJJmcruerSsi50HUHz3fqurSjXNGzaOu1+/MR7ueMu25WpDTS1u2ufs8s33E FSqKyigx3wPDEeaJLNzHSX0eVx89cHLpG0huuHV1/EwV2CWKQ1Zpfn5LYzPsEavx b1YPrlF5sI25jgj1doglzbvyEiIBQJBjCaQHPXfWSfSRaSEhtsw4MAG2FXAhXeuB My0OYwmx3s0ijK6T1vMjP6DYvIINh9scKbzuPpz7yd7KktGEKkSpyKSovRlO0GYF HAhsyqXBmswvO8mSHFeIutFLSFQwwIiW83crFFqPz6LMlL8ePl0p+0yy0GpyB27j /cCYpJzLm/b1b2lkGRSVp+gU4JajPNgwFYN+or1qZttnTOqaZjCdjVIO9FU2vk4a PwJFJ6atRqYoYrsFexsx8Z9RGfVzQZCk73rY9SqwgH6r8tiRE2Wgw7pzDzcbG6C1 onYw//VxsznfopyN4SQ/3EZxTDuum4kyu99WK7DuV/8SkntOtmLrV70HY1wxsWMh K4PlegmRKUnUcHrwl9BGTysWE0WIYEEdsBU+Zg/YfZbf6MklQ4g8J469/DzHQMmz M5ZByB0TkjBjz6aPncO+wtGSFe0vbqdGrCRkhoK7OC198h2rSfSwf5WYKLasQRxE JweNGALIutTJvBULS5wA =/vg0 -----END PGP SIGNATURE----- --Apple-Mail=_C482C710-CB01-4158-AE8A-D63219028179-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:37:31 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3E0B9FE; Thu, 20 Nov 2014 22:37:31 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 640DF93C; Thu, 20 Nov 2014 22:37:31 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id bs8so10249471wib.10 for ; Thu, 20 Nov 2014 14:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=MiEv05Z1bAiGRMBd2OpbRK4vizilncZ59jZZK+TFpmA=; b=oYyDzzvCQDPknOMUeA2EZ5Tp2a3duTSaB3QHFAxIf/1CpmZuZod/mETmrEPF6Rw8tN PEXL2OXFg0SBaVrBM09Hkgv2+0NkDBC36lCnaigi1piwCyY9lzknoCUU7X/e2HDMnD4H AAptCVRsD9eh5qqPcbUk07XPjfxrb3noLXk42vmo4Gvx7FqR9hGYSQA83RRYAmJRKbaI 1QTuJx9QjcV+HkYq5Mg7BW7FKUec8Y70uyh0kBXJ1nYne9/Wj4tUYRMszE3VDcqN6+5Q otKiBjf+OmwyNW6P1jf4EYThV7B+Bp+4fcvLpBwuRcUo+5Vn+5PCUVxpjC0TLfwki/YJ ahiw== MIME-Version: 1.0 X-Received: by 10.180.99.105 with SMTP id ep9mr2089565wib.26.1416523049815; Thu, 20 Nov 2014 14:37:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 20 Nov 2014 14:37:29 -0800 (PST) In-Reply-To: References: <201411201631.27556.jhb@freebsd.org> Date: Thu, 20 Nov 2014 14:37:29 -0800 X-Google-Sender-Auth: mahvChkv05s39DLDrCx0teN6z40 Message-ID: Subject: Re: I'd like to axe some drivers From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:37:32 -0000 On 20 November 2014 14:30, Warner Losh wrote: > tl;dr: kill everything on your list. > > Notes. > > On Nov 20, 2014, at 2:31 PM, John Baldwin wrote: > >> wl(4): This is a driver for an ancient pre-802.11 wireless adapter. = It >> also includes wlconfig(8). Warner promises he won't test an= y >> patches for this. It's older and slower than wi(4) and that dr= iver >> hasn't really worked in years. (One could make the case for ax= ing >> an(4) and wi(4) as well, but I'm just pushing for wl(4).) > > I had this driver working. In FreeBSD 4.2. I discontinued using this card > back in the 90=E2=80=99s. I discarded this cards themselves a couple of = years > ago. It doesn=E2=80=99t interoperate with anything except itself. Compari= sons to > wi(4) aren=E2=80=99t really relevant.This is ancient hardware, of limited= use to > all but a few arcane people that hasn=E2=80=99t likely be run in a real s= ystem > since before the US knew about Monica... > >> ie(4): Unfortunately, someone actually found one of these and tested = it >> several years ago when I added locking to it. It is the only I= SA >> NIC driver that doesn't have a pccard attachment (you can in th= eory >> still use a pccard NIC in a cardbus slot (though not ExpressCar= d)). >> This also only does 10Mb using PIO (no DMA). It doesn't use >> bus_space. > > No PC Cards using this chip were ever made that I could discover (and > I tried very hard). Not having enough users that care enough to update > it to the latest thing, nor to test it, etc speaks volumes. It=E2=80=99s = hardware that=E2=80=99s > not relevant enough to generate in the 15 years that they=E2=80=99ve been= around. > Other ISA and PC Card drivers have had those fixes done, but we=E2=80=99r= e not > talking about them. ie(4) should be retired. I found an ISA ie(4) NIC on Ebay. Who has a box with ISA ports? :) -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 20 22:54:57 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5D46EA; Thu, 20 Nov 2014 22:54:57 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A269B36; Thu, 20 Nov 2014 22:54:57 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id sAKMssx4065901; Thu, 20 Nov 2014 17:54:55 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id sAKMssPo065900; Thu, 20 Nov 2014 17:54:54 -0500 (EST) (envelope-from wollman) Date: Thu, 20 Nov 2014 17:54:54 -0500 (EST) From: Garrett Wollman Message-Id: <201411202254.sAKMssPo065900@hergotha.csail.mit.edu> To: jhb@freebsd.org Subject: Re: I'd like to axe some drivers X-Newsgroups: mit.lcs.mail.freebsd-arch References: <201411201631.27556.jhb@freebsd.org> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 20 Nov 2014 17:54:55 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:54:57 -0000 In article <201411201631.27556.jhb@freebsd.org>, John Baldwin writes: >ie(4): Unfortunately, someone actually found one of these and tested it > several years ago when I added locking to it. It is the only ISA > NIC driver that doesn't have a pccard attachment (you can in theory > still use a pccard NIC in a cardbus slot (though not ExpressCard)). > This also only does 10Mb using PIO (no DMA). It doesn't use > bus_space. The chip absolutely does do DMA, but at the time this driver was written, the only hardware I ever saw used dual-ported RAM (on the ISA bus) rather than DMA. (You'll recall that the ISA DMA controller was rather limited and could not operate autonomously in the way that a network controller needs.) I've been hoping this driver (which I wrote) would get axed for many many years, but someone has always stepped up in the past to save it. As a bonus, removing it also gets rid of a non-standard license from the tree (which I could never change since I no longer have a legal relationship with the University of Vermont). I haven't seen the hardware this was written for in more than 20 years, and I don't think I kept the databook. (For what it's worth, pretty much every Intel network controller designed since has had the same basic programming interface -- it's just the bus glue logic and the assignment of bits in the control blocks that changes!) -GAWollman From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 00:20:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2264D4DF; Fri, 21 Nov 2014 00:20:17 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9E46356; Fri, 21 Nov 2014 00:20:15 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBDFF9.dip0.t-ipconnect.de [93.203.223.249]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id sAL0G8wq043049; Fri, 21 Nov 2014 00:16:12 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id sAL0JxbS090224; Fri, 21 Nov 2014 01:19:59 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id sAL0Jldg060693; Fri, 21 Nov 2014 01:19:59 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201411210019.sAL0Jldg060693@fire.js.berklix.net> To: arch@freebsd.org Subject: Re: I'd like to axe some drivers From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 20 Nov 2014 14:37:29 -0800." Date: Fri, 21 Nov 2014 01:19:47 +0100 Cc: Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:20:17 -0000 > I found an ISA ie(4) NIC on Ebay. Who has a box with ISA ports? :) Me. I have about 30 pcs here (& boxes of eg ether isdn etc cards), mostly with older releases, some back to 4.11. Only my main laptop currently has current (also has an MBR with 10.0, 9.3 8.4.) My TV laptop 8.1 or 8.2 uses vr interface built in, not a card. Would be a shame to see that go. I think I have a [pcmcia ?] card uses ie. I have or had a couple of mcd cdroms but yes they are truly Slow. I think I managed to throw them away. Some other proposed deletions sound familiar, But it's 1AM & i have a ship to book, & 1000 km to drive in next 2 days so no time, sorry. If people want to know whats not being used, I guess near all on current & arch will have modern, so ask on hackers@ or more likely questions@ or the forums. There's loads of FreeBSD users runnng latest releases, who are not on any list (well maybe announce@) so when drivers go, it comes as a shock, so removals should be widely aired in advance in Releases notices, where possible please. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 00:37:29 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 227DFA11 for ; Fri, 21 Nov 2014 00:37:29 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3548794 for ; Fri, 21 Nov 2014 00:37:28 +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 sAL0bIF8000836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 16:37:18 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAL0bI8u000835; Thu, 20 Nov 2014 16:37:18 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 16:37:18 -0800 From: John-Mark Gurney To: "Julian H. Stacey" Subject: Re: I'd like to axe some drivers Message-ID: <20141121003718.GA99957@funkthat.com> Mail-Followup-To: "Julian H. Stacey" , arch@freebsd.org References: <201411210019.sAL0Jldg060693@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411210019.sAL0Jldg060693@fire.js.berklix.net> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Thu, 20 Nov 2014 16:37:18 -0800 (PST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:37:29 -0000 Julian H. Stacey wrote this message on Fri, Nov 21, 2014 at 01:19 +0100: > My TV laptop 8.1 or 8.2 uses vr interface built in, not a card. > Would be a shame to see that go. Do you run amd64 on that laptop? or i386? If it's i386, then it would not be effected by my proposed change. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 00:58:59 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73CC4E48 for ; Fri, 21 Nov 2014 00:58:59 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07BB096C for ; Fri, 21 Nov 2014 00:58:58 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBDFF9.dip0.t-ipconnect.de [93.203.223.249]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id sAL0smoi044297; Fri, 21 Nov 2014 00:54:49 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id sAL0weES090510; Fri, 21 Nov 2014 01:58:40 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id sAL0wMYV079291; Fri, 21 Nov 2014 01:58:34 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201411210058.sAL0wMYV079291@fire.js.berklix.net> To: John-Mark Gurney Subject: Re: I'd like to axe some drivers From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 20 Nov 2014 16:37:18 -0800." <20141121003718.GA99957@funkthat.com> Date: Fri, 21 Nov 2014 01:58:22 +0100 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:58:59 -0000 John-Mark Gurney wrote: > Julian H. Stacey wrote this message on Fri, Nov 21, 2014 at 01:19 +0100: > > My TV laptop 8.1 or 8.2 uses vr interface built in, not a card. > > Would be a shame to see that go. > > Do you run amd64 on that laptop? or i386? If it's i386, then it > would not be effected by my proposed change. amd64 uname -a FreeBSD lapo.js.berklix.net 8.4-RELEASE FreeBSD 8.4-RELEASE #1: Mon Nov 17 21:22:36 CET 2014 jhs@lapo.js.berklix.net:/usr/src/sys/amd64/compile/LAPO.small amd64 vr0: flags=8843 metric 0 mtu 1500 options=82808 media: Ethernet autoselect (100baseTX ) status: active Novatech (MiTAC) 8355 http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 01:33:44 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5F8169A for ; Fri, 21 Nov 2014 01:33:44 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 95E62CDC for ; Fri, 21 Nov 2014 01:33:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAKaVblSDaFve/2dsb2JhbABahDwEgwLQJQKBHwEBAQEBfYQCAQEBAwEjVgUWDgoCAg0ZAlkGE4g4Cb10lmkBAQEBAQEBAwEBAQEBAQEBGoEtjyc0B4J3gVQFjBupQYQZHzCBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,426,1413259200"; d="scan'208";a="171437871" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 20 Nov 2014 20:32:34 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A367CB403A; Thu, 20 Nov 2014 20:32:34 -0500 (EST) Date: Thu, 20 Nov 2014 20:32:34 -0500 (EST) From: Rick Macklem To: Warner Losh Message-ID: <606121646.4500834.1416533554657.JavaMail.root@uoguelph.ca> In-Reply-To: <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> Subject: Re: I'd like to axe some drivers MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:33:44 -0000 Warner Losh wrote: > > On Nov 20, 2014, at 3:07 PM, John-Mark Gurney > wrote: > > > I'm fine w/ removing these... Should we do some house cleaning on > > amd64's GENERIC too? > > > > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > > clearly not going to be used on these machines... > > > > My recommended list to remove: > > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, > > fe, > > sn, xe > > All the PC Card ones (cs, ed, ex, ep, fe, sn, xe) are no brainers to > remove > from GENERIC. > > hme is a Sparc-centric card, so can go. > > The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. > Older 64-bit > laptops have only CardBus, and some have these built-in. Since these > types > of systems are rare, and rarely NFS boot, having them as modules is > likely > fine. > Yep. I'm typing this on a laptop that has a single core amd chip and an re(4) net chip. I actually run i386 FreeBSD on it (although I have booted an amd64 FreeBSD CD), so I don't care so long as these old net drivers remain in i386. rick > Of the others, only pcn may be relevant enough to stay. At one time > it was in > there because one of the virtualization programs (qemu? virtual box?) > had that > as its default network config. > > Warner > > From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 06:16:14 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18917A12; Fri, 21 Nov 2014 06:16:14 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id EE8A0BAD; Fri, 21 Nov 2014 06:16:13 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id E1D6256168; Fri, 21 Nov 2014 00:16:12 -0600 (CST) Date: Fri, 21 Nov 2014 00:16:12 -0600 From: Mark Linimon To: Adrian Chadd Subject: Re: I'd like to axe some drivers Message-ID: <20141121061612.GA20582@lonesome.com> References: <201411201631.27556.jhb@freebsd.org> 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-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:16:14 -0000 On Thu, Nov 20, 2014 at 02:37:29PM -0800, Adrian Chadd wrote: > I found an ISA ie(4) NIC on Ebay. Who has a box with ISA ports? :) There's probably one in the closet or out in the shed. Maybe. If anyone wants it, pay shipping :-) mcl From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 07:12:10 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0585A909; Fri, 21 Nov 2014 07:12:10 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id BD740230; Fri, 21 Nov 2014 07:12:09 +0000 (UTC) Received: from ymer.vnode.se (h71n10-th-c-d4.ias.bredband.telia.com [81.234.63.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id 723B2B0591; Fri, 21 Nov 2014 07:56:28 +0100 (CET) Date: Fri, 21 Nov 2014 08:02:07 +0100 From: Joel Dahl To: John Baldwin , arch@freebsd.org Subject: Re: I'd like to axe some drivers Message-ID: <20141121070207.GA19348@ymer.vnode.se> Mail-Followup-To: John Baldwin , arch@freebsd.org References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141120220752.GI24601@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 07:12:10 -0000 On Thu, Nov 20, 2014 at 02:07:52PM -0800, John-Mark Gurney wrote: > John Baldwin wrote this message on Thu, Nov 20, 2014 at 16:31 -0500: > > I'm >< close to removing timeout/untimeout from the tree. As part of this I > > have updated several older drivers to use callout(9), but most of those > > patches were untested. Keeping old code around that no one uses does add > > future work as tree-wide API changes are made as well as things like locking > > (note that several of these drivers weren't locked until I recently changed > > them). To that end, here is my short list of things that I think we can bid > > farewell to in 11. Note that many of these are for ISA devices. > > > I'm fine w/ removing these... Should we do some house cleaning on > amd64's GENERIC too? > > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > clearly not going to be used on these machines... > > My recommended list to remove: > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, > sn, xe I have amd64 machines with dc, fxp, pcn, rl and xl cards, so please don't remove these from GENERIC. I think I have bfe, vr and ed cards as well, but I have to check if they're in i386 or amd64 machines. -- Joel From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 07:15:58 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C90009FB; Fri, 21 Nov 2014 07:15:58 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9104F257; Fri, 21 Nov 2014 07:15:58 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id z10so4641727pdj.26 for ; Thu, 20 Nov 2014 23:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0KmlaCfnJ6NATZ8e5bJoZrmv1fivMSd/LW4LBYGaPew=; b=Ldatak14s6IKZZEIX3RxhEmko2lDpkpzFHzdLrFGEyT+wd3+4q4Az0Smo2NJLbmN6t 5Ab8ziG9bAFKsD/T/tcHigK4+ce37nqD1nkt7u85T1ZnYF7ynZ2qA13bHqV9t5kNhpll kC2Vh4HS+pA5rnUNZMrGrjqWzfGMvMhw2veBgMRkRnUTdw6JMWru2nugcYzopl9k6mDm GGkRpnKC8EYknZU+GMcrSRe1zW+ZgO7HWI5mH0xVfftKaWjXDlERLLDFXE0g9hiKrdOe tR7+QGQvJNLkUARx/pMl2qe8Rs7gUnrBhbxPWg9AtkCNuzI+jEd7NT9RnyXceWwBO1TW i48w== X-Received: by 10.70.130.47 with SMTP id ob15mr4190254pdb.112.1416554157907; Thu, 20 Nov 2014 23:15:57 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:8068:323:54ba:1514? ([2601:8:ab80:7d6:8068:323:54ba:1514]) by mx.google.com with ESMTPSA id ra2sm3896663pbc.27.2014.11.20.23.15.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 23:15:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_902080BE-D06C-41DD-9511-1686D6B49E4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I'd like to axe some drivers From: Garrett Cooper In-Reply-To: <20141121070207.GA19348@ymer.vnode.se> Date: Thu, 20 Nov 2014 23:15:26 -0800 Message-Id: References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> <20141121070207.GA19348@ymer.vnode.se> To: Joel Dahl X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 07:15:59 -0000 --Apple-Mail=_902080BE-D06C-41DD-9511-1686D6B49E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2014, at 23:02, Joel Dahl wrote: > On Thu, Nov 20, 2014 at 02:07:52PM -0800, John-Mark Gurney wrote: >> John Baldwin wrote this message on Thu, Nov 20, 2014 at 16:31 -0500: >>> I'm >< close to removing timeout/untimeout from the tree. As part = of this I=20 >>> have updated several older drivers to use callout(9), but most of = those=20 >>> patches were untested. Keeping old code around that no one uses = does add=20 >>> future work as tree-wide API changes are made as well as things like = locking=20 >>> (note that several of these drivers weren't locked until I recently = changed=20 >>> them). To that end, here is my short list of things that I think we = can bid=20 >>> farewell to in 11. Note that many of these are for ISA devices. >>>=20 >> I'm fine w/ removing these... Should we do some house cleaning on >> amd64's GENERIC too? >>=20 >> amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are >> clearly not going to be used on these machines... >>=20 >> My recommended list to remove: >> ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, >> sn, xe >=20 > I have amd64 machines with dc, fxp, pcn, rl and xl cards, so please = don't remove > these from GENERIC. I think I have bfe, vr and ed cards as well, but I = have to > check if they're in i386 or amd64 machines. Hi jhb/jmg, I realize it=92s not canonical/complete, but have you checked = into BSDStats yet = http://bsdstats.org/bt/devices/class/02/subclass/00.html ? Thanks! --Apple-Mail=_902080BE-D06C-41DD-9511-1686D6B49E4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUbuaOAAoJEMZr5QU6S73eAVoIAJDSMTr+RT9nLenKaQV5wrwL g9dsH2CMEBDWgH0z9+9hI+nuQHZwNQamv6bpghg0XUQqAnsq+Sd3cPeZ75Uxfdqv 3DaIT9RHgl7AzIyByeCb39wBB+DNldSuoUVm++d8t/5zIsZdktbFzPQuS2b3wtnp LfQSEn6adatDgqW3Oc3bRs42U13kQMQgIEBLZiGeKok7meDrU0mdnSpEPaO9d1z3 JiKkUMg6xte7W6pnnkYIMTzjbmNntOma/ka09faJrl5O/cxkkXHRvxaScEIgxKVR KcqRSf3xg54bmAPiVRTuUwKLMhn7/3DvnROH0Vj2oV1ZZPjxemffiqu7pO5uy5U= =a8yJ -----END PGP SIGNATURE----- --Apple-Mail=_902080BE-D06C-41DD-9511-1686D6B49E4F-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 07:50:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EF96DBE; Fri, 21 Nov 2014 07:50:18 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A77B7C6; Fri, 21 Nov 2014 07:50:18 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id rd3so4329121pab.7 for ; Thu, 20 Nov 2014 23:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gBjZP8/z0kWpf4B4OSBMSijxxUZ6Sbrh4w3+5CXQJDw=; b=d4zOTjPjaz4Qm7jamU34xW97AVz3tIgaxmpzMdLF+OgKXh5xcz9ul6gHHxsffZnwWv uaEKu55xwaT2/KtEKqPw2adLq4S0Br2LZkdrV13Xbc3EzBWM+KCPTeE9NUOYOq9Nzxqw MwDP2fomh/4sAGvTsHyGlSc92AUt3aO24f1DsdvIWeXT9aolLcHjQoeglyVcFE15Mb3P xi9oIpbo6SgDYuBvpj8skCSIz2SFAhYZP00kJj9s/w2BxpHItu8DOpPgmvl7yyM1U9A/ Swno1VAvoOLnU29r17GgO4fggmG9VX3YznUH+BlJ7lxgr0ohChd3csoGkFi3+I6rxpwy uWdQ== MIME-Version: 1.0 X-Received: by 10.66.241.239 with SMTP id wl15mr4388381pac.15.1416556217854; Thu, 20 Nov 2014 23:50:17 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.70.166 with HTTP; Thu, 20 Nov 2014 23:50:17 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 08:50:17 +0100 X-Google-Sender-Auth: oYKMc_0f6wmYX4NTIA8ivYej6t4 Message-ID: Subject: Re: VIMAGE + pf security fix? From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "Bjoern A. Zeeb" , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 07:50:18 -0000 The fix for that was imported with the new import of pf(4) AFARIR. On Thu, Nov 20, 2014 at 7:07 PM, Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > > > > > For people to use pf with VIMAGE we first MUST have the security fix > > imported that I pointed out a couple of times in the past. > > > > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > > I see the security issue mentioned, but I can't find the patch that fixes > the problem. > Where is the patch? > > Thanks. > -- > Craig > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 08:07:00 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5E1AEC; Fri, 21 Nov 2014 08:07:00 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA7196F; Fri, 21 Nov 2014 08:07:00 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id gf13so3786685lab.14 for ; Fri, 21 Nov 2014 00:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=R6NaaR9sUPaIWwpNqAZOXjKSZ2hiSD7+wU7brstTvew=; b=lwGL8fO4IZs2Q789fdDJNV1LczNaheEFzY6b6BfP5Vn664k9nbzseGUb1Ml8gP3EB7 dJe7GBkC6j5xKuZxEuWUXpmGuMW2UB5T+or/6wBwilmmQApzYHgoJa/2CL7217/bqJbP duFq1EGpiPAwssx5qqu3hyUFpqaLL1qGv4NOYGWMQuKMiejkfAnN2qbIt62qgBD6eNOP 0gIXz3lfyZP7bEhFpQ7XL2cTD/64cGosjwvzSCDAHuFzD7Nv4HbKgfOS8hq0ZqHNahGo KFb6hHzpU/57q/9HKSjGQ2BN6rk56rI88NbteHGZpwyTpCwEjMLJ0Ra093yr1mlAH4RH wlmQ== MIME-Version: 1.0 X-Received: by 10.112.16.39 with SMTP id c7mr2550923lbd.19.1416557218197; Fri, 21 Nov 2014 00:06:58 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Fri, 21 Nov 2014 00:06:58 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 00:06:58 -0800 X-Google-Sender-Auth: NvEn0fM3QA5OFreLz0ufAqhcRlg Message-ID: Subject: Re: VIMAGE + pf security fix? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 08:07:00 -0000 On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > >> >> For people to use pf with VIMAGE we first MUST have the security fix >> imported that I pointed out a couple of times in the past. >> > > At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > > I see the security issue mentioned, but I can't find the patch that fixes > the problem. > Where is the patch? > I read this link: http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-filter-local-kernel-vulnerability and I think this is the fix: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=1.236&content-type=text/x-cvsweb-markup but I can't even apply that patch to our pf_ioctl.c. -- Craig From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 08:25:10 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 846E0FDA; Fri, 21 Nov 2014 08:25:10 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FA73B99; Fri, 21 Nov 2014 08:25:10 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XrjWd-000McC-Ge; Fri, 21 Nov 2014 08:25:08 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <20141120084832.GE24601@funkthat.com> Date: Fri, 21 Nov 2014 08:25:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 08:25:10 -0000 > On 20 Nov 2014, at 08:48, John-Mark Gurney wrote: >=20 > Should we make random standard now? We don't live in the 90's = anymore, > and a system really can't function w/o randomness anymore=E2=80=A6 There is a case to be made for making it default in all/most kernel configs. I disagree on making it compulsory in all cases, as very small embedded systems can easily argue for not having it. > I'm fine w/ making the various random mixers options, but the core > random infrastructure and /dev/u?random should be standard now=E2=80=A6 There is some compulsory infrastructure; this gets you the =E2=80=9Cdummy=E2= =80=9D driver which just blocks and never delivers anything. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 08:32:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DD5C8EB for ; Fri, 21 Nov 2014 08:32:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2BDD00 for ; Fri, 21 Nov 2014 08:32:45 +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 sAL8Wd4R005620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 00:32:40 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAL8Wdip005619; Fri, 21 Nov 2014 00:32:39 -0800 (PST) (envelope-from jmg) Date: Fri, 21 Nov 2014 00:32:39 -0800 From: John-Mark Gurney To: Rick Macklem Subject: Re: I'd like to axe some drivers Message-ID: <20141121083239.GE99957@funkthat.com> Mail-Followup-To: Rick Macklem , Warner Losh , arch@freebsd.org References: <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> <606121646.4500834.1416533554657.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <606121646.4500834.1416533554657.JavaMail.root@uoguelph.ca> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Fri, 21 Nov 2014 00:32:40 -0800 (PST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 08:32:45 -0000 Rick Macklem wrote this message on Thu, Nov 20, 2014 at 20:32 -0500: > Warner Losh wrote: > > > > On Nov 20, 2014, at 3:07 PM, John-Mark Gurney > > wrote: > > > > > I'm fine w/ removing these... Should we do some house cleaning on > > > amd64's GENERIC too? > > > > > > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > > > clearly not going to be used on these machines... > > > > > > My recommended list to remove: > > > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, > > > fe, > > > sn, xe > > > > All the PC Card ones (cs, ed, ex, ep, fe, sn, xe) are no brainers to > > remove > > from GENERIC. > > > > hme is a Sparc-centric card, so can go. > > > > The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. > > Older 64-bit > > laptops have only CardBus, and some have these built-in. Since these > > types > > of systems are rare, and rarely NFS boot, having them as modules is > > likely > > fine. > > > Yep. I'm typing this on a laptop that has a single core amd chip and > an re(4) net chip. I actually run i386 FreeBSD on it (although I have > booted an amd64 FreeBSD CD), so I don't care so long as these old net > drivers remain in i386. Considering I recently installed i386 HEAD on a K6/200 box w/ an fxp, it'll be a while before the drivers go from i386.. FreeBSD 11.0-CURRENT #0 r266964:267061M: Wed Jun 11 15:35:27 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/i386.i386/usr/src/sys/serbox i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD-K6tm w/ multimedia extensions (200.46-MHz 586-class CPU) Origin="AuthenticAMD" Id=0x562 Family=0x5 Model=0x6 Stepping=2 Features=0x8001bf AMD Features=0x400<> [...] fxp0: port 0x6800-0x683f mem 0xe0100000-0xe0100fff,0xe0000000-0xe00fffff irq 11 at device 10.0 on pci0 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 09:22:47 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABD2D3AF; Fri, 21 Nov 2014 09:22:47 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BFD01FA; Fri, 21 Nov 2014 09:22:47 +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 sAL9Mk9j006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 01:22:46 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAL9MkbY006244; Fri, 21 Nov 2014 01:22:46 -0800 (PST) (envelope-from jmg) Date: Fri, 21 Nov 2014 01:22:46 -0800 From: John-Mark Gurney To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141121092245.GI99957@funkthat.com> Mail-Followup-To: Mark R V Murray , Adrian Chadd , arch@freebsd.org References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Fri, 21 Nov 2014 01:22:46 -0800 (PST) Cc: arch@freebsd.org, Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 09:22:47 -0000 Mark Murray wrote this message on Fri, Nov 21, 2014 at 08:25 +0000: > > > On 20 Nov 2014, at 08:48, John-Mark Gurney wrote: > > > > Should we make random standard now? We don't live in the 90's anymore, > > and a system really can't function w/o randomness anymore??? > > There is a case to be made for making it default in all/most kernel > configs. > > I disagree on making it compulsory in all cases, as very small embedded > systems can easily argue for not having it. How will it talk w/ the out side world? w/o random, No sshd, no https... providing randomness is a core component of a modern OS... If you're really going for small embeded, you don't want FreeBSD, or if you do, you're willing to do the work to manually rip a lot more out of the standard kernel than just the random driver... My stripped down i386 kernel is still over 6MB in size... > > I'm fine w/ making the various random mixers options, but the core > > random infrastructure and /dev/u?random should be standard now??? > > There is some compulsory infrastructure; this gets you the ???dummy??? > driver which just blocks and never delivers anything. Plus, you'd need to turn off the entropy boot script among other things... If you can demonstrate a usable system w/o much modifications that runs w/ the dummy interface, or no boot random, that I'll drop my suggestion... I'll try removing random tomorrow and see what breaks... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 10:34:25 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3379A51B; Fri, 21 Nov 2014 10:34:25 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB62AB8D; Fri, 21 Nov 2014 10:34:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sALAYIs3034851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 12:34:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sALAYIs3034851 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sALAYI6W034850; Fri, 21 Nov 2014 12:34:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2014 12:34:18 +0200 From: Konstantin Belousov To: Mark R V Murray , Adrian Chadd , arch@freebsd.org Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141121103418.GL17068@kib.kiev.ua> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141121092245.GI99957@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 10:34:25 -0000 On Fri, Nov 21, 2014 at 01:22:46AM -0800, John-Mark Gurney wrote: > Mark Murray wrote this message on Fri, Nov 21, 2014 at 08:25 +0000: > > > > > On 20 Nov 2014, at 08:48, John-Mark Gurney wrote: > > > > > > Should we make random standard now? We don't live in the 90's anymore, > > > and a system really can't function w/o randomness anymore??? > > > > There is a case to be made for making it default in all/most kernel > > configs. > > > > I disagree on making it compulsory in all cases, as very small embedded > > systems can easily argue for not having it. > > How will it talk w/ the out side world? w/o random, No sshd, no > https... providing randomness is a core component of a modern OS... > > If you're really going for small embeded, you don't want FreeBSD, or > if you do, you're willing to do the work to manually rip a lot more > out of the standard kernel than just the random driver... My stripped > down i386 kernel is still over 6MB in size... My fully modularized non-debugging kernel on amd64 has 5.5MB file size, and 4.2MB text size. This is even with driver for rootfs and device volume of the rootfs as modules. I think it is possible to get down to 2.5-3MB on amd64 if really wanting minimal configuration. Equivalent i386 kernel would be smaller by 20-25%. > > > > I'm fine w/ making the various random mixers options, but the core > > > random infrastructure and /dev/u?random should be standard now??? > > > > There is some compulsory infrastructure; this gets you the ???dummy??? > > driver which just blocks and never delivers anything. FWIW, I consider it useful to have even that parts modularized. Possibly, not in default (I mean GENERIC, not the DEFAULT) configuration, but still leaving place for stripping down without source hacking. It does not have require any modifications of the source code. The Solaris approach of modularizing everything, even schedulers and nexus, and doing kernel linking on boot is useful for many things, including the pre-boot patching. The 'module-happy' approach of our new USB stack is good example. Our core is moving into other direction, unfortunately, e.g. compat32 cannot be kldload'ed, and making it module requires easy but significant amount of work, in particular, due to many hooks of #ifdef COMPAT32. > > Plus, you'd need to turn off the entropy boot script among other > things... > > If you can demonstrate a usable system w/o much modifications that > runs w/ the dummy interface, or no boot random, that I'll drop my > suggestion... I'll try removing random tomorrow and see what breaks... Using custom /etc/rc is easy and does not require e.g. init(8) modifications. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 10:52:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BBA38F7; Fri, 21 Nov 2014 10:52:14 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E7EFD54; Fri, 21 Nov 2014 10:52:13 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C817425D3AB1; Fri, 21 Nov 2014 10:52:10 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0511FC76FCE; Fri, 21 Nov 2014 10:52:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id S2Zsv9uDAm70; Fri, 21 Nov 2014 10:52:08 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3AD78C76FE0; Fri, 21 Nov 2014 10:52:06 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE + pf security fix? From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 21 Nov 2014 10:52:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 10:52:14 -0000 On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote: > On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues = > wrote: >=20 >> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb = wrote: >>=20 >>>=20 >>> For people to use pf with VIMAGE we first MUST have the security fix >>> imported that I pointed out a couple of times in the past. >>>=20 >>=20 >> At this link: = http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 >>=20 >> I see the security issue mentioned, but I can't find the patch that = fixes >> the problem. >> Where is the patch? >>=20 >=20 > I read this link: > = http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-= filter-local-kernel-vulnerability >=20 > and I think this is the fix: > = http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=3D1.23= 6&content-type=3Dtext/x-cvsweb-markup >=20 > but I can=92t even apply that patch to our pf_ioctl.c. to my best knowledge we have never pulled a fix for this in. The last = =93sync=94 of pf was way before that vulnerability (unless I completely = missed something). =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 13:02:29 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAD8B6B5; Fri, 21 Nov 2014 13:02:29 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A56F9D56; Fri, 21 Nov 2014 13:02:28 +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 PAA04809; Fri, 21 Nov 2014 15:04:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Xrnqu-0007T6-0v; Fri, 21 Nov 2014 15:02:20 +0200 Message-ID: <546F37A3.8090506@FreeBSD.org> Date: Fri, 21 Nov 2014 15:01:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: suspending threads before devices References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> <1580793.3ynJAbfVom@ralph.baldwin.cx> <20141120142806.GJ17068@kib.kiev.ua> In-Reply-To: <20141120142806.GJ17068@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 13:02:29 -0000 On 20/11/2014 16:28, Konstantin Belousov wrote: > Below is the prototyped patch for global process suspension. There is > debugging sysctl debug.total_stop, which demonstrates the KPI, also I > used it for light testing. It successfully survived suspend/resume of > usermode threads in multiuser with mt processes running. I applied this patch and hooked the code to ACPI suspend and I must that this greatly improved chances of suspend + resume working even when initiated during heavy graphic activity on my machine with radeon hardware. So far it hasn't failed a single time through a dozen tests. It even worked kern.vt.suspendswitch=0 which never worked for me before. In addition to your changes I also have have https://reviews.freebsd.org/D1004 for initiating VT switch at a more appropriate moment when kern.vt.suspendswitch=1. But that was not enough, I also had to split power_suspend into power_suspend and power_suspend_early. power_suspend_early is called before the userland is frozen, so that things like aforementioned VT switching could be done. power_suspend is called after the userland is frozen and it is more appropriate for things like powering down disks[*]. The code that I am running is here: https://github.com/avg-I/freebsd/compare/wip/kib-userland-freeze Speaking about the code I probably would like the names to be polished up a little bit. E.g. maybe proc_stop_total -> proc_stop_all or even stop_all_procs. 'Total' is slightly confusing in this context. SINGLE_TOTAL sounds very confusing and non-descriptive to me, but I can not think up a better name at the moment. Also, maybe met_stopped -> seen_stopped. Likewise, did_stop -> stopped_some? Finally, some calls to thread_unsuspend_one() look quite ugly because of line wrapping. Maybe thread_single() code could be restructured / reformatted a little bit to avoid that. Finally, it seems that the code assumes that the calling process (curproc when proc_stop_total is called) is single-threaded. I think that that is a fine assumption, but maybe it needs to be spelled out explicitly and asserted. I should add that the code logic is good, so I only have 'color of bikeshed' comments on its style. So, I like your change a lot! Thanks! [*] And that needs to be done via an event handler only because of the lack of proper integration between the bus code and CAM. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 15:16:35 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30162925; Fri, 21 Nov 2014 15:16:35 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFCF7D6D; Fri, 21 Nov 2014 15:16:34 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xrpwm-000Ejk-Sp; Fri, 21 Nov 2014 15:16:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALFGUuo003672; Fri, 21 Nov 2014 08:16:30 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18u3Gr+1cLsHPbeT6eXnjg/ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20141121092245.GI99957@funkthat.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 2014 08:16:29 -0700 Message-ID: <1416582989.1147.250.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:16:35 -0000 On Fri, 2014-11-21 at 01:22 -0800, John-Mark Gurney wrote: > Mark Murray wrote this message on Fri, Nov 21, 2014 at 08:25 +0000: > > > > > On 20 Nov 2014, at 08:48, John-Mark Gurney wrote: > > > > > > Should we make random standard now? We don't live in the 90's anymore, > > > and a system really can't function w/o randomness anymore??? > > > > There is a case to be made for making it default in all/most kernel > > configs. > > > > I disagree on making it compulsory in all cases, as very small embedded > > systems can easily argue for not having it. > > How will it talk w/ the out side world? w/o random, No sshd, no > https... providing randomness is a core component of a modern OS... > > If you're really going for small embeded, you don't want FreeBSD, or > if you do, you're willing to do the work to manually rip a lot more > out of the standard kernel than just the random driver... My stripped > down i386 kernel is still over 6MB in size... > > > > I'm fine w/ making the various random mixers options, but the core > > > random infrastructure and /dev/u?random should be standard now??? > > > > There is some compulsory infrastructure; this gets you the ???dummy??? > > driver which just blocks and never delivers anything. > > Plus, you'd need to turn off the entropy boot script among other > things... > > If you can demonstrate a usable system w/o much modifications that > runs w/ the dummy interface, or no boot random, that I'll drop my > suggestion... I'll try removing random tomorrow and see what breaks... > If your point is that after the recent commits you can no longer do these things, then I guess that's kind of hard to argue with given that some of us have been trying to say for a couple years that if /dev/random starts blocking to wait for entropy at startup, existing *functional* small systems will stop working. Before those changes everything worked fine on the 90mhz 64MB arm systems we build products around, which have no more than a few bits of entropy available during the boot process, and which (I'll say it again even though nobody has ever paid any attention to it) don't actually need any entropy to come up and do what it is they are designed to do. They don't use https (a few of them don't even have network connections). They use ssh for its convenience (it's better than telnet), but NOT for security. (And really, whether that makes sense to you or not, "the system must be secure" is not your decision to make.) I haven't tested a recent -current on those small systems, but we've already resigned ourselves to sticking with 8.x for those older boards just because the tide of bloat (both code and policy) is too much to swim against. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 15:58:43 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAC8BCC9; Fri, 21 Nov 2014 15:58:43 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 62ACA21C; Fri, 21 Nov 2014 15:58:43 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id sALFweOF008023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 07:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1416585521; x=1416671921; bh=GUTTJGAZaS3KWrR2LQmcTiY1Gvfb/C7LGwVwlD/eLnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=j8hEZBV8UvlULwgCiamh3qGNiLnoRTTEj6Mgng5zbiD1WYxUF5EzzDL56H5l8fk6U 4/RzUCxcZAiTkRE3HJpK5E9ERcjJImZD7cT4f7PlqCEIrbi6xNhiMu1CZMFhh49gN+ Pxf/tNbOZnnMt++ucoYkxnE7gU2BWHFu6zsefL/w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1416585521; x=1416671921; i=@elandsys.com; bh=GUTTJGAZaS3KWrR2LQmcTiY1Gvfb/C7LGwVwlD/eLnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UEidzyoOco0RtOHoWObL3Eyvb2Qr5eKUZhcf2bVU9SgUoPv3Ux6YF6+vuBTnF0unc zCzAs1ifbwWPdcwt/URkaIfqVfWuj+gtd8UdBVYuw5V0Ksj3VMa+SOGE976ZI4Z9GV uzKw1FIWz80VBAMJfDyMRM2S+x36VScaG1Uq5tBM= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id sALFwd0Z016967; Fri, 21 Nov 2014 07:58:39 -0800 (PST) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Fri, 21 Nov 2014 07:58:39 -0800 From: Loganaden Velvindron To: "Bjoern A. Zeeb" Subject: Re: VIMAGE + pf security fix? Message-ID: <20141121155839.GA15001@mx.elandsys.com> 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: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:58:43 -0000 On Fri, Nov 21, 2014 at 10:52:05AM +0000, Bjoern A. Zeeb wrote: > > On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote: > > > On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues > > wrote: > > > >> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote: > >> > >>> > >>> For people to use pf with VIMAGE we first MUST have the security fix > >>> imported that I pointed out a couple of times in the past. > >>> > >> > >> At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830 > >> > >> I see the security issue mentioned, but I can't find the patch that fixes > >> the problem. > >> Where is the patch? > >> > > > > I read this link: > > http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-filter-local-kernel-vulnerability > > > > and I think this is the fix: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=1.236&content-type=text/x-cvsweb-markup > > > > but I can?t even apply that patch to our pf_ioctl.c. > > to my best knowledge we have never pulled a fix for this in. The last ?sync? of pf was way before that vulnerability (unless I completely missed something). I'd be interested in helping to fix this, as I depend on this. > > ? > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 16:06:38 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD403EBC; Fri, 21 Nov 2014 16:06:38 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2250B32D; Fri, 21 Nov 2014 16:06:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sALG6TeL009576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 18:06:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sALG6TeL009576 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sALG6Tx1009575; Fri, 21 Nov 2014 18:06:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2014 18:06:29 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: suspending threads before devices Message-ID: <20141121160629.GO17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> <1580793.3ynJAbfVom@ralph.baldwin.cx> <20141120142806.GJ17068@kib.kiev.ua> <546F37A3.8090506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546F37A3.8090506@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:06:38 -0000 On Fri, Nov 21, 2014 at 03:01:23PM +0200, Andriy Gapon wrote: > On 20/11/2014 16:28, Konstantin Belousov wrote: > > Below is the prototyped patch for global process suspension. There is > > debugging sysctl debug.total_stop, which demonstrates the KPI, also I > > used it for light testing. It successfully survived suspend/resume of > > usermode threads in multiuser with mt processes running. > > I applied this patch and hooked the code to ACPI suspend and I must that this > greatly improved chances of suspend + resume working even when initiated during > heavy graphic activity on my machine with radeon hardware. So far it hasn't > failed a single time through a dozen tests. It even worked > kern.vt.suspendswitch=0 which never worked for me before. I am happy that you use this code. > > In addition to your changes I also have have https://reviews.freebsd.org/D1004 > for initiating VT switch at a more appropriate moment when kern.vt.suspendswitch=1. > But that was not enough, I also had to split power_suspend into power_suspend > and power_suspend_early. power_suspend_early is called before the userland is > frozen, so that things like aforementioned VT switching could be done. > power_suspend is called after the userland is frozen and it is more appropriate > for things like powering down disks[*]. > > The code that I am running is here: > https://github.com/avg-I/freebsd/compare/wip/kib-userland-freeze > > Speaking about the code I probably would like the names to be polished up a > little bit. > E.g. maybe proc_stop_total -> proc_stop_all or even stop_all_procs. 'Total' is > slightly confusing in this context. > SINGLE_TOTAL sounds very confusing and non-descriptive to me, but I can not > think up a better name at the moment. > Also, maybe met_stopped -> seen_stopped. Likewise, did_stop -> stopped_some? > Finally, some calls to thread_unsuspend_one() look quite ugly because of line > wrapping. Maybe thread_single() code could be restructured / reformatted a > little bit to avoid that. Fair enough, I obviously did not put any thought into naming. My excuse is that I considered the code only a prototype. > > Finally, it seems that the code assumes that the calling process (curproc when > proc_stop_total is called) is single-threaded. I think that that is a fine > assumption, but maybe it needs to be spelled out explicitly and asserted. Ok. > > I should add that the code logic is good, so I only have 'color of bikeshed' > comments on its style. > So, I like your change a lot! Thanks! So I did all renamings your proposed, I like them. Also, I added a bunch of asserts, they are still not exhaustive and only cover the SINGLE_ALLPROC mode, but single-threading code lacks many useful checks altogether. I also moved the code to weed the threads from the inhibited state out of thread_single() to make formatting easier, as you asked, and removed almost verbatim copy of thread_suspend_switch(). Below is the current version of the patch. I still have to write the code to sync local filesystems, > > [*] And that needs to be done via an event handler only because of the lack of > proper integration between the bus code and CAM. diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 7ae7d4e..19c33b6 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -289,7 +289,7 @@ kern_execve(td, args, mac_p) args->endp - args->begin_envv); if (p->p_flag & P_HADTHREADS) { PROC_LOCK(p); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p, SINGLE_BOUNDARY)) { PROC_UNLOCK(p); exec_free_args(args); return (ERESTART); /* Try again later. */ @@ -308,9 +308,9 @@ kern_execve(td, args, mac_p) * force other threads to suicide. */ if (error == 0) - thread_single(SINGLE_EXIT); + thread_single(p, SINGLE_EXIT); else - thread_single_end(); + thread_single_end(p, SINGLE_BOUNDARY); PROC_UNLOCK(p); } if ((td->td_pflags & TDP_EXECVMSPC) != 0) { diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 1e4c095..b58e830 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -206,7 +206,7 @@ exit1(struct thread *td, int rv) * re-check all suspension request, the thread should * either be suspended there or exit. */ - if (!thread_single(SINGLE_EXIT)) + if (!thread_single(p, SINGLE_EXIT)) break; /* diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 62f43ba..80d7f82 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -317,7 +317,7 @@ fork_norfproc(struct thread *td, int flags) if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p1, SINGLE_BOUNDARY)) { PROC_UNLOCK(p1); return (ERESTART); } @@ -348,7 +348,7 @@ fail: if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - thread_single_end(); + thread_single_end(p1, SINGLE_BOUNDARY); PROC_UNLOCK(p1); } return (error); diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 495139f..305f068 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2893,3 +2893,125 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_OSREL, osrel, CTLFLAG_RW | static SYSCTL_NODE(_kern_proc, KERN_PROC_SIGTRAMP, sigtramp, CTLFLAG_RD | CTLFLAG_MPSAFE, sysctl_kern_proc_sigtramp, "Process signal trampoline location"); + +void +stop_all_proc(void) +{ + struct proc *cp, *p; + int r; + bool restart, seen_stopped, stopped_some; + + cp = curproc; + /* + * stop_all_proc() assumes that all process which have + * usermode must be stopped, except current process, for + * obvious reasons. Since other threads in the process + * establishing global stop could unstop something, disable + * calls from multithreaded processes as precaution. The + * service must not be user-callable anyway. + */ + KASSERT((cp->p_flag & P_HADTHREADS) == 0 || + (cp->p_flag & P_KTHREAD) != 0, ("mt stop_all_proc")); + +allproc_loop: + sx_xlock(&allproc_lock); + seen_stopped = stopped_some = restart = false; + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & (P_KTHREAD | P_SYSTEM | + P_TOTAL_STOP)) != 0) { + PROC_UNLOCK(p); + continue; + } + if (P_SHOULDSTOP(p)) { + /* + * Stopped processes are only tolerated when + * there are no other processes which might + * continue them. + */ + seen_stopped = true; + PROC_UNLOCK(p); + continue; + } + _PHOLD(p); + sx_xunlock(&allproc_lock); + r = thread_single(p, SINGLE_ALLPROC); + if (r != 0) + restart = true; + else + stopped_some = true; + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } + sx_xunlock(&allproc_lock); + if (restart || (seen_stopped && stopped_some)) { + kern_yield(PRI_USER); + goto allproc_loop; + } +} + +void +resume_all_proc(void) +{ + struct proc *cp, *p; + + cp = curproc; + sx_xlock(&allproc_lock); + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & P_TOTAL_STOP) != 0) { + sx_xunlock(&allproc_lock); + _PHOLD(p); + thread_single_end(p, SINGLE_ALLPROC); + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } else { + PROC_UNLOCK(p); + } + } + sx_xunlock(&allproc_lock); +} + +#define TOTAL_STOP_DEBUG 1 +#ifdef TOTAL_STOP_DEBUG +volatile static int ap_resume; + +static int +sysctl_debug_stop_all_proc(SYSCTL_HANDLER_ARGS) +{ + int error, val; + + val = 0; + ap_resume = 0; + error = sysctl_handle_int(oidp, &val, 0, req); + if (error != 0 || req->newptr == NULL) + return (error); + if (val != 0) { + stop_all_proc(); + while (ap_resume == 0) + ; + resume_all_proc(); + } + return (0); +} + +SYSCTL_PROC(_debug, OID_AUTO, stop_all_proc, CTLTYPE_INT | CTLFLAG_RW | + CTLFLAG_MPSAFE, (void *)&ap_resume, 0, sysctl_debug_stop_all_proc, "I", + ""); +#endif diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 5cdc2ce..97245fb 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2471,7 +2471,7 @@ ptracestop(struct thread *td, int sig) cv_broadcast(&p->p_dbgwait); } stopme: - thread_suspend_switch(td); + thread_suspend_switch(td, p); if (p->p_xthread == td) p->p_xthread = NULL; if (!(p->p_flag & P_TRACED)) @@ -2730,7 +2730,7 @@ issignal(struct thread *td) p->p_xstat = sig; PROC_SLOCK(p); sig_suspend_threads(td, p, 0); - thread_suspend_switch(td); + thread_suspend_switch(td, p); PROC_SUNLOCK(p); mtx_lock(&ps->ps_mtx); break; @@ -2919,7 +2919,7 @@ sigexit(td, sig) * XXX If another thread attempts to single-thread before us * (e.g. via fork()), we won't get a dump at all. */ - if ((sigprop(sig) & SA_CORE) && (thread_single(SINGLE_NO_EXIT) == 0)) { + if ((sigprop(sig) & SA_CORE) && thread_single(p, SINGLE_NO_EXIT) == 0) { p->p_sig = sig; /* * Log signals which would cause core dumps diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index ec084ed..d10e1f3 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -64,7 +64,6 @@ __FBSDID("$FreeBSD$"); SDT_PROVIDER_DECLARE(proc); SDT_PROBE_DEFINE(proc, , , lwp__exit); - /* * thread related storage. */ @@ -446,7 +445,7 @@ thread_exit(void) if (p->p_numthreads == p->p_suspcount) { thread_lock(p->p_singlethread); wakeup_swapper = thread_unsuspend_one( - p->p_singlethread); + p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -575,13 +574,54 @@ calc_remaining(struct proc *p, int mode) remaining = p->p_numthreads; else if (mode == SINGLE_BOUNDARY) remaining = p->p_numthreads - p->p_boundary_count; - else if (mode == SINGLE_NO_EXIT) + else if (mode == SINGLE_NO_EXIT || mode == SINGLE_ALLPROC) remaining = p->p_numthreads - p->p_suspcount; else panic("calc_remaining: wrong mode %d", mode); return (remaining); } +static int +remain_for_mode(int mode) +{ + + return (mode == SINGLE_ALLPROC ? 0 : 1); +} + +static int +weed_inhib(int mode, struct thread *td2, struct proc *p) +{ + int wakeup_swapper; + + PROC_LOCK_ASSERT(p, MA_OWNED); + PROC_SLOCK_ASSERT(p, MA_OWNED); + THREAD_LOCK_ASSERT(td2, MA_OWNED); + + wakeup_swapper = 0; + switch (mode) { + case SINGLE_EXIT: + if (TD_IS_SUSPENDED(td2)) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, EINTR); + break; + case SINGLE_BOUNDARY: + if (TD_IS_SUSPENDED(td2) && (td2->td_flags & TDF_BOUNDARY) == 0) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, ERESTART); + break; + case SINGLE_ALLPROC: + case SINGLE_NO_EXIT: + if (TD_IS_SUSPENDED(td2) && (td2->td_flags & TDF_BOUNDARY) == 0) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, ERESTART); + break; + } + return (wakeup_swapper); +} + /* * Enforce single-threading. * @@ -596,19 +636,29 @@ calc_remaining(struct proc *p, int mode) * any sleeping threads that are interruptable. (PCATCH). */ int -thread_single(int mode) +thread_single(struct proc *p, int mode) { struct thread *td; struct thread *td2; - struct proc *p; int remaining, wakeup_swapper; td = curthread; - p = td->td_proc; + KASSERT(mode == SINGLE_EXIT || mode == SINGLE_BOUNDARY || + mode == SINGLE_ALLPROC || mode == SINGLE_NO_EXIT, + ("invalid mode %d", mode)); + /* + * If allowing non-ALLPROC singlethreading for non-curproc + * callers, calc_remaining() and remain_for_mode() should be + * adjusted to also account for td->td_proc != p. For now + * this is not implemented because it is not used. + */ + KASSERT((mode == SINGLE_ALLPROC && td->td_proc != p) || + (mode != SINGLE_ALLPROC && td->td_proc == p), + ("mode %d proc %p curproc %p", mode, p, td->td_proc)); mtx_assert(&Giant, MA_NOTOWNED); PROC_LOCK_ASSERT(p, MA_OWNED); - if ((p->p_flag & P_HADTHREADS) == 0) + if ((p->p_flag & P_HADTHREADS) == 0 && mode != SINGLE_ALLPROC) return (0); /* Is someone already single threading? */ @@ -625,11 +675,13 @@ thread_single(int mode) else p->p_flag &= ~P_SINGLE_BOUNDARY; } + if (mode == SINGLE_ALLPROC) + p->p_flag |= P_TOTAL_STOP; p->p_flag |= P_STOPPED_SINGLE; PROC_SLOCK(p); p->p_singlethread = td; remaining = calc_remaining(p, mode); - while (remaining != 1) { + while (remaining != remain_for_mode(mode)) { if (P_SHOULDSTOP(p) != P_STOPPED_SINGLE) goto stopme; wakeup_swapper = 0; @@ -638,41 +690,8 @@ thread_single(int mode) continue; thread_lock(td2); td2->td_flags |= TDF_ASTPENDING | TDF_NEEDSUSPCHK; - if (TD_IS_INHIBITED(td2)) { - switch (mode) { - case SINGLE_EXIT: - if (TD_IS_SUSPENDED(td2)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, EINTR); - break; - case SINGLE_BOUNDARY: - if (TD_IS_SUSPENDED(td2) && - !(td2->td_flags & TDF_BOUNDARY)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, ERESTART); - break; - case SINGLE_NO_EXIT: - if (TD_IS_SUSPENDED(td2) && - !(td2->td_flags & TDF_BOUNDARY)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, ERESTART); - break; - default: - break; - } - } + if (TD_IS_INHIBITED(td2)) + wakeup_swapper |= weed_inhib(mode, td2, p); #ifdef SMP else if (TD_IS_RUNNING(td2) && td != td2) { forward_signal(td2); @@ -687,7 +706,7 @@ thread_single(int mode) /* * Maybe we suspended some threads.. was it enough? */ - if (remaining == 1) + if (remaining == remain_for_mode(mode)) break; stopme: @@ -695,7 +714,7 @@ stopme: * Wake us up when everyone else has suspended. * In the mean time we suspend as well. */ - thread_suspend_switch(td); + thread_suspend_switch(td, p); remaining = calc_remaining(p, mode); } if (mode == SINGLE_EXIT) { @@ -821,7 +840,7 @@ thread_suspend_check(int return_instead) if (p->p_numthreads == p->p_suspcount + 1) { thread_lock(p->p_singlethread); wakeup_swapper = - thread_unsuspend_one(p->p_singlethread); + thread_unsuspend_one(p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -854,11 +873,9 @@ thread_suspend_check(int return_instead) } void -thread_suspend_switch(struct thread *td) +thread_suspend_switch(struct thread *td, struct proc *p) { - struct proc *p; - p = td->td_proc; KASSERT(!TD_IS_SUSPENDED(td), ("already suspended")); PROC_LOCK_ASSERT(p, MA_OWNED); PROC_SLOCK_ASSERT(p, MA_OWNED); @@ -866,8 +883,10 @@ thread_suspend_switch(struct thread *td) * We implement thread_suspend_one in stages here to avoid * dropping the proc lock while the thread lock is owned. */ - thread_stopped(p); - p->p_suspcount++; + if (p == td->td_proc) { + thread_stopped(p); + p->p_suspcount++; + } PROC_UNLOCK(p); thread_lock(td); td->td_flags &= ~TDF_NEEDSUSPCHK; @@ -897,15 +916,16 @@ thread_suspend_one(struct thread *td) } int -thread_unsuspend_one(struct thread *td) +thread_unsuspend_one(struct thread *td, struct proc *p) { - struct proc *p = td->td_proc; - PROC_SLOCK_ASSERT(p, MA_OWNED); THREAD_LOCK_ASSERT(td, MA_OWNED); KASSERT(TD_IS_SUSPENDED(td), ("Thread not suspended")); TD_CLR_SUSPENDED(td); - p->p_suspcount--; + if (td->td_proc == p) { + PROC_SLOCK_ASSERT(p, MA_OWNED); + p->p_suspcount--; + } return (setrunnable(td)); } @@ -925,7 +945,7 @@ thread_unsuspend(struct proc *p) FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } @@ -936,9 +956,12 @@ thread_unsuspend(struct proc *p) * threading request. Now we've downgraded to single-threaded, * let it continue. */ - thread_lock(p->p_singlethread); - wakeup_swapper = thread_unsuspend_one(p->p_singlethread); - thread_unlock(p->p_singlethread); + if (p->p_singlethread->td_proc == p) { + thread_lock(p->p_singlethread); + wakeup_swapper = thread_unsuspend_one( + p->p_singlethread, p); + thread_unlock(p->p_singlethread); + } } if (wakeup_swapper) kick_proc0(); @@ -948,16 +971,20 @@ thread_unsuspend(struct proc *p) * End the single threading mode.. */ void -thread_single_end(void) +thread_single_end(struct proc *p, int mode) { struct thread *td; - struct proc *p; int wakeup_swapper; - td = curthread; - p = td->td_proc; + KASSERT(mode == SINGLE_EXIT || mode == SINGLE_BOUNDARY || + mode == SINGLE_ALLPROC || mode == SINGLE_NO_EXIT, + ("invalid mode %d", mode)); PROC_LOCK_ASSERT(p, MA_OWNED); - p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY); + KASSERT((mode == SINGLE_ALLPROC && (p->p_flag & P_TOTAL_STOP) != 0) || + (mode != SINGLE_ALLPROC && (p->p_flag & P_TOTAL_STOP) == 0), + ("mode %d does not match P_TOTAL_STOP", mode)); + p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY | + P_TOTAL_STOP); PROC_SLOCK(p); p->p_singlethread = NULL; wakeup_swapper = 0; @@ -967,11 +994,11 @@ thread_single_end(void) * on the process. The single threader must be allowed * to continue however as this is a bad place to stop. */ - if ((p->p_numthreads != 1) && (!P_SHOULDSTOP(p))) { + if (p->p_numthreads != remain_for_mode(mode) && !P_SHOULDSTOP(p)) { FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fac0915..2163543 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -635,7 +635,7 @@ struct proc { #define P_SINGLE_BOUNDARY 0x400000 /* Threads should suspend at user boundary. */ #define P_HWPMC 0x800000 /* Process is using HWPMCs */ #define P_JAILED 0x1000000 /* Process is in jail. */ -#define P_UNUSED1 0x2000000 +#define P_TOTAL_STOP 0x2000000 /* Stopped in proc_stop_total. */ #define P_INEXEC 0x4000000 /* Process is in execve(). */ #define P_STATCHILD 0x8000000 /* Child process stopped or exited. */ #define P_INMEM 0x10000000 /* Loaded into memory. */ @@ -696,6 +696,7 @@ struct proc { #define SINGLE_NO_EXIT 0 #define SINGLE_EXIT 1 #define SINGLE_BOUNDARY 2 +#define SINGLE_ALLPROC 3 #ifdef MALLOC_DECLARE MALLOC_DECLARE(M_PARGS); @@ -945,22 +946,25 @@ void thread_exit(void) __dead2; void thread_free(struct thread *td); void thread_link(struct thread *td, struct proc *p); void thread_reap(void); -int thread_single(int how); -void thread_single_end(void); +int thread_single(struct proc *p, int how); +void thread_single_end(struct proc *p, int how); void thread_stash(struct thread *td); void thread_stopped(struct proc *p); void childproc_stopped(struct proc *child, int reason); void childproc_continued(struct proc *child); void childproc_exited(struct proc *child); int thread_suspend_check(int how); -void thread_suspend_switch(struct thread *); +void thread_suspend_switch(struct thread *, struct proc *p); void thread_suspend_one(struct thread *td); void thread_unlink(struct thread *td); void thread_unsuspend(struct proc *p); -int thread_unsuspend_one(struct thread *td); +int thread_unsuspend_one(struct thread *td, struct proc *p); void thread_wait(struct proc *p); struct thread *thread_find(struct proc *p, lwpid_t tid); +void stop_all_proc(void); +void resume_all_proc(void); + static __inline int curthread_pflags_set(int flags) { From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 16:15:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 414555E3; Fri, 21 Nov 2014 16:15:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1459C62F; Fri, 21 Nov 2014 16:15:16 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B069FB96C; Fri, 21 Nov 2014 11:15:14 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: I'd like to axe some drivers Date: Fri, 21 Nov 2014 11:13:48 -0500 Message-ID: <15972293.YeKrNztlpR@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <201411210019.sAL0Jldg060693@fire.js.berklix.net> References: <201411210019.sAL0Jldg060693@fire.js.berklix.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 21 Nov 2014 11:15:14 -0500 (EST) Cc: arch@freebsd.org, "Julian H. Stacey" , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:15:16 -0000 On Friday, November 21, 2014 01:19:47 AM Julian H. Stacey wrote: > If people want to know whats not being used, I guess near all on > current & arch will have modern, so ask on hackers@ or more likely > questions@ or the forums. I posted patches for most of these drivers to stable@ two months ago (which is a much broader audience than hackers@, current@, or arch@) and got no reply. I could post on question@. It's not clear given the rules where to post this on the forums. > There's loads of FreeBSD users runnng latest releases, who are not > on any list (well maybe announce@) so when drivers go, it comes as > a shock, so removals should be widely aired in advance in Releases > notices, where possible please. Yes, I think tagging these with relnotes: yes is a no-brainer. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 16:15:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 505CE5E6 for ; Fri, 21 Nov 2014 16:15:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B3C7632 for ; Fri, 21 Nov 2014 16:15:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 18F7BB989; Fri, 21 Nov 2014 11:15:16 -0500 (EST) From: John Baldwin To: John-Mark Gurney Subject: Re: I'd like to axe some drivers Date: Fri, 21 Nov 2014 10:55:33 -0500 Message-ID: <2540829.zyhqHXzioZ@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141120220752.GI24601@funkthat.com> References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 21 Nov 2014 11:15:16 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:15:17 -0000 On Thursday, November 20, 2014 02:07:52 PM John-Mark Gurney wrote: > I'm fine w/ removing these... Should we do some house cleaning on > amd64's GENERIC too? I'd rather not diverge this thread too much. > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > clearly not going to be used on these machines... I think ISA might make sense. I think 100Mbit PCI ethernet is not as obvious. One of my previous desktops (an Athlon64 machine) had pcn as its on-board Ethernet. > My recommended list to remove: > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, > sn, xe > > All of these are modules, so if someone really needs them, they can > load the module... One thing that might help is that if pccard grows the same ability as USB to auto-load modules on insert (I feel like pccardd did this in 4.x, so this might still work via devd now?), we could remove most of the ISA drivers from GENERIC on both i386 and amd64 that are nowadays only going to be used for pccard (that's pretty much all the ISA NICs aside from ie(4)). (And pccard things still work in CardBus slots, so are still possibly relevant for 64-bit laptops with CardBus.) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 16:15:16 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 895E95E5 for ; Fri, 21 Nov 2014 16:15:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60FF6630 for ; Fri, 21 Nov 2014 16:15:16 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 51CB5B915; Fri, 21 Nov 2014 11:15:15 -0500 (EST) From: John Baldwin To: Garrett Cooper Subject: Re: I'd like to axe some drivers Date: Fri, 21 Nov 2014 11:08:13 -0500 Message-ID: <1944373.WIr7m9fpMa@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <201411201631.27556.jhb@freebsd.org> <20141121070207.GA19348@ymer.vnode.se> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 21 Nov 2014 11:15:15 -0500 (EST) Cc: arch@freebsd.org, Joel Dahl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:15:16 -0000 On Thursday, November 20, 2014 11:15:26 PM Garrett Cooper wrote: > On Nov 20, 2014, at 23:02, Joel Dahl wrote: >=20 > > On Thu, Nov 20, 2014 at 02:07:52PM -0800, John-Mark Gurney wrote: > >> John Baldwin wrote this message on Thu, Nov 20, 2014 at 16:31 -050= 0: > >>> I'm >< close to removing timeout/untimeout from the tree. As par= t of this I=20 > >>> have updated several older drivers to use callout(9), but most of= those=20 > >>> patches were untested. Keeping old code around that no one uses = does add=20 > >>> future work as tree-wide API changes are made as well as things l= ike locking=20 > >>> (note that several of these drivers weren't locked until I recent= ly changed=20 > >>> them). To that end, here is my short list of things that I think= we can bid=20 > >>> farewell to in 11. Note that many of these are for ISA devices. > >>>=20 > >> I'm fine w/ removing these... Should we do some house cleaning on= > >> amd64's GENERIC too? > >>=20 > >> amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that ar= e > >> clearly not going to be used on these machines... > >>=20 > >> My recommended list to remove: > >> ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, f= e, > >> sn, xe > >=20 > > I have amd64 machines with dc, fxp, pcn, rl and xl cards, so please= don't remove > > these from GENERIC. I think I have bfe, vr and ed cards as well, bu= t I have to > > check if they're in i386 or amd64 machines. >=20 > Hi jhb/jmg, > =09I realize it=E2=80=99s not canonical/complete, but have you checke= d into BSDStats yet http://bsdstats.org/bt/devices/class/02/subclass/00= .html ? > Thanks! This only counts PCI devices, so it won't find the majority of the driv= ers I listed since those are all ISA. The exceptions are asr(4) and si(4) = which do support PCI. si(4) does not show up there at all. There is one asr= (4) card found, though that site doesn't lend itself to tell you anything u= seful such as which OS's or versions it is used on, so it could be something running 4.x for all I know. --=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 18:35:37 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18767A6A; Fri, 21 Nov 2014 18:35:37 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D541B900; Fri, 21 Nov 2014 18:35:36 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xrt3M-000NWT-P7; Fri, 21 Nov 2014 18:35:34 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <20141121092245.GI99957@funkthat.com> Date: Fri, 21 Nov 2014 18:35:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:35:37 -0000 > On 21 Nov 2014, at 09:22, John-Mark Gurney wrote: >=20 > Mark Murray wrote this message on Fri, Nov 21, 2014 at 08:25 +0000: >>=20 >>> On 20 Nov 2014, at 08:48, John-Mark Gurney wrote: >>>=20 >>> Should we make random standard now? We don't live in the 90's = anymore, >>> and a system really can't function w/o randomness anymore??? >>=20 >> There is a case to be made for making it default in all/most kernel >> configs. >>=20 >> I disagree on making it compulsory in all cases, as very small = embedded >> systems can easily argue for not having it. >=20 > How will it talk w/ the out side world? w/o random, No sshd, no > https... providing randomness is a core component of a modern OS=E2=80=A6= There are many options, including telnet, rsh, rcp, http, ftp and serial = ports. > If you're really going for small embeded, you don't want FreeBSD, Who are you to tell me what I want? ;-) >> There is some compulsory infrastructure; this gets you the = ???dummy??? >> driver which just blocks and never delivers anything. >=20 > Plus, you'd need to turn off the entropy boot script among other > things=E2=80=A6 Correct. > If you can demonstrate a usable system w/o much modifications that > runs w/ the dummy interface, or no boot random, that I'll drop my > suggestion... I'll try removing random tomorrow and see what = breaks=E2=80=A6 Quite a lot will break straight out-of-the-box right now, but I bet I can get a system with working telnetd/rshd going in under an hour. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 18:45:22 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A028EFD; Fri, 21 Nov 2014 18:45:22 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 610A99FD; Fri, 21 Nov 2014 18:45:22 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XrtCq-000NXo-IN; Fri, 21 Nov 2014 18:45:20 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416582989.1147.250.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 18:45:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:45:22 -0000 > On 21 Nov 2014, at 15:16, Ian Lepore wrote: >=20 >> If you can demonstrate a usable system w/o much modifications that >> runs w/ the dummy interface, or no boot random, that I'll drop my >> suggestion... I'll try removing random tomorrow and see what = breaks... >>=20 >=20 > If your point is that after the recent commits you can no longer do > these things, then I guess that's kind of hard to argue with given = that > some of us have been trying to say for a couple years that if=20 > /dev/random starts blocking to wait for entropy at startup, existing > *functional* small systems will stop working. As a fair bit of the security subsystem depends on working /dev/random, this is true. HOWEVER - I=E2=80=99m most willing to entertain ideas on how to get a = general config going that disables anything that is /dev/random-dependant. Asking the SO to break sshd(8) isn=E2=80=99t going to work, but enabling (say) telnet and/or rsh in the !random(4) case could be a way to do it. > Before those changes everything worked fine on the 90mhz 64MB arm > systems we build products around, which have no more than a few bits = of > entropy available during the boot process, and which (I'll say it = again > even though nobody has ever paid any attention to it) don't actually > need any entropy to come up and do what it is they are designed to do. >=20 > They don't use https (a few of them don't even have network > connections). They use ssh for its convenience (it's better than > telnet), but NOT for security. (And really, whether that makes sense = to > you or not, "the system must be secure" is not your decision to make.) Why not just use rsh? If the security overhead is onerous, don=E2=80=99t = use it. > I haven't tested a recent -current on those small systems, but we've > already resigned ourselves to sticking with 8.x for those older boards > just because the tide of bloat (both code and policy) is too much to > swim against. Yet you use ssh? M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 18:57:50 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B33C334; Fri, 21 Nov 2014 18:57:50 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF125B17; Fri, 21 Nov 2014 18:57:49 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrtOu-0001WM-4j; Fri, 21 Nov 2014 18:57:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALIvkxd004133; Fri, 21 Nov 2014 11:57:46 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vICsXSoFBgaE2AEHrglZS X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Mark R V Murray In-Reply-To: <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> Content-Type: text/plain; charset="iso-8859-7" Date: Fri, 21 Nov 2014 11:57:46 -0700 Message-ID: <1416596266.1147.290.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sALIvkxd004133 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:57:50 -0000 On Fri, 2014-11-21 at 18:45 +0000, Mark R V Murray wrote: > > On 21 Nov 2014, at 15:16, Ian Lepore wrote: > >=20 > >> If you can demonstrate a usable system w/o much modifications that > >> runs w/ the dummy interface, or no boot random, that I'll drop my > >> suggestion... I'll try removing random tomorrow and see what breaks= ... > >>=20 > >=20 > > If your point is that after the recent commits you can no longer do > > these things, then I guess that's kind of hard to argue with given th= at > > some of us have been trying to say for a couple years that if=20 > > /dev/random starts blocking to wait for entropy at startup, existing > > *functional* small systems will stop working. >=20 > As a fair bit of the security subsystem depends on working /dev/random, > this is true. >=20 > HOWEVER - I=A2m most willing to entertain ideas on how to get a general > config going that disables anything that is /dev/random-dependant. >=20 > Asking the SO to break sshd(8) isn=A2t going to work, but enabling > (say) telnet and/or rsh in the !random(4) case could be a way to do > it. >=20 > > Before those changes everything worked fine on the 90mhz 64MB arm > > systems we build products around, which have no more than a few bits = of > > entropy available during the boot process, and which (I'll say it aga= in > > even though nobody has ever paid any attention to it) don't actually > > need any entropy to come up and do what it is they are designed to do. > >=20 > > They don't use https (a few of them don't even have network > > connections). They use ssh for its convenience (it's better than > > telnet), but NOT for security. (And really, whether that makes sense= to > > you or not, "the system must be secure" is not your decision to make.= ) >=20 > Why not just use rsh? If the security overhead is onerous, don=A2t use = it. >=20 > > I haven't tested a recent -current on those small systems, but we've > > already resigned ourselves to sticking with 8.x for those older board= s > > just because the tide of bloat (both code and policy) is too much to > > swim against. >=20 > Yet you use ssh? >=20 > M All I've ever asked for, since day one of discussing this topic, is a knob to prevent /dev/random from blocking, ever. A way in which an administrativive policy decision can be made about what consitutes "good enough" entropy (and by extension, security). The knob could be of the nature that it's hard to turn on accidentally -- it's a dangerous thing and like an industrial stamping press maybe you have to hold down two buttons far apart from each other to make it go. As far as I know we have that now, but it sounds like not forever. I'm just arguing in favor of providing the tools, making it reasonably hard to accidentally cut yourself on them, but ultimately leaving the policy decisions of how to use them to the people who own and run the systems. I kind of thought that was the unix way. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:02:00 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4DA3436; Fri, 21 Nov 2014 19:02:00 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B142BD8; Fri, 21 Nov 2014 19:02:00 +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 sALJ1wxl012626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 11:01:59 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sALJ1wB7012625; Fri, 21 Nov 2014 11:01:58 -0800 (PST) (envelope-from jmg) Date: Fri, 21 Nov 2014 11:01:58 -0800 From: John-Mark Gurney To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141121190158.GJ99957@funkthat.com> Mail-Followup-To: Mark R V Murray , arch@freebsd.org, Adrian Chadd References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Fri, 21 Nov 2014 11:01:59 -0800 (PST) Cc: arch@freebsd.org, Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:02:00 -0000 Mark Murray wrote this message on Fri, Nov 21, 2014 at 18:35 +0000: > > If you're really going for small embeded, you don't want FreeBSD, > > Who are you to tell me what I want? ;-) So, after sleeping on it, I think the more sane way to go is to create a STANDARD (or better named) kernel config file in sys/conf that is always included by config... Then things like random can be included here, and it allows the adventurous to use nodevice and nooption to disable... This has the added benifit that other options that are now "standard" could be made optional with a bit of work, and those that try to reduce the kernel config could impore their changes for others w/o breaking things for the rest of us... Thoughts on this? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:14:41 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82D3679F; Fri, 21 Nov 2014 19:14:41 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54574D0E; Fri, 21 Nov 2014 19:14:41 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrtfD-000LKi-SB; Fri, 21 Nov 2014 19:14:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALJEcJL004174; Fri, 21 Nov 2014 12:14:38 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19RVikzj4bIVdWk45/wj+mR X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20141121190158.GJ99957@funkthat.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> <20141121190158.GJ99957@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 2014 12:14:38 -0700 Message-ID: <1416597278.1147.295.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:14:41 -0000 On Fri, 2014-11-21 at 11:01 -0800, John-Mark Gurney wrote: > Mark Murray wrote this message on Fri, Nov 21, 2014 at 18:35 +0000: > > > If you're really going for small embeded, you don't want FreeBSD, > > > > Who are you to tell me what I want? ;-) > > So, after sleeping on it, I think the more sane way to go is to create > a STANDARD (or better named) kernel config file in sys/conf that is > always included by config... Then things like random can be included > here, and it allows the adventurous to use nodevice and nooption to > disable... > > This has the added benifit that other options that are now "standard" > could be made optional with a bit of work, and those that try to reduce > the kernel config could impore their changes for others w/o breaking > things for the rest of us... > > Thoughts on this? > When I tried to add things to arm/conf/DEFAULTS I got my hand slapped and was told to remove what I had added because the only thing that is supposed to be in there is stuff required for the platform to run. That sounds a lot like what you're proposing. It doesn't take more than a glance at the existing DEFAULTS files to see that's not how they're actually being used now. arm is probably closest, but it has a couple partition type options in it that I don't think are required. I'm not sure it's wise to create the same thing again with yet another name, only to find years from now that it too has drifted away from the original author's intentions. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:23:34 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C5CAA85; Fri, 21 Nov 2014 19:23:34 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14FE0E06; Fri, 21 Nov 2014 19:23:34 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xrtno-000Nax-C8; Fri, 21 Nov 2014 19:23:32 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii From: Mark R V Murray In-Reply-To: <20141121190158.GJ99957@funkthat.com> Date: Fri, 21 Nov 2014 19:23:31 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> <20141121190158.GJ99957@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:23:34 -0000 > On 21 Nov 2014, at 19:01, John-Mark Gurney wrote: > > Mark Murray wrote this message on Fri, Nov 21, 2014 at 18:35 +0000: >>> If you're really going for small embeded, you don't want FreeBSD, >> >> Who are you to tell me what I want? ;-) > > So, after sleeping on it, I think the more sane way to go is to create > a STANDARD (or better named) kernel config file in sys/conf that is > always included by config... Then things like random can be included > here, and it allows the adventurous to use nodevice and nooption to > disable... > > This has the added benifit that other options that are now "standard" > could be made optional with a bit of work, and those that try to reduce > the kernel config could impore their changes for others w/o breaking > things for the rest of us... > > Thoughts on this? I like it! :-) M -- Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:37:27 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDE0AC21; Fri, 21 Nov 2014 19:37:27 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 948F2F16; Fri, 21 Nov 2014 19:37:27 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xru1E-000Nbt-To; Fri, 21 Nov 2014 19:37:25 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416596266.1147.290.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 19:37:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:37:27 -0000 > On 21 Nov 2014, at 18:57, Ian Lepore wrote: >=20 > All I've ever asked for, since day one of discussing this topic, is a > knob to prevent /dev/random from blocking, ever. A way in which an > administrativive policy decision can be made about what consitutes = "good > enough" entropy (and by extension, security). The knob could be of = the > nature that it's hard to turn on accidentally -- it's a dangerous = thing > and like an industrial stamping press maybe you have to hold down two > buttons far apart from each other to make it go. I=E2=80=99m suspicious of motive here. You are planning on ignoring = lousy entropy coming out of /dev/random; you seem to need a way of breaking to do so. (I can=E2=80=99t think of a better word than =E2=80=9Cignoring=E2= =80=9D; what I mean is that you don=E2=80=99t seem to care how bad the output is.) If you don=E2=80=99t care about the contents of /dev/random, why not = simply ignore it? Choosing to use tools that require good-quality /dev/random output means you should choose other tools, not break /dev/random! > As far as I know we have that now, but it sounds like not forever. = I'm > just arguing in favor of providing the tools, making it reasonably = hard > to accidentally cut yourself on them, but ultimately leaving the = policy > decisions of how to use them to the people who own and run the = systems. > I kind of thought that was the unix way. The Snowden revelations have made folks considerably more paranoid. Providing tools that bad guys could potentially use where the good guys have alternatives is not a way that security-minded folks are keen to go. You have the right to ignore /dev/random. Asking for a back door to break it is a bigger deal. Bad guys like these back doors. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:39:22 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBC1CD10; Fri, 21 Nov 2014 19:39:21 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1541F2F; Fri, 21 Nov 2014 19:39:21 +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 sALJdKNZ013065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 11:39:20 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sALJdKho013064; Fri, 21 Nov 2014 11:39:20 -0800 (PST) (envelope-from jmg) Date: Fri, 21 Nov 2014 11:39:20 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141121193920.GM99957@funkthat.com> Mail-Followup-To: Ian Lepore , Mark R V Murray , arch@FreeBSD.org, Adrian Chadd References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <30DC3E76-7737-4A55-8200-8A662811B9B7@grondar.org> <20141121190158.GJ99957@funkthat.com> <1416597278.1147.295.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416597278.1147.295.camel@revolution.hippie.lan> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Fri, 21 Nov 2014 11:39:20 -0800 (PST) Cc: arch@FreeBSD.org, Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:39:22 -0000 Ian Lepore wrote this message on Fri, Nov 21, 2014 at 12:14 -0700: > On Fri, 2014-11-21 at 11:01 -0800, John-Mark Gurney wrote: > > Mark Murray wrote this message on Fri, Nov 21, 2014 at 18:35 +0000: > > > > If you're really going for small embeded, you don't want FreeBSD, > > > > > > Who are you to tell me what I want? ;-) > > > > So, after sleeping on it, I think the more sane way to go is to create > > a STANDARD (or better named) kernel config file in sys/conf that is > > always included by config... Then things like random can be included > > here, and it allows the adventurous to use nodevice and nooption to > > disable... > > > > This has the added benifit that other options that are now "standard" > > could be made optional with a bit of work, and those that try to reduce > > the kernel config could impore their changes for others w/o breaking > > things for the rest of us... > > > > Thoughts on this? > > When I tried to add things to arm/conf/DEFAULTS I got my hand slapped > and was told to remove what I had added because the only thing that is > supposed to be in there is stuff required for the platform to run. That > sounds a lot like what you're proposing. Kinda, except it's what is required for "FreeBSD" (for the definition we are familar w/) to run... After looking at */conf/DEFAULTS, we already have one other option for this global include, device mem... And you could argue that options NEW_PCIB should be there too (or really, it just be turned on by default now)... Though why they forced you to remove GEOM_PART_BSD, but didn't remove it from all the other DEFAULTS is beyond me... arm is the ONLY one that doesn't have GEOM_PART_BSD in it... GEOM_PART is completely unnecessary for a system to run since you can do NFS root... So, the argument that it is required for the platform to run is BS... > It doesn't take more than a glance at the existing DEFAULTS files to see > that's not how they're actually being used now. arm is probably > closest, but it has a couple partition type options in it that I don't > think are required. I'm not sure it's wise to create the same thing > again with yet another name, only to find years from now that it too has > drifted away from the original author's intentions. IMO, we should have a global defaults file which include a few standard things.. For example, on really small systems, you might want to rip out subsystems you don't want/need, so things like kqueue might be able to be removed... Back before config supported nodevice and nooption, it made sense to only include required options, because there was no way you could turn it off... Now that we have nooption and nodevice, including the most common for each platform in DEFAULTS is the way to go... btw, include was added in 2001, and two years later nodevice and nooption was added... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:41:33 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E25B1FFF; Fri, 21 Nov 2014 19:41:32 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0EB6FDE; Fri, 21 Nov 2014 19:41:32 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xru5D-0009Pz-CZ; Fri, 21 Nov 2014 19:41:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALJfTOj004218; Fri, 21 Nov 2014 12:41:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+q7f5GjiilTO3VUth3K+8M X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Mark R V Murray In-Reply-To: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-8859-13" Date: Fri, 21 Nov 2014 12:41:29 -0700 Message-ID: <1416598889.1147.297.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sALJfTOj004218 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:41:33 -0000 On Fri, 2014-11-21 at 19:37 +0000, Mark R V Murray wrote: > > On 21 Nov 2014, at 18:57, Ian Lepore wrote: > >=20 > > All I've ever asked for, since day one of discussing this topic, is a > > knob to prevent /dev/random from blocking, ever. A way in which an > > administrativive policy decision can be made about what consitutes "g= ood > > enough" entropy (and by extension, security). The knob could be of t= he > > nature that it's hard to turn on accidentally -- it's a dangerous thi= ng > > and like an industrial stamping press maybe you have to hold down two > > buttons far apart from each other to make it go. >=20 > I=FFm suspicious of motive here. You are planning on ignoring lousy > entropy coming out of /dev/random; you seem to need a way of breaking > to do so. (I can=FFt think of a better word than =B4ignoring=A1; what I= mean > is that you don=FFt seem to care how bad the output is.) >=20 > If you don=FFt care about the contents of /dev/random, why not simply > ignore it? Choosing to use tools that require good-quality /dev/random > output means you should choose other tools, not break /dev/random! >=20 > > As far as I know we have that now, but it sounds like not forever. I= 'm > > just arguing in favor of providing the tools, making it reasonably ha= rd > > to accidentally cut yourself on them, but ultimately leaving the poli= cy > > decisions of how to use them to the people who own and run the system= s. > > I kind of thought that was the unix way. >=20 > The Snowden revelations have made folks considerably more paranoid. >=20 > Providing tools that bad guys could potentially use where the good guys > have alternatives is not a way that security-minded folks are keen to > go. >=20 > You have the right to ignore /dev/random. Asking for a back door to > break it is a bigger deal. Bad guys like these back doors. >=20 > M The arrogance in the way you talk down to me about my right and ability to decide these things is mind-boggling. It's clear you're going to do whatever you want, so I guess I'll just shut up. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:53:54 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581A560C; Fri, 21 Nov 2014 19:53:54 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E2D5195; Fri, 21 Nov 2014 19:53:54 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XruH9-000Nda-KM; Fri, 21 Nov 2014 19:53:51 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416598889.1147.297.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 19:53:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:53:54 -0000 > On 21 Nov 2014, at 19:41, Ian Lepore wrote: > The arrogance in the way you talk down to me about my right and = ability > to decide these things is mind-boggling. It's clear you're going to = do > whatever you want, so I guess I'll just shut up. I=E2=80=99m sorry for offence; that was unintended. Was *was* intended was to attempt to engage you in dialogue. You are obviously annoyed, but after rather a lot of discussion (2 devsummits, 1 EuroBSDCon and a lot of email), some form of consensus was required. Unfortunately you are not one of those who could not be accommodated to the extent that you desired. We obviously couldn=E2=80=99t make everyone = happy. Some aspects of the compromise were things *I* really didn=E2=80=99t = like. I think there are ways round your problem, and I=E2=80=99ll be happy to = help you get there. Please don=E2=80=99t just hold out for one particular = solution; be flexible. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 21:57:32 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BB60BD6; Fri, 21 Nov 2014 21:57:32 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CD25125; Fri, 21 Nov 2014 21:57:31 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id y10so7727195wgg.27 for ; Fri, 21 Nov 2014 13:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ORQhp1m/Pfv5BC+mZwReGwKsUQ7sXIdHZskFsmBM7b4=; b=oT2GYiS5c/LXux4r7FzxWiDhW7nc9yPUs6CgufzE1VvJ0QXM7WjKW546TmV6G9HByQ bFJrWm+uSLm07/8tlyCqXSICjjERYmdXDSAtvklRSCwd6/M5iP0ZiG//+byybDZXeuPJ 1hEDxwP25ulMbac+Ipiohu41tXB91Vo9Lsz/fzWe1typfXgTwibpgk27/Sqzy4SklGyC Aj7AmpeZNKKt1rUzujD2WGDLygw4R9PNoLlaTYyFKce9eVIAuUdI1xuZiVeFzwBij78J gxoPx97J96K01XEHyLmSoD3JNF5vef+aB0xtouhv7zguTypr5lHiIYCv9QvMhldQBr5U 0HTw== MIME-Version: 1.0 X-Received: by 10.180.108.35 with SMTP id hh3mr543115wib.59.1416607049892; Fri, 21 Nov 2014 13:57:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 21 Nov 2014 13:57:29 -0800 (PST) In-Reply-To: <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> Date: Fri, 21 Nov 2014 13:57:29 -0800 X-Google-Sender-Auth: 387BA5uncCPocLEHUe63XUL9scE Message-ID: Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Adrian Chadd To: Mark R V Murray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arch@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 21:57:32 -0000 On 21 November 2014 11:53, Mark R V Murray wrote: > >> On 21 Nov 2014, at 19:41, Ian Lepore wrote: >> The arrogance in the way you talk down to me about my right and ability >> to decide these things is mind-boggling. It's clear you're going to do >> whatever you want, so I guess I'll just shut up. > > I=E2=80=99m sorry for offence; that was unintended. > > Was *was* intended was to attempt to engage you in dialogue. You are > obviously annoyed, but after rather a lot of discussion (2 devsummits, > 1 EuroBSDCon and a lot of email), some form of consensus was required. > Unfortunately you are not one of those who could not be accommodated to > the extent that you desired. We obviously couldn=E2=80=99t make everyone = happy. > Some aspects of the compromise were things *I* really didn=E2=80=99t like= . > > I think there are ways round your problem, and I=E2=80=99ll be happy to h= elp you > get there. Please don=E2=80=99t just hold out for one particular solution= ; be > flexible. Unfortunately there are things that the real world expects on these silly embedded platforms that we can't avoid: * sshd as a requirement for remote access; * HTTPS as a requirement for remote access; * crypto available for WPA/WPA2 key negotiation for wifi access; and so on. So, we can't just "not" have random ready early at boot and only use non-crypto services, because the real world knocked on our door and said "We don't care about full security at boot; we'll gather entropy and improve things soon." So yes, I +1 needing some build option that lets us feed some crappy random numbers out at startup. I dislike it, but the realities of these ubiquitous embedded platforms is unfortunate :( -adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 22:20:08 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAC17ED8; Fri, 21 Nov 2014 22:20:08 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7511A357; Fri, 21 Nov 2014 22:20:08 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrwYg-0009Py-Qe; Fri, 21 Nov 2014 22:20:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALMK5W9004531; Fri, 21 Nov 2014 15:20:05 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Yi8tON/s1phLtEBlKROvq X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> Content-Type: text/plain; charset="iso-8859-7" Date: Fri, 21 Nov 2014 15:20:05 -0700 Message-ID: <1416608405.1147.307.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sALMK5W9004531 Cc: "freebsd-arch@freebsd.org" , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 22:20:08 -0000 On Fri, 2014-11-21 at 13:57 -0800, Adrian Chadd wrote: > On 21 November 2014 11:53, Mark R V Murray wrote: > > > >> On 21 Nov 2014, at 19:41, Ian Lepore wrote: > >> The arrogance in the way you talk down to me about my right and abil= ity > >> to decide these things is mind-boggling. It's clear you're going to= do > >> whatever you want, so I guess I'll just shut up. > > > > I=A2m sorry for offence; that was unintended. > > > > Was *was* intended was to attempt to engage you in dialogue. You are > > obviously annoyed, but after rather a lot of discussion (2 devsummits= , > > 1 EuroBSDCon and a lot of email), some form of consensus was required. > > Unfortunately you are not one of those who could not be accommodated = to > > the extent that you desired. We obviously couldn=A2t make everyone ha= ppy. > > Some aspects of the compromise were things *I* really didn=A2t like. > > > > I think there are ways round your problem, and I=A2ll be happy to hel= p you > > get there. Please don=A2t just hold out for one particular solution; = be > > flexible. >=20 > Unfortunately there are things that the real world expects on these > silly embedded platforms that we can't avoid: >=20 > * sshd as a requirement for remote access; > * HTTPS as a requirement for remote access; > * crypto available for WPA/WPA2 key negotiation for wifi access; >=20 > and so on. >=20 > So, we can't just "not" have random ready early at boot and only use > non-crypto services, because the real world knocked on our door and > said "We don't care about full security at boot; we'll gather entropy > and improve things soon." >=20 > So yes, I +1 needing some build option that lets us feed some crappy > random numbers out at startup. I dislike it, but the realities of > these ubiquitous embedded platforms is unfortunate :( >=20 Just for the record, what you're describing and asking for is really unrelated to what I've been saying. It sounds to me like you're saying you want a general purpose device which WILL be exposed to all the hazards of the great wide world to be allowed to operate unsecurely in the face of those hazards. Maybe there's validity in that, maybe not. My situation is different... I'm talking about devices in which there is no exposure to such hazards, most often because the device is a small part of some larger system and the protections are provided by the wider environment (if that's even an issue, for example if a network connection is even part of the system). But in the wider sense, I've also been talking about policy, and who should be in control of it. Traditionally it has been in the hands of system administrators. Newthink is apparently that they're too dumb to get it right and policy should be dictated by software authors. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 00:06:35 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D995579D for ; Sat, 22 Nov 2014 00:06:35 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6C77FBC for ; Sat, 22 Nov 2014 00:06:35 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so5920410pab.2 for ; Fri, 21 Nov 2014 16:06:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RPxlKqb8jG0MJUAQbSzMvKsJZzOtecMi1aRNHw8sVrY=; b=cak4VL4+IOY2as0Pnlo/Im2FetEdZnzegdjQdNwgRMFiTgLwVysDy41Tuqk3N8se7N lJxcAlylx5VgM/q37iGcIlHeHevnRuChYu7ZMDyMJQ0n2A4hSkN6xFuBRNqUXKElXK4A +E3+m80mUKxkxqqaaJm3lIaRbgHWr3z9GEKR80wM2hoh16+KEMwf985jmriSbQUp+UFv yjSLRDzqlkKvjm3ZINb4bCk4ywqxZCGvYmUCx2a9WSy/BsNfeXyyUgWg4OS59xt3EhTR 69Tx1XaXPiKH7JoaJOeWaQv1i2hmJzpCZPtImy7qYC6+17mvZcZ/R4y43lIxeYJx6JYB Eb8Q== X-Gm-Message-State: ALoCoQnznbHfzBHIfEFGKNff6a0RUZPBbxbtmLEZi+jABMa0Qv8oWbRCjWZFzDOp+NWkzXj+mTer X-Received: by 10.70.132.130 with SMTP id ou2mr11719850pdb.168.1416614794436; Fri, 21 Nov 2014 16:06:34 -0800 (PST) Received: from lgmac-stuffs.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id yw1sm5795338pbb.52.2014.11.21.16.06.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 16:06:33 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C880F4EE-956A-487C-9B56-01F615F8FB3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I'd like to axe some drivers From: Warner Losh In-Reply-To: <2540829.zyhqHXzioZ@ralph.baldwin.cx> Date: Fri, 21 Nov 2014 17:06:28 -0700 Message-Id: <14FB18AA-11CB-4501-80E6-5214C3AD36AD@bsdimp.com> References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> <2540829.zyhqHXzioZ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:06:35 -0000 --Apple-Mail=_C880F4EE-956A-487C-9B56-01F615F8FB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 21, 2014, at 8:55 AM, John Baldwin wrote: > On Thursday, November 20, 2014 02:07:52 PM John-Mark Gurney wrote: >> I'm fine w/ removing these... Should we do some house cleaning on >> amd64's GENERIC too? >=20 > I'd rather not diverge this thread too much. >=20 >> amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are >> clearly not going to be used on these machines... >=20 > I think ISA might make sense. I think 100Mbit PCI ethernet is not as > obvious. One of my previous desktops (an Athlon64 machine) had pcn as > its on-board Ethernet. >=20 >> My recommended list to remove: >> ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, >> sn, xe >>=20 >> All of these are modules, so if someone really needs them, they can >> load the module... >=20 > One thing that might help is that if pccard grows the same ability as > USB to auto-load modules on insert (I feel like pccardd did this in > 4.x, so this might still work via devd now?), we could remove most of > the ISA drivers from GENERIC on both i386 and amd64 that are nowadays > only going to be used for pccard (that's pretty much all the ISA NICs > aside from ie(4)). (And pccard things still work in CardBus slots, so > are still possibly relevant for 64-bit laptops with CardBus.) USB doesn=92t have the ability to autoload, and never has. Huge, ugly tables of all USB devices are generated and fed into devd=20 as NOMATCH rules to give the illusion that it supports autoload. It is = really evil. pccardd never did do autoload, unless you hacked the default matching stuff to include module loading. PC Card devices could do a similar set of evil, since almost almost all = the PC Card drivers use a centralized table routine. It could almost be an = ELF section of the .ko that could be parsed by a generic NOMATCH program. But failing that, an ugly dirty script could be written to grep the data = out of the source and produce evil nasty Bagginses, errr, NOMATCH scripts. Forget about it for CardBus cards, because PCI never did do anything = this nicely and there=92s a wide variety of ways to match the card extant in = the tree. Warner --Apple-Mail=_C880F4EE-956A-487C-9B56-01F615F8FB3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUb9OEAAoJEGwc0Sh9sBEAnFEQANX9f+/fCnulzOdkfdlIIWJz hqXSgvPALQkhDlzhrZ6VnHhQLAw6AHkOO4GGhyTgJusJl7pGLlA45Se8R2mZO+fS MCFxKJV4NfYHGrHwNtPVG2MydukKY+2fdBT+UHs8mySpJXWIQnPpYbME803Iln80 AlP8opcda7ZZPHZJpQSKDF61NOzKh81mkTYYL3rYqYIQyjnzWF022LJ3hssQdBt4 d0uUCof9N1ItXZZu1+wi0dJ9JFsnvc+wM8we5bmq7jgFkyg9d7/ufNrlreEV54zl S0cPiN/DjuO9fbTljRWP3uUvkCJESxhw3iew5jdYosO+nczyJPeN5AZa/cIlBzNU ZCww4mPTEr2JIZpoemdpZn1A/LSpaimySlwBGeyP7Rxhg83a0Ph9HPCQOQojTbg9 jJ+/ED0UIZWgJw0YxE9J2GLvUT26jAv+NkcJCViS9fAH2jJXFgS8z0wfzUEyD3pi +zMhFGl81BZHInOEp5Zg8DgkDks6+Qx7/Y8aIbKc5K2T1Re82h1hR2eCcb6NHNTH pEnezzhW6XcEi32Myap8dlnDBGDTgN32SEzrWd2KbjdeY75cKW6GV4rWZi1yUBG7 KYWESu0DarNHKL7gl70WEsCsSKG93ykJ+ym9DedAxPWYmrBSqAOQsagkqvTqpZ9/ PXT2Iy+IPCzXGHctatGn =vBfm -----END PGP SIGNATURE----- --Apple-Mail=_C880F4EE-956A-487C-9B56-01F615F8FB3A-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 12:05:46 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05322DFF; Sat, 22 Nov 2014 12:05:46 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9CDD98E; Sat, 22 Nov 2014 12:05:45 +0000 (UTC) Received: from [2001:470:9174:1:178:bba0:7b1:d5c2] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xs9Re-000OiQ-NK; Sat, 22 Nov 2014 12:05:42 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii From: Mark R V Murray In-Reply-To: <1416608405.1147.307.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 12:05:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1FF084FC-A8FF-4B5D-B9DA-6B5D50B22BDC@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> <1416608405.1147.307.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 12:05:46 -0000 > On 21 Nov 2014, at 22:20, Ian Lepore wrote: >=20 > My situation is different... I'm talking about devices in which there = is > no exposure to such hazards, most often because the device is a small > part of some larger system and the protections are provided by the = wider > environment (if that's even an issue, for example if a network > connection is even part of the system). Lets try a couple of things. 1) Please see if changing to Fortuna gets you an unlocked device quickly = enough: device random # Entropy device options RANDOM_DEBUG options RANDOM_FORTUNA # Use the Fortuna CSPRNG #options RANDOM_YARROW # The default 2) If you are staying with Yarrow, then try setting these sysctls = suitably early: kern.random.yarrow.fastthresh: 48 kern.random.yarrow.slowthresh: 64 kern.random.yarrow.slowoverthresh: 1 In either case, please post verbose output from a clean boot. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 17:06:06 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37441CCA; Sat, 22 Nov 2014 17:06:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DE25948; Sat, 22 Nov 2014 17:06:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAMH5u2K065665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2014 19:05:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAMH5u2K065665 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAMH5uuD065664; Sat, 22 Nov 2014 19:05:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2014 19:05:56 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: suspending threads before devices Message-ID: <20141122170556.GY17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> <1580793.3ynJAbfVom@ralph.baldwin.cx> <20141120142806.GJ17068@kib.kiev.ua> <546F37A3.8090506@FreeBSD.org> <20141121160629.GO17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141121160629.GO17068@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 17:06:06 -0000 On Fri, Nov 21, 2014 at 06:06:29PM +0200, Konstantin Belousov wrote: > Below is the current version of the patch. I still have to write the > code to sync local filesystems, I decided to utilize syncer shutdown mode for this. It seems to be easy and does what we need. An interesting corner case are the pagedaemon and vmdaemon. Both of them could generate more writes to the filesystems even after all userspace is stopped and the sync flushed everything. It is more probable for pagedaemon. Might be, it would need a suspend/resume methods in future. Note that bufdaemon does not need suspend, since all dirty buffers are handled by syncer. diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 7ae7d4e..19c33b6 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -289,7 +289,7 @@ kern_execve(td, args, mac_p) args->endp - args->begin_envv); if (p->p_flag & P_HADTHREADS) { PROC_LOCK(p); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p, SINGLE_BOUNDARY)) { PROC_UNLOCK(p); exec_free_args(args); return (ERESTART); /* Try again later. */ @@ -308,9 +308,9 @@ kern_execve(td, args, mac_p) * force other threads to suicide. */ if (error == 0) - thread_single(SINGLE_EXIT); + thread_single(p, SINGLE_EXIT); else - thread_single_end(); + thread_single_end(p, SINGLE_BOUNDARY); PROC_UNLOCK(p); } if ((td->td_pflags & TDP_EXECVMSPC) != 0) { diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 1e4c095..b58e830 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -206,7 +206,7 @@ exit1(struct thread *td, int rv) * re-check all suspension request, the thread should * either be suspended there or exit. */ - if (!thread_single(SINGLE_EXIT)) + if (!thread_single(p, SINGLE_EXIT)) break; /* diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 62f43ba..80d7f82 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -317,7 +317,7 @@ fork_norfproc(struct thread *td, int flags) if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - if (thread_single(SINGLE_BOUNDARY)) { + if (thread_single(p1, SINGLE_BOUNDARY)) { PROC_UNLOCK(p1); return (ERESTART); } @@ -348,7 +348,7 @@ fail: if (((p1->p_flag & (P_HADTHREADS|P_SYSTEM)) == P_HADTHREADS) && (flags & (RFCFDG | RFFDG))) { PROC_LOCK(p1); - thread_single_end(); + thread_single_end(p1, SINGLE_BOUNDARY); PROC_UNLOCK(p1); } return (error); diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 495139f..1a11655 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2893,3 +2893,128 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_OSREL, osrel, CTLFLAG_RW | static SYSCTL_NODE(_kern_proc, KERN_PROC_SIGTRAMP, sigtramp, CTLFLAG_RD | CTLFLAG_MPSAFE, sysctl_kern_proc_sigtramp, "Process signal trampoline location"); + +void +stop_all_proc(void) +{ + struct proc *cp, *p; + int r; + bool restart, seen_stopped, stopped_some; + + cp = curproc; + /* + * stop_all_proc() assumes that all process which have + * usermode must be stopped, except current process, for + * obvious reasons. Since other threads in the process + * establishing global stop could unstop something, disable + * calls from multithreaded processes as precaution. The + * service must not be user-callable anyway. + */ + KASSERT((cp->p_flag & P_HADTHREADS) == 0 || + (cp->p_flag & P_KTHREAD) != 0, ("mt stop_all_proc")); + +allproc_loop: + sx_xlock(&allproc_lock); + seen_stopped = stopped_some = restart = false; + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & (P_KTHREAD | P_SYSTEM | + P_TOTAL_STOP)) != 0) { + PROC_UNLOCK(p); + continue; + } + if (P_SHOULDSTOP(p)) { + /* + * Stopped processes are only tolerated when + * there are no other processes which might + * continue them. + */ + seen_stopped = true; + PROC_UNLOCK(p); + continue; + } + _PHOLD(p); + sx_xunlock(&allproc_lock); + r = thread_single(p, SINGLE_ALLPROC); + if (r != 0) + restart = true; + else + stopped_some = true; + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } + sx_xunlock(&allproc_lock); + if (restart || (seen_stopped && stopped_some)) { + kern_yield(PRI_USER); + goto allproc_loop; + } +} + +void +resume_all_proc(void) +{ + struct proc *cp, *p; + + cp = curproc; + sx_xlock(&allproc_lock); + LIST_REMOVE(cp, p_list); + LIST_INSERT_HEAD(&allproc, cp, p_list); + for (;;) { + p = LIST_NEXT(cp, p_list); + if (p == NULL) + break; + LIST_REMOVE(cp, p_list); + LIST_INSERT_AFTER(p, cp, p_list); + PROC_LOCK(p); + if ((p->p_flag & P_TOTAL_STOP) != 0) { + sx_xunlock(&allproc_lock); + _PHOLD(p); + thread_single_end(p, SINGLE_ALLPROC); + _PRELE(p); + PROC_UNLOCK(p); + sx_xlock(&allproc_lock); + } else { + PROC_UNLOCK(p); + } + } + sx_xunlock(&allproc_lock); +} + +#define TOTAL_STOP_DEBUG 1 +#ifdef TOTAL_STOP_DEBUG +volatile static int ap_resume; +#include + +static int +sysctl_debug_stop_all_proc(SYSCTL_HANDLER_ARGS) +{ + int error, val; + + val = 0; + ap_resume = 0; + error = sysctl_handle_int(oidp, &val, 0, req); + if (error != 0 || req->newptr == NULL) + return (error); + if (val != 0) { + stop_all_proc(); + syncer_suspend(); + while (ap_resume == 0) + ; + syncer_resume(); + resume_all_proc(); + } + return (0); +} + +SYSCTL_PROC(_debug, OID_AUTO, stop_all_proc, CTLTYPE_INT | CTLFLAG_RW | + CTLFLAG_MPSAFE, (void *)&ap_resume, 0, sysctl_debug_stop_all_proc, "I", + ""); +#endif diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 5cdc2ce..97245fb 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2471,7 +2471,7 @@ ptracestop(struct thread *td, int sig) cv_broadcast(&p->p_dbgwait); } stopme: - thread_suspend_switch(td); + thread_suspend_switch(td, p); if (p->p_xthread == td) p->p_xthread = NULL; if (!(p->p_flag & P_TRACED)) @@ -2730,7 +2730,7 @@ issignal(struct thread *td) p->p_xstat = sig; PROC_SLOCK(p); sig_suspend_threads(td, p, 0); - thread_suspend_switch(td); + thread_suspend_switch(td, p); PROC_SUNLOCK(p); mtx_lock(&ps->ps_mtx); break; @@ -2919,7 +2919,7 @@ sigexit(td, sig) * XXX If another thread attempts to single-thread before us * (e.g. via fork()), we won't get a dump at all. */ - if ((sigprop(sig) & SA_CORE) && (thread_single(SINGLE_NO_EXIT) == 0)) { + if ((sigprop(sig) & SA_CORE) && thread_single(p, SINGLE_NO_EXIT) == 0) { p->p_sig = sig; /* * Log signals which would cause core dumps diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index ec084ed..d10e1f3 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -64,7 +64,6 @@ __FBSDID("$FreeBSD$"); SDT_PROVIDER_DECLARE(proc); SDT_PROBE_DEFINE(proc, , , lwp__exit); - /* * thread related storage. */ @@ -446,7 +445,7 @@ thread_exit(void) if (p->p_numthreads == p->p_suspcount) { thread_lock(p->p_singlethread); wakeup_swapper = thread_unsuspend_one( - p->p_singlethread); + p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -575,13 +574,54 @@ calc_remaining(struct proc *p, int mode) remaining = p->p_numthreads; else if (mode == SINGLE_BOUNDARY) remaining = p->p_numthreads - p->p_boundary_count; - else if (mode == SINGLE_NO_EXIT) + else if (mode == SINGLE_NO_EXIT || mode == SINGLE_ALLPROC) remaining = p->p_numthreads - p->p_suspcount; else panic("calc_remaining: wrong mode %d", mode); return (remaining); } +static int +remain_for_mode(int mode) +{ + + return (mode == SINGLE_ALLPROC ? 0 : 1); +} + +static int +weed_inhib(int mode, struct thread *td2, struct proc *p) +{ + int wakeup_swapper; + + PROC_LOCK_ASSERT(p, MA_OWNED); + PROC_SLOCK_ASSERT(p, MA_OWNED); + THREAD_LOCK_ASSERT(td2, MA_OWNED); + + wakeup_swapper = 0; + switch (mode) { + case SINGLE_EXIT: + if (TD_IS_SUSPENDED(td2)) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, EINTR); + break; + case SINGLE_BOUNDARY: + if (TD_IS_SUSPENDED(td2) && (td2->td_flags & TDF_BOUNDARY) == 0) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, ERESTART); + break; + case SINGLE_ALLPROC: + case SINGLE_NO_EXIT: + if (TD_IS_SUSPENDED(td2) && (td2->td_flags & TDF_BOUNDARY) == 0) + wakeup_swapper |= thread_unsuspend_one(td2, p); + if (TD_ON_SLEEPQ(td2) && (td2->td_flags & TDF_SINTR) != 0) + wakeup_swapper |= sleepq_abort(td2, ERESTART); + break; + } + return (wakeup_swapper); +} + /* * Enforce single-threading. * @@ -596,19 +636,29 @@ calc_remaining(struct proc *p, int mode) * any sleeping threads that are interruptable. (PCATCH). */ int -thread_single(int mode) +thread_single(struct proc *p, int mode) { struct thread *td; struct thread *td2; - struct proc *p; int remaining, wakeup_swapper; td = curthread; - p = td->td_proc; + KASSERT(mode == SINGLE_EXIT || mode == SINGLE_BOUNDARY || + mode == SINGLE_ALLPROC || mode == SINGLE_NO_EXIT, + ("invalid mode %d", mode)); + /* + * If allowing non-ALLPROC singlethreading for non-curproc + * callers, calc_remaining() and remain_for_mode() should be + * adjusted to also account for td->td_proc != p. For now + * this is not implemented because it is not used. + */ + KASSERT((mode == SINGLE_ALLPROC && td->td_proc != p) || + (mode != SINGLE_ALLPROC && td->td_proc == p), + ("mode %d proc %p curproc %p", mode, p, td->td_proc)); mtx_assert(&Giant, MA_NOTOWNED); PROC_LOCK_ASSERT(p, MA_OWNED); - if ((p->p_flag & P_HADTHREADS) == 0) + if ((p->p_flag & P_HADTHREADS) == 0 && mode != SINGLE_ALLPROC) return (0); /* Is someone already single threading? */ @@ -625,11 +675,13 @@ thread_single(int mode) else p->p_flag &= ~P_SINGLE_BOUNDARY; } + if (mode == SINGLE_ALLPROC) + p->p_flag |= P_TOTAL_STOP; p->p_flag |= P_STOPPED_SINGLE; PROC_SLOCK(p); p->p_singlethread = td; remaining = calc_remaining(p, mode); - while (remaining != 1) { + while (remaining != remain_for_mode(mode)) { if (P_SHOULDSTOP(p) != P_STOPPED_SINGLE) goto stopme; wakeup_swapper = 0; @@ -638,41 +690,8 @@ thread_single(int mode) continue; thread_lock(td2); td2->td_flags |= TDF_ASTPENDING | TDF_NEEDSUSPCHK; - if (TD_IS_INHIBITED(td2)) { - switch (mode) { - case SINGLE_EXIT: - if (TD_IS_SUSPENDED(td2)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, EINTR); - break; - case SINGLE_BOUNDARY: - if (TD_IS_SUSPENDED(td2) && - !(td2->td_flags & TDF_BOUNDARY)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, ERESTART); - break; - case SINGLE_NO_EXIT: - if (TD_IS_SUSPENDED(td2) && - !(td2->td_flags & TDF_BOUNDARY)) - wakeup_swapper |= - thread_unsuspend_one(td2); - if (TD_ON_SLEEPQ(td2) && - (td2->td_flags & TDF_SINTR)) - wakeup_swapper |= - sleepq_abort(td2, ERESTART); - break; - default: - break; - } - } + if (TD_IS_INHIBITED(td2)) + wakeup_swapper |= weed_inhib(mode, td2, p); #ifdef SMP else if (TD_IS_RUNNING(td2) && td != td2) { forward_signal(td2); @@ -687,7 +706,7 @@ thread_single(int mode) /* * Maybe we suspended some threads.. was it enough? */ - if (remaining == 1) + if (remaining == remain_for_mode(mode)) break; stopme: @@ -695,7 +714,7 @@ stopme: * Wake us up when everyone else has suspended. * In the mean time we suspend as well. */ - thread_suspend_switch(td); + thread_suspend_switch(td, p); remaining = calc_remaining(p, mode); } if (mode == SINGLE_EXIT) { @@ -821,7 +840,7 @@ thread_suspend_check(int return_instead) if (p->p_numthreads == p->p_suspcount + 1) { thread_lock(p->p_singlethread); wakeup_swapper = - thread_unsuspend_one(p->p_singlethread); + thread_unsuspend_one(p->p_singlethread, p); thread_unlock(p->p_singlethread); if (wakeup_swapper) kick_proc0(); @@ -854,11 +873,9 @@ thread_suspend_check(int return_instead) } void -thread_suspend_switch(struct thread *td) +thread_suspend_switch(struct thread *td, struct proc *p) { - struct proc *p; - p = td->td_proc; KASSERT(!TD_IS_SUSPENDED(td), ("already suspended")); PROC_LOCK_ASSERT(p, MA_OWNED); PROC_SLOCK_ASSERT(p, MA_OWNED); @@ -866,8 +883,10 @@ thread_suspend_switch(struct thread *td) * We implement thread_suspend_one in stages here to avoid * dropping the proc lock while the thread lock is owned. */ - thread_stopped(p); - p->p_suspcount++; + if (p == td->td_proc) { + thread_stopped(p); + p->p_suspcount++; + } PROC_UNLOCK(p); thread_lock(td); td->td_flags &= ~TDF_NEEDSUSPCHK; @@ -897,15 +916,16 @@ thread_suspend_one(struct thread *td) } int -thread_unsuspend_one(struct thread *td) +thread_unsuspend_one(struct thread *td, struct proc *p) { - struct proc *p = td->td_proc; - PROC_SLOCK_ASSERT(p, MA_OWNED); THREAD_LOCK_ASSERT(td, MA_OWNED); KASSERT(TD_IS_SUSPENDED(td), ("Thread not suspended")); TD_CLR_SUSPENDED(td); - p->p_suspcount--; + if (td->td_proc == p) { + PROC_SLOCK_ASSERT(p, MA_OWNED); + p->p_suspcount--; + } return (setrunnable(td)); } @@ -925,7 +945,7 @@ thread_unsuspend(struct proc *p) FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } @@ -936,9 +956,12 @@ thread_unsuspend(struct proc *p) * threading request. Now we've downgraded to single-threaded, * let it continue. */ - thread_lock(p->p_singlethread); - wakeup_swapper = thread_unsuspend_one(p->p_singlethread); - thread_unlock(p->p_singlethread); + if (p->p_singlethread->td_proc == p) { + thread_lock(p->p_singlethread); + wakeup_swapper = thread_unsuspend_one( + p->p_singlethread, p); + thread_unlock(p->p_singlethread); + } } if (wakeup_swapper) kick_proc0(); @@ -948,16 +971,20 @@ thread_unsuspend(struct proc *p) * End the single threading mode.. */ void -thread_single_end(void) +thread_single_end(struct proc *p, int mode) { struct thread *td; - struct proc *p; int wakeup_swapper; - td = curthread; - p = td->td_proc; + KASSERT(mode == SINGLE_EXIT || mode == SINGLE_BOUNDARY || + mode == SINGLE_ALLPROC || mode == SINGLE_NO_EXIT, + ("invalid mode %d", mode)); PROC_LOCK_ASSERT(p, MA_OWNED); - p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY); + KASSERT((mode == SINGLE_ALLPROC && (p->p_flag & P_TOTAL_STOP) != 0) || + (mode != SINGLE_ALLPROC && (p->p_flag & P_TOTAL_STOP) == 0), + ("mode %d does not match P_TOTAL_STOP", mode)); + p->p_flag &= ~(P_STOPPED_SINGLE | P_SINGLE_EXIT | P_SINGLE_BOUNDARY | + P_TOTAL_STOP); PROC_SLOCK(p); p->p_singlethread = NULL; wakeup_swapper = 0; @@ -967,11 +994,11 @@ thread_single_end(void) * on the process. The single threader must be allowed * to continue however as this is a bad place to stop. */ - if ((p->p_numthreads != 1) && (!P_SHOULDSTOP(p))) { + if (p->p_numthreads != remain_for_mode(mode) && !P_SHOULDSTOP(p)) { FOREACH_THREAD_IN_PROC(p, td) { thread_lock(td); if (TD_IS_SUSPENDED(td)) { - wakeup_swapper |= thread_unsuspend_one(td); + wakeup_swapper |= thread_unsuspend_one(td, p); } thread_unlock(td); } diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 345aad6..b4dde06 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -1773,6 +1773,8 @@ sync_vnode(struct synclist *slp, struct bufobj **bo, struct thread *td) return (0); } +static int first_printf = 1; + /* * System filesystem synchronizer daemon. */ @@ -1791,7 +1793,6 @@ sched_sync(void) last_work_seen = 0; syncer_final_iter = 0; - first_printf = 1; syncer_state = SYNCER_RUNNING; starttime = time_uptime; td->td_pflags |= TDP_NORUNNINGBUF; @@ -1955,6 +1956,25 @@ syncer_shutdown(void *arg, int howto) kproc_shutdown(arg, howto); } +void +syncer_suspend(void) +{ + + syncer_shutdown(updateproc, 0); +} + +void +syncer_resume(void) +{ + + mtx_lock(&sync_mtx); + first_printf = 1; + syncer_state = SYNCER_RUNNING; + mtx_unlock(&sync_mtx); + cv_broadcast(&sync_wakeup); + kproc_resume(updateproc); +} + /* * Reassign a buffer from one vnode to another. * Used to assign file specific control information diff --git a/sys/sys/mount.h b/sys/sys/mount.h index c4e1145..07b9c7a 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -917,6 +917,9 @@ vfs_uninit_t vfs_stduninit; vfs_extattrctl_t vfs_stdextattrctl; vfs_sysctl_t vfs_stdsysctl; +void syncer_suspend(void); +void syncer_resume(void); + #else /* !_KERNEL */ #include diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fac0915..2163543 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -635,7 +635,7 @@ struct proc { #define P_SINGLE_BOUNDARY 0x400000 /* Threads should suspend at user boundary. */ #define P_HWPMC 0x800000 /* Process is using HWPMCs */ #define P_JAILED 0x1000000 /* Process is in jail. */ -#define P_UNUSED1 0x2000000 +#define P_TOTAL_STOP 0x2000000 /* Stopped in proc_stop_total. */ #define P_INEXEC 0x4000000 /* Process is in execve(). */ #define P_STATCHILD 0x8000000 /* Child process stopped or exited. */ #define P_INMEM 0x10000000 /* Loaded into memory. */ @@ -696,6 +696,7 @@ struct proc { #define SINGLE_NO_EXIT 0 #define SINGLE_EXIT 1 #define SINGLE_BOUNDARY 2 +#define SINGLE_ALLPROC 3 #ifdef MALLOC_DECLARE MALLOC_DECLARE(M_PARGS); @@ -945,22 +946,25 @@ void thread_exit(void) __dead2; void thread_free(struct thread *td); void thread_link(struct thread *td, struct proc *p); void thread_reap(void); -int thread_single(int how); -void thread_single_end(void); +int thread_single(struct proc *p, int how); +void thread_single_end(struct proc *p, int how); void thread_stash(struct thread *td); void thread_stopped(struct proc *p); void childproc_stopped(struct proc *child, int reason); void childproc_continued(struct proc *child); void childproc_exited(struct proc *child); int thread_suspend_check(int how); -void thread_suspend_switch(struct thread *); +void thread_suspend_switch(struct thread *, struct proc *p); void thread_suspend_one(struct thread *td); void thread_unlink(struct thread *td); void thread_unsuspend(struct proc *p); -int thread_unsuspend_one(struct thread *td); +int thread_unsuspend_one(struct thread *td, struct proc *p); void thread_wait(struct proc *p); struct thread *thread_find(struct proc *p, lwpid_t tid); +void stop_all_proc(void); +void resume_all_proc(void); + static __inline int curthread_pflags_set(int flags) { From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 18:23:59 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D0B38C5; Sat, 22 Nov 2014 18:23:59 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22CBE199; Sat, 22 Nov 2014 18:23:59 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id w10so7334014pde.10 for ; Sat, 22 Nov 2014 10:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=cYRlYWgJFRExMdS/c+Q7zWOcoxyAiQi6oFTvDphVd/c=; b=qga/4lZ5kvn5pW2mpVzRPW6Cy7SjLxutXrHDZKSLmc2ibxfmIObUVxdypSh/G1K/+0 joBb4uoSAD99JBqyCpAOnyZ0gPPTlXuo1/IIRtLWoybj8Iixo7Uz27Ki0uSywzHSpFDN ULz/zaWeDvWRRvTDzOe1Rfxnu//DHwV1QLT+ZXgzzDmVVDP5jwPGK0mfm+T6cHYyno5g 6o/XpMChbAQV28OZgqS/YT5uL8yeFIZadxzJ/ysjFIuu4q6R7z9nsHmXroSPpU0wrZap c/Mjr7nGoiITuuBbUQZx8grw4g1mmv7aWqszwWRnUj0BmdN86w7drOgADL2qqAw9/wrO syiw== X-Received: by 10.66.157.39 with SMTP id wj7mr18530337pab.117.1416680638723; Sat, 22 Nov 2014 10:23:58 -0800 (PST) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id hy15sm8092709pad.11.2014.11.22.10.23.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Nov 2014 10:23:57 -0800 (PST) References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> <1416608405.1147.307.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1416608405.1147.307.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: svn commit: r274739 - head/sys/mips/conf Date: Sat, 22 Nov 2014 10:23:57 -0800 To: Ian Lepore Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 18:23:59 -0000 This is part of what jkh brought up at MeetBSD. There are some devices that r= un FreeBSD that generally would run RTOSes, but instead run FreeBSD to do tr= anscoding and perform other tasks. One instance he brought up was an HDMI ca= ble. Devices like this don't necessarily need remote access, so there's no sense i= n running sshd, etc on them.= From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 20:42:20 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D3EDD47; Sat, 22 Nov 2014 20:42:20 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3D401108; Sat, 22 Nov 2014 20:42:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 6A09BACB7; Sat, 22 Nov 2014 20:42:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 035331F8B; Sat, 22 Nov 2014 21:42:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> Date: Sat, 22 Nov 2014 21:42:17 +0100 In-Reply-To: <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> (Mark R. V. Murray's message of "Fri, 21 Nov 2014 18:45:19 +0000") Message-ID: <86ioi7ufva.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 20:42:20 -0000 Mark R V Murray writes: > Why not just use rsh? If the security overhead is onerous, don=E2=80=99t = use it. The flower said I wish I were a tree / the tree said I wish I could be a different kind of tree /the cat wished that it was a bee / the SO wished that he could kill / rsh and rlogin... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 21:06:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25CA1E06; Sat, 22 Nov 2014 21:06:45 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D839535E; Sat, 22 Nov 2014 21:06:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id DEBB3AD40; Sat, 22 Nov 2014 21:06:43 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7778A1F91; Sat, 22 Nov 2014 22:06:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 22:06:43 +0100 In-Reply-To: <1416598889.1147.297.camel@revolution.hippie.lan> (Ian Lepore's message of "Fri, 21 Nov 2014 12:41:29 -0700") Message-ID: <86egsvueqk.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:06:45 -0000 Ian Lepore writes: > The arrogance in the way you talk down to me about my right and ability > to decide these things is mind-boggling. It's clear you're going to do > whatever you want, so I guess I'll just shut up. With all due respect, Ian, you've been very difficult to work with, not least because any attempt to have an adult discussion with you on this subject ends with you saying "you clearly don't want to listen so I'll just go away". It's simply not true, but repeat it often enough and it will *become* true. We now have automatic unblocking back (which is *precisely* what you wanted), and I am willing to allow a tunable to turn it off, but I will not allow disabling it by default, because I believe it is better than the alternative in all but a minority of cases. Considering that those cases are usually very specialized embedded systems where the developers either do not care about randomness at all or understand that it is an important issue that they need to address, I think we are better off focusing our efforts on issues such as clone divergence. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 21:12:30 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 290AD139; Sat, 22 Nov 2014 21:12:30 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D9E4B60C; Sat, 22 Nov 2014 21:12:29 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id B4957AD60; Sat, 22 Nov 2014 21:12:28 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7A8181F95; Sat, 22 Nov 2014 22:12:28 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> Date: Sat, 22 Nov 2014 22:12:28 +0100 In-Reply-To: (Adrian Chadd's message of "Fri, 21 Nov 2014 13:57:29 -0800") Message-ID: <86a93juegz.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arch@freebsd.org" , Ian Lepore , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:12:30 -0000 Adrian Chadd writes: > Unfortunately there are things that the real world expects on these > silly embedded platforms that we can't avoid [...] So, we can't just > "not" have random ready early at boot [...] Sorry to break up a good shouting match with facts, but: | r273958 | des | 2014-11-02 03:01:55 +0100 (Sun, 02 Nov 2014) | 5 lines |=20 | Restore the auto-reseed logic, but move it to a much later point, | immediately before kick_init. |=20 | Approved by: so (self) which will be three weeks ago in about five hours. Auto-reseeding was off for about 80 hours, and three weeks later you and Ian are still acting like it's off and we're refusing to turn it back on. Grow up. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 21:21:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CED083D7; Sat, 22 Nov 2014 21:21:17 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C5246D7; Sat, 22 Nov 2014 21:21:17 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XsI7I-000Cpr-J7; Sat, 22 Nov 2014 21:21:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAMLLEbD007001; Sat, 22 Nov 2014 14:21:14 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/FgM0+8yBoflTTpAkBtmUg X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86egsvueqk.fsf@nine.des.no> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 22 Nov 2014 14:21:14 -0700 Message-ID: <1416691274.1147.339.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAMLLEbD007001 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:21:17 -0000 On Sat, 2014-11-22 at 22:06 +0100, Dag-Erling Sm=F8rgrav wrote: > Ian Lepore writes: > > The arrogance in the way you talk down to me about my right and abili= ty > > to decide these things is mind-boggling. It's clear you're going to = do > > whatever you want, so I guess I'll just shut up. >=20 > With all due respect, Ian, you've been very difficult to work with, not > least because any attempt to have an adult discussion with you on this > subject ends with you saying "you clearly don't want to listen so I'll > just go away". It's simply not true, but repeat it often enough and it > will *become* true. >=20 > We now have automatic unblocking back (which is *precisely* what you I noted that in one of my replies, and also said that it appeared from this thread that that was considered a temporary action which would be undone. Nobody contradicted that until now. > wanted), and I am willing to allow a tunable to turn it off, but I will > not allow disabling it by default, because I believe it is better than That's all I ever asked for, from day one, and this is the first non-negative response to it I can remember. I never asked for it to be disabled by default. I asked for a knob. I asked for it to possibily take multiple knobs, or anything else reasonable to make it difficult to do the wrong thing by accident. When Adrian started talking about a somewhat different need, I went out of my way to point out that his request was different than mine, just to make sure there was no confusion about any sort of enabled-by-default. So yes, maybe my tone has been a bit strident. That tends to happen when you keep saying one thing and the responses you get are as if you had said something else completely. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 22:33:13 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59677C37; Sat, 22 Nov 2014 22:33:13 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7A45D13; Sat, 22 Nov 2014 22:33:12 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so2442122wiw.15 for ; Sat, 22 Nov 2014 14:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tlH/X91KnkNe5EbSXq/mQZlwEMy56Wgbk6Xq6v8L1ps=; b=mlD6vuR9gQsh3g/uaRVki2lAzkKyBBNf69z4vpLZreZD4sBeHSmsdzIyKVR50NTw98 lxOwgphNnefzI4R1Y452a2QovXS/+LMfZ++MxOh886sgj9Ku98sA0TamJi9YhYYJUMog Lr6XjQhAJ+MZAzbvyhjjlxp0nby5FId6LIpkwYhxNkIgWV0O8dvAMIP8Kg1lhaOwyWbS Ca1rO70fMmdR3w6NZM+k9hPe0S2u6v1Mcn+yKrigjl33To4rIG1fC9yF6fwOH6UFONyo 4Pilvpf1Ugjya24edi5o6fkl17wa7IG33Dq3onq0VFBa/ENXJT3ma0+wgoLAJ1k5c18f UFUw== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr20040562wjn.68.1416695591317; Sat, 22 Nov 2014 14:33:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 22 Nov 2014 14:33:11 -0800 (PST) In-Reply-To: <86a93juegz.fsf@nine.des.no> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> <86a93juegz.fsf@nine.des.no> Date: Sat, 22 Nov 2014 14:33:11 -0800 X-Google-Sender-Auth: kvQgR4cWAs5G7JgewpSDPJIUVM8 Message-ID: Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Adrian Chadd To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arch@freebsd.org" , Ian Lepore , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:33:13 -0000 On 22 November 2014 at 13:12, Dag-Erling Sm=C3=B8rgrav wrote: > Adrian Chadd writes: >> Unfortunately there are things that the real world expects on these >> silly embedded platforms that we can't avoid [...] So, we can't just >> "not" have random ready early at boot [...] > > Sorry to break up a good shouting match with facts, but: > > | r273958 | des | 2014-11-02 03:01:55 +0100 (Sun, 02 Nov 2014) | 5 lines > | > | Restore the auto-reseed logic, but move it to a much later point, > | immediately before kick_init. > | > | Approved by: so (self) > > which will be three weeks ago in about five hours. Auto-reseeding was > off for about 80 hours, and three weeks later you and Ian are still > acting like it's off and we're refusing to turn it back on. Grow up. And I thank you for that. -adrian From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 22:55:27 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EFD11DA; Sat, 22 Nov 2014 22:55:27 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 030C1E9B; Sat, 22 Nov 2014 22:55:26 +0000 (UTC) Received: from [2001:470:9174:1:178:bba0:7b1:d5c2] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XsJaO-000PLR-8e; Sat, 22 Nov 2014 22:55:24 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=windows-1252 From: Mark R V Murray In-Reply-To: <1416691274.1147.339.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 22:55:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:55:27 -0000 > On 22 Nov 2014, at 21:21, Ian Lepore wrote: >> We now have automatic unblocking back (which is *precisely* what you >=20 > I noted that in one of my replies, and also said that it appeared from > this thread that that was considered a temporary action which would be > undone. Nobody contradicted that until now. This is Yarrow-specific. As Yarrow is no longer recommended by its designers, it should be considered deprecated. Fortuna gets going much quicker than Yarrow; have you tried this like I asked? >> wanted), and I am willing to allow a tunable to turn it off, but I = will >> not allow disabling it by default, because I believe it is better = than >=20 > That's all I ever asked for, from day one, and this is the first > non-negative response to it I can remember. I never asked for it to = be > disabled by default. I asked for a knob. I asked for it to possibily > take multiple knobs, or anything else reasonable to make it difficult = to > do the wrong thing by accident. See above and my other mail (the one you didn=92t answer). M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 22:58:02 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C271369; Sat, 22 Nov 2014 22:58:02 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EAE7EB1; Sat, 22 Nov 2014 22:58:02 +0000 (UTC) Received: from [2001:470:9174:1:178:bba0:7b1:d5c2] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XsJcu-000PLZ-9i; Sat, 22 Nov 2014 22:58:00 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii From: Mark R V Murray In-Reply-To: Date: Sat, 22 Nov 2014 22:57:40 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <7387FDB9-206F-418F-8B0B-D1FB9723A4D7@grondar.org> <86a93juegz.fsf@nine.des.no> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:58:02 -0000 > On 22 Nov 2014, at 22:33, Adrian Chadd wrote: >> | Restore the auto-reseed logic, but move it to a much later point, >> | immediately before kick_init. >> | >> | Approved by: so (self) >> >> which will be three weeks ago in about five hours. Auto-reseeding was >> off for about 80 hours, and three weeks later you and Ian are still >> acting like it's off and we're refusing to turn it back on. Grow up. > > And I thank you for that. And note that this is Yarrow-specific. Reports of acceptable Fortuna behaviour are so far absent, despite requests. M -- Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Sat Nov 22 23:12:03 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70E4E7C0 for ; Sat, 22 Nov 2014 23:12:03 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 383BD85 for ; Sat, 22 Nov 2014 23:12:03 +0000 (UTC) Received: from [2001:470:9174:1:178:bba0:7b1:d5c2] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XsJqS-000PMK-37; Sat, 22 Nov 2014 23:12:01 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <86ioi7ufva.fsf@nine.des.no> Date: Sat, 22 Nov 2014 23:11:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5110F41E-AFC7-4759-A8CF-2D962352C006@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <86ioi7ufva.fsf@nine.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:12:03 -0000 > On 22 Nov 2014, at 20:42, Dag-Erling Sm=C3=B8rgrav wrote: >=20 > Mark R V Murray writes: >> Why not just use rsh? If the security overhead is onerous, don=E2=80=99= t use it. >=20 > The flower said I wish I were a tree / the tree said I wish I could be = a > different kind of tree /the cat wished that it was a bee / the SO = wished > that he could kill / rsh and rlogin=E2=80=A6 Hehehehe! I still like using these in isolated nets where external hackery is of = no concern, and something low-maintenance/overhead is needed. Its been a = while since I did this, I admit, but I=E2=80=99d hate to lose them. They = are, after all, disabled by default, as is telnet. Some time ago I had a separate =E2=80=9Cbackbone=E2=80=9D net on which = my NFS mounts operated. I also ran various inter-box jobs using rsh so I = didn=E2=80=99t have to deal with crypto overhead. The single = outward-facing connection was heavily secured. I'd prefer to see r-utils maintained as part of the core OS, but if = there was a maintained port, I guess I could tolerate that. :-) M --=20 Mark R V Murray