From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 20:53:21 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21F8E10656A9 for ; Mon, 25 Oct 2010 20:53:21 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B3A3E8FC18 for ; Mon, 25 Oct 2010 20:53:19 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAU2g-0003XS-AN for freebsd-arch@freebsd.org; Mon, 25 Oct 2010 22:53:18 +0200 Received: from 78-1-180-0.adsl.net.t-com.hr ([78.1.180.0]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 22:53:18 +0200 Received: from ivoras by 78-1-180-0.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 22:53:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 25 Oct 2010 22:53:08 +0200 Lines: 43 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-180-0.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 Subject: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:53:21 -0000 Fusefs is the Linux-developed userland filesystem interface which is fairly popular in the wild, especially with the "sshfs" module which allows mounting of generic ssh/sftp directories in a very easy way. It was developed in one of the very early Google Summer of Code projects (2005) and is now in a bit unusual situation: 1) it *is* popular, as reports about its breakage arrive pretty soon after it breaks 2) it is currently practically unmaintained. The source code archive is from 2008 and the port contains a dozen patches to be applied to it to make it work on recent systems 3) it is also not exactly rock stable, though this has improved with the above patches; personally I'd judge it to be as stable as ZFS was two years ago so there :) I'm proposing to import the kernel module into the official tree (there are also userland libraries under the GPL; they will stay as ports). There are no license conflicts for the kernel module. I see two benefits from it: 1) it will finally integrate the patches needed for it to work in one tree and provide the "one official place" to work on it 2) it will be easier to maintain it here, and changes to the VFS APIs would be applied to it in sweeping commits together with other file systems. I'm not knowledgeable enough to actively work on it (yet) but I can mechanically maintain it and generally take care of it. Objections? References: http://fuse.sourceforge.net/ http://fuse4bsd.creo.hu/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/ http://old.nabble.com/forum/Search.jtp?forum=6572&local=y&query=fusefs http://old.nabble.com/forum/Search.jtp?forum=6610&local=y&query=fusefs From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 21:19:09 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB4A106564A for ; Mon, 25 Oct 2010 21:19:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 160038FC14 for ; Mon, 25 Oct 2010 21:19:08 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9PLJ46T088043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 00:19:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9PLJ4xH038606; Tue, 26 Oct 2010 00:19:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9PLJ4G7038605; Tue, 26 Oct 2010 00:19:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Oct 2010 00:19:04 +0300 From: Kostik Belousov To: Ivan Voras Message-ID: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2EBbOLNpWrgl9Xdv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:19:09 -0000 --2EBbOLNpWrgl9Xdv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: > Fusefs is the Linux-developed userland filesystem interface which is=20 > fairly popular in the wild, especially with the "sshfs" module which=20 > allows mounting of generic ssh/sftp directories in a very easy way. >=20 > It was developed in one of the very early Google Summer of Code projects= =20 > (2005) and is now in a bit unusual situation: >=20 > 1) it *is* popular, as reports about its breakage arrive pretty soon=20 > after it breaks >=20 > 2) it is currently practically unmaintained. The source code archive is= =20 > from 2008 and the port contains a dozen patches to be applied to it to=20 > make it work on recent systems >=20 > 3) it is also not exactly rock stable, though this has improved with the= =20 > above patches; personally I'd judge it to be as stable as ZFS was two=20 > years ago so there :) >=20 > I'm proposing to import the kernel module into the official tree (there= =20 > are also userland libraries under the GPL; they will stay as ports).=20 > There are no license conflicts for the kernel module. I see two benefits= =20 > from it: >=20 > 1) it will finally integrate the patches needed for it to work in one=20 > tree and provide the "one official place" to work on it >=20 > 2) it will be easier to maintain it here, and changes to the VFS APIs=20 > would be applied to it in sweeping commits together with other file syste= ms. >=20 > I'm not knowledgeable enough to actively work on it (yet) but I can=20 > mechanically maintain it and generally take care of it. >=20 > Objections? This is not going to work. The code is unmaintained. Committing it into the src/ just makes the pile of not working code in src/ bigger. --2EBbOLNpWrgl9Xdv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzF9EgACgkQC3+MBN1Mb4gVngCg9YXz6HPSYCEMqquDuCAD1tw4 AXAAoJ1/GGPBHAQu6RF/Z0a3hCEeuOxV =zdAf -----END PGP SIGNATURE----- --2EBbOLNpWrgl9Xdv-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 21:29:19 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EA0106566B; Mon, 25 Oct 2010 21:29:19 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACBF8FC16; Mon, 25 Oct 2010 21:29:18 +0000 (UTC) Received: by bwz3 with SMTP id 3so3361035bwz.13 for ; Mon, 25 Oct 2010 14:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=PQo4ZiQY+1th7+Bgkfz9m69Cn3yoM3XGEcw8uYhhrPw=; b=oJeENy1xHVboIk5p07OqwiC1RR12x3/atCLqu71OiO/ZPW8pb8AJ4AVSxGLdjhnj5d wuNZbiC6hYrR4SH19SU60sWdyGUZ3ne12Re4EhLlIVkJcZZTUC/w4oTLt/jI27ceC1nb W1eanst0tbRfve2xxhUbUplQgvxBt/LhtX9Z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=GsB2LBBHLqIzfPmWA7fribCBW6oHu61uQinoveFQzUJpCvQYj3GKnbJS8UAZrpKInG k32kS29tHIFsBJpmCWIPuEaRsbCvOB28XeBXCq3+aZ+wIwXXjLn10ENltBykXkoOrAVO 2cvgbnC/ukLRRm+nUTDrk6qODaDUYzq5sWyBk= Received: by 10.204.114.205 with SMTP id f13mr4540755bkq.86.1288040732406; Mon, 25 Oct 2010 14:05:32 -0700 (PDT) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id t10sm5263239bkj.4.2010.10.25.14.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 14:05:31 -0700 (PDT) Sender: Alex Kozlov Date: Tue, 26 Oct 2010 00:05:29 +0300 From: Alex Kozlov To: Ivan Voras , freebsd-arch@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20101025210529.GB27091@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:29:19 -0000 On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: > Fusefs is the Linux-developed userland filesystem interface which is > fairly popular in the wild, especially with the "sshfs" module which > allows mounting of generic ssh/sftp directories in a very easy way. > > It was developed in one of the very early Google Summer of Code projects > (2005) and is now in a bit unusual situation: > > 1) it *is* popular, as reports about its breakage arrive pretty soon > after it breaks > > 2) it is currently practically unmaintained. The source code archive is > from 2008 and the port contains a dozen patches to be applied to it to > make it work on recent systems > > 3) it is also not exactly rock stable, though this has improved with the > above patches; personally I'd judge it to be as stable as ZFS was two > years ago so there :) > > I'm proposing to import the kernel module into the official tree (there > are also userland libraries under the GPL; they will stay as ports). > There are no license conflicts for the kernel module. I see two benefits > from it: > > 1) it will finally integrate the patches needed for it to work in one > tree and provide the "one official place" to work on it > > 2) it will be easier to maintain it here, and changes to the VFS APIs > would be applied to it in sweeping commits together with other file systems. > > I'm not knowledgeable enough to actively work on it (yet) but I can > mechanically maintain it and generally take care of it. > > Objections? Have You considered the possibility of importing puffs/refuse instead? http://www.netbsd.org/docs/puffs/ -- Adios From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 21:35:35 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36BE31065670 for ; Mon, 25 Oct 2010 21:35:35 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E485D8FC15 for ; Mon, 25 Oct 2010 21:35:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAUhZ-0004oZ-0n for freebsd-arch@freebsd.org; Mon, 25 Oct 2010 23:35:33 +0200 Received: from 78-1-180-0.adsl.net.t-com.hr ([78.1.180.0]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 23:35:33 +0200 Received: from ivoras by 78-1-180-0.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 23:35:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 25 Oct 2010 23:35:22 +0200 Lines: 25 Message-ID: References: <20101025210529.GB27091@ravenloft.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-180-0.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 In-Reply-To: <20101025210529.GB27091@ravenloft.kiev.ua> Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:35:35 -0000 On 10/25/10 23:05, Alex Kozlov wrote: > On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: >> Fusefs is the Linux-developed userland filesystem interface which is >> fairly popular in the wild, especially with the "sshfs" module which >> allows mounting of generic ssh/sftp directories in a very easy way. > Have You considered the possibility of importing puffs/refuse instead? > http://www.netbsd.org/docs/puffs/ Yes, and discarded it for these reasons: - fusefs is much more popular / has more file systems developed for it (and refuse is not 1:1 identical enough to be stable) - it has a better concurrency model, allowing for potentially better performance - it is older / more mature There was a relatively recent Summer of Code effort to port puffs to FreeBSD, but it is in the same state fusefs was when it was being worked on: there are rough edges that need patching. Of course, all this does not preclude anyone importing puffs in the future. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 21:40:09 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6842106566B for ; Mon, 25 Oct 2010 21:40:09 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 888998FC0A for ; Mon, 25 Oct 2010 21:40:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAUlx-0006dh-Bi for freebsd-arch@freebsd.org; Mon, 25 Oct 2010 23:40:05 +0200 Received: from 78-1-180-0.adsl.net.t-com.hr ([78.1.180.0]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 23:40:05 +0200 Received: from ivoras by 78-1-180-0.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Oct 2010 23:40:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 25 Oct 2010 23:38:44 +0200 Lines: 7 Message-ID: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-180-0.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 In-Reply-To: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:40:09 -0000 On 10/25/10 23:19, Kostik Belousov wrote: > This is not going to work. The code is unmaintained. Committing it into > the src/ just makes the pile of not working code in src/ bigger. Yes, but on the other hand, not importing it means that the code will only decay faster. It's basically a damage control issue :) From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 21:46:35 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C379106566C; Mon, 25 Oct 2010 21:46:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 018958FC15; Mon, 25 Oct 2010 21:46:34 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9PLkVBL089727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 00:46:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9PLkUPa038830; Tue, 26 Oct 2010 00:46:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9PLkUF5038829; Tue, 26 Oct 2010 00:46:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Oct 2010 00:46:30 +0300 From: Kostik Belousov To: Ivan Voras Message-ID: <20101025214630.GO2392@deviant.kiev.zoral.com.ua> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rh1jIF008qzNHrIf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:46:35 -0000 --Rh1jIF008qzNHrIf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2010 at 11:38:44PM +0200, Ivan Voras wrote: > On 10/25/10 23:19, Kostik Belousov wrote: >=20 > >This is not going to work. The code is unmaintained. Committing it into > >the src/ just makes the pile of not working code in src/ bigger. >=20 > Yes, but on the other hand, not importing it means that the code will=20 > only decay faster. It's basically a damage control issue :) No, the fusefs it is not usable in its current state (means, causing random kernel memory corruption). Committing it causes wrong users expectation, because code does not work, and also looks like a trick to make it appears to be maintaned, which obviously will not happen. Consider this as an official objection for the import, unless somebody is going to take the maintainership. --Rh1jIF008qzNHrIf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzF+rYACgkQC3+MBN1Mb4gPrQCfeKtCj0p4SZ8BaDr3O6Fl4sul n7gAoKI3w2aC/Sgh7NH0Xv5Y7p39JH0q =Hb0g -----END PGP SIGNATURE----- --Rh1jIF008qzNHrIf-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 22:37:31 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE3F1065675 for ; Mon, 25 Oct 2010 22:37:31 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 970BF8FC26 for ; Mon, 25 Oct 2010 22:37:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAVfT-00044m-OH for freebsd-arch@freebsd.org; Tue, 26 Oct 2010 00:37:27 +0200 Received: from 78-1-180-0.adsl.net.t-com.hr ([78.1.180.0]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Oct 2010 00:37:27 +0200 Received: from ivoras by 78-1-180-0.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Oct 2010 00:37:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Tue, 26 Oct 2010 00:37:18 +0200 Lines: 30 Message-ID: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101025214630.GO2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-180-0.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 In-Reply-To: <20101025214630.GO2392@deviant.kiev.zoral.com.ua> Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:37:32 -0000 On 10/25/10 23:46, Kostik Belousov wrote: > On Mon, Oct 25, 2010 at 11:38:44PM +0200, Ivan Voras wrote: >> On 10/25/10 23:19, Kostik Belousov wrote: >> >>> This is not going to work. The code is unmaintained. Committing it into >>> the src/ just makes the pile of not working code in src/ bigger. >> >> Yes, but on the other hand, not importing it means that the code will >> only decay faster. It's basically a damage control issue :) > No, the fusefs it is not usable in its current state (means, causing random > kernel memory corruption). The current state of it (tested against sshfs on 8-stable amd64) is: - survives blogbench runs - survives fsx runs with arguments "-W -R -L", i.e. no mmaped operations, no file size / truncate operations ... without crashing. I cannot verify kernel memory corruption but I'm running a heavy X desktop here and it survives. > Committing it causes wrong users expectation, because code does > not work, and also looks like a trick to make it appears to be maintaned, > which obviously will not happen. > > Consider this as an official objection for the import, unless somebody > is going to take the maintainership. Noted. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 07:09:27 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF714106564A; Tue, 26 Oct 2010 07:09:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 27ACA8FC12; Tue, 26 Oct 2010 07:09:26 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=4dE6tNKVm/0afO7MQGRPv7y2YwMo4emTIiDjbh74onY= c=1 sm=1 a=XsWmvbIU2mQA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=BLIEhfte67SCe0Bhgu4A:9 a=bmRNXRO6FmIuT8YvwPwA:7 a=t-3melNy48VAGpZ45l34bllu5VkA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 40177900; Tue, 26 Oct 2010 08:59:23 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 26 Oct 2010 09:00:35 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010260900.35059.hselasky@c2i.net> Cc: Kostik Belousov , Ivan Voras Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:09:27 -0000 On Monday 25 October 2010 23:19:04 Kostik Belousov wrote: > On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: > > Fusefs is the Linux-developed userland filesystem interface which is > > fairly popular in the wild, especially with the "sshfs" module which > > allows mounting of generic ssh/sftp directories in a very easy way. > > > > It was developed in one of the very early Google Summer of Code projects > > (2005) and is now in a bit unusual situation: > > > > 1) it *is* popular, as reports about its breakage arrive pretty soon > > after it breaks > > > > 2) it is currently practically unmaintained. The source code archive is > > from 2008 and the port contains a dozen patches to be applied to it to > > make it work on recent systems > > > > 3) it is also not exactly rock stable, though this has improved with the > > above patches; personally I'd judge it to be as stable as ZFS was two > > years ago so there :) > > > > I'm proposing to import the kernel module into the official tree (there > > are also userland libraries under the GPL; they will stay as ports). > > There are no license conflicts for the kernel module. I see two benefits > > from it: > > > > 1) it will finally integrate the patches needed for it to work in one > > tree and provide the "one official place" to work on it > > > > 2) it will be easier to maintain it here, and changes to the VFS APIs > > would be applied to it in sweeping commits together with other file > > systems. > > > > I'm not knowledgeable enough to actively work on it (yet) but I can > > mechanically maintain it and generally take care of it. > > > > Objections? > > This is not going to work. The code is unmaintained. Committing it into > the src/ just makes the pile of not working code in src/ bigger. FYI: There also exists a project called cuse4bsd. --HPS From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 07:35:08 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 544561065696 for ; Tue, 26 Oct 2010 07:35:08 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id D6AC48FC1A for ; Tue, 26 Oct 2010 07:35:07 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9Q7Z4Sl024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 18:35:05 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o9Q7Z4PT044934; Tue, 26 Oct 2010 18:35:04 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o9Q7Z44f044933; Tue, 26 Oct 2010 18:35:04 +1100 (EST) (envelope-from peter) Date: Tue, 26 Oct 2010 18:35:04 +1100 From: Peter Jeremy To: Ivan Voras Message-ID: <20101026073504.GA44394@server.vk2pj.dyndns.org> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101025214630.GO2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:35:08 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-26 00:37:18 +0200, Ivan Voras wrote: >On 10/25/10 23:46, Kostik Belousov wrote: >> On Mon, Oct 25, 2010 at 11:38:44PM +0200, Ivan Voras wrote: >>> On 10/25/10 23:19, Kostik Belousov wrote: >>> >>>> This is not going to work. The code is unmaintained. Committing it into >>>> the src/ just makes the pile of not working code in src/ bigger. >>> >>> Yes, but on the other hand, not importing it means that the code will >>> only decay faster. It's basically a damage control issue :) IMHO, Kostik is correct - whilst the Project has imported code with rough edges in the past, the code was usable/useful as imported as was undergoing active development. My understanding is that you are not offering to provide active maintainership which basically means you are offering to import a block of buggy code which will then be left to rot further. > - survives fsx runs with arguments "-W -R -L", i.e. no mmaped=20 >operations, no file size / truncate operations mmap(2) is fairly critical: An initial quick check shows that cp(1), cmp(1), ar(1) and grep(1) use it where possible and rtld(1) relies on it. I would suggest that fusefs should remain as a port until it becomes reasonably stable and has someone willing to actively maintain it. --=20 Peter Jeremy --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzGhKgACgkQ/opHv/APuIcZwwCgqNfrU0OWx6A0K9yOxCY4ABRu QjUAnR56jG+XudWkZ3dMyT6z4eKzs67p =Ee1v -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 09:59:52 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B72106564A; Tue, 26 Oct 2010 09:59:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id F08A38FC15; Tue, 26 Oct 2010 09:59:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=XsWmvbIU2mQA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=ndaoGXS1AAAA:8 a=oBVm4UjiHrNnijQnX3cA:9 a=4M0SHhIVea82AFazK3S3iSHtk4gA:4 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 39807422; Tue, 26 Oct 2010 11:59:30 +0200 From: Hans Petter Selasky To: Ivan Voras Date: Tue, 26 Oct 2010 11:59:06 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010260900.35059.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010261159.07015.hselasky@c2i.net> Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 09:59:52 -0000 On Tuesday 26 October 2010 11:53:59 Ivan Voras wrote: > On 26 October 2010 09:00, Hans Petter Selasky wrote: > > cuse4bsd > > Thanks; I think the page at > http://www.selasky.org/hans_petter/cuse4bsd/index.html would be better > if it contained a short description of what cuse4bsd can be used for > > :) > > (I also found http://www.selasky.org/hans_petter/video4bsd/) > > FWIW, I'm in favor of enhancing userland-kernel tools like that - if > it's stable enough, I'd also vote for importing cuse4bsd. Hi, It is currently in ports: /usr/ports/multimedia/cuse4bsd-kmod It supports mmap, but the number of allocations is limited due to the fact that memory which has been mmap'ed cannot be freed. cuse4bsd has room for optimalisations. And there is a manpage after you install it :-) man cuse4bsd --HPS From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 10:17:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E1DC1065670 for ; Tue, 26 Oct 2010 10:17:50 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8EBA8FC1A for ; Tue, 26 Oct 2010 10:17:49 +0000 (UTC) Received: by qwe4 with SMTP id 4so2369400qwe.13 for ; Tue, 26 Oct 2010 03:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=+ndKimgVuUF6iVy3Iq+gZsGpktgF7nJxn1S9EAfrw1M=; b=edF9a6TJYzimLqzQyCzHnAsbBMUaRumct1b5Yk7yMCgotJHc7OhrunPce6XjASzjIN 1nOLOUNveydVhiNwYGxnGlAy4fFzACEphkV054XIlEsfH9uxY1EFw0COcUkRMWjfBqD6 PT1D+rNdqA0meABAtRQn2gmDlKNLHgG/8V0u8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=aebvQowZdAjEPKhdWivNtnWCpEguaFfunQJ/EVYo4HFnNngHl+kXwxjRZ4FYo7jNao NzXQqis9O3p4H9S0AzgqIfRhLKGF17mwY+lnCVpEA+dZQlmZW2lmh3woFzrKx9ZHjBhD m+yxCxm6yt3xKF6z4YlZ4cIPP/GOhCB128cjw= Received: by 10.229.231.8 with SMTP id jo8mr7152805qcb.45.1288086881191; Tue, 26 Oct 2010 02:54:41 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Tue, 26 Oct 2010 02:53:59 -0700 (PDT) In-Reply-To: <201010260900.35059.hselasky@c2i.net> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <201010260900.35059.hselasky@c2i.net> From: Ivan Voras Date: Tue, 26 Oct 2010 11:53:59 +0200 X-Google-Sender-Auth: _NHbLR_QRBsisTKC2OwpAqi-vRI Message-ID: To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 10:17:50 -0000 On 26 October 2010 09:00, Hans Petter Selasky wrote: > cuse4bsd Thanks; I think the page at http://www.selasky.org/hans_petter/cuse4bsd/index.html would be better if it contained a short description of what cuse4bsd can be used for :) (I also found http://www.selasky.org/hans_petter/video4bsd/) FWIW, I'm in favor of enhancing userland-kernel tools like that - if it's stable enough, I'd also vote for importing cuse4bsd. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 11:51:02 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67AB7106566B for ; Tue, 26 Oct 2010 11:51:02 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 281C68FC1B for ; Tue, 26 Oct 2010 11:51:01 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id 8D6B039DFE; Tue, 26 Oct 2010 13:33:36 +0200 (CEST) Date: Tue, 26 Oct 2010 13:33:36 +0200 From: Lars Engels To: Ivan Voras Message-ID: <20101026113336.GD26383@e.0x20.net> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lc9FT7cWel8HagAv" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: , kris@pcbsd.org, freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 11:51:02 -0000 --lc9FT7cWel8HagAv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2010 at 11:38:44PM +0200, Ivan Voras wrote: > On 10/25/10 23:19, Kostik Belousov wrote: >=20 > > This is not going to work. The code is unmaintained. Committing it into > > the src/ just makes the pile of not working code in src/ bigger. >=20 > Yes, but on the other hand, not importing it means that the code will=20 > only decay faster. It's basically a damage control issue :) Maybe the PCBSD people / iXSystems is interested in polishing fuse? I guess that many users of PCBSD also have a Windows NTFS slice on their machine and want to access their data on that slice. --lc9FT7cWel8HagAv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkzGvJAACgkQKc512sD3afilXgCdHRR96H0l+wNAHkE7sqAR2Zv7 8X8AoJB/YfpJWVUvOSv2O4Ebh8jcwVns =jJ+1 -----END PGP SIGNATURE----- --lc9FT7cWel8HagAv-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 20:58:03 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117BC1065670 for ; Tue, 26 Oct 2010 20:58:03 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id AE9AF8FC12 for ; Tue, 26 Oct 2010 20:58:02 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id o9QKw15f039764; Tue, 26 Oct 2010 16:58:01 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id o9QKw16V039763; Tue, 26 Oct 2010 16:58:01 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 26 Oct 2010 16:58:01 -0400 From: David Schultz To: Kostik Belousov Message-ID: <20101026205801.GA39716@zim.MIT.EDU> Mail-Followup-To: Kostik Belousov , Ivan Voras , freebsd-arch@freebsd.org References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> Cc: Ivan Voras , freebsd-arch@FreeBSD.ORG Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:58:03 -0000 On Tue, Oct 26, 2010, Kostik Belousov wrote: > On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: > > Fusefs is the Linux-developed userland filesystem interface which is > > fairly popular in the wild, especially with the "sshfs" module which > > allows mounting of generic ssh/sftp directories in a very easy way. > > > > It was developed in one of the very early Google Summer of Code projects > > (2005) and is now in a bit unusual situation: > > > > 1) it *is* popular, as reports about its breakage arrive pretty soon > > after it breaks > > > > 2) it is currently practically unmaintained. The source code archive is > > from 2008 and the port contains a dozen patches to be applied to it to > > make it work on recent systems > > > > 3) it is also not exactly rock stable, though this has improved with the > > above patches; personally I'd judge it to be as stable as ZFS was two > > years ago so there :) > > > > I'm proposing to import the kernel module into the official tree (there > > are also userland libraries under the GPL; they will stay as ports). > > There are no license conflicts for the kernel module. I see two benefits > > from it: > > > > 1) it will finally integrate the patches needed for it to work in one > > tree and provide the "one official place" to work on it > > > > 2) it will be easier to maintain it here, and changes to the VFS APIs > > would be applied to it in sweeping commits together with other file systems. > > > > I'm not knowledgeable enough to actively work on it (yet) but I can > > mechanically maintain it and generally take care of it. > > > > Objections? > This is not going to work. The code is unmaintained. Committing it into > the src/ just makes the pile of not working code in src/ bigger. I used it about a year ago to grade student projects for a class. I had a bunch of buggy student code interfacing with the kernel module via libfuse, and it was quite stable for my purposes. The project didn't involve supporting mmap, though. When I subsequently upgraded my kernel, however, the port broke. The value of having FUSE in the tree is that it encourages people to put forth the modicum of effort required to ensure that it still compiles when kernel APIs change. I can't comment on whether it is popular enough to support to such a minimal extent, but it is a nifty little package: you maintain one kernel module, and you get passable support for several dozen filesystems for free. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 23:31:09 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCE6106566C; Tue, 26 Oct 2010 23:31:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1588FC16; Tue, 26 Oct 2010 23:31:08 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9QNKBHJ013878; Tue, 26 Oct 2010 17:20:11 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101026205801.GA39716@zim.MIT.EDU> Date: Tue, 26 Oct 2010 17:20:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Kostik Belousov , Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:31:09 -0000 On Oct 26, 2010, at 2:58 PM, David Schultz wrote: > On Tue, Oct 26, 2010, Kostik Belousov wrote: >> On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: >>> Fusefs is the Linux-developed userland filesystem interface which is=20= >>> fairly popular in the wild, especially with the "sshfs" module which=20= >>> allows mounting of generic ssh/sftp directories in a very easy way. >>>=20 >>> It was developed in one of the very early Google Summer of Code = projects=20 >>> (2005) and is now in a bit unusual situation: >>>=20 >>> 1) it *is* popular, as reports about its breakage arrive pretty soon=20= >>> after it breaks >>>=20 >>> 2) it is currently practically unmaintained. The source code archive = is=20 >>> from 2008 and the port contains a dozen patches to be applied to it = to=20 >>> make it work on recent systems >>>=20 >>> 3) it is also not exactly rock stable, though this has improved with = the=20 >>> above patches; personally I'd judge it to be as stable as ZFS was = two=20 >>> years ago so there :) >>>=20 >>> I'm proposing to import the kernel module into the official tree = (there=20 >>> are also userland libraries under the GPL; they will stay as ports).=20= >>> There are no license conflicts for the kernel module. I see two = benefits=20 >>> from it: >>>=20 >>> 1) it will finally integrate the patches needed for it to work in = one=20 >>> tree and provide the "one official place" to work on it >>>=20 >>> 2) it will be easier to maintain it here, and changes to the VFS = APIs=20 >>> would be applied to it in sweeping commits together with other file = systems. >>>=20 >>> I'm not knowledgeable enough to actively work on it (yet) but I can=20= >>> mechanically maintain it and generally take care of it. >>>=20 >>> Objections? >> This is not going to work. The code is unmaintained. Committing it = into >> the src/ just makes the pile of not working code in src/ bigger. >=20 > I used it about a year ago to grade student projects for a class. > I had a bunch of buggy student code interfacing with the kernel > module via libfuse, and it was quite stable for my purposes. > The project didn't involve supporting mmap, though. >=20 > When I subsequently upgraded my kernel, however, the port broke. >=20 > The value of having FUSE in the tree is that it encourages people > to put forth the modicum of effort required to ensure that it still > compiles when kernel APIs change. I can't comment on whether it is > popular enough to support to such a minimal extent, but it is a > nifty little package: you maintain one kernel module, and you get > passable support for several dozen filesystems for free. What is comes down to is that it needs a committed owner, someone who = not only will shepherd it into the tree, but also work on continuous = improvements and handle bug reports. I personally think that it would = be a good thing to have in the kernel, but I can't afford the = commitment. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 00:46:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4F4106564A; Wed, 27 Oct 2010 00:46:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 275DB8FC16; Wed, 27 Oct 2010 00:46:57 +0000 (UTC) Received: by wwb24 with SMTP id 24so97114wwb.31 for ; Tue, 26 Oct 2010 17:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SzsaPbE+9hHZ5RfQAWkoBHJ0gk28zsBG+hSaF0KhYt0=; b=Uqofqyr6dq42DwsJUKECp59VBaFyrFFBPAA1H3vMK+6Bg/4QwSID9M2jTEAKZ6wQHt nVu5AvKK8IUfsK5mVZVySwkNgzhduKxPNrOdz5S3CmpVLg9R77GdId2bChQb68N/doB+ gfYZeUkPTj6KH3V1xOmJWh6jrHPc2+cGm8ksM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=C9+7Ap6fCLo64ciq/ql2SeZjIirZkAZJmvUW+7QtI6Djwg4nW9wMZtsuSBU2cVhiep SAr0ajRpMwKYJn+U/C9j0/m/aUWC/n5FXAcXYbC+SpdenOTV0AUuHfwG9O90IGuRYizf +eE60ncjX3bXlILRMzuQ095vu3ABTvf5UEUxw= MIME-Version: 1.0 Received: by 10.227.155.11 with SMTP id q11mr114394wbw.130.1288138931355; Tue, 26 Oct 2010 17:22:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Tue, 26 Oct 2010 17:22:11 -0700 (PDT) In-Reply-To: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> Date: Tue, 26 Oct 2010 17:22:11 -0700 X-Google-Sender-Auth: 4oFZjc9u-sYPVHI4XZ30-NrB7gc Message-ID: From: Garrett Cooper To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , David Schultz , Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:46:58 -0000 On Tue, Oct 26, 2010 at 4:20 PM, Scott Long wrote: > On Oct 26, 2010, at 2:58 PM, David Schultz wrote: >> On Tue, Oct 26, 2010, Kostik Belousov wrote: >>> On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: >>>> Fusefs is the Linux-developed userland filesystem interface which is >>>> fairly popular in the wild, especially with the "sshfs" module which >>>> allows mounting of generic ssh/sftp directories in a very easy way. >>>> >>>> It was developed in one of the very early Google Summer of Code projec= ts >>>> (2005) and is now in a bit unusual situation: >>>> >>>> 1) it *is* popular, as reports about its breakage arrive pretty soon >>>> after it breaks >>>> >>>> 2) it is currently practically unmaintained. The source code archive i= s >>>> from 2008 and the port contains a dozen patches to be applied to it to >>>> make it work on recent systems >>>> >>>> 3) it is also not exactly rock stable, though this has improved with t= he >>>> above patches; personally I'd judge it to be as stable as ZFS was two >>>> years ago so there :) >>>> >>>> I'm proposing to import the kernel module into the official tree (ther= e >>>> are also userland libraries under the GPL; they will stay as ports). >>>> There are no license conflicts for the kernel module. I see two benefi= ts >>>> from it: >>>> >>>> 1) it will finally integrate the patches needed for it to work in one >>>> tree and provide the "one official place" to work on it >>>> >>>> 2) it will be easier to maintain it here, and changes to the VFS APIs >>>> would be applied to it in sweeping commits together with other file sy= stems. >>>> >>>> I'm not knowledgeable enough to actively work on it (yet) but I can >>>> mechanically maintain it and generally take care of it. >>>> >>>> Objections? >>> This is not going to work. The code is unmaintained. Committing it into >>> the src/ just makes the pile of not working code in src/ bigger. >> >> I used it about a year ago to grade student projects for a class. >> I had a bunch of buggy student code interfacing with the kernel >> module via libfuse, and it was quite stable for my purposes. >> The project didn't involve supporting mmap, though. >> >> When I subsequently upgraded my kernel, however, the port broke. >> >> The value of having FUSE in the tree is that it encourages people >> to put forth the modicum of effort required to ensure that it still >> compiles when kernel APIs change. =A0I can't comment on whether it is >> popular enough to support to such a minimal extent, but it is a >> nifty little package: you maintain one kernel module, and you get >> passable support for several dozen filesystems for free. > > What is comes down to is that it needs a committed owner, someone who not= only will shepherd it into the tree, but also work on continuous improveme= nts and handle bug reports. =A0I personally think that it would be a good t= hing to have in the kernel, but I can't afford the commitment. If this module was in the tree, could we drop other less maintained filesystems, like our in-tree ntfs support (/sys/fs/ntfs/)? I know it sounds radical, but it would be nice to have a working filesystem instead of a filesystem that's out-of-date and broken like our in-tree ntfs. Also, what about our hfs / hfs+ support? I haven't checked lately (and I'll confirm when I get home), but it looks like support might be a bit shaky ( https://forums.freebsd.org/showthread.php?t=3D1198 ). I wouldn't mind having good filesystem support for my PowerPC Mac and iPod :). There are some other handy filesystems like sshfs, etc that people have rolled for other purposes that would be interesting to have access to. So I would be game to help maintain things, but I'd need help getting up to speed on FUSE and figure out the lay of the land. I wouldn't be very effective for a while though because I'm not knowledgeable in the ways of the vfs[, yet?].. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 07:57:20 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF78B1065672 for ; Wed, 27 Oct 2010 07:57:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id A03A28FC12 for ; Wed, 27 Oct 2010 07:57:19 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id Pjk41f0011swQuc55jk4m4; Wed, 27 Oct 2010 07:44:04 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.westchester.pa.mail.comcast.net with comcast id Pjk31f0093LrwQ23bjk3kY; Wed, 27 Oct 2010 07:44:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0AC1D9B425; Wed, 27 Oct 2010 00:44:02 -0700 (PDT) Date: Wed, 27 Oct 2010 00:44:02 -0700 From: Jeremy Chadwick To: pjd@freebsd.org Message-ID: <20101027074401.GA18014@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 07:57:20 -0000 The below commit has broken the ability to build system boot blocks (including pxeldr) the "historic way"[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): ======================================== # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. ======================================== Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 08:36:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A005B106564A for ; Wed, 27 Oct 2010 08:36:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D4EFC8FC0C for ; Wed, 27 Oct 2010 08:36:57 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2556D45E82; Wed, 27 Oct 2010 10:09:00 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8840D456B1; Wed, 27 Oct 2010 10:08:52 +0200 (CEST) Date: Wed, 27 Oct 2010 10:08:17 +0200 From: Pawel Jakub Dawidek To: Jeremy Chadwick Message-ID: <20101027080817.GC1848@garage.freebsd.pl> References: <20101027074401.GA18014@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline In-Reply-To: <20101027074401.GA18014@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:36:58 -0000 --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: >=20 > http://freshbsd.org/2010/10/17/20/10/00 >=20 > The breakage on RELENG_8 (dated as of a few minutes ago): >=20 > =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 > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean > [...] > # make > [...] > cc -DBOOTPROG=3D\"gptboot\" -Os -fno-guess-branch-probability -fomit-f= rame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx= -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT= =3D0x3f8 -DSIOFMT=3D0x3 -DSIOSPD=3D9600 -I/usr/src/sys/boot/i386/gptboot= /../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/b= oot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 = -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-decla= rations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Ws= trict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single= =3D100 -ffreestanding -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -= mno-sse -mno-sse2 -mno-sse3 -m32 -march=3Di386 -std=3Dgnu99 -c /usr/src/s= ys/boot/i386/gptboot/../../common/gpt.c > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_AT= TR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undec= lared identifier is reported only once > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each fu= nction it appears in.) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfa= iled': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_AT= TR_BOOTFAILED' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootco= nv': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_AT= TR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_AT= TR_BOOTFAILED' undeclared (first use in this function) > *** Error code 1 >=20 > Stop in /usr/src/sys/boot/i386/gptboot. > *** Error code 1 >=20 > Stop in /usr/src/sys/boot/i386. > *** Error code 1 >=20 > Stop in /usr/src/sys/boot. > =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 >=20 > Please advise. If there is a new/correct method, then I'd like to know > what it is, in addition to the Handbook needing to be updated. >=20 > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > (See Section 26.6.5.2) Well, your problem is that gptboot.c is including gpt.h not from your source tree, but from /usr/include/sys/, which has an old version of this header file. This can be easly fixed by extending CFLAGS in one of the Makefiles (which is already done in HEAD), but I'm afraid this procedure is incorrect (and never was correct). Apart from including wrong files it also links to wrong libraries, etc. The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean && make && make install --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzH3fAACgkQForvXbEpPzTRwACghgKgz6hNhG7JEBj98vZxoSTR xsUAnj5j+suzPxx6bP2kgYKD6KFPbN9X =OtoJ -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 09:30:39 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92FD31065670 for ; Wed, 27 Oct 2010 09:30:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 78F358FC08 for ; Wed, 27 Oct 2010 09:30:39 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta10.emeryville.ca.mail.comcast.net with comcast id PlGq1f0051Y3wxoAAlHUnb; Wed, 27 Oct 2010 09:17:28 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id PlHT1f0023LrwQ28blHTWd; Wed, 27 Oct 2010 09:17:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 673829B425; Wed, 27 Oct 2010 02:17:27 -0700 (PDT) Date: Wed, 27 Oct 2010 02:17:27 -0700 From: Jeremy Chadwick To: Pawel Jakub Dawidek Message-ID: <20101027091727.GA44893@icarus.home.lan> References: <20101027074401.GA18014@icarus.home.lan> <20101027080817.GC1848@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027080817.GC1848@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 09:30:39 -0000 On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > ======================================== > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > [...] > > # make > > [...] > > cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386/gptboot. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot. > > ======================================== > > > > Please advise. If there is a new/correct method, then I'd like to know > > what it is, in addition to the Handbook needing to be updated. > > > > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > > (See Section 26.6.5.2) > > Well, your problem is that gptboot.c is including gpt.h not from your > source tree, but from /usr/include/sys/, which has an old version of > this header file. This can be easly fixed by extending CFLAGS in one of > the Makefiles (which is already done in HEAD), but I'm afraid this > procedure is incorrect (and never was correct). Apart from including > wrong files it also links to wrong libraries, etc. > > The proper way is to: > > # cd /usr/src > # make buildenv > # cd sys/boot > # make clean && make && make install Thanks for the tip -- the CFLAGS change in a Makefile sounds like the solution, since the latter (re: "proper way") didn't work (exact same problem). The Makefile adjustment you mention for HEAD is here: http://freshbsd.org/2010/10/08/10/27/52 But there's no mention of an MFC date in the commit message. Can this be MFC'd? For now, "make buildworld" works as a workaround (pull the bootstrap binaries needed out of /usr/obj). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 10:05:51 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9251065673 for ; Wed, 27 Oct 2010 10:05:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A33B68FC08 for ; Wed, 27 Oct 2010 10:05:50 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19108; Wed, 27 Oct 2010 12:47:12 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CC7F520.10300@icyb.net.ua> Date: Wed, 27 Oct 2010 12:47:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <20101027074401.GA18014@icarus.home.lan> <20101027080817.GC1848@garage.freebsd.pl> <20101027091727.GA44893@icarus.home.lan> In-Reply-To: <20101027091727.GA44893@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:05:51 -0000 on 27/10/2010 12:17 Jeremy Chadwick said the following: > On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: >> The proper way is to: >> >> # cd /usr/src >> # make buildenv >> # cd sys/boot >> # make clean && make && make install > > Thanks for the tip -- the CFLAGS change in a Makefile sounds like the > solution, since the latter (re: "proper way") didn't work (exact same > problem). The above will work if you already have the toolchain built - that's the only way to ensure that you don't depend on anything in the currently installed world. See build(7). -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 11:15:19 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6F81065670; Wed, 27 Oct 2010 11:15:19 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87D6C8FC16; Wed, 27 Oct 2010 11:15:18 +0000 (UTC) Received: by qwe4 with SMTP id 4so555071qwe.13 for ; Wed, 27 Oct 2010 04:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=UxhLm9W/DNzzcazb+qrzmKuLlJw+W8swbWdeuKSVCCs=; b=xyzQ0RKafaLU15uVT8BwHKxaTmQ6HJKOl2yNRWVL1S9BvvIH8RYOLqU3+8WyR21Fbz HTqb+gjUNtvdlkheaQDVuLHWw4G3+ojPEmhzT9v9Ns3NVUop18/uNCcGoUcRBy9mffIL ONQW3mJnmtegZ/1TsgJFYydKqig/ErnGsMGt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Bb0u31W1VeSxouOxFjMEJyY0fJ1+v4mAPv3exa0L+bg3QLB6Su3Sz+kCIMRcRrMArF VizZez/80Bp+h/GoOVJ5SnpK+CyF35F7q3o+pNRiiEND9ctFy8XLB4efvJoAkszB0xH4 557YgCJ7bJs9/0Fkwu26idLPw+VMCuROQVkR0= Received: by 10.229.99.84 with SMTP id t20mr4423094qcn.120.1288178117483; Wed, 27 Oct 2010 04:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Wed, 27 Oct 2010 04:14:36 -0700 (PDT) In-Reply-To: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> From: Ivan Voras Date: Wed, 27 Oct 2010 13:14:36 +0200 X-Google-Sender-Auth: OhnGK4qd6c_QPxoOFaR6Gw0WCzg Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Scott Long , David Schultz , freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:15:19 -0000 On 27 October 2010 02:22, Garrett Cooper wrote: > =C2=A0 =C2=A0If this module was in the tree, could we drop other less > maintained filesystems, like our in-tree ntfs support (/sys/fs/ntfs/)? I'd vote for "yes". > =C2=A0 =C2=A0So I would be game to help maintain things, but I'd need hel= p > getting up to speed on FUSE and figure out the lay of the land. I > wouldn't be very effective for a while though because I'm not > knowledgeable in the ways of the vfs[, yet?].. It's about the same story with me - given that I'm always playing with storage, I'll get to VFS eventually. Could 2 half-maintainers instead of one full maintainer be enough to satisfy the doubters? :) How about 3? (I know someone who's also interested in a junior-hacker kind of way) From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 13:28:02 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8473F1065758; Wed, 27 Oct 2010 13:28:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 52F7A8FC1B; Wed, 27 Oct 2010 13:28:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EE48D46B09; Wed, 27 Oct 2010 09:28:01 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D2B418A027; Wed, 27 Oct 2010 09:28:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 27 Oct 2010 09:27:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101027074401.GA18014@icarus.home.lan> In-Reply-To: <20101027074401.GA18014@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010270927.04145.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 09:28:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: pjd@freebsd.org, Jeremy Chadwick , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:28:02 -0000 On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: > > http://freshbsd.org/2010/10/17/20/10/00 > > The breakage on RELENG_8 (dated as of a few minutes ago): > > ======================================== > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. The handbook section is meant as more of a tutorial on how to enable a serial console on a fresh box. Once you are experienced enough to start using buildworld, etc. I don't think it is unreasonable to require users to understand that having a source tree different from the installed world requires extra steps. If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 13:49:01 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86D6F1065695 for ; Wed, 27 Oct 2010 13:49:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 324068FC25 for ; Wed, 27 Oct 2010 13:49:00 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Pmdg1f0041c6gX85Bpp1UY; Wed, 27 Oct 2010 13:49:01 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta23.westchester.pa.mail.comcast.net with comcast id Ppoz1f00G3LrwQ23jpp0rQ; Wed, 27 Oct 2010 13:49:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 62AD79B425; Wed, 27 Oct 2010 06:48:58 -0700 (PDT) Date: Wed, 27 Oct 2010 06:48:58 -0700 From: Jeremy Chadwick To: John Baldwin Message-ID: <20101027134858.GA14454@icarus.home.lan> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010270927.04145.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:49:01 -0000 On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > ======================================== > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > This only works if your source tree is in sync with your installed world. > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested > will work for the case that your source tree does not match your installed > world. But this doesn't appear to be the case here: $ uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ sudo -i icarus# rm -fr /usr/obj/* rm: No match. icarus# cd /usr/src icarus# make buildenv Entering world for amd64:amd64 # make clean && make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. # ls -l /usr/src/sys/boot/i386/gptboot/../../common/gpt.c -rw-r--r-- 1 root wheel 10927 Oct 17 13:10 /usr/src/sys/boot/i386/gptboot/../../common/gpt.c Any ideas? > Maybe you could add text to the handbook to say this, but it is already > implicitly assumed in the handbook section you are referring to since it > assumes you can safely compile a new kernel, etc. The handbook section is > meant as more of a tutorial on how to enable a serial console on a fresh box. > Once you are experienced enough to start using buildworld, etc. I don't think > it is unreasonable to require users to understand that having a source tree > different from the installed world requires extra steps. I don't think it's unreasonable either, it's just not well-documented or well-established. For example, this is the first time I've heard of "buildenv", not to mention the other pieces mentioned in build(7). That doesn't mean FreeBSD is at fault, it just means there's been changes to things which are hard to keep up to date on. > If we were to document those every time it would clutter documentation > making it harder for someone who is new to FreeBSD to simply setup a > serial console on a box that they just installed. Understood. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 13:58:37 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6132C106566B; Wed, 27 Oct 2010 13:58:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 081128FC20; Wed, 27 Oct 2010 13:58:34 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D10EB45C98; Wed, 27 Oct 2010 15:58:32 +0200 (CEST) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0947C45683; Wed, 27 Oct 2010 15:58:27 +0200 (CEST) Date: Wed, 27 Oct 2010 15:57:53 +0200 From: Pawel Jakub Dawidek To: Jeremy Chadwick Message-ID: <20101027135753.GB2038@garage.freebsd.pl> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> <20101027134858.GA14454@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20101027134858.GA14454@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:58:37 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 06:48:58AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > > The below commit has broken the ability to build system boot blocks > > > (including pxeldr) the "historic way"[1]: > > >=20 > > > http://freshbsd.org/2010/10/17/20/10/00 > > >=20 > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > >=20 > > > =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 > > > # rm -fr /usr/obj/* > > > # cd /sys/boot > > > # make clean > >=20 > > This only works if your source tree is in sync with your installed worl= d. =20 > > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ sug= gested=20 > > will work for the case that your source tree does not match your instal= led=20 > > world. >=20 > But this doesn't appear to be the case here: [...] Because you don't have toolchain built. Once you buildworld you can do that. All in all, the safest and most recommended way is to just use buildworld/buildkernel. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzIL+EACgkQForvXbEpPzTX3wCdHbpr7NRw1naIUBrVhbnUVvYh okwAoKYdSg5Cew8OGUfQgMMI37H94R/6 =P3Qy -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 15:26:33 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41EB4106566C for ; Wed, 27 Oct 2010 15:26:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 013238FC18 for ; Wed, 27 Oct 2010 15:26:32 +0000 (UTC) Received: by qwe4 with SMTP id 4so808476qwe.13 for ; Wed, 27 Oct 2010 08:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=gLTBEuG1PUh0/O7N6CCXGG4MvL0MVyh4oYNPadcSVkQ=; b=iSNu3OnsIfCy8+K3iEg1IAOtmnwlDgcrAbDttDKJqwd3tjTB9TjLJYusJYK6hplspa /tXn5XaP3jHk2n4EHza718cFMMzYAi0sTjIZ8cfHAfC5urSJMz2Kln5WHX+g8rpNkKp+ btKr3+aKMP/WAtK9etzoC9Fo6DijR3uOZwNx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=XkQhgNL61xi70wkBZdzraGqbANdFjCp8SeqJBI3j7jy6eFbEnMIC62mxNSdSIoNs0/ +lTKNTr/0MkcooPDm19oSxZHmYCr/i4IcYwL1bxe1uPU+Bnwru2R0mYBtw00DT5dkcgV V06uMRYEZfMKQEW3bkTds+EVhvPQAGkiW5IRs= MIME-Version: 1.0 Received: by 10.224.196.2 with SMTP id ee2mr2705195qab.268.1288191366956; Wed, 27 Oct 2010 07:56:06 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Wed, 27 Oct 2010 07:56:06 -0700 (PDT) Date: Wed, 27 Oct 2010 16:56:06 +0200 X-Google-Sender-Auth: QqaxHvFsnRntHZ_AslZqrsFji0U Message-ID: From: Attilio Rao To: FreeBSD Arch Content-Type: text/plain; charset=UTF-8 Cc: Subject: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 15:26:33 -0000 This patch should convert a (simple and 100% shared between amd64 and i386 header) under the x86 sub-tree. Please note that in this patch I "svn cp" the file from sys/amd64/include/mptable.h into sys/x86/include/mptable.h: http://www.freebsd.org/~attilio/headers-x86.diff This is someway a POC, that I really want to get in. The idea is simple and someway follows the pc98 case (even if not entirely): the files under machine/include/* became just mere stubs for x86/include/* contents and redirect there. This won't particulary help reducing the number of available files, but generally removing verbatim and would also be the way to go for handling MFCs. If you find this is the right way I'll commit the fix and start moving other files as time permits. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 17:55:47 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC86A106564A; Wed, 27 Oct 2010 17:55:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8FC8FC12; Wed, 27 Oct 2010 17:55:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3991646B0C; Wed, 27 Oct 2010 13:55:47 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F8A68A01D; Wed, 27 Oct 2010 13:55:46 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 27 Oct 2010 13:55:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010271355.40685.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 13:55:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Attilio Rao Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:55:47 -0000 On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: > This patch should convert a (simple and 100% shared between amd64 and > i386 header) under the x86 sub-tree. Please note that in this patch I > "svn cp" the file from sys/amd64/include/mptable.h into > sys/x86/include/mptable.h: > http://www.freebsd.org/~attilio/headers-x86.diff > > This is someway a POC, that I really want to get in. The idea is > simple and someway follows the pc98 case (even if not entirely): the > files under machine/include/* became just mere stubs for x86/include/* > contents and redirect there. > This won't particulary help reducing the number of available files, > but generally removing verbatim and would also be the way to go for > handling MFCs. > If you find this is the right way I'll commit the fix and start moving > other files as time permits. No, we want to do this differently because we also want this to work in userland. (e.g. I'd like to outright move mca.h to x86/include and then use '#include ' in both kernel and userland for it). We'd need some special glue to setup an 'x86' symlink during a kernel build that points to @/x86/include as we do now to setup an 'i386' link for pc98 kernels. We'd also need to install the x86 headers into /usr/include during an installworld. Warner has some more pointers on this I think. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 18:42:25 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14633106564A; Wed, 27 Oct 2010 18:42:25 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C68388FC15; Wed, 27 Oct 2010 18:42:24 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 474091FFC5B; Wed, 27 Oct 2010 18:25:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2060084507; Wed, 27 Oct 2010 20:25:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jeremy Chadwick References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> <20101027134858.GA14454@icarus.home.lan> Date: Wed, 27 Oct 2010 20:25:21 +0200 In-Reply-To: <20101027134858.GA14454@icarus.home.lan> (Jeremy Chadwick's message of "Wed, 27 Oct 2010 06:48:58 -0700") Message-ID: <86tyk7xzla.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:42:25 -0000 Jeremy Chadwick writes: > $ uname -a > FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:1= 0:54 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_= amd64 amd64 > $ sudo -i > icarus# rm -fr /usr/obj/* > rm: No match. > icarus# cd /usr/src icarus# make toolchain > icarus# make buildenv > Entering world for amd64:amd64 > # make clean && make > [...] FTFY. HTH, HAND! DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 20:25:15 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AAF0106566C for ; Wed, 27 Oct 2010 20:25:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2408FC1E for ; Wed, 27 Oct 2010 20:25:14 +0000 (UTC) Received: by qyk7 with SMTP id 7so4023552qyk.13 for ; Wed, 27 Oct 2010 13:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tQeuEXcbkuC74V+L8CEFXZqyzoI5SM280J7Srn7Vl70=; b=t4TcCLp/MeSBWTcwD9n7esVzsAOzXlOryq5bbfw6hrQEW4g3W3t0z2ceQ22PgIknsM CKMdPVetAIyMRQIRuutdB0l00nUvJMpxGzZimiDNq0XfQzLy83BcY0MeR72pOgAw8HpB yU86ky89B0YEkcZpnhG7Ad36P601Nf28HCBcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GgiYSAumIuEz+OeBJSwThRGMm/u3KSpManZjCvE2yguQ5QG815SmTMKw/4PYt96PRO DxZK5p+FLV35xMNEXNcdblf8EopytPLorJS2MAbVVZVs+44AvdBbTKLogXeSLah7bZfI CvzbDNTQD1PF9aqgMe6VGNqI4Ziu7ZIeQkg6Y= MIME-Version: 1.0 Received: by 10.229.184.68 with SMTP id cj4mr9379682qcb.48.1288209615860; Wed, 27 Oct 2010 13:00:15 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Wed, 27 Oct 2010 13:00:15 -0700 (PDT) In-Reply-To: <201010271355.40685.jhb@freebsd.org> References: <201010271355.40685.jhb@freebsd.org> Date: Wed, 27 Oct 2010 22:00:15 +0200 X-Google-Sender-Auth: DApXj-Q2aBqh3N8iz9u2IeCBz_4 Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:25:15 -0000 2010/10/27 John Baldwin : > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >> This patch should convert a (simple and 100% shared between amd64 and >> i386 header) under the x86 sub-tree. Please note that in this patch I >> "svn cp" the file from sys/amd64/include/mptable.h into >> sys/x86/include/mptable.h: >> http://www.freebsd.org/~attilio/headers-x86.diff >> >> This is someway a POC, that I really want to get in. The idea is >> simple and someway follows the pc98 case (even if not entirely): the >> files under machine/include/* became just mere stubs for x86/include/* >> contents and redirect there. >> This won't particulary help reducing the number of available files, >> but generally removing verbatim and would also be the way to go for >> handling MFCs. >> If you find this is the right way I'll commit the fix and start moving >> other files as time permits. > > No, we want to do this differently because we also want this to work in > userland. =C2=A0(e.g. I'd like to outright move mca.h to x86/include and = then use > '#include ' in both kernel and userland for it). =C2=A0We'd ne= ed some > special glue to setup an 'x86' symlink during a kernel build that points = to > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. > > We'd also need to install the x86 headers into /usr/include during an > installworld. =C2=A0Warner has some more pointers on this I think. So you probabilly are suggesting to go w/ the "pc98 approach". I'm fine with it, I'll try to look for how it works and implement as well. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 20:56:38 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12C6C1065679; Wed, 27 Oct 2010 20:56:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D4AB28FC15; Wed, 27 Oct 2010 20:56:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 657F446B09; Wed, 27 Oct 2010 16:56:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7094E8A009; Wed, 27 Oct 2010 16:56:36 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Wed, 27 Oct 2010 16:49:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010271649.47880.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 16:56:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:56:38 -0000 On Wednesday, October 27, 2010 4:00:15 pm Attilio Rao wrote: > 2010/10/27 John Baldwin : > > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: > >> This patch should convert a (simple and 100% shared between amd64 and > >> i386 header) under the x86 sub-tree. Please note that in this patch I > >> "svn cp" the file from sys/amd64/include/mptable.h into > >> sys/x86/include/mptable.h: > >> http://www.freebsd.org/~attilio/headers-x86.diff > >> > >> This is someway a POC, that I really want to get in. The idea is > >> simple and someway follows the pc98 case (even if not entirely): the > >> files under machine/include/* became just mere stubs for x86/include/* > >> contents and redirect there. > >> This won't particulary help reducing the number of available files, > >> but generally removing verbatim and would also be the way to go for > >> handling MFCs. > >> If you find this is the right way I'll commit the fix and start moving > >> other files as time permits. > > > > No, we want to do this differently because we also want this to work in > > userland. (e.g. I'd like to outright move mca.h to x86/include and then use > > '#include ' in both kernel and userland for it). We'd need some > > special glue to setup an 'x86' symlink during a kernel build that points to > > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. > > > > We'd also need to install the x86 headers into /usr/include during an > > installworld. Warner has some more pointers on this I think. > > So you probabilly are suggesting to go w/ the "pc98 approach". > I'm fine with it, I'll try to look for how it works and implement as well. Thanks. I think it is fine to use '#include ' in code directly with this approach as well. I only think we should provide wrappers in /usr/include/machine if compatibility is needed. mca.h and mptable.h shouldn't need compatibility for example, but specialreg.h might. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 21:25:22 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 146D6106566B; Wed, 27 Oct 2010 21:25:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id A77A98FC18; Wed, 27 Oct 2010 21:25:21 +0000 (UTC) Received: by qyk2 with SMTP id 2so87244qyk.13 for ; Wed, 27 Oct 2010 14:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qs6IucI1SR1E1SRR4IuhurFvsXyOVQYwHNMcJh/MWoU=; b=SwL4/j34ay+WKW9VQxNS1tHAoh6PtnaxwSBB2ndV3kWcBwGL4beHi4nsBLNcuHroUK puq1ZsjGSgLb4OLiqZVZGmJOw/xdfFTRDA+R/jdnOimu2DkH2bNqLl5JSnqoUQ+NNMs5 y4/sYJiz0qlQu3i4cKSZQcVpA/JyR/4JJXB7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gqDv0JU3yNCjwluWaSM6fVXkgsA6X4LzebLNHLuyhc6GkL7vMT/+s0y6tTjcW4S8ld pWtK3WpHcBSrWdo/VqH69xaWmfBwgCqa5Mck25S5y+RaFsCKl2Yz7HftGcr3l4ggB5xR qIL5mNyKmFb0fhYBn5YsJ2AQOJmW//Nx+2wcc= MIME-Version: 1.0 Received: by 10.229.212.5 with SMTP id gq5mr1620607qcb.275.1288214720808; Wed, 27 Oct 2010 14:25:20 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Wed, 27 Oct 2010 14:25:20 -0700 (PDT) In-Reply-To: <201010271649.47880.jhb@freebsd.org> References: <201010271355.40685.jhb@freebsd.org> <201010271649.47880.jhb@freebsd.org> Date: Wed, 27 Oct 2010 23:25:20 +0200 X-Google-Sender-Auth: 0HE71wz6rJQqxiuaAA2C7DybL-Y Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:25:22 -0000 2010/10/27 John Baldwin : > On Wednesday, October 27, 2010 4:00:15 pm Attilio Rao wrote: >> 2010/10/27 John Baldwin : >> > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >> >> This patch should convert a (simple and 100% shared between amd64 and >> >> i386 header) under the x86 sub-tree. Please note that in this patch I >> >> "svn cp" the file from sys/amd64/include/mptable.h into >> >> sys/x86/include/mptable.h: >> >> http://www.freebsd.org/~attilio/headers-x86.diff >> >> >> >> This is someway a POC, that I really want to get in. The idea is >> >> simple and someway follows the pc98 case (even if not entirely): the >> >> files under machine/include/* became just mere stubs for x86/include/= * >> >> contents and redirect there. >> >> This won't particulary help reducing the number of available files, >> >> but generally removing verbatim and would also be the way to go for >> >> handling MFCs. >> >> If you find this is the right way I'll commit the fix and start movin= g >> >> other files as time permits. >> > >> > No, we want to do this differently because we also want this to work i= n >> > userland. =C2=A0(e.g. I'd like to outright move mca.h to x86/include a= nd then use >> > '#include ' in both kernel and userland for it). =C2=A0We'd= need some >> > special glue to setup an 'x86' symlink during a kernel build that poin= ts to >> > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. >> > >> > We'd also need to install the x86 headers into /usr/include during an >> > installworld. =C2=A0Warner has some more pointers on this I think. >> >> So you probabilly are suggesting to go w/ the "pc98 approach". >> I'm fine with it, I'll try to look for how it works and implement as wel= l. > > Thanks. =C2=A0I think it is fine to use '#include ' in code di= rectly > with this approach as well. =C2=A0I only think we should provide wrappers= in > /usr/include/machine if compatibility is needed. =C2=A0mca.h and mptable.= h > shouldn't need compatibility for example, but specialreg.h might. I'd expect to potentially mirror any header, otherwise on which criterias we can say some are needed and other not? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 21:49:59 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 121E1106566C; Wed, 27 Oct 2010 21:49:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C40558FC0A; Wed, 27 Oct 2010 21:49:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D25546B51; Wed, 27 Oct 2010 17:49:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 450228A01D; Wed, 27 Oct 2010 17:49:57 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Wed, 27 Oct 2010 17:49:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271649.47880.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <201010271749.54619.jhb@freebsd.org> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 17:49:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:49:59 -0000 On Wednesday, October 27, 2010 5:25:20 pm Attilio Rao wrote: > 2010/10/27 John Baldwin : > > On Wednesday, October 27, 2010 4:00:15 pm Attilio Rao wrote: > >> 2010/10/27 John Baldwin : > >> > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: > >> >> This patch should convert a (simple and 100% shared between amd64 and > >> >> i386 header) under the x86 sub-tree. Please note that in this patch I > >> >> "svn cp" the file from sys/amd64/include/mptable.h into > >> >> sys/x86/include/mptable.h: > >> >> http://www.freebsd.org/~attilio/headers-x86.diff > >> >> > >> >> This is someway a POC, that I really want to get in. The idea is > >> >> simple and someway follows the pc98 case (even if not entirely): the > >> >> files under machine/include/* became just mere stubs for x86/include/* > >> >> contents and redirect there. > >> >> This won't particulary help reducing the number of available files, > >> >> but generally removing verbatim and would also be the way to go for > >> >> handling MFCs. > >> >> If you find this is the right way I'll commit the fix and start moving > >> >> other files as time permits. > >> > > >> > No, we want to do this differently because we also want this to work in > >> > userland. (e.g. I'd like to outright move mca.h to x86/include and then use > >> > '#include ' in both kernel and userland for it). We'd need some > >> > special glue to setup an 'x86' symlink during a kernel build that points to > >> > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. > >> > > >> > We'd also need to install the x86 headers into /usr/include during an > >> > installworld. Warner has some more pointers on this I think. > >> > >> So you probabilly are suggesting to go w/ the "pc98 approach". > >> I'm fine with it, I'll try to look for how it works and implement as well. > > > > Thanks. I think it is fine to use '#include ' in code directly > > with this approach as well. I only think we should provide wrappers in > > /usr/include/machine if compatibility is needed. mca.h and mptable.h > > shouldn't need compatibility for example, but specialreg.h might. > > I'd expect to potentially mirror any header, otherwise on which > criterias we can say some are needed and other not? If it is widely used in userland. :) mptable.h is probably only used by the mptable utility which is easily fixed. It will not be of interest to any 3rd party software. mca.h may eventually be used by third party software, but it is very new, so we can probably move it now without causing any harm. Kernel-only headers such as intr_machdep.h certainly do not need any compat wrappers. We can always add a compat header in machine if we find it is needed, but I'd like to minimize the amount of compat cruft as much as possible. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 21:55:25 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405DE106566C; Wed, 27 Oct 2010 21:55:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CFFD78FC22; Wed, 27 Oct 2010 21:55:24 +0000 (UTC) Received: by qwe4 with SMTP id 4so1164620qwe.13 for ; Wed, 27 Oct 2010 14:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vsYFnY+RGp8AMT+myvTlYAolQxdOQ8NGdyE4dsco1l0=; b=dnREf9TtYBH7YewqLZU7edbQSuAWSTOvYlafP5EICj+QNt5gpbjg/3vxGUhf2JKUqf zZBI9bM9Z2LZE1P6z8XWZ299vay7o0I6I/XK+mf0LiU35B0txTDanMp4CcGn/NXfRuZ4 S9GnQGHEQloPtse1RysDDmBe8+4c6Ij2RxpoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HGRDDlLRmsQCAzvVC5t7k/7XdjAmiVg9iNdtRaU/BPCC9jKxCNgVPH7EM+egVy/p3d 8J43/VXssRasqPBAefFCS+c8+xFBX/4aJMVmN6EOsM35/QXjsb9xiRhUpg4/7pEYkSG8 E3kvUkq2JLsFcWR9cyrlEPyLRaekk4WbdYruo= MIME-Version: 1.0 Received: by 10.229.232.133 with SMTP id ju5mr5705647qcb.213.1288216523529; Wed, 27 Oct 2010 14:55:23 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Wed, 27 Oct 2010 14:55:23 -0700 (PDT) In-Reply-To: <201010271749.54619.jhb@freebsd.org> References: <201010271649.47880.jhb@freebsd.org> <201010271749.54619.jhb@freebsd.org> Date: Wed, 27 Oct 2010 23:55:23 +0200 X-Google-Sender-Auth: 10VQhsR6BG20W6E3XOo4FrlR-oc Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:55:25 -0000 2010/10/27 John Baldwin : > On Wednesday, October 27, 2010 5:25:20 pm Attilio Rao wrote: >> 2010/10/27 John Baldwin : >> > On Wednesday, October 27, 2010 4:00:15 pm Attilio Rao wrote: >> >> 2010/10/27 John Baldwin : >> >> > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >> >> >> This patch should convert a (simple and 100% shared between amd64 = and >> >> >> i386 header) under the x86 sub-tree. Please note that in this patc= h I >> >> >> "svn cp" the file from sys/amd64/include/mptable.h into >> >> >> sys/x86/include/mptable.h: >> >> >> http://www.freebsd.org/~attilio/headers-x86.diff >> >> >> >> >> >> This is someway a POC, that I really want to get in. The idea is >> >> >> simple and someway follows the pc98 case (even if not entirely): t= he >> >> >> files under machine/include/* became just mere stubs for x86/inclu= de/* >> >> >> contents and redirect there. >> >> >> This won't particulary help reducing the number of available files= , >> >> >> but generally removing verbatim and would also be the way to go fo= r >> >> >> handling MFCs. >> >> >> If you find this is the right way I'll commit the fix and start mo= ving >> >> >> other files as time permits. >> >> > >> >> > No, we want to do this differently because we also want this to wor= k in >> >> > userland. =C2=A0(e.g. I'd like to outright move mca.h to x86/includ= e and then use >> >> > '#include ' in both kernel and userland for it). =C2=A0W= e'd need some >> >> > special glue to setup an 'x86' symlink during a kernel build that p= oints to >> >> > @/x86/include as we do now to setup an 'i386' link for pc98 kernels= . >> >> > >> >> > We'd also need to install the x86 headers into /usr/include during = an >> >> > installworld. =C2=A0Warner has some more pointers on this I think. >> >> >> >> So you probabilly are suggesting to go w/ the "pc98 approach". >> >> I'm fine with it, I'll try to look for how it works and implement as = well. >> > >> > Thanks. =C2=A0I think it is fine to use '#include ' in code= directly >> > with this approach as well. =C2=A0I only think we should provide wrapp= ers in >> > /usr/include/machine if compatibility is needed. =C2=A0mca.h and mptab= le.h >> > shouldn't need compatibility for example, but specialreg.h might. >> >> I'd expect to potentially mirror any header, otherwise on which >> criterias we can say some are needed and other not? > > If it is widely used in userland. :) =C2=A0mptable.h is probably only use= d by the > mptable utility which is easily fixed. =C2=A0It will not be of interest t= o any 3rd > party software. =C2=A0mca.h may eventually be used by third party softwar= e, but it > is very new, so we can probably move it now without causing any harm. > > Kernel-only headers such as intr_machdep.h certainly do not need any comp= at > wrappers. > > We can always add a compat header in machine if we find it is needed, but= I'd > like to minimize the amount of compat cruft as much as possible. I'd say in general I agree, so let's add them just on-demand is possibly fi= ne. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 01:56:56 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9448B106566C; Thu, 28 Oct 2010 01:56:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC1B8FC08; Thu, 28 Oct 2010 01:56:56 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0163346B5B; Wed, 27 Oct 2010 21:56:56 -0400 (EDT) Date: Thu, 28 Oct 2010 02:56:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: Message-ID: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , David Schultz , Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 01:56:56 -0000 On Tue, 26 Oct 2010, Scott Long wrote: >> The value of having FUSE in the tree is that it encourages people to put >> forth the modicum of effort required to ensure that it still compiles when >> kernel APIs change. I can't comment on whether it is popular enough to >> support to such a minimal extent, but it is a nifty little package: you >> maintain one kernel module, and you get passable support for several dozen >> filesystems for free. > > What is comes down to is that it needs a committed owner, someone who not > only will shepherd it into the tree, but also work on continuous > improvements and handle bug reports. I personally think that it would be a > good thing to have in the kernel, but I can't afford the commitment. Agreed entirely: FreeBSD definitely needs fuse -- but it needs a fuse that works well, not one that corrupts data and panics in casual use. Once there's an active maintainer who understands the code and can fix the issues, I think importing it is the best thing to do -- while certain classes of kernel modules might live comfortable in ports, file system modules are not among them. But it needs an owner first. Ivan: sounds like perhaps a call for volunteers on current@ / fs@ might be the best way forward? Robert From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 07:44:23 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD470106566B; Thu, 28 Oct 2010 07:44:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 33B938FC15; Thu, 28 Oct 2010 07:44:22 +0000 (UTC) Received: by qyk7 with SMTP id 7so4563229qyk.13 for ; Thu, 28 Oct 2010 00:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ROkFIqfTEI+Kcl1h5KUam3oRDQyT0tSYNC3h5tQBOjQ=; b=sQ8CFuD+fLo5KAPNU4MuQ6KlQt2IFOAiSPJny3fDvumhSjQy9Q/lzDUpXajOM50Zd9 GXh7HnKFptDxwX2GMONsC6Emw2wAuO6Om/9OD6t34kvzb258hZ/HGuXl2ZgoMkDaKA3H +v2nP4yMUj8zkRii/Zs1l0V+8Mee+RkRUi1mI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FQ3l6Vs2YVeodzWCv+dmDgjR8hHdPSwWccI2rhdFStxSW+j8a/tnADQdYCYT5Jz0ai td+kGFP2HgwoEPnKovp7rWIGJZbe9anDUvxBQ6apIZB1BS0NWj9Ct6Dn98VkWeF/G7re ixkZEzCAzJc73ciHQua5z9PDRw0JbOFGCslDQ= MIME-Version: 1.0 Received: by 10.229.222.19 with SMTP id ie19mr8096703qcb.198.1288251861490; Thu, 28 Oct 2010 00:44:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Thu, 28 Oct 2010 00:44:21 -0700 (PDT) In-Reply-To: <201010271355.40685.jhb@freebsd.org> References: <201010271355.40685.jhb@freebsd.org> Date: Thu, 28 Oct 2010 09:44:21 +0200 X-Google-Sender-Auth: 1-6Zww2HuhaQhcG7TvK_w9NwKhA Message-ID: From: Attilio Rao To: John Baldwin , Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:44:23 -0000 2010/10/27 John Baldwin : > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >> This patch should convert a (simple and 100% shared between amd64 and >> i386 header) under the x86 sub-tree. Please note that in this patch I >> "svn cp" the file from sys/amd64/include/mptable.h into >> sys/x86/include/mptable.h: >> http://www.freebsd.org/~attilio/headers-x86.diff >> >> This is someway a POC, that I really want to get in. The idea is >> simple and someway follows the pc98 case (even if not entirely): the >> files under machine/include/* became just mere stubs for x86/include/* >> contents and redirect there. >> This won't particulary help reducing the number of available files, >> but generally removing verbatim and would also be the way to go for >> handling MFCs. >> If you find this is the right way I'll commit the fix and start moving >> other files as time permits. > > No, we want to do this differently because we also want this to work in > userland. =C2=A0(e.g. I'd like to outright move mca.h to x86/include and = then use > '#include ' in both kernel and userland for it). =C2=A0We'd ne= ed some > special glue to setup an 'x86' symlink during a kernel build that points = to > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. > > We'd also need to install the x86 headers into /usr/include during an > installworld. =C2=A0Warner has some more pointers on this I think. I spoke with Warner briefly about it. One question I'm having now, though, is how getting co-living of pc98 and x86 now, as we are basically overriding the same infrastructure (MACHINE_CPUARCH) in the i386/amd64 case? Do you have ideas about that? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 09:29:06 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E2106564A; Thu, 28 Oct 2010 09:29:06 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 023D98FC14; Thu, 28 Oct 2010 09:29:04 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id o9S7wKhv011021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Oct 2010 09:58:20 +0200 Received: from [147.83.40.242] ([147.83.40.242]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o9S7wJZd030905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 09:58:19 +0200 Message-ID: <4CC92D1B.5010701@entel.upc.edu> Date: Thu, 28 Oct 2010 09:58:19 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Thunderbird/3.1.5 MIME-Version: 1.0 To: Garrett Cooper References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Thu, 28 Oct 2010 09:58:20 +0200 (CEST) Cc: Kostik Belousov , Scott Long , freebsd-arch@freebsd.org, David Schultz , Ivan Voras Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 09:29:06 -0000 > So I would be game to help maintain things, but I'd need help > getting up to speed on FUSE and figure out the lay of the land. I > wouldn't be very effective for a while though because I'm not > knowledgeable in the ways of the vfs[, yet?].. > Thanks, > -Garrett It would be great to also have support for something like gvfs-fuse-daemon. It has been long since it was added to gnome, but our fuse implementation just can not handle it. When been used, sshfs and other fusefs get blocked until the calling app that triggers the use of gvfs-fuse-daemon gets an I/O error from the kernel. PC-BSD (and desktop-oriented bsd's) could also benefit of this, it allows working with files everywhere with any app. I've seen kubuntu (kde based distro) uses gvfs-fuse-daemon to handle remote files, so you (or dolphin instead) don't have to copy the remote files locally to open them. Moreover, I had many troubles with ntfs-3g (when copying lots of files from/to ntfs, it stalls and then fails). fuse-ipod simply doesn't work. Not to mention I once tried to port ifuse and friends (to work with new ipods/iphones), I gave up. In the server side, things like glusterfs and others would be very useful. At least it would be very useful for me. The point is, do we stick with fuse or do we switch to puffs ? What is harder, reorganize the code we already have (which seems that has many problems) or we use something new ? And whe the choice is made, do we keep the code as a port or do we import it into the kernel tree ? I don't have enough knowledge to maintain, but I could help a bit testing (and so I can also learn internals and the start helping). I may be mistaken, but that's how I see it from the shore. Just my humble opinion ... Regards, Gus From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 10:09:09 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 642A31065672; Thu, 28 Oct 2010 10:09:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4445C8FC16; Thu, 28 Oct 2010 10:09:09 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 7477E56027; Thu, 28 Oct 2010 09:50:21 +0000 (UTC) Date: Thu, 28 Oct 2010 09:50:21 +0000 From: Mark Linimon To: John Baldwin Message-ID: <20101028095021.GB393@lonesome.com> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010270927.04145.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:09:09 -0000 On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > Maybe you could add text to the handbook to say this, but it is already > implicitly assumed in the handbook section you are referring to since it > assumes you can safely compile a new kernel, etc. [...] If we were to > document those every time it would clutter documentation making it harder for > someone who is new to FreeBSD to simply setup a serial console on a box that > they just installed. It sounds like what we need is a tutorial, and (somewhere else?) the extended version. People seem to trip over things like this fairly often; at least this way we could refer them to a standard text. No, I don't have the backgroud, or cycles, to write it :-) mcl From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 10:20:34 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDDB0106564A; Thu, 28 Oct 2010 10:20:34 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 550038FC15; Thu, 28 Oct 2010 10:20:33 +0000 (UTC) Received: by qwe4 with SMTP id 4so1756351qwe.13 for ; Thu, 28 Oct 2010 03:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=XMETfdUsW1CEnyTEcddZwYpd8+1Awg8eRLfAXjq1h0A=; b=KVZhOex775mY0wv+jJP88M4arWKCO2KfOpABOnoFd3VYpOxqI4jHX+n9DxxUVQZEHO Ly08/ghSUJrRWXFBYqWeN5mQEWSmaYwKgfgIsw+DJPo3zaOm66ACevFUIn2h6PDrItIS V8HtW5PchVwo/io1UX8O7yMTW8MtC6pF6BMKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=UjQIlc3bLqLTmmZxfn7T1SGIpc3xMRRH8kp2ulYR2/jvQVrCoNrVwJztZzVO9ZqyMc Bj0PKE9DkNRygxGrPpoThRL3C1xh1pkvl2/LWJ0pL9bMnjG9xxxfi2g71vPaFgkSCjqz Gf5O/+ZkdjrRBJD+BXDapunRCMR/wsdOUZVyc= Received: by 10.224.218.132 with SMTP id hq4mr3488206qab.33.1288261233115; Thu, 28 Oct 2010 03:20:33 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 03:19:52 -0700 (PDT) In-Reply-To: <4CC92D1B.5010701@entel.upc.edu> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> <4CC92D1B.5010701@entel.upc.edu> From: Ivan Voras Date: Thu, 28 Oct 2010 12:19:52 +0200 X-Google-Sender-Auth: TUfkIKq7kkNn1GNijBglXuZk4lg Message-ID: To: =?UTF-8?Q?Gustau_P=C3=A9rez?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Scott Long , freebsd-arch@freebsd.org, David Schultz , Garrett Cooper Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:20:34 -0000 2010/10/28 Gustau P=C3=A9rez : > =C2=A0 The point is, do we stick with fuse or do we switch to puffs ? Wha= t is Basically my vote goes to fuse for these reasons: * More file systems are developed for fuse * It's more popular both among the users and 3d party software developers (you mentioned Gnome) * It's better performing, at least in theory, because puffs was not originally written for a multi-threaded kernel (lots of serialization) From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 14:21:17 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B3C1065670; Thu, 28 Oct 2010 14:21:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 09E078FC08; Thu, 28 Oct 2010 14:21:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A845D46B39; Thu, 28 Oct 2010 10:21:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2B5C68A01D; Thu, 28 Oct 2010 10:21:15 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Thu, 28 Oct 2010 10:13:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010281013.03261.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 10:21:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 14:21:17 -0000 On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: > 2010/10/27 John Baldwin : > > On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: > >> This patch should convert a (simple and 100% shared between amd64 and > >> i386 header) under the x86 sub-tree. Please note that in this patch I > >> "svn cp" the file from sys/amd64/include/mptable.h into > >> sys/x86/include/mptable.h: > >> http://www.freebsd.org/~attilio/headers-x86.diff > >> > >> This is someway a POC, that I really want to get in. The idea is > >> simple and someway follows the pc98 case (even if not entirely): the > >> files under machine/include/* became just mere stubs for x86/include/* > >> contents and redirect there. > >> This won't particulary help reducing the number of available files, > >> but generally removing verbatim and would also be the way to go for > >> handling MFCs. > >> If you find this is the right way I'll commit the fix and start moving > >> other files as time permits. > > > > No, we want to do this differently because we also want this to work in > > userland. (e.g. I'd like to outright move mca.h to x86/include and then use > > '#include ' in both kernel and userland for it). We'd need some > > special glue to setup an 'x86' symlink during a kernel build that points to > > @/x86/include as we do now to setup an 'i386' link for pc98 kernels. > > > > We'd also need to install the x86 headers into /usr/include during an > > installworld. Warner has some more pointers on this I think. > > I spoke with Warner briefly about it. > One question I'm having now, though, is how getting co-living of pc98 > and x86 now, as we are basically overriding the same infrastructure > (MACHINE_CPUARCH) in the i386/amd64 case? > Do you have ideas about that? I'm still doing testing, but this seems to be working so far. I am moving mca.h as my current test. Index: include/Makefile =================================================================== --- include/Makefile (revision 214386) +++ include/Makefile (working copy) @@ -116,8 +116,11 @@ .endfor .if ${MACHINE} != ${MACHINE_CPUARCH} -_MARCH=${MACHINE_CPUARCH} +_MARCHS= ${MACHINE_CPUARCH} .endif +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" +_MARCHS+= x86 +.endif .include @@ -126,7 +129,7 @@ # Take care of stale directory-level symlinks. compat: -.for i in ${LDIRS} ${LSUBDIRS} machine ${_MARCH} crypto +.for i in ${LDIRS} ${LSUBDIRS} machine ${_MARCHS} crypto if [ -L ${DESTDIR}${INCLUDEDIR}/$i ]; then \ rm -f ${DESTDIR}${INCLUDEDIR}/$i; \ fi @@ -142,7 +145,7 @@ copies: .for i in ${LDIRS} ${LSUBDIRS} ${LSUBSUBDIRS} altq crypto machine machine/pc \ - ${_MARCH} + ${_MARCHS} .if exists(${DESTDIR}${INCLUDEDIR}/$i) cd ${DESTDIR}${INCLUDEDIR}/$i; \ for h in *.h; do \ @@ -189,7 +192,8 @@ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \ ${DESTDIR}${INCLUDEDIR}/machine/pc .endif -.if defined(_MARCH) && exists(${.CURDIR}/../sys/${_MARCH}/include) +.for _MARCH in ${_MARCHS} +.if exists(${.CURDIR}/../sys/${_MARCH}/include) ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 755 \ ${DESTDIR}${INCLUDEDIR}/${_MARCH}; \ cd ${.CURDIR}/../sys/${_MARCH}/include; \ @@ -203,6 +207,7 @@ ${DESTDIR}${INCLUDEDIR}/${_MARCH}/pc .endif .endif +.endfor cd ${.CURDIR}/../sys/rpc; \ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 types.h \ ${DESTDIR}${INCLUDEDIR}/rpc Index: sys/conf/kern.post.mk =================================================================== --- sys/conf/kern.post.mk (revision 214386) +++ sys/conf/kern.post.mk (working copy) @@ -169,6 +169,9 @@ .if ${MACHINE} != ${MACHINE_CPUARCH} _ILINKS+= ${MACHINE_CPUARCH} .endif +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" +_ILINKS+= x86 +.endif # Ensure that the link exists without depending on it when it exists. .for _link in ${_ILINKS} @@ -181,8 +184,8 @@ @case ${.TARGET} in \ machine) \ path=${S}/${MACHINE}/include ;; \ - ${MACHINE_CPUARCH}) \ - path=${S}/${MACHINE_CPUARCH}/include ;; \ + *) \ + path=${S}/${.TARGET}/include ;; \ esac ; \ ${ECHO} ${.TARGET} "->" $$path ; \ ln -s $$path ${.TARGET} -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 14:53:57 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DA331065673; Thu, 28 Oct 2010 14:53:57 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id ABC118FC13; Thu, 28 Oct 2010 14:53:56 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id o9SErnIM037476; Thu, 28 Oct 2010 23:53:54 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Thu, 28 Oct 2010 23:53:49 +0900 (JST) Message-Id: <20101028.235349.173529218.nyan@jp.FreeBSD.org> To: jhb@freebsd.org From: TAKAHASHI Yoshihiro In-Reply-To: <201010281013.03261.jhb@freebsd.org> References: <201010271355.40685.jhb@freebsd.org> <201010281013.03261.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, imp@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 14:53:57 -0000 In article <201010281013.03261.jhb@freebsd.org> John Baldwin writes: > I'm still doing testing, but this seems to be working so far. I am > moving mca.h as my current test. sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. --- TAKAHASHI Yoshihiro From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 15:53:47 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B53106566B; Thu, 28 Oct 2010 15:53:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 340AB8FC1B; Thu, 28 Oct 2010 15:53:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BDD6346B03; Thu, 28 Oct 2010 11:53:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 70A788A01D; Thu, 28 Oct 2010 11:53:45 -0400 (EDT) From: John Baldwin To: TAKAHASHI Yoshihiro Date: Thu, 28 Oct 2010 11:53:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> <201010281013.03261.jhb@freebsd.org> <20101028.235349.173529218.nyan@jp.FreeBSD.org> In-Reply-To: <20101028.235349.173529218.nyan@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281153.17104.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 11:53:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: attilio@freebsd.org, imp@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:53:47 -0000 On Thursday, October 28, 2010 10:53:49 am TAKAHASHI Yoshihiro wrote: > In article <201010281013.03261.jhb@freebsd.org> > John Baldwin writes: > > > I'm still doing testing, but this seems to be working so far. I am > > moving mca.h as my current test. > > sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. Yes, I just tested a similar fix. I had also missed the links section of src/include/Makefile. I'm waiting for amd64 and i386 buildworlds to finish. If those work ok I will post an updated patch. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 16:03:44 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D1C2106566B; Thu, 28 Oct 2010 16:03:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB8E8FC0A; Thu, 28 Oct 2010 16:03:44 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9SFwPMU029728; Thu, 28 Oct 2010 09:58:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CC99DA1.1030105@bsdimp.com> Date: Thu, 28 Oct 2010 09:58:25 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: TAKAHASHI Yoshihiro References: <201010271355.40685.jhb@freebsd.org> <201010281013.03261.jhb@freebsd.org> <20101028.235349.173529218.nyan@jp.FreeBSD.org> In-Reply-To: <20101028.235349.173529218.nyan@jp.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, imp@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:03:44 -0000 On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: > In article<201010281013.03261.jhb@freebsd.org> > John Baldwin writes: > >> I'm still doing testing, but this seems to be working so far. I am >> moving mca.h as my current test. > sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. I think that the pre-patch kern.post.mk code actually may be wrong... Or not so much wrong as redundant with what config(8) already does. IIRC, it was put in there as a stop-gap compatibility thing and it can now actually be removed (although it makes things nicer for John's patch). Warner > --- > TAKAHASHI Yoshihiro > > > From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 16:50:09 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4324106564A; Thu, 28 Oct 2010 16:50:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 755D08FC08; Thu, 28 Oct 2010 16:50:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2868346B49; Thu, 28 Oct 2010 12:50:09 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1D53B8A01D; Thu, 28 Oct 2010 12:50:04 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Thu, 28 Oct 2010 12:49:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> <20101028.235349.173529218.nyan@jp.FreeBSD.org> <4CC99DA1.1030105@bsdimp.com> In-Reply-To: <4CC99DA1.1030105@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281249.37512.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 12:50:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: attilio@freebsd.org, imp@freebsd.org, TAKAHASHI Yoshihiro , freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:50:09 -0000 On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote: > On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: > > In article<201010281013.03261.jhb@freebsd.org> > > John Baldwin writes: > > > >> I'm still doing testing, but this seems to be working so far. I am > >> moving mca.h as my current test. > > sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. > I think that the pre-patch kern.post.mk code actually may be wrong... > Or not so much wrong as redundant with what config(8) already does. > IIRC, it was put in there as a stop-gap compatibility thing and it can > now actually be removed (although it makes things nicer for John's patch). Err, I'd rather remove the code from config? config can't handle the kmod.mk and include/Makefile cases and it is easier to verify the logic is identical for the three cases if all three are done in Makefiles rather than having two of them done via Makefiles and one done via config. Honestly, I also prefer that we do kernel build stuff in the Makefiles rather than config when possible since config is much more of a black box. Putting things in config is also a bit more fragile. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 16:54:44 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E43C106566C; Thu, 28 Oct 2010 16:54:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 70A2B8FC15; Thu, 28 Oct 2010 16:54:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0948846B1A; Thu, 28 Oct 2010 12:54:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 114E68A01D; Thu, 28 Oct 2010 12:54:43 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Date: Thu, 28 Oct 2010 12:54:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201010281254.39862.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 12:54:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.7 required=4.2 tests=BAYES_00,TO_NO_BRKTS_DIRECT autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org Subject: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:54:44 -0000 [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience of arch@ ] I think we should drop support for having acpi load as a module for i386. It adds extra complication and hacks to the i386 APIC and interrupt code that are gratuitously different from amd64 as a result. Originally it was made a module so that GENERIC on i386 did not include ACPI by default but would only use up memory to hold ACPI-related code if the machine supported ACPI. Now that acpi is part of GENERIC on i386 in 8.0 and later this argument is no longer relevant. I'd like to remove support for ACPI as a module to remove the various hacks on i386 and reduce differences with amd64. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 17:27:51 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D107B106566B for ; Thu, 28 Oct 2010 17:27:51 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 808048FC13 for ; Thu, 28 Oct 2010 17:27:51 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9SGvSCD064650 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 28 Oct 2010 09:57:28 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CC9AB72.1000800@feral.com> Date: Thu, 28 Oct 2010 09:57:22 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <201010281254.39862.jhb@freebsd.org> In-Reply-To: <201010281254.39862.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Thu, 28 Oct 2010 09:57:29 -0700 (PDT) Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:27:51 -0000 Will there be still a a way to disable it from the OK prompt? On 10/28/2010 9:54 AM, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > of arch@ ] > > I think we should drop support for having acpi load as a module for i386. It > adds extra complication and hacks to the i386 APIC and interrupt code that are > gratuitously different from amd64 as a result. Originally it was made a > module so that GENERIC on i386 did not include ACPI by default but would only > use up memory to hold ACPI-related code if the machine supported ACPI. Now > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > longer relevant. I'd like to remove support for ACPI as a module to remove > the various hacks on i386 and reduce differences with amd64. > From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 17:31:10 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B1B21065693; Thu, 28 Oct 2010 17:31:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4957A8FC1C; Thu, 28 Oct 2010 17:31:09 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SH1OXC035490; Thu, 28 Oct 2010 11:01:24 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201010281254.39862.jhb@freebsd.org> Date: Thu, 28 Oct 2010 11:01:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> References: <201010281254.39862.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:31:10 -0000 On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider = audience=20 > of arch@ ] >=20 > I think we should drop support for having acpi load as a module for = i386. It=20 > adds extra complication and hacks to the i386 APIC and interrupt code = that are=20 > gratuitously different from amd64 as a result. Originally it was made = a=20 > module so that GENERIC on i386 did not include ACPI by default but = would only=20 > use up memory to hold ACPI-related code if the machine supported ACPI. = Now=20 > that acpi is part of GENERIC on i386 in 8.0 and later this argument is = no=20 > longer relevant. I'd like to remove support for ACPI as a module to = remove=20 > the various hacks on i386 and reduce differences with amd64. >=20 Just to be clear, it'll still be an optional kernel device, it just = won't be a KLD anymore, right? If you do that, what will happen with = the evil bootloader code that gropes around for the AML tables and = auto-loads the module? Is there any reason to keep that around for = compatibility? If it goes away, don't forget to also update the = bootforth code that knows how to manipulate it. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 17:35:58 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 147541065670; Thu, 28 Oct 2010 17:35:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A3DC78FC1D; Thu, 28 Oct 2010 17:35:57 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9SHWNXI030743; Thu, 28 Oct 2010 11:32:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CC9B3A7.60701@bsdimp.com> Date: Thu, 28 Oct 2010 11:32:23 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201010271355.40685.jhb@freebsd.org> <20101028.235349.173529218.nyan@jp.FreeBSD.org> <4CC99DA1.1030105@bsdimp.com> <201010281249.37512.jhb@freebsd.org> In-Reply-To: <201010281249.37512.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, imp@FreeBSD.org, TAKAHASHI Yoshihiro , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:35:58 -0000 On 10/28/2010 10:49, John Baldwin wrote: > On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote: >> On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: >>> In article<201010281013.03261.jhb@freebsd.org> >>> John Baldwin writes: >>> >>>> I'm still doing testing, but this seems to be working so far. I am >>>> moving mca.h as my current test. >>> sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. >> I think that the pre-patch kern.post.mk code actually may be wrong... >> Or not so much wrong as redundant with what config(8) already does. >> IIRC, it was put in there as a stop-gap compatibility thing and it can >> now actually be removed (although it makes things nicer for John's patch). > Err, I'd rather remove the code from config? config can't handle the kmod.mk > and include/Makefile cases and it is easier to verify the logic is identical > for the three cases if all three are done in Makefiles rather than having two > of them done via Makefiles and one done via config. Yea, the current behavior in config is to match NetBSD's approach (both at the time years ago, and now) > Honestly, I also prefer that we do kernel build stuff in the Makefiles rather > than config when possible since config is much more of a black box. Putting > things in config is also a bit more fragile. Config knows things that the make system might not know. It has been used to create the proper environment to build in. That's its job. Having said that, we can have config just export that information when generating its Makefiles. It dates from a time when it was difficult to do things in a Makefile, so it makes sense to reevaluate what we're doing with config. One example: We should have it set MACHINE and MACHINE_ARCH in the generated Makefile. We've hacked things to include and/or rely on them being set, but right now have them in the Makefiles. This isn't quite right anymore, so moving the code into config to export this information, and moving things out of config like the symbolic links makes sense. But we'll need to bump the config version to do this properly since there's compatibility issues if we're not careful... Warner Warner From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:04:48 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C23F106566B; Thu, 28 Oct 2010 18:04:48 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 37CF88FC08; Thu, 28 Oct 2010 18:04:47 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-7-59.dsl.snfc21.pacbell.net [71.139.7.59]) by mail.root.org (Postfix) with ESMTP id B0C276D5C; Thu, 28 Oct 2010 17:48:57 +0000 (UTC) Message-ID: <4CC9B788.3080704@root.org> Date: Thu, 28 Oct 2010 10:48:56 -0700 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <201010281254.39862.jhb@freebsd.org> In-Reply-To: <201010281254.39862.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:04:48 -0000 On 10/28/2010 9:54 AM, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > of arch@ ] > > I think we should drop support for having acpi load as a module for i386. It > adds extra complication and hacks to the i386 APIC and interrupt code that are > gratuitously different from amd64 as a result. Originally it was made a > module so that GENERIC on i386 did not include ACPI by default but would only > use up memory to hold ACPI-related code if the machine supported ACPI. Now > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > longer relevant. I'd like to remove support for ACPI as a module to remove > the various hacks on i386 and reduce differences with amd64. Fine with me. Users will still be able to disable ACPI if they want. And systems that don't have ACPI (pre-2001) can still compile it out with "nodevice" to save a few 100 KB of RAM. There's no reason to keep it as a kernel module. -- Nate From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:15:47 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F43106564A for ; Thu, 28 Oct 2010 18:15:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 44C828FC32 for ; Thu, 28 Oct 2010 18:15:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C039246B0C; Thu, 28 Oct 2010 14:15:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D1DEF8A009; Thu, 28 Oct 2010 14:15:45 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 28 Oct 2010 13:59:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <4CC9AB72.1000800@feral.com> In-Reply-To: <4CC9AB72.1000800@feral.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281359.31192.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 14:15:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Jacob Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:15:47 -0000 On Thursday, October 28, 2010 12:57:22 pm Matthew Jacob wrote: > Will there be still a a way to disable it from the OK prompt? Yes. Using 'hint.acpi.0.disabled=1' has always worked to do that and the 'safe mode' menu item will continue to disable ACPI via that tunable (though for many newer machines disabling ACPI is actually less safe, but that is the subject of a separate thread). > On 10/28/2010 9:54 AM, John Baldwin wrote: > > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > > of arch@ ] > > > > I think we should drop support for having acpi load as a module for i386. It > > adds extra complication and hacks to the i386 APIC and interrupt code that are > > gratuitously different from amd64 as a result. Originally it was made a > > module so that GENERIC on i386 did not include ACPI by default but would only > > use up memory to hold ACPI-related code if the machine supported ACPI. Now > > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > > longer relevant. I'd like to remove support for ACPI as a module to remove > > the various hacks on i386 and reduce differences with amd64. > > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:15:49 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13C5F106564A; Thu, 28 Oct 2010 18:15:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BCFC78FC22; Thu, 28 Oct 2010 18:15:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 42C4546B1A; Thu, 28 Oct 2010 14:15:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F09E28A01D; Thu, 28 Oct 2010 14:15:46 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Thu, 28 Oct 2010 14:01:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> <201010281249.37512.jhb@freebsd.org> <4CC9B3A7.60701@bsdimp.com> In-Reply-To: <4CC9B3A7.60701@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281401.33549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 14:15:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: attilio@freebsd.org, imp@freebsd.org, TAKAHASHI Yoshihiro , freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:15:49 -0000 On Thursday, October 28, 2010 1:32:23 pm Warner Losh wrote: > On 10/28/2010 10:49, John Baldwin wrote: > > On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote: > >> On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: > >>> In article<201010281013.03261.jhb@freebsd.org> > >>> John Baldwin writes: > >>> > >>>> I'm still doing testing, but this seems to be working so far. I am > >>>> moving mca.h as my current test. > >>> sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. > >> I think that the pre-patch kern.post.mk code actually may be wrong... > >> Or not so much wrong as redundant with what config(8) already does. > >> IIRC, it was put in there as a stop-gap compatibility thing and it can > >> now actually be removed (although it makes things nicer for John's patch). > > Err, I'd rather remove the code from config? config can't handle the kmod.mk > > and include/Makefile cases and it is easier to verify the logic is identical > > for the three cases if all three are done in Makefiles rather than having two > > of them done via Makefiles and one done via config. > Yea, the current behavior in config is to match NetBSD's approach (both > at the time years ago, and now) > > Honestly, I also prefer that we do kernel build stuff in the Makefiles rather > > than config when possible since config is much more of a black box. Putting > > things in config is also a bit more fragile. > Config knows things that the make system might not know. It has been > used to create the proper environment to build in. That's its job. > > Having said that, we can have config just export that information when > generating its Makefiles. It dates from a time when it was difficult to > do things in a Makefile, so it makes sense to reevaluate what we're > doing with config. > > One example: We should have it set MACHINE and MACHINE_ARCH in the > generated Makefile. We've hacked things to include and/or rely on them > being set, but right now have them in the Makefiles. This isn't quite > right anymore, so moving the code into config to export this > information, and moving things out of config like the symbolic links > makes sense. But we'll need to bump the config version to do this > properly since there's compatibility issues if we're not careful... It turns out our Makefiles were already fixed by ru@ to handle this properly and config already exports the path to the source directory in the generated Makefile. ru@ had planned on removing the code to generate symlinks from config but didn't do it. My makefile changes to generate the x86 link worked fine with buildkernel (using config -d) even though config was not patched to create the link because of ru@'s changes. I'm going to test just removing the changes from config altogether. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:15:51 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6AA1065720; Thu, 28 Oct 2010 18:15:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DF5688FC34; Thu, 28 Oct 2010 18:15:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8056046B35; Thu, 28 Oct 2010 14:15:50 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A5C78A027; Thu, 28 Oct 2010 14:15:49 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 28 Oct 2010 14:02:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> In-Reply-To: <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281402.48848.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 14:15:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:15:51 -0000 On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: > On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > > of arch@ ] > > > > I think we should drop support for having acpi load as a module for i386. It > > adds extra complication and hacks to the i386 APIC and interrupt code that are > > gratuitously different from amd64 as a result. Originally it was made a > > module so that GENERIC on i386 did not include ACPI by default but would only > > use up memory to hold ACPI-related code if the machine supported ACPI. Now > > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > > longer relevant. I'd like to remove support for ACPI as a module to remove > > the various hacks on i386 and reduce differences with amd64. > > > > Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it goes away, don't forget to also update the bootforth code that knows how to manipulate it. It already does the right thing in this case (it did regardless, but that was part of the testing before enabling 'device acpi' in GENERIC for 8.0). If we remove the KLD support then we can now remove that code from the loader and Forth scripts as they will no longer be needed. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:45:06 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB8B1065670; Thu, 28 Oct 2010 18:45:06 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB1718FC08; Thu, 28 Oct 2010 18:45:05 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9SIj4uE062791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 20:45:04 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1288291504; bh=YR++qhfKaVV5rDaztlG3V6niAj3fJPkAi+QikjL95jQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=H9hGhaMXggnd41Gl+NY+z0duviloBXjc5CW4h8TIJ/U+YkAzr9e4SoKkdPP3Kpexc H2oFTLfYPHx9HPnIH0+9vyqt6Dsfyt1NDPGjFFwTNildAeDzWK33gx2HuerKWoT90k 16q68OQwaopc1VTwgRkWLAGCVv9npWpnhuSkiCbQ= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9SIj47a062790; Thu, 28 Oct 2010 20:45:04 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 28 Oct 2010 20:45:04 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ivan Voras Message-ID: <20101028184504.GB46314@acme.spoerlein.net> Mail-Followup-To: Ivan Voras , freebsd-arch@freebsd.org References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> <4CC92D1B.5010701@entel.upc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:45:06 -0000 On Thu, 28.10.2010 at 12:19:52 +0200, Ivan Voras wrote: > 2010/10/28 Gustau Pérez : > > >   The point is, do we stick with fuse or do we switch to puffs ? What is > > Basically my vote goes to fuse for these reasons: > > * More file systems are developed for fuse > * It's more popular both among the users and 3d party software > developers (you mentioned Gnome) > * It's better performing, at least in theory, because puffs was not > originally written for a multi-threaded kernel (lots of serialization) I was under the impression, there's a library for puffs (called re-fuse?!?) which would provide API compatible shims for FUSE, rendering your first argument invalid. Or am I wrong? Uli From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:50:48 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622541065698; Thu, 28 Oct 2010 18:50:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 058B78FC18; Thu, 28 Oct 2010 18:50:47 +0000 (UTC) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SIogog036148; Thu, 28 Oct 2010 12:50:42 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Thu, 28 Oct 2010 12:50:42 -0600 (MDT) From: Scott Long To: John Baldwin In-Reply-To: <201010281402.48848.jhb@freebsd.org> Message-ID: References: <201010281254.39862.jhb@freebsd.org> <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> <201010281402.48848.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:50:48 -0000 On Thu, 28 Oct 2010, John Baldwin wrote: > On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: >> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: >>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience >>> of arch@ ] >>> >>> I think we should drop support for having acpi load as a module for i386. It >>> adds extra complication and hacks to the i386 APIC and interrupt code that are >>> gratuitously different from amd64 as a result. Originally it was made a >>> module so that GENERIC on i386 did not include ACPI by default but would only >>> use up memory to hold ACPI-related code if the machine supported ACPI. Now >>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is no >>> longer relevant. I'd like to remove support for ACPI as a module to remove >>> the various hacks on i386 and reduce differences with amd64. >>> >> >> Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil > bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it > goes away, don't forget to also update the bootforth code that knows how to manipulate it. > > It already does the right thing in this case (it did regardless, but that was > part of the testing before enabling 'device acpi' in GENERIC for 8.0). If > we remove the KLD support then we can now remove that code from the loader > and Forth scripts as they will no longer be needed. > You lost me, what is "the right thing". What I'm asking is whether there will be any surprises to people upgrading from 8.0 to 8.x with regard to the bootloader no longer autoloading acpi.ko, and will there be any surprises to those who update their bootblocks but maybe switch back and forth between old and new kernels? Scott From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 19:29:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 815CB106566B; Thu, 28 Oct 2010 19:29:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 374F78FC14; Thu, 28 Oct 2010 19:29:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B729446B09; Thu, 28 Oct 2010 15:29:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A9E678A009; Thu, 28 Oct 2010 15:29:43 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 28 Oct 2010 15:29:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281529.03379.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 15:29:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 19:29:45 -0000 On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote: > On Thu, 28 Oct 2010, John Baldwin wrote: > > On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: > >> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > >>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > >>> of arch@ ] > >>> > >>> I think we should drop support for having acpi load as a module for i386. It > >>> adds extra complication and hacks to the i386 APIC and interrupt code that are > >>> gratuitously different from amd64 as a result. Originally it was made a > >>> module so that GENERIC on i386 did not include ACPI by default but would only > >>> use up memory to hold ACPI-related code if the machine supported ACPI. Now > >>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > >>> longer relevant. I'd like to remove support for ACPI as a module to remove > >>> the various hacks on i386 and reduce differences with amd64. > >>> > >> > >> Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil > > bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it > > goes away, don't forget to also update the bootforth code that knows how to manipulate it. > > > > It already does the right thing in this case (it did regardless, but that was > > part of the testing before enabling 'device acpi' in GENERIC for 8.0). If > > we remove the KLD support then we can now remove that code from the loader > > and Forth scripts as they will no longer be needed. > > > > You lost me, what is "the right thing". What I'm asking is whether there > will be any surprises to people upgrading from 8.0 to 8.x with regard to > the bootloader no longer autoloading acpi.ko, and will there be any > surprises to those who update their bootblocks but maybe switch back and > forth between old and new kernels? The loader code just sets 'acpi_load=YES'. If acpi is compiled into the kernel or it is not present it just silently fails. This was already considered and tested during the 8.0 release cycle. I am only proposing making this change for 9, FYI, not to MFC it. If we were to remove the code from the loader that sets acpi_load in 9 and someone booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.ko would not be autoloaded. We could easily leave the code in the loader around until 10.0 so there is one release branch worth of compatibility, though the fact that GENERIC i386 in 8 ships with acpi compiled in and not a module on i386 is probably already giving us a release branch of compatibility as it is. That is, a GENERIC 8.0 i386 kernel would work fine with a loader that removed the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko with a modified loader. Given that we don't generally support 7.x -> 9.0 upgrades, I really think it would be ok to remove the loader support from 9. However, what I really care about are the kernel changes, not the loader changes. The loader changes could wait until 10 if really necessary. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 19:44:49 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1EC2106566C; Thu, 28 Oct 2010 19:44:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 785848FC14; Thu, 28 Oct 2010 19:44:49 +0000 (UTC) Received: from [10.70.143.238] (166-205-014-036.mobile.mymmode.com [166.205.14.36] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SJidYq036520; Thu, 28 Oct 2010 13:44:45 -0600 (MDT) (envelope-from scottl@samsco.org) References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> <201010281529.03379.jhb@freebsd.org> In-Reply-To: <201010281529.03379.jhb@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Scott Long Date: Thu, 28 Oct 2010 13:44:16 -0600 To: John Baldwin X-Spam-Status: No, score=1.9 required=3.8 tests=MAY_BE_FORGED, MIME_QP_LONG_LINE, RCVD_IN_RP_RNBL, RDNS_DYNAMIC autolearn=no version=3.3.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "acpi@freebsd.org" , "arch@freebsd.org" Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 19:44:49 -0000 On Oct 28, 2010, at 1:29 PM, John Baldwin wrote: > On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote: >> On Thu, 28 Oct 2010, John Baldwin wrote: >>> On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: >>>> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: >>>>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider au= dience >>>>> of arch@ ] >>>>>=20 >>>>> I think we should drop support for having acpi load as a module for i3= 86. It >>>>> adds extra complication and hacks to the i386 APIC and interrupt code t= hat are >>>>> gratuitously different from amd64 as a result. Originally it was made= a >>>>> module so that GENERIC on i386 did not include ACPI by default but wou= ld only >>>>> use up memory to hold ACPI-related code if the machine supported ACPI.= Now >>>>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is= no >>>>> longer relevant. I'd like to remove support for ACPI as a module to r= emove >>>>> the various hacks on i386 and reduce differences with amd64. >>>>>=20 >>>>=20 >>>> Just to be clear, it'll still be an optional kernel device, it just won= 't be a KLD anymore, right? If you do that, what will happen with the=20 > evil >>> bootloader code that gropes around for the AML tables and auto-loads the= module? Is there any reason to keep that around for compatibility? =20 > If it >>> goes away, don't forget to also update the bootforth code that knows how= to manipulate it. >>>=20 >>> It already does the right thing in this case (it did regardless, but tha= t was >>> part of the testing before enabling 'device acpi' in GENERIC for 8.0). I= f >>> we remove the KLD support then we can now remove that code from the load= er >>> and Forth scripts as they will no longer be needed. >>>=20 >>=20 >> You lost me, what is "the right thing". What I'm asking is whether there= =20 >> will be any surprises to people upgrading from 8.0 to 8.x with regard to=20= >> the bootloader no longer autoloading acpi.ko, and will there be any=20 >> surprises to those who update their bootblocks but maybe switch back and=20= >> forth between old and new kernels? >=20 > The loader code just sets 'acpi_load=3DYES'. If acpi is compiled into the= > kernel or it is not present it just silently fails. This was already > considered and tested during the 8.0 release cycle. >=20 > I am only proposing making this change for 9, FYI, not to MFC it. If we > were to remove the code from the loader that sets acpi_load in 9 and someo= ne > booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.= ko > would not be autoloaded. We could easily leave the code in the loader aro= und > until 10.0 so there is one release branch worth of compatibility, though t= he > fact that GENERIC i386 in 8 ships with acpi compiled in and not a module o= n > i386 is probably already giving us a release branch of compatibility as it= is. >=20 I agree. > That is, a GENERIC 8.0 i386 kernel would work fine with a loader that remo= ved > the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko wi= th a > modified loader. Given that we don't generally support 7.x -> 9.0 upgrade= s, I > really think it would be ok to remove the loader support from 9. >=20 > However, what I really care about are the kernel changes, not the loader c= hanges. > The loader changes could wait until 10 if really necessary. >=20 >=20 Sounds like a good plan. I don't think that's there any reason to wait for 1= 0.0 Scott= From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 20:07:16 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075421065670 for ; Thu, 28 Oct 2010 20:07:16 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 939F88FC1A for ; Thu, 28 Oct 2010 20:07:15 +0000 (UTC) Received: by qwg8 with SMTP id 8so283569qwg.13 for ; Thu, 28 Oct 2010 13:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=LpS/vPBoB7KqN66Hi7oaHT/j1pSkMvf2MvOJnNm40tw=; b=KLNJcjI/4JtGB/ctkETk87PvIKweIhd+dsgGJSXS2fx7QAwMXfmAvWe82Mir/B2dDG AVfuYcaSSPHF9V+9OsGj66ycFvkIai3016XFiB2ty3k+BDqBpuE8tJ3iuAjgqfGZWyO4 Im8v/OiQpJWst3FiT2nr1W1j6f9T7nSExlBeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=x0eoNeOO1+X7E990RBHNIdCx/tHn5rWElrCwBYrHeYq77wNKVbbS4pVfNtNDlbMuPc oPMxXtX2+y+IZah0uKr0X4K7y6PtEC1vlRORyb6oL9z4IqceGwjwHs9iBzoo3RKQ8XB0 UKggjdop06i9qqBuwwEoZTQD+C6Lz9+Itpd+8= Received: by 10.229.220.201 with SMTP id hz9mr10901756qcb.194.1288296433349; Thu, 28 Oct 2010 13:07:13 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 13:06:32 -0700 (PDT) In-Reply-To: <20101028184504.GB46314@acme.spoerlein.net> References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> <4CC92D1B.5010701@entel.upc.edu> <20101028184504.GB46314@acme.spoerlein.net> From: Ivan Voras Date: Thu, 28 Oct 2010 22:06:32 +0200 X-Google-Sender-Auth: R2OdQTXzRjizEO7PmOa1rcj5SEI Message-ID: To: Ivan Voras , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 20:07:16 -0000 On 28 October 2010 20:45, Ulrich Sp=C3=B6rlein wrote: > On Thu, 28.10.2010 at 12:19:52 +0200, Ivan Voras wrote: >> 2010/10/28 Gustau P=C3=A9rez : >> >> > =C2=A0 The point is, do we stick with fuse or do we switch to puffs ? = What is >> >> Basically my vote goes to fuse for these reasons: >> >> =C2=A0* More file systems are developed for fuse >> =C2=A0* It's more popular both among the users and 3d party software >> developers (you mentioned Gnome) >> =C2=A0* It's better performing, at least in theory, because puffs was no= t >> originally written for a multi-threaded kernel (lots of serialization) > > I was under the impression, there's a library for puffs (called > re-fuse?!?) which would provide API compatible shims for FUSE, rendering > your first argument invalid. > > Or am I wrong? Sort of. According to the development paper at http://www.netbsd.org/docs/puffs/refuse.pdf the refuse library doesn't/didn't support the whole FUSE API, and according to a post I can't seem to find right now (and will send if I find it) the architectures (especially wrt threading) are too different for it to be 100% mapping between puffs and fuse. As I'm interested in the more advanced fuse file systems (e.g. cluster fs's), this stands out as a possible problem. The puffs system continued to be developed at NetBSD after the FreeBSD port was branched. There will also be nontrivial work to merge new code from NetBSD. I'm not specifically against puffs, but I think dispersal of efforts between the two APIs is the worst possible outcome right now. The above paper also states that there are OpenSolaris and MacOS X implementations of FUSE which are based on fuse4bsd so there's even that aspect - they made it stable, why can't we? From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 20:58:17 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8CA1065675; Thu, 28 Oct 2010 20:58:17 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id EDAE18FC14; Thu, 28 Oct 2010 20:58:16 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9SKwGxK066010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 22:58:16 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1288299496; bh=uAH5Wj4w4w3n02ABbFQL70Zqpq/yUUFiRAzSe5ERGc0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=nX5uXj9SUypl+XObEgY1M9pGfZnnAtHauUPpoyvMTCvBIphAX+9OLCzpcPLYYWrXr OcQCQTcqwSbvHbB5PBIwYyJlq2tGpQjAdlpJ4+TEYwkMfHpFddBNBP/NBNv/fyCtqa 6GnMxMYESUh2f1PkAPOxePc9qGilJKIeJ5XgBEAc= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9SKwG9V066009; Thu, 28 Oct 2010 22:58:16 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 28 Oct 2010 22:58:15 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Attilio Rao Message-ID: <20101028205815.GF46314@acme.spoerlein.net> Mail-Followup-To: Attilio Rao , FreeBSD Arch References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Arch Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 20:58:17 -0000 On Wed, 27.10.2010 at 16:56:06 +0200, Attilio Rao wrote: > This patch should convert a (simple and 100% shared between amd64 and > i386 header) under the x86 sub-tree. Please note that in this patch I > "svn cp" the file from sys/amd64/include/mptable.h into > sys/x86/include/mptable.h: > http://www.freebsd.org/~attilio/headers-x86.diff > > This is someway a POC, that I really want to get in. The idea is > simple and someway follows the pc98 case (even if not entirely): the > files under machine/include/* became just mere stubs for x86/include/* > contents and redirect there. > This won't particulary help reducing the number of available files, > but generally removing verbatim and would also be the way to go for > handling MFCs. > If you find this is the right way I'll commit the fix and start moving > other files as time permits. What I don't quite get with the new x86 directory is, why we didn't make it arch/x86 from the start? The usual argument against moving architecture specific stuff to arch/ is that it will break diffs for vendors. Now with x86 and the merging we are breaking their stuff anyway, but we don't actually improve the clutter under /sys and even gain a new arch-specific dir, not under arch/ Somehow, this seems like a missed opportunity for an often requested cleanup. :/ Uli From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 22:00:41 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E058A106566B; Thu, 28 Oct 2010 22:00:40 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id F160C8FC16; Thu, 28 Oct 2010 22:00:38 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAM6GyUxbsdlD/2dsb2JhbACTW413cr8WhUgE Received: from 67.217-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.217.67]) by relay.skynet.be with ESMTP; 28 Oct 2010 23:31:22 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o9SLVLL1005717; Thu, 28 Oct 2010 23:31:21 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Thu, 28 Oct 2010 23:31:09 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010281013.03261.jhb@freebsd.org> In-Reply-To: <201010281013.03261.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1436314.ToryqBqT7b"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201010282331.19825.tijl@coosemans.org> Cc: Attilio Rao , Warner Losh Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 22:00:41 -0000 --nextPart1436314.ToryqBqT7b Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 28 October 2010 16:13:02 John Baldwin wrote: > On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: >> 2010/10/27 John Baldwin : >>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >>>> This patch should convert a (simple and 100% shared between amd64 and >>>> i386 header) under the x86 sub-tree. Please note that in this patch I >>>> "svn cp" the file from sys/amd64/include/mptable.h into >>>> sys/x86/include/mptable.h: >>>> http://www.freebsd.org/~attilio/headers-x86.diff >>>> >>>> This is someway a POC, that I really want to get in. The idea is >>>> simple and someway follows the pc98 case (even if not entirely): the >>>> files under machine/include/* became just mere stubs for x86/include/* >>>> contents and redirect there. >>>> This won't particulary help reducing the number of available files, >>>> but generally removing verbatim and would also be the way to go for >>>> handling MFCs. >>>> If you find this is the right way I'll commit the fix and start moving >>>> other files as time permits. >>> >>> No, we want to do this differently because we also want this to work in >>> userland. (e.g. I'd like to outright move mca.h to x86/include and then >>> use '#include ' in both kernel and userland for it). We'd n= eed >>> some special glue to setup an 'x86' symlink during a kernel build that >>> points to @/x86/include as we do now to setup an 'i386' link for pc98 >>> kernels. >>> >>> We'd also need to install the x86 headers into /usr/include during an >>> installworld. Warner has some more pointers on this I think. >>=20 >> I spoke with Warner briefly about it. >> One question I'm having now, though, is how getting co-living of pc98 >> and x86 now, as we are basically overriding the same infrastructure >> (MACHINE_CPUARCH) in the i386/amd64 case? >> Do you have ideas about that? >=20 > I'm still doing testing, but this seems to be working so far. I am > moving mca.h as my current test. >=20 > Index: include/Makefile > =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 > --- include/Makefile (revision 214386) > +++ include/Makefile (working copy) > @@ -116,8 +116,11 @@ > .endfor > =20 > .if ${MACHINE} !=3D ${MACHINE_CPUARCH} > -_MARCH=3D${MACHINE_CPUARCH} > +_MARCHS=3D ${MACHINE_CPUARCH} > .endif > +.if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D "amd64" > +_MARCHS+=3D x86 > +.endif Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98 cases? This patch wouldn't be needed then. --nextPart1436314.ToryqBqT7b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzJ66cACgkQfoCS2CCgtisIhgEAhPtUZJMFamWhivkzFNCNGjQf PUdu+BKMYL8YUz9vTpAA+wQXWIXk3V7gOt50SFvY6Mnl7XaJRiqw1hdCkiUQ3Z+C =TIUO -----END PGP SIGNATURE----- --nextPart1436314.ToryqBqT7b-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 01:57:25 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B034810656AD; Fri, 29 Oct 2010 01:57:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6078FC36; Fri, 29 Oct 2010 01:57:25 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9T1tso4035910; Thu, 28 Oct 2010 19:55:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CCA29AA.6090701@bsdimp.com> Date: Thu, 28 Oct 2010 19:55:54 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: Tijl Coosemans References: <201010281013.03261.jhb@freebsd.org> <201010282331.19825.tijl@coosemans.org> In-Reply-To: <201010282331.19825.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , Warner Losh , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 01:57:25 -0000 On 10/28/2010 15:31, Tijl Coosemans wrote: > On Thursday 28 October 2010 16:13:02 John Baldwin wrote: >> On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: >>> 2010/10/27 John Baldwin: >>>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >>>>> This patch should convert a (simple and 100% shared between amd64 and >>>>> i386 header) under the x86 sub-tree. Please note that in this patch I >>>>> "svn cp" the file from sys/amd64/include/mptable.h into >>>>> sys/x86/include/mptable.h: >>>>> http://www.freebsd.org/~attilio/headers-x86.diff >>>>> >>>>> This is someway a POC, that I really want to get in. The idea is >>>>> simple and someway follows the pc98 case (even if not entirely): the >>>>> files under machine/include/* became just mere stubs for x86/include/* >>>>> contents and redirect there. >>>>> This won't particulary help reducing the number of available files, >>>>> but generally removing verbatim and would also be the way to go for >>>>> handling MFCs. >>>>> If you find this is the right way I'll commit the fix and start moving >>>>> other files as time permits. >>>> No, we want to do this differently because we also want this to work in >>>> userland. (e.g. I'd like to outright move mca.h to x86/include and then >>>> use '#include' in both kernel and userland for it). We'd need >>>> some special glue to setup an 'x86' symlink during a kernel build that >>>> points to @/x86/include as we do now to setup an 'i386' link for pc98 >>>> kernels. >>>> >>>> We'd also need to install the x86 headers into /usr/include during an >>>> installworld. Warner has some more pointers on this I think. >>> I spoke with Warner briefly about it. >>> One question I'm having now, though, is how getting co-living of pc98 >>> and x86 now, as we are basically overriding the same infrastructure >>> (MACHINE_CPUARCH) in the i386/amd64 case? >>> Do you have ideas about that? >> I'm still doing testing, but this seems to be working so far. I am >> moving mca.h as my current test. >> >> Index: include/Makefile >> =================================================================== >> --- include/Makefile (revision 214386) >> +++ include/Makefile (working copy) >> @@ -116,8 +116,11 @@ >> .endfor >> >> .if ${MACHINE} != ${MACHINE_CPUARCH} >> -_MARCH=${MACHINE_CPUARCH} >> +_MARCHS= ${MACHINE_CPUARCH} >> .endif >> +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" >> +_MARCHS+= x86 >> +.endif > Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98 > cases? This patch wouldn't be needed then. Nope. Not yet anyway, there's lots of other things that would break at the moment... It is a long-term goal, however, to get there eventually. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 01:57:26 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F1710656B4; Fri, 29 Oct 2010 01:57:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EE96A8FC0C; Fri, 29 Oct 2010 01:57:25 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9T1qbBK035890; Thu, 28 Oct 2010 19:52:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CCA28E5.6020102@bsdimp.com> Date: Thu, 28 Oct 2010 19:52:37 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201010271355.40685.jhb@freebsd.org> <201010281249.37512.jhb@freebsd.org> <4CC9B3A7.60701@bsdimp.com> <201010281401.33549.jhb@freebsd.org> In-Reply-To: <201010281401.33549.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, imp@FreeBSD.org, TAKAHASHI Yoshihiro , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 01:57:26 -0000 On 10/28/2010 12:01, John Baldwin wrote: > On Thursday, October 28, 2010 1:32:23 pm Warner Losh wrote: >> On 10/28/2010 10:49, John Baldwin wrote: >>> On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote: >>>> On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: >>>>> In article<201010281013.03261.jhb@freebsd.org> >>>>> John Baldwin writes: >>>>> >>>>>> I'm still doing testing, but this seems to be working so far. I am >>>>>> moving mca.h as my current test. >>>>> sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. >>>> I think that the pre-patch kern.post.mk code actually may be wrong... >>>> Or not so much wrong as redundant with what config(8) already does. >>>> IIRC, it was put in there as a stop-gap compatibility thing and it can >>>> now actually be removed (although it makes things nicer for John's patch). >>> Err, I'd rather remove the code from config? config can't handle the kmod.mk >>> and include/Makefile cases and it is easier to verify the logic is identical >>> for the three cases if all three are done in Makefiles rather than having two >>> of them done via Makefiles and one done via config. >> Yea, the current behavior in config is to match NetBSD's approach (both >> at the time years ago, and now) >>> Honestly, I also prefer that we do kernel build stuff in the Makefiles rather >>> than config when possible since config is much more of a black box. Putting >>> things in config is also a bit more fragile. >> Config knows things that the make system might not know. It has been >> used to create the proper environment to build in. That's its job. >> >> Having said that, we can have config just export that information when >> generating its Makefiles. It dates from a time when it was difficult to >> do things in a Makefile, so it makes sense to reevaluate what we're >> doing with config. >> >> One example: We should have it set MACHINE and MACHINE_ARCH in the >> generated Makefile. We've hacked things to include and/or rely on them >> being set, but right now have them in the Makefiles. This isn't quite >> right anymore, so moving the code into config to export this >> information, and moving things out of config like the symbolic links >> makes sense. But we'll need to bump the config version to do this >> properly since there's compatibility issues if we're not careful... > It turns out our Makefiles were already fixed by ru@ to handle this properly > and config already exports the path to the source directory in the generated > Makefile. ru@ had planned on removing the code to generate symlinks from > config but didn't do it. My makefile changes to generate the x86 link worked > fine with buildkernel (using config -d) even though config was not patched to > create the link because of ru@'s changes. I'm going to test just removing the > changes from config altogether. We've tried to make it possible for one config to be used on 7, 8 and 9. Please make sure this is still possible. Thanks! If that's all tested, then I'm cool with the changes... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 13:44:56 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CF81065674; Fri, 29 Oct 2010 13:44:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1398FC21; Fri, 29 Oct 2010 13:44:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C535446B37; Fri, 29 Oct 2010 09:44:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA5648A009; Fri, 29 Oct 2010 09:44:54 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 29 Oct 2010 09:21:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101028205815.GF46314@acme.spoerlein.net> In-Reply-To: <20101028205815.GF46314@acme.spoerlein.net> MIME-Version: 1.0 Message-Id: <201010290921.03397.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 09:44:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Attilio Rao , Ulrich =?iso-8859-1?q?Sp=F6rlein?= Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:44:56 -0000 On Thursday, October 28, 2010 4:58:15 pm Ulrich Sp=F6rlein wrote: > On Wed, 27.10.2010 at 16:56:06 +0200, Attilio Rao wrote: > > This patch should convert a (simple and 100% shared between amd64 and > > i386 header) under the x86 sub-tree. Please note that in this patch I > > "svn cp" the file from sys/amd64/include/mptable.h into > > sys/x86/include/mptable.h: > > http://www.freebsd.org/~attilio/headers-x86.diff > >=20 > > This is someway a POC, that I really want to get in. The idea is > > simple and someway follows the pc98 case (even if not entirely): the > > files under machine/include/* became just mere stubs for x86/include/* > > contents and redirect there. > > This won't particulary help reducing the number of available files, > > but generally removing verbatim and would also be the way to go for > > handling MFCs. > > If you find this is the right way I'll commit the fix and start moving > > other files as time permits. >=20 > What I don't quite get with the new x86 directory is, why we didn't make > it arch/x86 from the start? The usual argument against moving > architecture specific stuff to arch/ is that it will break diffs for > vendors. Now with x86 and the merging we are breaking their stuff > anyway, but we don't actually improve the clutter under /sys and even > gain a new arch-specific dir, not under arch/ >=20 > Somehow, this seems like a missed opportunity for an often requested > cleanup. :/ Because you'd need to move all the architectures to be consistent. Also, t= he=20 point of 'x86' is that there are a lot of bits that are shared between i386= =20 and amd64. Prior to 'x86' many of that code was simply duplicated making i= t=20 harder to maintain. The goal of an 'x86' arch is to be a repository for co= de=20 shared between i386 and amd64. Note that both Linux and NetBSD have adopte= d a=20 similar model for code shared between i386 and amd64. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 13:45:15 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9290E1065738; Fri, 29 Oct 2010 13:45:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 214088FC14; Fri, 29 Oct 2010 13:45:01 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 93CC446B49; Fri, 29 Oct 2010 09:45:00 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1EBF38A009; Fri, 29 Oct 2010 09:44:59 -0400 (EDT) From: John Baldwin To: Tijl Coosemans Date: Fri, 29 Oct 2010 09:40:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281013.03261.jhb@freebsd.org> <201010282331.19825.tijl@coosemans.org> In-Reply-To: <201010282331.19825.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010290940.17353.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 09:44:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Attilio Rao , Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:45:15 -0000 On Thursday, October 28, 2010 5:31:09 pm Tijl Coosemans wrote: > On Thursday 28 October 2010 16:13:02 John Baldwin wrote: > > On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: > >> 2010/10/27 John Baldwin : > >>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: > >>>> This patch should convert a (simple and 100% shared between amd64 and > >>>> i386 header) under the x86 sub-tree. Please note that in this patch I > >>>> "svn cp" the file from sys/amd64/include/mptable.h into > >>>> sys/x86/include/mptable.h: > >>>> http://www.freebsd.org/~attilio/headers-x86.diff > >>>> > >>>> This is someway a POC, that I really want to get in. The idea is > >>>> simple and someway follows the pc98 case (even if not entirely): the > >>>> files under machine/include/* became just mere stubs for x86/include/* > >>>> contents and redirect there. > >>>> This won't particulary help reducing the number of available files, > >>>> but generally removing verbatim and would also be the way to go for > >>>> handling MFCs. > >>>> If you find this is the right way I'll commit the fix and start moving > >>>> other files as time permits. > >>> > >>> No, we want to do this differently because we also want this to work in > >>> userland. (e.g. I'd like to outright move mca.h to x86/include and then > >>> use '#include ' in both kernel and userland for it). We'd need > >>> some special glue to setup an 'x86' symlink during a kernel build that > >>> points to @/x86/include as we do now to setup an 'i386' link for pc98 > >>> kernels. > >>> > >>> We'd also need to install the x86 headers into /usr/include during an > >>> installworld. Warner has some more pointers on this I think. > >> > >> I spoke with Warner briefly about it. > >> One question I'm having now, though, is how getting co-living of pc98 > >> and x86 now, as we are basically overriding the same infrastructure > >> (MACHINE_CPUARCH) in the i386/amd64 case? > >> Do you have ideas about that? > > > > I'm still doing testing, but this seems to be working so far. I am > > moving mca.h as my current test. > > > > Index: include/Makefile > > =================================================================== > > --- include/Makefile (revision 214386) > > +++ include/Makefile (working copy) > > @@ -116,8 +116,11 @@ > > .endfor > > > > .if ${MACHINE} != ${MACHINE_CPUARCH} > > -_MARCH=${MACHINE_CPUARCH} > > +_MARCHS= ${MACHINE_CPUARCH} > > .endif > > +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" > > +_MARCHS+= x86 > > +.endif > > Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98 > cases? This patch wouldn't be needed then. As Warner said, we aren't quite ready for that yet. However, even if we do that, pc98 would need further help as it still needs /usr/include/i386 installed. So that will require a code along the lines of: .if ${MACHINE} != ${MACHINE_CPUARCH} _MARCHS= ${MACHINE_CPUARCH} .endif .if ${MACHINE} != ${MACHINE_ARCH} && ${MACHINE_ARCH} != ${MACHINE_CPUARCH} _MARCHS+= ${MACHINE_ARCH} .endif With pc98 having MACHINE=pc98, MACHINE_ARCH=i386, MACHINE_CPUARCH=x86. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 14:29:28 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A4C4106564A for ; Fri, 29 Oct 2010 14:29:28 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 71B6B8FC08 for ; Fri, 29 Oct 2010 14:29:28 +0000 (UTC) From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2010 09:42:09 -0400 Message-Id: To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: RFC: ARP Packet Queues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:29:28 -0000 Howdy, Please review the following patch against HEAD: http://people.freebsd.org/~gnn/head-arpqueue.diff =20 This patch makes two changes to the ARP code: 1) It adds a sysctl configurable queue of packets that are held until an = ARP reply is received or timed out. net.link.ether.inet.maxhold Having the queue addresses a problem in modern systems where programs = that use connectionless=20 protocols for communication will suffer from dropping many packets when = they start up or when an ARP entry moves. 2) Makes the time we wait for an arp reply configurable via another = sysctl. net.link.ether.inet.wait The old, pre 8.0, ARP code would run the timer once per second. The new ARP code sets a timeout of 20 seconds on each entry. Neither value was = specified in RFC 826. As a matter of fact, RFC 826 had this to say about = timeouts: "It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol." This new code does not change the default value of either the arpqueue = (which was always 1 packet) nor does it change the new value of the ARP down = timeout. I have a different patch for 7, which I will propose after I can get = this in to HEAD and MFC'd to 8. Best, George From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 15:36:05 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A827106566C; Fri, 29 Oct 2010 15:36:05 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAF48FC19; Fri, 29 Oct 2010 15:36:03 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFGGykxbsWDm/2dsb2JhbAChU3K/FoVIBIlk Received: from 230.96-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.96.230]) by relay.skynet.be with ESMTP; 29 Oct 2010 17:36:02 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o9TFa1IP023273; Fri, 29 Oct 2010 17:36:01 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Fri, 29 Oct 2010 17:35:50 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010282331.19825.tijl@coosemans.org> <201010290940.17353.jhb@freebsd.org> In-Reply-To: <201010290940.17353.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2362348.uCLvzsYlJ3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201010291735.59702.tijl@coosemans.org> Cc: Attilio Rao , Warner Losh Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:36:05 -0000 --nextPart2362348.uCLvzsYlJ3 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday 29 October 2010 15:40:17 John Baldwin wrote: > On Thursday, October 28, 2010 5:31:09 pm Tijl Coosemans wrote: >> On Thursday 28 October 2010 16:13:02 John Baldwin wrote: >>> On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: >>>> 2010/10/27 John Baldwin : >>>>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >>>>>> This patch should convert a (simple and 100% shared between amd64 and >>>>>> i386 header) under the x86 sub-tree. Please note that in this patch I >>>>>> "svn cp" the file from sys/amd64/include/mptable.h into >>>>>> sys/x86/include/mptable.h: >>>>>> http://www.freebsd.org/~attilio/headers-x86.diff >>>>>> >>>>>> This is someway a POC, that I really want to get in. The idea is >>>>>> simple and someway follows the pc98 case (even if not entirely): the >>>>>> files under machine/include/* became just mere stubs for x86/include= /* >>>>>> contents and redirect there. >>>>>> This won't particulary help reducing the number of available files, >>>>>> but generally removing verbatim and would also be the way to go for >>>>>> handling MFCs. >>>>>> If you find this is the right way I'll commit the fix and start movi= ng >>>>>> other files as time permits. >>>>> >>>>> No, we want to do this differently because we also want this to work = in >>>>> userland. (e.g. I'd like to outright move mca.h to x86/include and t= hen >>>>> use '#include ' in both kernel and userland for it). We'd >>>>> need >>>>> some special glue to setup an 'x86' symlink during a kernel build that >>>>> points to @/x86/include as we do now to setup an 'i386' link for pc98 >>>>> kernels. >>>>> >>>>> We'd also need to install the x86 headers into /usr/include during an >>>>> installworld. Warner has some more pointers on this I think. >>>>=20 >>>> I spoke with Warner briefly about it. >>>> One question I'm having now, though, is how getting co-living of pc98 >>>> and x86 now, as we are basically overriding the same infrastructure >>>> (MACHINE_CPUARCH) in the i386/amd64 case? >>>> Do you have ideas about that? >>>=20 >>> I'm still doing testing, but this seems to be working so far. I am >>> moving mca.h as my current test. >>>=20 >>> Index: include/Makefile >>> =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 >>> --- include/Makefile (revision 214386) >>> +++ include/Makefile (working copy) >>> @@ -116,8 +116,11 @@ >>> .endfor >>> =20 >>> .if ${MACHINE} !=3D ${MACHINE_CPUARCH} >>> -_MARCH=3D${MACHINE_CPUARCH} >>> +_MARCHS=3D ${MACHINE_CPUARCH} >>> .endif >>> +.if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D "amd= 64" >>> +_MARCHS+=3D x86 >>> +.endif >>=20 >> Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98 >> cases? This patch wouldn't be needed then. >=20 > As Warner said, we aren't quite ready for that yet. However, even if we > do that, pc98 would need further help as it still needs /usr/include/i386 > installed. So that will require a code along the lines of: >=20 > .if ${MACHINE} !=3D ${MACHINE_CPUARCH} > _MARCHS=3D ${MACHINE_CPUARCH} > .endif > .if ${MACHINE} !=3D ${MACHINE_ARCH} && ${MACHINE_ARCH} !=3D ${MACHINE_CPU= ARCH} > _MARCHS+=3D ${MACHINE_ARCH} > .endif >=20 > With pc98 having MACHINE=3Dpc98, MACHINE_ARCH=3Di386, MACHINE_CPUARCH=3Dx= 86. Ok, thanks. I'm interested in this mainly because to get "cc -m32" working on amd64, i386 headers would have to be installed there as well. I sent a patch similar to yours to this list a few months ago: http://lists.freebsd.org/pipermail/freebsd-arch/2010-August/010559.html http://people.freebsd.org/~tijl/cc-m32-2.diff One of the problems I encountered was that the build of kdump generates a file that includes all headers containing ioctl definitions. Both i386 and amd64 headers got included which caused conflicts. Moving common headers under x86 would solve that. --nextPart2362348.uCLvzsYlJ3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzK6d8ACgkQfoCS2CCgtiuYfwEAha9vverIJeemVNMWgoDKA0gJ IAtmCVZBu/Nv08I86LAA/3lA1XQiA+c9JLYjn4FZ7Uw02F8wIN9rrC0Jp6wr4+0s =BPo7 -----END PGP SIGNATURE----- --nextPart2362348.uCLvzsYlJ3-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 16:02:44 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA4A1065672; Fri, 29 Oct 2010 16:02:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC508FC18; Fri, 29 Oct 2010 16:02:44 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9TFvF82044394; Fri, 29 Oct 2010 09:57:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CCAEEDB.8090804@bsdimp.com> Date: Fri, 29 Oct 2010 09:57:15 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: Tijl Coosemans References: <201010282331.19825.tijl@coosemans.org> <201010290940.17353.jhb@freebsd.org> <201010291735.59702.tijl@coosemans.org> In-Reply-To: <201010291735.59702.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , Warner Losh , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:02:44 -0000 On 10/29/2010 09:35, Tijl Coosemans wrote: > On Friday 29 October 2010 15:40:17 John Baldwin wrote: >> On Thursday, October 28, 2010 5:31:09 pm Tijl Coosemans wrote: >>> On Thursday 28 October 2010 16:13:02 John Baldwin wrote: >>>> On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote: >>>>> 2010/10/27 John Baldwin: >>>>>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote: >>>>>>> This patch should convert a (simple and 100% shared between amd64 and >>>>>>> i386 header) under the x86 sub-tree. Please note that in this patch I >>>>>>> "svn cp" the file from sys/amd64/include/mptable.h into >>>>>>> sys/x86/include/mptable.h: >>>>>>> http://www.freebsd.org/~attilio/headers-x86.diff >>>>>>> >>>>>>> This is someway a POC, that I really want to get in. The idea is >>>>>>> simple and someway follows the pc98 case (even if not entirely): the >>>>>>> files under machine/include/* became just mere stubs for x86/include/* >>>>>>> contents and redirect there. >>>>>>> This won't particulary help reducing the number of available files, >>>>>>> but generally removing verbatim and would also be the way to go for >>>>>>> handling MFCs. >>>>>>> If you find this is the right way I'll commit the fix and start moving >>>>>>> other files as time permits. >>>>>> No, we want to do this differently because we also want this to work in >>>>>> userland. (e.g. I'd like to outright move mca.h to x86/include and then >>>>>> use '#include' in both kernel and userland for it). We'd >>>>>> need >>>>>> some special glue to setup an 'x86' symlink during a kernel build that >>>>>> points to @/x86/include as we do now to setup an 'i386' link for pc98 >>>>>> kernels. >>>>>> >>>>>> We'd also need to install the x86 headers into /usr/include during an >>>>>> installworld. Warner has some more pointers on this I think. >>>>> I spoke with Warner briefly about it. >>>>> One question I'm having now, though, is how getting co-living of pc98 >>>>> and x86 now, as we are basically overriding the same infrastructure >>>>> (MACHINE_CPUARCH) in the i386/amd64 case? >>>>> Do you have ideas about that? >>>> I'm still doing testing, but this seems to be working so far. I am >>>> moving mca.h as my current test. >>>> >>>> Index: include/Makefile >>>> =================================================================== >>>> --- include/Makefile (revision 214386) >>>> +++ include/Makefile (working copy) >>>> @@ -116,8 +116,11 @@ >>>> .endfor >>>> >>>> .if ${MACHINE} != ${MACHINE_CPUARCH} >>>> -_MARCH=${MACHINE_CPUARCH} >>>> +_MARCHS= ${MACHINE_CPUARCH} >>>> .endif >>>> +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" >>>> +_MARCHS+= x86 >>>> +.endif >>> Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98 >>> cases? This patch wouldn't be needed then. >> As Warner said, we aren't quite ready for that yet. However, even if we >> do that, pc98 would need further help as it still needs /usr/include/i386 >> installed. So that will require a code along the lines of: >> >> .if ${MACHINE} != ${MACHINE_CPUARCH} >> _MARCHS= ${MACHINE_CPUARCH} >> .endif >> .if ${MACHINE} != ${MACHINE_ARCH}&& ${MACHINE_ARCH} != ${MACHINE_CPUARCH} >> _MARCHS+= ${MACHINE_ARCH} >> .endif >> >> With pc98 having MACHINE=pc98, MACHINE_ARCH=i386, MACHINE_CPUARCH=x86. > Ok, thanks. I'm interested in this mainly because to get "cc -m32" > working on amd64, i386 headers would have to be installed there as > well. I sent a patch similar to yours to this list a few months ago: > http://lists.freebsd.org/pipermail/freebsd-arch/2010-August/010559.htmlsol > http://people.freebsd.org/~tijl/cc-m32-2.diff > > One of the problems I encountered was that the build of kdump generates > a file that includes all headers containing ioctl definitions. Both > i386 and amd64 headers got included which caused conflicts. Moving > common headers under x86 would solve that. Well, mostly solve. I'd love to see the x86 family of architectures have their machine/include files look like: #ifdef PC98 #include #elif defined(i386) #include #elif defined(amd64) #error That doesn't exist here #endif for files that are common, or mostly common. That would go a long ways towards making -m32 work. Then we'd install i386, pc98 and amd64 on all x86 architectures always and install the generated files as above in machine. not sure how to specify pc98, since -m32 implies i386 not pc98... But maybe support for pc98 generated code is yet another, orthogonal problem to -m32. -mpc98 maybe needed, but the -m32 patches wouldn't be required to do that... The big drawback of this is that the kernel builds would still using the raw headers, not via the intermediary include files. While not a problem in theory, I wonder if there might be some weird edge cases that we mask doing that. Given buildworld though, I kinda doubt we'd have undetected problems for long. This is completely orthogonal to the common header problem john and atillio are trying to solve. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 17:42:36 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E5E106566C for ; Fri, 29 Oct 2010 17:42:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA218FC17 for ; Fri, 29 Oct 2010 17:42:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: Date: Fri, 29 Oct 2010 13:42:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Garrett Cooper X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: arch@freebsd.org Subject: Re: RFC: ARP Packet Queues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:42:36 -0000 On Oct 29, 2010, at 13:19 , Garrett Cooper wrote: > 1. This needs a tab after the #define for the macro: > > +#define V_arp_maxhold VNET(arp_maxhold) > OK. > 2. Is the naming convention for these sysctls always > net.link.ether imply arp, or is it another naming convention? I'm not quite sure what you're asking? ARP maps from inet to ether so net.link.ether.inet is where these are. Are you thinking about Neighbor Discovery and other such ARP like protocols for other, higher layer, protocols? > 3. Is there a reason why packets_dropped is a signed quantity, > i.e. int, not size_t, etc? I should fix that. > The rest looks ok, but I could be missing some context, or a > subtlety of some kind. I'll give this a shot on my new router box this > weekend because it looks interesting. Thanks. Be sure so increase maxtries as well as maxhold otherwise you'll be limited in how many packets you can hold. Best, George From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 17:49:25 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B291065670 for ; Fri, 29 Oct 2010 17:49:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9F48FC0A for ; Fri, 29 Oct 2010 17:49:24 +0000 (UTC) Received: by wwi18 with SMTP id 18so4409906wwi.1 for ; Fri, 29 Oct 2010 10:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8v3U+DqVeF6j30XSSr3INEY/S+0z3F4hy3NHNwYBlT8=; b=uv4rFVe/OQANlKVOMdjwBdjJEpeshkueT7fPsQuT6ZXlKWDtl3mMpYc5w1pdAGZ7gZ 2T0laP6NGIJKWdcPg7CmIDm2Y5IKRyT814FaqW9FMnCbl97B7mqj5fH74wh3cJIbZxP8 0q0ku6aKaBpFCh8wgfEF83Vxl35EgsxCqZycQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hHjRkoH7R4bYuefMz47oIHcEIQ6R5TWeC2hhKdGhMH6eBfnRhPpI4cmpdCEjR5iY+v 2SlwvWeHJ/DM7LJF1tajmTkZKXOqqf40eYRKBfTtNFJJ8/MU89ctIQpW7QfQUe8A/3JB wdzvJAmdfCpaHv05nMjeQuF0gOm5pzJP6a5NA= MIME-Version: 1.0 Received: by 10.216.36.84 with SMTP id v62mr790646wea.77.1288372789001; Fri, 29 Oct 2010 10:19:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Fri, 29 Oct 2010 10:19:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 10:19:48 -0700 X-Google-Sender-Auth: CZDzs5SO2JGub_CLRJ80H7zc4D0 Message-ID: From: Garrett Cooper To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: RFC: ARP Packet Queues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:49:25 -0000 On Fri, Oct 29, 2010 at 6:42 AM, George Neville-Neil wrote: > Howdy, > > Please review the following patch against HEAD: > > http://people.freebsd.org/~gnn/head-arpqueue.diff > > This patch makes two changes to the ARP code: > > 1) It adds a sysctl configurable queue of packets that are held until an = ARP reply is received or > timed out. > > net.link.ether.inet.maxhold > > Having the queue addresses a problem in modern systems where programs tha= t use connectionless > protocols for communication will suffer from dropping many packets when t= hey start up or when > an ARP entry moves. > > 2) Makes the time we wait for an arp reply configurable via another sysct= l. > > net.link.ether.inet.wait > > The old, pre 8.0, ARP code would run the timer once per second. =A0The ne= w > ARP code sets a timeout of 20 seconds on each entry. =A0Neither value was= specified > in RFC 826. =A0As a matter of fact, RFC 826 had this to say about timeout= s: > > "It may be desirable to have table aging and/or timeouts. =A0The > implementation of these is outside the scope of this protocol." > > This new code does not change the default value of either the arpqueue (w= hich was > always 1 packet) nor does it change the new value of the ARP down timeout= . > > I have a different patch for 7, which I will propose after I can get this= in to > HEAD and MFC'd to 8. Hi George, I'm just curious so I took at look at the patch (although I'm not really good at reviewing this section of code). 1. This needs a tab after the #define for the macro: +#define V_arp_maxhold VNET(arp_maxhold) 2. Is the naming convention for these sysctls always net.link.ether imply arp, or is it another naming convention? 3. Is there a reason why packets_dropped is a signed quantity, i.e. int, not size_t, etc? The rest looks ok, but I could be missing some context, or a subtlety of some kind. I'll give this a shot on my new router box this weekend because it looks interesting. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 19:12:00 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF1F1065670 for ; Fri, 29 Oct 2010 19:12:00 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62FA58FC13 for ; Fri, 29 Oct 2010 19:11:59 +0000 (UTC) Received: by bwz3 with SMTP id 3so2821199bwz.13 for ; Fri, 29 Oct 2010 12:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=5PsOgYJlUcY8D1HkqgEU5Zyksx1MaCw9y7dnQZinvvg=; b=naCBKwxCp+JB6MpTREFgmJ6UvHfj3mqBzZpk0xARjp2oicx6e7CqGEeU6wqIGxI4do pIjpDaiX1mDx8cQPC5gW/UTKOx7AlgVO8if0gcBuqT5SXRqkGo7W8z2m4cN6SNzyOq9u bkqnBZdW7HX/i/NbvHqTAzhJgobBcuKBbdi6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=WHLE35Opv8bRjEk3EDP1Ca1NaUiD9Dzo2GajJZyTAX16ukYfQuaAyJEq6QxP0NU3JB 4CW+eRq/Rec4yyDPJ2MOkLVqITuG8Qu//30n8AYtdtlfJ+avecLkx8yfoL+kSMzEgUo3 NEPtncFadKaZ6QnXVTfrH/XvJNuleb9AiUXas= Received: by 10.204.180.75 with SMTP id bt11mr2099358bkb.115.1288377886679; Fri, 29 Oct 2010 11:44:46 -0700 (PDT) Received: from [192.168.1.102] (45.81.datacomsa.pl [195.34.81.45]) by mx.google.com with ESMTPS id t10sm1086875bkj.4.2010.10.29.11.44.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 11:44:45 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Oct 2010 20:44:40 +0200 Message-Id: <7CE78D72-F349-443B-A635-8DC7B970C2E0@freebsd.org> To: "arch@" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Adapting FreeBSD to PSARC/2010/029. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 19:12:00 -0000 Currently, NFSv4 ACLs support in FreeBSD adheres to a draft by Sam Falkner (it also complies with RFC3530, but that one leaves many things undefined). Semantics for both UFS and ZFS is exactly the same. With ZFS v28, the semantics has changed; see the link below for details: http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum In short, the semantics is simplified - "weird stuff" no longer happens after chmod, entries don't get duplicated during inheritance, and trivial ACLs no longer contain three "DENY" entries, which is also more friendly to MS Windows. Patch below makes UFS comply with the new semantics instead of Falkner's draft. It's controlled by sysctl and disabled by default; to enable, set vfs.acl_nfs4_old_semantics to 0. Review is welcome. I'd like to commit it as soon as I finish writing regression tests, with the new semantics disabled by default. I plan to change the default after ZFS v28 gets committed to CURRENT, to keep UFS and ZFS in sync. http://people.freebsd.org/~trasz/acl-psarc-2.diff -- If you cut off my head, what would I say? Me and my head, or me and my body? From owner-freebsd-arch@FreeBSD.ORG Sat Oct 30 05:49:12 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35F31065673 for ; Sat, 30 Oct 2010 05:49:12 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 942CF8FC18 for ; Sat, 30 Oct 2010 05:49:12 +0000 (UTC) Received: from [10.123.2.178] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o9U5HCSO016521; Sat, 30 Oct 2010 05:17:12 GMT (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Tim Kientzle In-Reply-To: <7CE78D72-F349-443B-A635-8DC7B970C2E0@freebsd.org> Date: Fri, 29 Oct 2010 22:17:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C4615AC-7F1F-4486-A431-500535B79B2E@kientzle.com> References: <7CE78D72-F349-443B-A635-8DC7B970C2E0@freebsd.org> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1081) Cc: "arch@" Subject: Re: Adapting FreeBSD to PSARC/2010/029. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 05:49:12 -0000 On Oct 29, 2010, at 11:44 AM, Edward Tomasz Napiera=C5=82a wrote: > Currently, NFSv4 ACLs support in FreeBSD adheres to a draft by Sam = Falkner > (it also complies with RFC3530, but that one leaves many things = undefined). > Semantics for both UFS and ZFS is exactly the same. With ZFS v28, the > semantics has changed; see the link below for details: >=20 > = http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbau= m I guess I need to get back to work on the NFSv4 ACL support for = libarchive, eh? This is great. Together with the acl_is_trivial_np() test function, the = ACL support now makes a lot more sense. The chmod(2) interaction, in particular, is a huge improvement. Tim