From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 00:38:03 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CE816A427; Sun, 28 Aug 2005 00:38:03 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AEED43DBC; Sun, 28 Aug 2005 00:15:52 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7S0Fonm007381 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 28 Aug 2005 10:15:51 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7S0FoSR070294; Sun, 28 Aug 2005 10:15:50 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7S0FoCv070293; Sun, 28 Aug 2005 10:15:50 +1000 (EST) (envelope-from pjeremy) Date: Sun, 28 Aug 2005 10:15:50 +1000 From: Peter Jeremy To: Colin Percival Message-ID: <20050828001550.GO37107@cirb503493.alcatel.com.au> References: <4310D819.9080903@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4310D819.9080903@freebsd.org> User-Agent: Mutt/1.4.2i Cc: freebsd-arch@freebsd.org Subject: Re: portsnap base thought 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: Sun, 28 Aug 2005 00:38:03 -0000 On Sat, 2005-Aug-27 14:16:09 -0700, Colin Percival wrote: >Given that portsnap currently only has about 1500-2000 users I'd suggest that is a reasonable userbase and the sooner the portsnap database is on the release CDs, the quicker it will grow. > it doesn't seem reasonable to make major changes to how releases >are done yet; but assuming the usage of portsnap increases significantly >over the next year, this is certainly something to consider for 7.0-R. I agree it's too late for 6.0-R but I don't see why this needs to wait for 7.0. As I see it, the prerequisites are: - Find ~7MB additional space on -RELEASE disk 1 (probably the hardest) - Add the tools to build /var/db/portsnap and /usr/ports/.portsnap.INDEX into "make release" (and remove ports.tgz) - Teach sysinstall to unpack the ports tree from /var/db/portsnap (or maybe just invoke portsnap) I don't think any of these amount to "major changes". The portsnap binaries will be in 6.0 so I don't see a serious problem with switching to portsnap in 6.1. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 06:25:12 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D546C16A41F for ; Sun, 28 Aug 2005 06:25:12 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FAEA43D45 for ; Sun, 28 Aug 2005 06:25:12 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j7S6P5xe077518; Sun, 28 Aug 2005 02:25:11 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 28 Aug 2005 02:25:05 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Brooks Davis In-Reply-To: <20050827170600.GB14720@odin.ac.hmc.edu> Message-ID: <20050828022351.F63789@sasami.jurai.net> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2064422761-1125210305=:63789" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Sun, 28 Aug 2005 02:25:11 -0400 (EDT) Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application 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: Sun, 28 Aug 2005 06:25:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2064422761-1125210305=:63789 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 27 Aug 2005, Brooks Davis wrote: > I'd like to see dhclient-script pull in /etc/rc.conf. Attached. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 --0-2064422761-1125210305=:63789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dhclient-script.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20050828022505.P63789@sasami.jurai.net> Content-Description: Content-Disposition: attachment; filename="dhclient-script.patch" SW5kZXg6IHNiaW4vZGhjbGllbnQvZGhjbGllbnQtc2NyaXB0DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL3NyYy9zYmlu L2RoY2xpZW50L2RoY2xpZW50LXNjcmlwdCx2DQpyZXRyaWV2aW5nIHJldmlz aW9uIDEuOA0KZGlmZiAtdSAtdSAtcjEuOCBkaGNsaWVudC1zY3JpcHQNCi0t LSBzYmluL2RoY2xpZW50L2RoY2xpZW50LXNjcmlwdAkyNiBBdWcgMjAwNSAy MDozMTowNCAtMDAwMAkxLjgNCisrKyBzYmluL2RoY2xpZW50L2RoY2xpZW50 LXNjcmlwdAkyOCBBdWcgMjAwNSAwNjowMjoxNiAtMDAwMA0KQEAgLTE5LDYg KzE5LDkgQEANCiAjDQogIw0KIA0KKy4gL2V0Yy9yYy5zdWJyDQorbG9hZF9y Y19jb25maWcgZGhjbGllbnQtc2NyaXB0DQorDQogTkVUU1RBVD0vdXNyL2Jp bi9uZXRzdGF0DQogQVdLPS91c3IvYmluL2F3aw0KIEhPU1ROQU1FPS9iaW4v aG9zdG5hbWUNCkBAIC0xMjcsNiArMTMwLDIzIEBADQogCWZpDQogfQ0KIA0K K21ha2VfbmFtZWRfZm9yd2FyZGVycygpIHsNCisJaWYgWyAteiAiJG5ld19k b21haW5fbmFtZV9zZXJ2ZXJzIiBdOyB0aGVuDQorCQlyZXR1cm4gMQ0KKwlm aQ0KKw0KKwlybSAtZiAvdmFyL3J1bi9uYW1lZC5mb3J3YXJkZXJzDQorCWVj aG8gIglmb3J3YXJkZXJzIHsiID4gL3Zhci9ydW4vbmFtZWQuZm9yd2FyZGVy cw0KKwlmb3IgbmFtZXNlcnZlciBpbiAkbmV3X2RvbWFpbl9uYW1lX3NlcnZl cnM7IGRvDQorCQllY2hvICIJCSRuYW1lc2VydmVyOyIgPj4gL3Zhci9ydW4v bmFtZWQuZm9yd2FyZGVycw0KKwlkb25lDQorCWVjaG8gIgl9OyIgPj4gL3Zh ci9ydW4vbmFtZWQuZm9yd2FyZGVycw0KKw0KKwljZCAvZXRjL25hbWVkYiAm JiBtYWtlIC1mIG1ha2UtbmFtZWQuY29uZg0KKw0KKwlyZXR1cm4gMA0KK30N CisNCiBhZGRfbmV3X3Jlc29sdl9jb25mKCkgew0KIAkjIFhYWCBPbGQgY29k ZSBkaWQgbm90IGNyZWF0ZS91cGRhdGUgcmVzb2x2LmNvbmYgdW5sZXNzIGJv dGgNCiAJIyAkbmV3X2RvbWFpbl9uYW1lIGFuZCAkbmV3X2RvbWFpbl9uYW1l X3NlcnZlcnMgd2VyZSBwcm92aWRlZC4gIFBSDQpAQCAtMjM4LDcgKzI1OCwx MiBAQA0KIAlpZiBbICIkbmV3X2lwX2FkZHJlc3MiICE9ICIkYWxpYXNfaXBf YWRkcmVzcyIgXTsgdGhlbg0KIAkJYWRkX25ld19hbGlhcw0KIAlmaQ0KLQlh ZGRfbmV3X3Jlc29sdl9jb25mDQorCWlmIGNoZWNreWVzbm8gZGhjbGllbnRf c2NyaXB0X3Jlc29sdl9jb25mOyB0aGVuDQorCQlhZGRfbmV3X3Jlc29sdl9j b25mDQorCWZpDQorCWlmIGNoZWNreWVzbm8gZGhjbGllbnRfc2NyaXB0X25h bWVkX2ZvcndhcmRlcnM7IHRoZW4NCisJCW1ha2VfbmFtZWRfZm9yd2FyZGVy cw0KKwlmaQ0KIAk7Ow0KIA0KIEVYUElSRXxGQUlMKQ0KQEAgLTI2Niw4ICsy OTEsMTMgQEANCiAJCQkJYWRkX25ld19hbGlhcw0KIAkJCWZpDQogCQkJYWRk X25ld19yb3V0ZXMNCi0JCQlpZiBhZGRfbmV3X3Jlc29sdl9jb25mOyB0aGVu DQotCQkJCWV4aXRfd2l0aF9ob29rcyAwDQorCQkJaWYgY2hlY2t5ZXNubyBk aGNsaWVudF9zY3JpcHRfbmFtZWRfZm9yd2FyZGVyczsgdGhlbg0KKwkJCQlt YWtlX25hbWVkX2ZvcndhcmRlcnMNCisJCQlmaQ0KKwkJCWlmIGNoZWNreWVz bm8gZGhjbGllbnRfc2NyaXB0X3Jlc29sdl9jb25mOyB0aGVuDQorCQkJCWlm IGFkZF9uZXdfcmVzb2x2X2NvbmY7IHRoZW4NCisJCQkJCWV4aXRfd2l0aF9o b29rcyAwDQorCQkJCWZpDQogCQkJZmkNCiAJCWZpDQogCWZpDQpJbmRleDog ZXRjL2RlZmF1bHRzL3JjLmNvbmYNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvaG9tZS9jdnMvc3JjL2V0Yy9kZWZhdWx0cy9yYy5jb25m LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNTkNCmRpZmYgLXUgLXUgLXIx LjI1OSByYy5jb25mDQotLS0gZXRjL2RlZmF1bHRzL3JjLmNvbmYJMjQgQXVn IDIwMDUgMTY6MjU6NDcgLTAwMDAJMS4yNTkNCisrKyBldGMvZGVmYXVsdHMv cmMuY29uZgkyOCBBdWcgMjAwNSAwNTo0NjoxOCAtMDAwMA0KQEAgLTkzLDYg KzkzLDkgQEANCiBuaXNkb21haW5uYW1lPSJOTyIJCSMgU2V0IHRvIE5JUyBk b21haW4gaWYgdXNpbmcgTklTIChvciBOTykuDQogZGhjbGllbnRfcHJvZ3Jh bT0iL3NiaW4vZGhjbGllbnQiCSMgUGF0aCB0byBkaGNwIGNsaWVudCBwcm9n cmFtLg0KIGRoY2xpZW50X2ZsYWdzPSIiCQkjIEFkZGl0aW9uYWwgZmxhZ3Mg dG8gcGFzcyB0byBkaGNwIGNsaWVudC4NCitkaGNsaWVudF9zY3JpcHRfcmVz b2x2X2NvbmY9IllFUyIJIyBVcGRhdGUgL2V0Yy9yZXNvbHYuY29uZg0KK2Ro Y2xpZW50X3NjcmlwdF9uYW1lZF9mb3J3YXJkZXJzPSJOTyIJIyBVcGRhdGUg L3Zhci9ydW4vbmFtZWQuZm9yd2FyZGVycyBhbmQNCisJCQkJCSMgcmVidWls ZCAvZXRjL25hbWVkYi9uYW1lZC5jb25mDQogYmFja2dyb3VuZF9kaGNsaWVu dD0iTk8iCSMgU3RhcnQgZGhjcCBjbGllbnQgaW4gdGhlIGJhY2tncm91bmQu DQogZmlyZXdhbGxfZW5hYmxlPSJOTyIJCSMgU2V0IHRvIFlFUyB0byBlbmFi bGUgZmlyZXdhbGwgZnVuY3Rpb25hbGl0eQ0KIGZpcmV3YWxsX3NjcmlwdD0i L2V0Yy9yYy5maXJld2FsbCIgIyBXaGljaCBzY3JpcHQgdG8gcnVuIHRvIHNl dCB1cCB0aGUgZmlyZXdhbGwNCkluZGV4OiBldGMvbmFtZWRiL01ha2VmaWxl DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3Zz L3NyYy9ldGMvbmFtZWRiL01ha2VmaWxlLHYNCnJldHJpZXZpbmcgcmV2aXNp b24gMS40DQpkaWZmIC11IC11IC1yMS40IE1ha2VmaWxlDQotLS0gZXRjL25h bWVkYi9NYWtlZmlsZQkyMSBEZWMgMjAwNCAwODo0Njo1MCAtMDAwMAkxLjQN CisrKyBldGMvbmFtZWRiL01ha2VmaWxlCTI4IEF1ZyAyMDA1IDA2OjE0OjUw IC0wMDAwDQpAQCAtMSw3ICsxLDcgQEANCi0jICRGcmVlQlNEJA0KKyMgJEZy ZWVCU0Q6IHNyYy9ldGMvbmFtZWRiL01ha2VmaWxlLHYgMS40IDIwMDQvMTIv MjEgMDg6NDY6NTAgcnUgRXhwICQNCiANCiBGSUxFUz0JUFJPVE8ubG9jYWxo b3N0LnJldiBQUk9UTy5sb2NhbGhvc3QtdjYucmV2IG5hbWVkLmNvbmYgbmFt ZWQucm9vdCBcDQotCW1ha2UtbG9jYWxob3N0DQorCW1ha2UtbG9jYWxob3N0 IG1ha2UtbmFtZWQuY29uZg0KIE5PX09CSj0NCiBGSUxFU0RJUj0gL2V0Yy9u YW1lZGINCiBGSUxFU01PREU9IDY0NA0KSW5kZXg6IGV0Yy9uYW1lZGIvbWFr ZS1uYW1lZC5jb25mDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls ZTogZXRjL25hbWVkYi9tYWtlLW5hbWVkLmNvbmYNCmRpZmYgLU4gZXRjL25h bWVkYi9tYWtlLW5hbWVkLmNvbmYNCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3 MCAwMDowMDowMCAtMDAwMA0KKysrIGV0Yy9uYW1lZGIvbWFrZS1uYW1lZC5j b25mCTI4IEF1ZyAyMDA1IDA1OjU5OjEyIC0wMDAwDQpAQCAtMCwwICsxLDE3 IEBADQorIyAkRnJlZUJTRCQNCisjDQorDQorIw0KKyMgTW92ZSAvZXRjL25h bWVkLmNvbmYgdG8gL2V0Yy9uYW1lZC5jb25mLmluIGFuZCBhZGQgdGhlIGZv bGxvd2luZw0KKyMgbGluZXMgdG8gdGhlIG9wdGlvbnMgc2VjdGlvbi4NCisj DQorIwlmb3J3YXJkIG9ubHk7DQorIyAjaW5jbHVkZSAiL3Zhci9ydW4vbmFt ZWQuZm9yd2FyZGVycyINCisjDQorDQorbmFtZWQuY29uZjogbmFtZWQuY29u Zi5pbiAvdmFyL3J1bi9uYW1lZC5mb3J3YXJkZXJzDQorCWNwcCAtUCAtQyBu YW1lZC5jb25mLmluID4gJEANCisJL2V0Yy9yYy5kL25hbWVkIHJlc3RhcnQN CisNCisvdmFyL3J1bi9uYW1lZC5mb3J3YXJkZXJzOg0KKwlAdG91Y2ggL3Zh ci9ydW4vbmFtZWQuZm9yd2FyZGVycw0K --0-2064422761-1125210305=:63789-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 07:36:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D9316A41F; Sun, 28 Aug 2005 07:36:22 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id C19CB43D45; Sun, 28 Aug 2005 07:36:21 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j7S7a9BD023483; Sun, 28 Aug 2005 17:36:09 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j7S7a2ZT002428; Sun, 28 Aug 2005 17:36:07 +1000 Date: Sun, 28 Aug 2005 17:36:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Craig Rodrigues In-Reply-To: <20050827235140.GA3063@crodrigues.org> Message-ID: <20050828172712.T86328@delplex.bde.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> <20050827235140.GA3063@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? 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: Sun, 28 Aug 2005 07:36:22 -0000 On Sat, 27 Aug 2005, Craig Rodrigues wrote: > On Tue, Aug 09, 2005 at 08:23:08PM -0700, David O'Brien wrote: >> This is a GCC bug that I am working to get fixed. > > Did you try something like this patch to GCC? > > Index: c-decl.c > =================================================================== > RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v > retrieving revision 1.630.6.16 > diff -u -u -r1.630.6.16 c-decl.c > --- c-decl.c 16 Aug 2005 20:34:19 -0000 1.630.6.16 > +++ c-decl.c 27 Aug 2005 23:43:06 -0000 > @@ -1559,7 +1559,10 @@ > && !(DECL_EXTERNAL (olddecl) && !DECL_EXTERNAL (newdecl)) > /* Don't warn about forward parameter decls. */ > && !(TREE_CODE (newdecl) == PARM_DECL > - && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl))) > + && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl)) > + /* Don't warn about forward static variable decls. */ > + && !(TREE_CODE (newdecl) == VAR_DECL > + && !TREE_PUBLIC (olddecl) && !TREE_PUBLIC (newdecl))) > { > warning ("%Jredundant redeclaration of %qD", newdecl, newdecl); > warned = true; It should warn about static variable decls iff they are redundant. This requires determining if the new declaration adds info. I couldn't find any macros to help determine this, not even ones to say if the new declaration has an initializer and the old one doesn't. Also, it shouldn't say that a redundant decl is a "redundant redeclaration". All (identical) redeclarations are redundant, but not all redundancies are caused by (identical) redeclarations. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 08:20:40 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1812416A41F for ; Sun, 28 Aug 2005 08:20:40 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8FCD43D45 for ; Sun, 28 Aug 2005 08:20:39 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ILX007U6B6FRH70@l-daemon> for freebsd-arch@freebsd.org; Sun, 28 Aug 2005 02:20:39 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ILX008BSB6FK580@pd4mr5so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sun, 28 Aug 2005 02:20:39 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ILX0010YB6EG2@l-daemon> for freebsd-arch@freebsd.org; Sun, 28 Aug 2005 02:20:39 -0600 (MDT) Date: Sun, 28 Aug 2005 01:20:38 -0700 From: Colin Percival In-reply-to: <20050828001550.GO37107@cirb503493.alcatel.com.au> To: Peter Jeremy Message-id: <431173D6.4020709@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.92.0.0 References: <4310D819.9080903@freebsd.org> <20050828001550.GO37107@cirb503493.alcatel.com.au> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: freebsd-arch@freebsd.org Subject: Re: portsnap base thought 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: Sun, 28 Aug 2005 08:20:40 -0000 Peter Jeremy wrote: > On Sat, 2005-Aug-27 14:16:09 -0700, Colin Percival wrote: >>Given that portsnap currently only has about 1500-2000 users > > I'd suggest that is a reasonable userbase and the sooner the portsnap > database is on the release CDs, the quicker it will grow. I entirely agree. >>it doesn't seem reasonable to make major changes to how releases >>are done yet; but assuming the usage of portsnap increases significantly >>over the next year, this is certainly something to consider for 7.0-R. > > I agree it's too late for 6.0-R but I don't see why this needs to wait > for 7.0. As I see it, the prerequisites are: > - Find ~7MB additional space on -RELEASE disk 1 (probably the hardest) Now that disk 1 doesn't contain any packages, I think this part is easy. > - Add the tools to build /var/db/portsnap and /usr/ports/.portsnap.INDEX > into "make release" (and remove ports.tgz) > - Teach sysinstall to unpack the ports tree from /var/db/portsnap (or > maybe just invoke portsnap) Getting sysinstall to install /var/db/portsnap and its contents would not be very hard, but getting a copy which corresponds to the release tag would take a bit of work, since portsnap builds don't take any notice of CVS tags. > I don't think any of these amount to "major changes". The portsnap > binaries will be in 6.0 so I don't see a serious problem with > switching to portsnap in 6.1. My biggest concern with doing this in a minor release is the question of removing ports.tgz. That tarball has been on the release CDs for an awfully long time, and I'm sure there are people who will be quite astonished if it suddenly disappears. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 11:01:02 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C86D16A41F; Sun, 28 Aug 2005 11:01:02 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id E838243D45; Sun, 28 Aug 2005 11:00:59 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7SB0vbH028308 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 28 Aug 2005 21:00:58 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7SB0uSR070939; Sun, 28 Aug 2005 21:00:57 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7SB0umJ070938; Sun, 28 Aug 2005 21:00:56 +1000 (EST) (envelope-from pjeremy) Date: Sun, 28 Aug 2005 21:00:55 +1000 From: Peter Jeremy To: Colin Percival Message-ID: <20050828110055.GP37107@cirb503493.alcatel.com.au> References: <4310D819.9080903@freebsd.org> <20050828001550.GO37107@cirb503493.alcatel.com.au> <431173D6.4020709@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431173D6.4020709@freebsd.org> User-Agent: Mutt/1.4.2i Cc: freebsd-arch@freebsd.org Subject: Re: portsnap base thought 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: Sun, 28 Aug 2005 11:01:02 -0000 On Sun, 2005-Aug-28 01:20:38 -0700, Colin Percival wrote: >Peter Jeremy wrote: >> - Find ~7MB additional space on -RELEASE disk 1 (probably the hardest) > >Now that disk 1 doesn't contain any packages, I think this part is easy. I missed the package removal. That would seem to simplify things a bit. >My biggest concern with doing this in a minor release is the question of >removing ports.tgz. That tarball has been on the release CDs for an awfully >long time, and I'm sure there are people who will be quite astonished if it >suddenly disappears. Since there's space, include both in 6.x, with ports.tgz marked as deprecated. If you consider 6.0 to be an "early adopter's" release, you can probably get away with claiming that ports.tgz has been deprecated for the 6.x tree and can therefore be dropped in 7.x (in line with Project guidelines for feature deprecation). -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:46:47 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9528416A420 for ; Tue, 30 Aug 2005 01:46:47 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D3E43D46 for ; Tue, 30 Aug 2005 01:46:46 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mr8so.prod.shaw.ca (pd5mr8so-qfe3.prod.shaw.ca [10.0.141.184]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IM0004G4I9YPP60@l-daemon> for freebsd-arch@freebsd.org; Mon, 29 Aug 2005 19:46:46 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd5mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IM000CBMI9YS1J0@pd5mr8so.prod.shaw.ca> for freebsd-arch@freebsd.org; Mon, 29 Aug 2005 19:46:46 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IM00072JI9XX8@l-daemon> for freebsd-arch@freebsd.org; Mon, 29 Aug 2005 19:46:46 -0600 (MDT) Date: Mon, 29 Aug 2005 18:46:45 -0700 From: Colin Percival In-reply-to: <20050828110055.GP37107@cirb503493.alcatel.com.au> To: Peter Jeremy Message-id: <4313BA85.9050809@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.92.0.0 References: <4310D819.9080903@freebsd.org> <20050828001550.GO37107@cirb503493.alcatel.com.au> <431173D6.4020709@freebsd.org> <20050828110055.GP37107@cirb503493.alcatel.com.au> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: freebsd-arch@freebsd.org Subject: Re: portsnap base thought 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, 30 Aug 2005 01:46:47 -0000 Peter Jeremy wrote: > On Sun, 2005-Aug-28 01:20:38 -0700, Colin Percival wrote: >>My biggest concern with doing this in a minor release is the question of >>removing ports.tgz. That tarball has been on the release CDs for an awfully >>long time, and I'm sure there are people who will be quite astonished if it >>suddenly disappears. > > Since there's space, include both in 6.x, with ports.tgz marked as > deprecated. If you consider 6.0 to be an "early adopter's" release, > you can probably get away with claiming that ports.tgz has been > deprecated for the 6.x tree and can therefore be dropped in 7.x As far as I know, there are no plans for 6.0 to be declared an "early adopter's" release. As always, such announcements can only come from the release engineering team, but the last I've heard is that the 6-STABLE branch will start with 6.0-RELEASE. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 07:55:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5C2416A420 for ; Tue, 30 Aug 2005 07:55:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BF4143D49 for ; Tue, 30 Aug 2005 07:55:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 80823 invoked by uid 399); 30 Aug 2005 07:55:31 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 30 Aug 2005 07:55:31 -0000 Received: (qmail 2924 invoked by uid 399); 30 Aug 2005 07:55:31 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 30 Aug 2005 07:55:31 -0000 Message-ID: <431410F1.7020509@FreeBSD.org> Date: Tue, 30 Aug 2005 00:55:29 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050829) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-arch@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ip6.int deprecated 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, 30 Aug 2005 07:55:33 -0000 [ -hackers and -arch cc'ed to try and get a wide audience for this. Please pick the one list that is most appropriate for any topics you want to follow up on. Thanks. ] Howdy, RFC 4159 was published today, which officially deprecates ip6.int. You can find the full text at http://www.rfc-editor.org/rfc/rfc4159.txt. Here is a relevant excerpt: In August 2001 the IETF published [RFC3152], which advised that the use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses to DNS names was deprecated. The document noted that the use of "ip6.int" would be phased out in an orderly fashion. As of 1 September 2005, the IETF advises the community that the DNS domain "ip6.int" should no longer be used to perform reverse mapping of IPv6 addresses to domain names, and that the domain "ip6.arpa" should be used henceforth, in accordance with the IANA Considerations described in [RFC3596]. The domain "ip6.int" is deprecated, and its use in IPv6 implementations that conform to the IPv6 Internet Standards is discontinued. The one step I'm going to take directly to support this deprecation is to remove the ip6.int example from the sample named.conf file in the base. I'm sending this message to provide notice of that, and notice to the community generally that we should start moving in the direction of deprecating ip6.int wherever it might be found. For those not aware of the history, ip6.int was the first stab at creating a reverse DNS zone for IP version 6. Eventually, the "issues" surrounding this topic were sorted out, and it was agreed to do reverse DNS in IPv6 in .arpa instead. Unfortunately, that left a lot of early adopters in a difficult position, and so the various players in the game (ICANN, the Regional Internet Registries, etc.) have been supporting both zones since 2001. In order to reduce the workload associated with this issue, and in order to encourage complete migration to ip6.arpa before wide deployment of IPv6 (and I'm sure for a lot of other reasons), the decision was made to officially deprecate ip6.int from the IETF perspective. Other than some old references in src/contrib/bind9, the only place I see a reference to ip6.int in our base is in the named.conf file that I mentioned above. I hope that this note is useful however as a more general source of information, and of course if there is anything I've missed, I welcome others to take appropriate action. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 08:30:55 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DEA616A41F; Tue, 30 Aug 2005 08:30:55 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE48843D46; Tue, 30 Aug 2005 08:30:54 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1EA1W8-000Ikd-4h; Tue, 30 Aug 2005 12:30:52 +0400 Message-ID: <4314193B.80208@FreeBSD.org> Date: Tue, 30 Aug 2005 12:30:51 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: standards@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: standards/85090: [patch] add memalign() and posix_memalign() functions 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, 30 Aug 2005 08:30:55 -0000 Could I hear some comments, need we a memalign() function or not? -- Sem. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 14:44:41 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDCDF16A420; Tue, 30 Aug 2005 14:44:41 +0000 (GMT) (envelope-from JermaineMcbride@photonwebhosting.com) Received: from host-84-9-16-223.bulldogdsl.com (host-84-9-16-223.bulldogdsl.com [84.9.16.223]) by mx1.FreeBSD.org (Postfix) with SMTP id B6F1443D45; Tue, 30 Aug 2005 14:44:28 +0000 (GMT) (envelope-from JermaineMcbride@photonwebhosting.com) Received: (from JermaineMcbride@photonwebhosting.com) by JermaineMcbride@photonwebhosting.com.ac.za (7.11.6/0.11.0) id g826Fa430261 for JermaineMcbride@photonwebhosting.com; Tue, 30 Aug 2005 08:33:50 -0700 Message-Id: From: "Salvador Waters" Date: Tue, 30 Aug 2005 14:35:50 -0100 To: freebsd-arch@freebsd.org User-Agent: Mutt/1.2.5.1i Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Windows XP + Office XP 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, 30 Aug 2005 14:44:43 -0000 [1][sdfsdfsdf.sdfsdf] References 1. http://kretomusta.info/usa/ From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 17:02:36 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 926DB16A41F; Tue, 30 Aug 2005 17:02:36 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B02B43D46; Tue, 30 Aug 2005 17:02:35 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7UH2Z2i021950; Tue, 30 Aug 2005 12:02:35 -0500 (CDT) (envelope-from dan) Date: Tue, 30 Aug 2005 12:02:35 -0500 From: Dan Nelson To: Sergey Matveychuk Message-ID: <20050830170235.GB4337@dan.emsphone.com> References: <4314193B.80208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4314193B.80208@FreeBSD.org> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org, standards@freebsd.org Subject: Re: standards/85090: [patch] add memalign() and posix_memalign() functions 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, 30 Aug 2005 17:02:36 -0000 In the last episode (Aug 30), Sergey Matveychuk said: > Could I hear some comments, need we a memalign() function or not? Our malloc already aligns pretty well. Blocks < 16 bytes are aligned to 16 bytes. Blocks from 16 to pagesize are aligned to powers of two (rounded up), and blocks greater than pagesize are aligned to pagesize. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 02:09:38 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F12A016A41F; Wed, 31 Aug 2005 02:09:37 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0440343D48; Wed, 31 Aug 2005 02:09:35 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:2eHbhZwaIgDo2Sydkd9PkM8205jAVq/2DsXz60tdO2bPgF2z8Zr9R6zsSpdWUgcd@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j7V29LJV088412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 11:09:27 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 31 Aug 2005 11:09:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Doug Barton In-Reply-To: <431410F1.7020509@FreeBSD.org> References: <431410F1.7020509@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 31 Aug 2005 11:09:29 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: ip6.int deprecated 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, 31 Aug 2005 02:09:38 -0000 Hi, >>>>> On Tue, 30 Aug 2005 00:55:29 -0700 >>>>> Doug Barton said: dougb> The one step I'm going to take directly to support this deprecation is to dougb> remove the ip6.int example from the sample named.conf file in the base. I'm dougb> sending this message to provide notice of that, and notice to the community dougb> generally that we should start moving in the direction of deprecating dougb> ip6.int wherever it might be found. I think it's a time to nuke RFC 1886 example from our named.conf. dougb> Other than some old references in src/contrib/bind9, the only place I see a dougb> reference to ip6.int in our base is in the named.conf file that I mentioned dougb> above. I hope that this note is useful however as a more general source of dougb> information, and of course if there is anything I've missed, I welcome dougb> others to take appropriate action. Yes, there were ip6.int. lookups in our libc. But, I nuked them already about one year ago. I left named.conf as is intentionally at the time to help the boxes which don't support RFC 3152. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 08:14:35 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A181716A41F; Wed, 31 Aug 2005 08:14:35 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD9CC43D46; Wed, 31 Aug 2005 08:14:34 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1EANjn-0001SE-TD; Wed, 31 Aug 2005 12:14:28 +0400 Message-ID: <431566E3.5040606@FreeBSD.org> Date: Wed, 31 Aug 2005 12:14:27 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Nelson References: <4314193B.80208@FreeBSD.org> <20050830170235.GB4337@dan.emsphone.com> In-Reply-To: <20050830170235.GB4337@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, standards@freebsd.org Subject: Re: standards/85090: [patch] add memalign() and posix_memalign() functions 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, 31 Aug 2005 08:14:35 -0000 Dan Nelson wrote: > In the last episode (Aug 30), Sergey Matveychuk said: > >>Could I hear some comments, need we a memalign() function or not? > > > Our malloc already aligns pretty well. Blocks < 16 bytes are aligned > to 16 bytes. Blocks from 16 to pagesize are aligned to powers of two > (rounded up), and blocks greater than pagesize are aligned to pagesize. > Yes, I know. But if programmer needs some special align? There is posix_memalign() in standard (as extension). Need we posix_memalign() then? -- Sem. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 10:21:13 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56B3416A41F; Wed, 31 Aug 2005 10:21:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FB543D46; Wed, 31 Aug 2005 10:21:12 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 0F09A319E27; Wed, 31 Aug 2005 12:21:12 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 90883405A; Wed, 31 Aug 2005 12:21:30 +0200 (CEST) Date: Wed, 31 Aug 2005 12:21:30 +0200 From: Jeremie Le Hen To: Doug Barton Message-ID: <20050831102130.GE659@obiwan.tataz.chchile.org> References: <431410F1.7020509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431410F1.7020509@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: ip6.int deprecated 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, 31 Aug 2005 10:21:13 -0000 Hi Doug, On Tue, Aug 30, 2005 at 12:55:29AM -0700, Doug Barton wrote: > [...] > > Other than some old references in src/contrib/bind9, the only place I see a > reference to ip6.int in our base is in the named.conf file that I mentioned > above. I hope that this note is useful however as a more general source of > information, and of course if there is anything I've missed, I welcome > others to take appropriate action. I think however it would be worth adding a small note in a manpage (I can't think of which, named.conf(5) isn't an option since this is an imported software) telling that ip6.int is deprecated in favor to ip6.arpa, this would prevent some traffic on -net@. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 11:27:31 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8237416A41F for ; Wed, 31 Aug 2005 11:27:31 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A94E43D48 for ; Wed, 31 Aug 2005 11:27:30 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (sccrmhc13) with ESMTP id <20050831112729013004ree2e>; Wed, 31 Aug 2005 11:27:30 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j7VBRPve055406; Wed, 31 Aug 2005 07:27:25 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j7VBROrJ055405; Wed, 31 Aug 2005 07:27:24 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 31 Aug 2005 07:27:20 -0400 From: Craig Rodrigues To: Bruce Evans Message-ID: <20050831112720.GA55376@crodrigues.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> <20050827235140.GA3063@crodrigues.org> <20050828172712.T86328@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050828172712.T86328@delplex.bde.org> User-Agent: Mutt/1.5.9i Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? 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, 31 Aug 2005 11:27:31 -0000 On Sun, Aug 28, 2005 at 05:36:01PM +1000, Bruce Evans wrote: > It should warn about static variable decls iff they are redundant. This > requires determining if the new declaration adds info. I couldn't find > any macros to help determine this, not even ones to say if the new > declaration has an initializer and the old one doesn't. DECL_INITIAL is the macro to tell if a node is part of an initializer or not. I updated the patch to GCC to use DECL_INITIAL and submitted a testcase here: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01812.html -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 12:32:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA1E16A41F for ; Wed, 31 Aug 2005 12:32:32 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4ADF43D46 for ; Wed, 31 Aug 2005 12:32:31 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j7VCWBo7006989; Wed, 31 Aug 2005 22:32:11 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j7VCW8JO026584; Wed, 31 Aug 2005 22:32:10 +1000 Date: Wed, 31 Aug 2005 22:32:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Craig Rodrigues In-Reply-To: <20050831112720.GA55376@crodrigues.org> Message-ID: <20050831215640.S1678@epsplex.bde.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> <20050827235140.GA3063@crodrigues.org> <20050828172712.T86328@delplex.bde.org> <20050831112720.GA55376@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? 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, 31 Aug 2005 12:32:32 -0000 On Wed, 31 Aug 2005, Craig Rodrigues wrote: > On Sun, Aug 28, 2005 at 05:36:01PM +1000, Bruce Evans wrote: >> It should warn about static variable decls iff they are redundant. This >> requires determining if the new declaration adds info. I couldn't find >> any macros to help determine this, not even ones to say if the new >> declaration has an initializer and the old one doesn't. > > DECL_INITIAL is the macro to tell if a node is part of an > initializer or not. Ah. I see that gcc already uses this macro a lot for similar things and not just for warnings -- changing the initializer from its default of 0 (when there is no explicit initializer) to a non default require checking whether the previous initializer is the default since there cannot be more than 1 explicit initializer. > I updated the patch to GCC to use DECL_INITIAL and submitted a testcase here: > > http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01812.html % Index: c-decl.c % =================================================================== % RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v % retrieving revision 1.630.6.16 % diff -u -u -r1.630.6.16 c-decl.c % --- c-decl.c 16 Aug 2005 20:34:19 -0000 1.630.6.16 % +++ c-decl.c 31 Aug 2005 04:55:40 -0000 % @@ -1559,7 +1559,11 @@ % && !(DECL_EXTERNAL (olddecl) && !DECL_EXTERNAL (newdecl)) % /* Don't warn about forward parameter decls. */ % && !(TREE_CODE (newdecl) == PARM_DECL % - && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl))) % + && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl)) % + /* Don't warn about forward static variable decls. */ This should something like say "Don't warn about a static variable definition following a declaration." Many of the preceding comments should be similarly reworded. % + && !(TREE_CODE (newdecl) == VAR_DECL % + && !TREE_PUBLIC (olddecl) && !TREE_PUBLIC (newdecl) % + && DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl))) This seems reasonable. Is it necessary to check TREE_PUBLIC () explicitly? We have already avoided warning for externs, so only weird cases are left. I can't see any reason not to use simply: /* Don't warn about a definition following a declaration. */ if (DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl))) since a definition (i.e., a declaration with an initializer) following a declaration (i.e., a tentative definition) can never be redundant. % { % warning ("%Jredundant redeclaration of %qD", newdecl, newdecl); % warned = true; Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 08:56:18 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BAE16A41F for ; Thu, 1 Sep 2005 08:56:18 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3430243D4C for ; Thu, 1 Sep 2005 08:56:16 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j818u6Zi007414 for ; Thu, 1 Sep 2005 11:56:06 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Thu, 1 Sep 2005 11:56:06 +0300 (EEST) From: Dmitry Pryanishnikov To: freebsd-arch@freebsd.org Message-ID: <20050901113819.F95708@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 01 Sep 2005 08:56:18 -0000 Hello! During the hunting the bug kern/85503 (panic: wrong dirclust in msdosfs) I've tried to think about the solution, but it seems to be architecture-related. The problem is: msdosfs uses pseudo-inodes (that is, the offset from the start of the partition to the start of directory entry in bytes) which must therefore have off_t bitness (at least 64 bits). I've found the primary error (lack of casts leaded to 32-bit result), but then we should transfer this 64-bit "inode" number to vfs_hash_get(). Oops, it also limited to u_int (32 bits on i386). Finally, I see that the primary shortcoming here: in sys/vnode.h we have /* * vfs_hash: (mount + inode) -> vnode hash. */ LIST_ENTRY(vnode) v_hashlist; u_int v_hash; I think it's feasible and useful to upgrade type of v_hash to at least off_t. In our days of large media we will face filesystems with more than 4 billions files (and thus at least 64-bit inode numbers) quite often. Am I right? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 13:47:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC9FB16A41F for ; Thu, 1 Sep 2005 13:47:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4766D43D45 for ; Thu, 1 Sep 2005 13:47:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j81DlIVc021240; Thu, 1 Sep 2005 23:47:18 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j81DlFfX002872; Thu, 1 Sep 2005 23:47:17 +1000 Date: Thu, 1 Sep 2005 23:47:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dmitry Pryanishnikov In-Reply-To: <20050901113819.F95708@atlantis.atlantis.dp.ua> Message-ID: <20050901201602.X99455@delplex.bde.org> References: <20050901113819.F95708@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 01 Sep 2005 13:47:35 -0000 On Thu, 1 Sep 2005, Dmitry Pryanishnikov wrote: > During the hunting the bug kern/85503 (panic: wrong dirclust in msdosfs) > I've tried to think about the solution, but it seems to be > architecture-related. The problem is: msdosfs uses pseudo-inodes (that is, > the offset from the start of the partition to the start of directory entry > in bytes) which must therefore have off_t bitness (at least 64 bits). I've > found the primary error (lack of casts leaded to 32-bit result), but then > we should transfer this 64-bit "inode" number to vfs_hash_get(). Oops, > it also limited to u_int (32 bits on i386). Finally, I see that the > primary shortcoming here: in sys/vnode.h we have > > /* > * vfs_hash: (mount + inode) -> vnode hash. > */ > LIST_ENTRY(vnode) v_hashlist; > u_int v_hash; > > I think it's feasible and useful to upgrade type of v_hash to at least off_t. > In our days of large media we will face filesystems with more than 4 billions > files (and thus at least 64-bit inode numbers) quite often. Am I right? This is not needed yet. Filesystems with more than 4G files are not supported yet, since ino_t is 32 bits and is used in critical APIs (struct stat...). Also, d_fileno in struct dirent is 32 bits but not identical to ino_t (POSIX with XSI extensions requires it to be identical). Even when ino_t is enlarged, backwards- and sideways-compat syscalls must do something with unrepresentable inode numbers. It's best for filesystems to map large inode numbers to small ones so that unrepresentable inodes are never seen by upper layers. So all current file systems need to generate unique 32-bit inode numbers. This may be difficult, but once it is done I think the inode number can be used as a key to pass to the hash functions. (The key is bogusly named "hash" in the hash function args and in v_hash above.) For msdosfs, the inode number is essentially the byte offset divided by the size of a directory entry. The size is 32, so this breaks at a byte offset of 128G instead of 4G. Details: - the inode number of the root dir is 1 - the inode number of a non-root dir is the (byte offset of the dir as a file) / 32 - the inode number of a non-dir is the (byte offset of the dir entry for the file) / 32. For stat() and possibly for readdir() and hashget(), I think it would work to use the cluster offset of the file for the fake inode number. The cluster size is always much larger than 32, so this would work for much larger file systems. cd9660 has a related bug suite. Its inode numbers are byte offsets of directory entries, so they break at 4G as in msdosfs. In addition, cd9660 needs to support hard links, but a 1-1 mapping from directory entries to hard links is perfectly wrong. This bug was worked around for stat() and readdir() in rev.1.77 of cd9660_vnops.c, by using the block offset of the file for the fake inode number. cd9660_ihashget() remained broken for directories above 4G and for hard links (having multiple active vnodes for the same file can't be good but might not be too bad for a read-only file system). However, rev.1.77 was temporarily backed out in rev.1.98 because it broke cd9660_fhtovp() and/or nfs readdirplus(). File handles in cd9660 contain an inode number and cd9660_fhtovp() depends on this number being compatible with the one set by readdir(). This part of the bug suite is smaller in msdosfs -- there file handles are directory (cluster, offset) pairs so enough info is available to derive whatever number vget() wants. The log message for rev.1.77 says that cd9660 did things better in FreeBSD-1 where it used directory (cluster, offset) pairs more. It seems to have never used these for file handles, so I now think that it needs to use them in some places where it now abuses inodes to look up directory entries, but that cd9660_fhtovp() is not one of these places (or hard to fix). cd9660_fhtovp() only needs to look up vnodes and a unique inode number is enough for that; the (cluster, offset) pair in msdosfs's file handles is just to match deget()'s interface. Try always using the cluster offset of the file for the fake inode number in msdosfs. cd9660 is harder to fix since it has hard links and symlinks. IIRC, its "inode" numbers are needed only to look up directory entries for symlinks. Using the directory entry for the inode in cd9660_ihashget() is bad for all types of links. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 15:15:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1612916A420 for ; Thu, 1 Sep 2005 15:15:34 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 923D243D4C for ; Thu, 1 Sep 2005 15:15:32 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (rwcrmhc13) with ESMTP id <2005090115153101500j141ve>; Thu, 1 Sep 2005 15:15:31 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j81FFV6r043644; Thu, 1 Sep 2005 11:15:31 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j81FFVm5043643; Thu, 1 Sep 2005 11:15:31 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 1 Sep 2005 11:15:31 -0400 From: Craig Rodrigues To: Bruce Evans Message-ID: <20050901151531.GA43623@crodrigues.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> <20050827235140.GA3063@crodrigues.org> <20050828172712.T86328@delplex.bde.org> <20050831112720.GA55376@crodrigues.org> <20050831215640.S1678@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831215640.S1678@epsplex.bde.org> User-Agent: Mutt/1.5.9i Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? 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, 01 Sep 2005 15:15:34 -0000 On Wed, Aug 31, 2005 at 10:32:08PM +1000, Bruce Evans wrote: > This seems reasonable. Is it necessary to check TREE_PUBLIC () > explicitly? We have already avoided warning for externs, so only > weird cases are left. I can't see any reason not to use simply: > > /* Don't warn about a definition following a declaration. */ > if (DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl))) > > since a definition (i.e., a declaration with an initializer) following > a declaration (i.e., a tentative definition) can never be redundant. I think you are right. I submitted a modified patch based on what you suggested here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00006.html and got approval for it on the GCC mainline here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00019.html I'll try to get it into GCC soon. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 16:20:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E11B16A41F for ; Thu, 1 Sep 2005 16:20:45 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3281B43D45 for ; Thu, 1 Sep 2005 16:20:43 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j81GKXsK080104; Thu, 1 Sep 2005 19:20:33 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Thu, 1 Sep 2005 19:20:33 +0300 (EEST) From: Dmitry Pryanishnikov To: Bruce Evans Message-ID: <20050901183311.D62325@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 01 Sep 2005 16:20:45 -0000 Hello! > Date: Thu, 1 Sep 2005 23:47:15 +1000 (EST) > From: Bruce Evans >> LIST_ENTRY(vnode) v_hashlist; >> u_int v_hash; >> >> I think it's feasible and useful to upgrade type of v_hash to at least >> off_t. > > This is not needed yet. > > Filesystems with more than 4G files are not supported yet, since ino_t > is 32 bits and is used in critical APIs (struct stat...). Also, Sorry, I don't agree with you. The current situation is ugly: not only it forces us to play dirty tricks within filesystems in order to generate unique 32-bit inode numbers, but also it creates an artificial limit on maximum number of files for 32-bit architectures. E.g., on FreeBSD/ia64 u_int is 64 bits, and thus it would be no problem for it's API to create and handle more than 4G files/fs. But such a file system will be incompatible with FreeBSD/i386! Isn't this ugly? u_int has nothing to do with storage size, while off_t has. It is clear that no media with maximum size of off_t will contain more than off_t files, while we can't guarantee this for u_int, which is bounded to CPU abilities. I think UNIX is about compatibility between different architectures, isn't it? > So all current file systems need to generate unique 32-bit inode > numbers. This may be difficult, but once it is done I think the inode ^^^^^^^^^^^^^^^^ ...and may be close-to-impossible. What if e.g. Microsoft invites say FAT-2005 with variable-length directory entries? I'm not sure that for every third-party filesystem it would be possible to generate 32-bit pseudoinode. And it's very bad that we can't handle >4Gfiles/fs at all. > For msdosfs, the inode number is essentially the byte offset divided by > the size of a directory entry. The size is 32, so this breaks at a byte > offset of 128G instead of 4G. Details: This is also imperfect: it creates a lot of pain and limitations for options MSDOSFS_LARGE So, while I understand complexity of such a transitions, but it's clear that for long-term solution ino_t should be upgraded to the size of off_t everywhere. For short-term one... Well, msdosfs isn't the worst case. > > Bruce > Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 07:39:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EC1316A41F for ; Fri, 2 Sep 2005 07:39:22 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A7CD43D48 for ; Fri, 2 Sep 2005 07:39:22 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 91214BC66 for ; Fri, 2 Sep 2005 07:39:20 +0000 (UTC) To: arch@freebsd.org From: Poul-Henning Kamp Date: Fri, 02 Sep 2005 09:39:19 +0200 Message-ID: <34182.1125646759@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Subject: Consoles, past and future. 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, 02 Sep 2005 07:39:22 -0000 Console n. [From Latin consolatio(n) "comfort, spiritual solace"]. A device for displaying or printing condolences and obituaries for the operator. -- The Devils DP Dictionary As I probably too briefly said in my previous email, the console code is a major headache for tty and device locking and something needs to happen. I would like to propose that we let something radical happen to our rather archaic concept of a "console" which still to a large degree is based on the fact that all PDP and VAX computers came with a hardcopy system console terminal. Here is my analysis: If we look at what the console code _does_ for us right now, (as opposed to what features it sports), we find a number of distinct functionalities: 1. Kernel boot progress indicator. All the device probe and attach etc. API: printf(9) and friends. 2. Single user terminal connection For manually fixing things before /etc/rc is run. API: Any tty(4) (and various other) devices will do. 3. System initialization progress indicator. The output from /etc/rc and its spawn. API: any file, pipe, stream socket and most devices will do. Using a tty(4) gives the ability to SIGINT processes which hang/sleep/get confused during startup. 4. Alert channel to the system responsible person. API: printf(9), log(9) or syslog. 5. Fall back input channel for dump(8) and a few other programs. If dump is run in the background it will ask for tape-changes on /dev/console. API: any tty(4) device which can be opened. 6. Kernel startup input channel Asking for root device. API: printf(9), gets(9). 7. Kernel panic fact recorder API: printf(9) 8. Kernel debugger interface. API: db_printf(9) etc. 9. Remote debugger interface. API: sys/gdb uses special hooks into relevant device driver. If we look at how this is all implemented presently: In the kernel, devices which can support a console publish a few functions, getchar(), putchar() etc. These functions are special in that they can not rely on interrupts and locking to be functional. A (somewhat) central body of code selects which console device(s) to use. kern.console is handled here. printf(9) and all that stuff, calls into the central console code. db_printf(9) is more or less just the same. gdb(9) has its own hooks into the device driver. I'm not sure I know why, but it probably makes sense. A special magic piece of code is the device driver for /dev/console which does not, as one would think, implement a tty which calls the console code, but rather tries to shortcut to the tty device which the device driver has associated with the same hardware as the console functionality. Since open of /dev/console should in principle always succeed, some rather evil stuff happens here. The major part of the trouble comes from the /dev/console implementation and its rather intimate abuse of ttys and this is the bits we need to fix. For now we can just leave point 1, 6, 7, 8 & 9 as is. That leaves 2, 3, 4, 5. Nobody mandates that 2 & 3 has to happen on "/dev/console", /sbin/init could open any device it prefer for this, so if the device drivers export a proposed device name along with their console functions, /sbin/init could pick this up with a sysctl and proceed from there. The loader could present a hint to override this. That leaves us with 4 and 5, which we can't do much about because short-sighted UNIX standards which goldpated the past rather than steer the future and therefore mandate that /dev/console must be a tty(4) device. But we can implement /dev/console as a pseudo device driver without breaking anything. Most people these days view this part of the console functionality through syslog or xconsole(-like) programs anyway which uses various ioctls to get their bit of the cake. In order to stay compatible with old stuff, we could use a null-modem backside device so that people could say "tip console" and interact with dump(8) that way. (Keeping a buffer of the most recent 2K output and replaying that on open would probably be a good idea). The driver would also have the task of directing the output to /dev/console to syslogd for permanent recording. Thanks for listening. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 09:40:30 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 650AC16A41F for ; Fri, 2 Sep 2005 09:40:30 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAEFD43D45 for ; Fri, 2 Sep 2005 09:40:29 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (tradenet-it.gw.ai.net [205.134.160.6] (may be forged)) (authenticated bits=0) by pittgoth.com (8.13.3/8.13.3) with ESMTP id j829eR4E081914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Sep 2005 05:40:28 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 2 Sep 2005 05:39:27 -0400 From: Tom Rhodes To: Poul-Henning Kamp Message-ID: <20050902053927.3656b245@localhost> In-Reply-To: <34182.1125646759@phk.freebsd.dk> References: <34182.1125646759@phk.freebsd.dk> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 09:40:30 -0000 On Fri, 02 Sep 2005 09:39:19 +0200 Poul-Henning Kamp wrote: [SNIP] > Nobody mandates that 2 & 3 has to happen on "/dev/console", /sbin/init > could open any device it prefer for this, so if the device drivers > export a proposed device name along with their console functions, > /sbin/init could pick this up with a sysctl and proceed from there. > The loader could present a hint to override this. > > That leaves us with 4 and 5, which we can't do much about because > short-sighted UNIX standards which goldpated the past rather than > steer the future and therefore mandate that /dev/console must be a > tty(4) device. > > But we can implement /dev/console as a pseudo device driver without > breaking anything. > > Most people these days view this part of the console functionality > through syslog or xconsole(-like) programs anyway which uses various > ioctls to get their bit of the cake. > > In order to stay compatible with old stuff, we could use a null-modem > backside device so that people could say "tip console" and interact > with dump(8) that way. (Keeping a buffer of the most recent 2K output > and replaying that on open would probably be a good idea). > > The driver would also have the task of directing the output to > /dev/console to syslogd for permanent recording. > > Thanks for listening. > You're welcome. :) My question is, and I know this hasn't been tested so be my guest and theorize a bit. Are there any performance gains or losses as a result of taking this route? -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 10:01:00 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77CF816A41F; Fri, 2 Sep 2005 10:01:00 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27FC043D49; Fri, 2 Sep 2005 10:01:00 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A709FBC66; Fri, 2 Sep 2005 10:00:58 +0000 (UTC) To: Tom Rhodes From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Sep 2005 05:39:27 EDT." <20050902053927.3656b245@localhost> Date: Fri, 02 Sep 2005 12:00:58 +0200 Message-ID: <34962.1125655258@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@FreeBSD.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 10:01:00 -0000 In message <20050902053927.3656b245@localhost>, Tom Rhodes writes: >My question is, and I know this hasn't been tested so be my >guest and theorize a bit. Are there any performance gains >or losses as a result of taking this route? If we are concerned about the performance of /dev/console, we need our collective heads and tails smacked until we come to our senses :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 10:08:36 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB7A216A41F for ; Fri, 2 Sep 2005 10:08:36 +0000 (GMT) (envelope-from roam@ringlet.net) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id B805643D48 for ; Fri, 2 Sep 2005 10:08:35 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 30595 invoked from network); 2 Sep 2005 10:08:31 -0000 Received: from unknown (HELO straylight.ringlet.net) (85.95.80.111) by gandalf.online.bg with SMTP; 2 Sep 2005 10:08:31 -0000 Received: (qmail 65413 invoked by uid 1000); 2 Sep 2005 13:08:34 +0300 Date: Fri, 2 Sep 2005 13:08:34 +0300 From: Peter Pentchev To: Poul-Henning Kamp Message-ID: <20050902100834.GB25237@straylight.m.ringlet.net> Mail-Followup-To: Poul-Henning Kamp , Tom Rhodes , arch@FreeBSD.org References: <20050902053927.3656b245@localhost> <34962.1125655258@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <34962.1125655258@phk.freebsd.dk> User-Agent: Mutt/1.5.10i Cc: Tom Rhodes , arch@FreeBSD.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 10:08:37 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 02, 2005 at 12:00:58PM +0200, Poul-Henning Kamp wrote: > In message <20050902053927.3656b245@localhost>, Tom Rhodes writes: >=20 >=20 > >My question is, and I know this hasn't been tested so be my > >guest and theorize a bit. Are there any performance gains > >or losses as a result of taking this route? >=20 > If we are concerned about the performance of /dev/console, we > need our collective heads and tails smacked until we come to > our senses :-) Somebody fortune this! :) (Hey, 'fortune' is a verb, innit now?) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDGCSi7Ri2jRYZRVMRAmDaAJ93dTeY9bdbVnLJk15Ja8HG35mcHwCeLUIy VDc6X/UEjTAdiEGVN3P7uQA= =yK3D -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 10:37:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7601416A41F for ; Fri, 2 Sep 2005 10:37:57 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20C5543D45 for ; Fri, 2 Sep 2005 10:37:57 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 97C7DBC66; Fri, 2 Sep 2005 10:37:55 +0000 (UTC) To: Dmitry Pryanishnikov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 01 Sep 2005 11:56:06 +0300." <20050901113819.F95708@atlantis.atlantis.dp.ua> Date: Fri, 02 Sep 2005 12:37:54 +0200 Message-ID: <35184.1125657474@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 02 Sep 2005 10:37:57 -0000 In message <20050901113819.F95708@atlantis.atlantis.dp.ua>, Dmitry Pryanishniko v writes: > >Hello! > > During the hunting the bug kern/85503 (panic: wrong dirclust in msdosfs) >I've tried to think about the solution, but it seems to be >architecture-related. The problem is: msdosfs uses pseudo-inodes (that is, >the offset from the start of the partition to the start of directory entry >in bytes) which must therefore have off_t bitness (at least 64 bits). I've >found the primary error (lack of casts leaded to 32-bit result), but then >we should transfer this 64-bit "inode" number to vfs_hash_get(). Oops, >it also limited to u_int (32 bits on i386). Finally, I see that the >primary shortcoming here: in sys/vnode.h we have NFS has the same sort of problem, it has 16 or 32 *bytes* filehandles that need to hash to 32 bit "inode numbers". If you look at vfs_hash_get calls in sys/nfsclient you can see that it calculates a 32bit hash but then provides a "nfs_vncmpf" function to do the actual comparison to resolve hash collisions. You need to do the same thing. Making the hashes be 64bit is pointless since no filesystems will have that many inodes and it still doesn't solve the problem properly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 11:05:07 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16BAD16A41F for ; Fri, 2 Sep 2005 11:05:07 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED4243D49 for ; Fri, 2 Sep 2005 11:05:06 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 2F456BC6B; Fri, 2 Sep 2005 11:05:02 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 01 Sep 2005 23:47:15 +1000." <20050901201602.X99455@delplex.bde.org> Date: Fri, 02 Sep 2005 13:05:02 +0200 Message-ID: <35359.1125659102@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Dmitry Pryanishnikov , freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 02 Sep 2005 11:05:07 -0000 In message <20050901201602.X99455@delplex.bde.org>, Bruce Evans writes: >So all current file systems need to generate unique 32-bit inode >numbers. This may be difficult, but once it is done I think the inode >number can be used as a key to pass to the hash functions. (The key >is bogusly named "hash" in the hash function args and in v_hash above.) Almost, but not quite correct: The hash and inode are not and can not be identical for remote filesystems like NFS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 11:39:24 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D498016A41F for ; Fri, 2 Sep 2005 11:39:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4064A43D46 for ; Fri, 2 Sep 2005 11:39:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j82Bd8cw001167; Fri, 2 Sep 2005 21:39:08 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j82Bd7HH007500; Fri, 2 Sep 2005 21:39:07 +1000 Date: Fri, 2 Sep 2005 21:39:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dmitry Pryanishnikov In-Reply-To: <20050901183311.D62325@atlantis.atlantis.dp.ua> Message-ID: <20050902205456.S2885@delplex.bde.org> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 02 Sep 2005 11:39:25 -0000 On Thu, 1 Sep 2005, Dmitry Pryanishnikov wrote: >>> I think it's feasible and useful to upgrade type of v_hash to at least >>> off_t. >> >> This is not needed yet. >> >> Filesystems with more than 4G files are not supported yet, since ino_t >> is 32 bits and is used in critical APIs (struct stat...). Also, > > Sorry, I don't agree with you. The current situation is ugly: not only > it forces us to play dirty tricks within filesystems in order to generate > unique 32-bit inode numbers, but also it creates an artificial limit If you want to fix this, first work on the much larger problems of enlarging ino_t and changing the not-unused ffs file system to support more than 4G files. Note that this was considered too hard to do for ffs2. Tricks to map to the API's inode number space are unavoidable due to the existence of compatibility APIs and belong in individual file systems since they are too hard to do generally. General code could only hash from a larger v_hash type to a smaller compat_subsystem_ino_t type and then somehow make the hash unique. It is only necessary for the result to be unique for files actually returned the the smaller ino_t's since boot time (or since mount time for a poor implementation that doesn't work as well as possible for at least nfs servers), but even this seems to require storing up to SMALLER_INO_T_MAX*sizeof(smaller_ino_t) bytes of history of recycled vnodes. > on maximum number of files for 32-bit architectures. E.g., on FreeBSD/ia64 > u_int is 64 bits, and thus it would be no problem for it's API to create and > handle more than 4G files/fs. But such a file system will be incompatible Actually u_int is 32 bits for ia64, and the ino_t API/ABI is indenpendent of the size of u_int. ino_t is uint32_t. > with FreeBSD/i386! Isn't this ugly? u_int has nothing to do with storage > size, while off_t has. It is clear that no media with maximum size of Neither u_int nor off_t has anything to do with the correct storage size here. off_t is a signed integer type suitable for representing offsets within files. Sicne off_t is unsigned, it is unsuitable for representing offsets within file systems. It just happens to work because it is 64 bits and an offset of 2^63-1 bytes is enough for anyone ;-). (Actually it is not even enough for offsets within files since offsets in /dev/kmem are often > 2^63 on 64-bit systems.) ino_t is closer to being the correct type. The type of v_hash certainly needs to be larger than ino_t. My main point is that although it could be larger so that file systems can easily create a (unique) id from things like (dirclust, diroffset) pairs, it is not useful for it to be larger since file systems need to create an id for the inode number anyway. (Creation in some file system, e.g. ffs, is just copying the inode number from the inode.) > off_t will contain more than off_t files, while we can't guarantee this > for u_int, which is bounded to CPU abilities. I think UNIX is about > compatibility between different architectures, isn't it? Unix is mostly about source-level compatibility. >> So all current file systems need to generate unique 32-bit inode >> numbers. This may be difficult, but once it is done I think the inode > ^^^^^^^^^^^^^^^^ > > ...and may be close-to-impossible. What if e.g. Microsoft invites say > FAT-2005 with variable-length directory entries? I'm not sure that for > every third-party filesystem it would be possible to generate 32-bit > pseudoinode. And it's very bad that we can't handle >4Gfiles/fs at all. It already invented variable-length entries for long names in 1990-1995 :-). But the sizes of the entries are multiples of 32. This is required for compatibility and won't change. I think I said that the inode number in msdosfs should be the cluster number of the first cluster in the file. This would be broken by variable-sized clusters (unlikely, and even less useful) or new file types like symlinks (useful and not so unlikely -- FreeBSD could add them as an extension). >> For msdosfs, the inode number is essentially the byte offset divided by >> the size of a directory entry. The size is 32, so this breaks at a byte >> offset of 128G instead of 4G. Details: > > This is also imperfect: it creates a lot of pain and limitations for > > options MSDOSFS_LARGE So use the cluster number and only worry about the limit of 16TB for 4K-clusters, etc. > So, while I understand complexity of such a transitions, but it's clear > that for long-term solution ino_t should be upgraded to the size of off_t > everywhere. For short-term one... Well, msdosfs isn't the worst case. Indeed. The only important cases are ffs and some network file systems that already support >= 4G files. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 12:48:29 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1890E16A468 for ; Fri, 2 Sep 2005 12:48:29 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93CE343D4C for ; Fri, 2 Sep 2005 12:48:28 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 6BE5BBC66; Fri, 2 Sep 2005 12:48:24 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Sep 2005 21:39:06 +1000." <20050902205456.S2885@delplex.bde.org> Date: Fri, 02 Sep 2005 14:48:23 +0200 Message-ID: <35672.1125665303@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 02 Sep 2005 12:48:29 -0000 In message <20050902205456.S2885@delplex.bde.org>, Bruce Evans writes: >If you want to fix this, first work on the much larger problems of enlarging >ino_t and changing the not-unused ffs file system to support more than 4G >files. Note that this was considered too hard to do for ffs2. Not quite. It was considered and we decided that it would be a waste of perfectly good diskspace and performance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 15:21:49 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E27816A41F; Fri, 2 Sep 2005 15:21:49 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD5943D49; Fri, 2 Sep 2005 15:21:49 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id BF3028A3; Fri, 2 Sep 2005 10:21:48 -0500 (CDT) Date: Fri, 2 Sep 2005 10:21:48 -0500 To: Poul-Henning Kamp Message-ID: <20050902152148.GE22022@soaustin.net> References: <20050902053927.3656b245@localhost> <34962.1125655258@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34962.1125655258@phk.freebsd.dk> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: Tom Rhodes , arch@FreeBSD.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 15:21:49 -0000 On Fri, Sep 02, 2005 at 12:00:58PM +0200, Poul-Henning Kamp wrote: > If we are concerned about the performance of /dev/console, we > need our collective heads and tails smacked until we come to > our senses :-) Ah, you've figured out a way to get Tom's attention for sure. mcl From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 16:56:00 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A967516A41F for ; Fri, 2 Sep 2005 16:56:00 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F75843D49 for ; Fri, 2 Sep 2005 16:56:00 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j82GtxS0014515; Fri, 2 Sep 2005 09:55:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <34182.1125646759@phk.freebsd.dk> References: <34182.1125646759@phk.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 2 Sep 2005 09:55:57 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.734) Cc: arch@freebsd.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 16:56:00 -0000 On Sep 2, 2005, at 12:39 AM, Poul-Henning Kamp wrote: > 1. Kernel boot progress indicator. > All the device probe and attach etc. > API: printf(9) and friends. > > 2. Single user terminal connection > For manually fixing things before /etc/rc is run. > API: Any tty(4) (and various other) devices will do. > > 3. System initialization progress indicator. > The output from /etc/rc and its spawn. > API: any file, pipe, stream socket and most devices will do. > Using a tty(4) gives the ability to SIGINT processes which > hang/sleep/get confused during startup. 2 & 3 are in essence the same thing currently. That is, both depend on the tty device /sbin/init uses. Whether they should be the same thing or not is not expressed with this statement. > gdb(9) has its own hooks into the device driver. I'm not sure I > know why, but it probably makes sense. Because a debug port is not a tty. The communication over a debug port is not bound to the rules and regulations of a tty. It therefore demands a separate interface. That you can implement one in terms of the other is merely an upshot. If we want to think radically, we probably should shift our thinking. We still treat the console as a central and fundamental piece of the kernel. I think we should instead make a 180 degrees turn and start off with a kernel that's deaf and dumb. I think it goes without saying that such an OS is still functional. Now, with this flatscreen or CRT in front of us, it would be nice to actually make use of it. But for what I hear you think... What is the use of a display? Well, it's a feedback device. We interact with the machine by looking at the display and act on what we see. This also means that the use of a display is dictated by the the abilities of the user, the role the machines plays in the user's life and the role of thew user in relation to the machine. In concreto: We have end-users, sysadmins, developers and machine builders as our possible audience and related to that we have FreeBSD ranging from a home computer to a hardware validation vehicle. The feedback appropriate in each of those scenarios is different. If we have disabled users, a display may not even be usable as a feedback device in the first place... What this means is that printf(9) can never mean the same as printf(3). It makes more sense to have printf(9) be the interface to internal logging and use a completely separate mechanism for sending the log information to some device if such would be beneficial. This allows us to not display the boot probe gobbledegook so that we can present the end-user with a nice logo instead as well as allows us do the complete opposite and and make all those weird developers happy. In any case, this concept cannot be explained in an email that's written on the verge of me going to work, so let me end here and see what grows from the seed that has been planted. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 17:34:08 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A807216A41F for ; Fri, 2 Sep 2005 17:34:08 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 501D643D45 for ; Fri, 2 Sep 2005 17:34:07 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id E9260BC66; Fri, 2 Sep 2005 17:34:05 +0000 (UTC) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Sep 2005 09:55:57 PDT." <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net> Date: Fri, 02 Sep 2005 19:34:04 +0200 Message-ID: <36330.1125682444@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@freebsd.org Subject: Re: Consoles, past and future. 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, 02 Sep 2005 17:34:08 -0000 In message <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net>, Marcel Moolenaar writes: >On Sep 2, 2005, at 12:39 AM, Poul-Henning Kamp wrote: >> 2. Single user terminal connection >> For manually fixing things before /etc/rc is run. >> API: Any tty(4) (and various other) devices will do. >> >> 3. System initialization progress indicator. >> The output from /etc/rc and its spawn. >> API: any file, pipe, stream socket and most devices will do. >> Using a tty(4) gives the ability to SIGINT processes which >> hang/sleep/get confused during startup. > >2 & 3 are in essence the same thing currently. That is, both depend >on the >tty device /sbin/init uses. Whether they should be the same thing or not >is not expressed with this statement. That's why I listed them separately :-) >> gdb(9) has its own hooks into the device driver. I'm not sure I >> know why, but it probably makes sense. > >Because a debug port is not a tty. The communication over a debug port >is not bound to the rules and regulations of a tty. It therefore demands >a separate interface. That you can implement one in terms of the other >is merely an upshot. Right, as I said: it probably makes sense :-) >If we want to think radically, we probably should shift our thinking. >We still treat the console as a central and fundamental piece of the >kernel. I think we should instead make a 180 degrees turn and start >off with a kernel that's deaf and dumb. I think it goes without saying >that such an OS is still functional. I must admit that I avoided this bit of the discussion to not get diverted into the "we need a graphic installer" bikeshed. I agree that we should look at this also, but I do consider it somewhat secondary in the sense that my email is about what mechnisms we have whereas this question is more about what we use them for. Knowing how the bikesheds grow bigger as we get closer to the user interface, I'd prefer if we could constrain ourselves to the first part for now, but certainly keeping the second part in sight. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 21:30:54 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5DBD16A41F for ; Fri, 2 Sep 2005 21:30:54 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from rohrpostix.tallence.de (rohrpostix.tallence.de [212.12.62.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8806A43D46 for ; Fri, 2 Sep 2005 21:30:51 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [44.128.40.11] (janus.spock.tallence.de [44.128.40.11]) by rohrpostix.tallence.de (Postfix) with ESMTP id 01A911AD91A; Fri, 2 Sep 2005 23:30:50 +0200 (CEST) In-Reply-To: <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net> References: <34182.1125646759@phk.freebsd.dk> <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 2 Sep 2005 23:30:49 +0200 To: Marcel Moolenaar X-Mailer: Apple Mail (2.733) Cc: arch@freebsd.org Subject: Re: Consoles, past and future. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 21:30:55 -0000 Am 02.09.2005 um 18:55 schrieb Marcel Moolenaar: > This allows us to not display the boot probe gobbledegook so that > we can present > the end-user with a nice logo[...] I know that Marcel actually qualified this statement, but I'd still like point out this common misconception. People are interested in receiving information that is useful to them. Being informed about startup progress is useful information; most people (me included) just don't care about the details. (Unless I'm trying to debug a problem.) A "nice logo" has nothing to do with it. As Marcel points out, there should be a mechanism that serves more than one purpose. F'up to -chat... Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 08:47:26 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66CF616A41F; Sat, 3 Sep 2005 08:47:26 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB1E43D46; Sat, 3 Sep 2005 08:47:25 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (tradenet-it.gw.ai.net [205.134.160.6] (may be forged)) (authenticated bits=0) by pittgoth.com (8.13.3/8.13.3) with ESMTP id j838lNwP093378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Sep 2005 04:47:24 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Sat, 3 Sep 2005 04:46:21 -0400 From: Tom Rhodes To: "Poul-Henning Kamp" Message-ID: <20050903044621.316451c4@localhost> In-Reply-To: <34962.1125655258@phk.freebsd.dk> References: <20050902053927.3656b245@localhost> <34962.1125655258@phk.freebsd.dk> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tom Rhodes , arch@FreeBSD.org Subject: Re: Consoles, past and future. 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, 03 Sep 2005 08:47:26 -0000 On Fri, 02 Sep 2005 12:00:58 +0200 "Poul-Henning Kamp" wrote: > In message <20050902053927.3656b245@localhost>, Tom Rhodes writes: > > > >My question is, and I know this hasn't been tested so be my > >guest and theorize a bit. Are there any performance gains > >or losses as a result of taking this route? > > If we are concerned about the performance of /dev/console, we > need our collective heads and tails smacked until we come to > our senses :-) > Good point. :) -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 09:44:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE6E16A41F for ; Sat, 3 Sep 2005 09:44:37 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.3.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DFA43D45 for ; Sat, 3 Sep 2005 09:44:36 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from localhost (localhost [127.0.0.1]) by kweetal.tue.nl (Postfix) with ESMTP id 2EF3D13B819 for ; Sat, 3 Sep 2005 11:44:35 +0200 (CEST) Received: from kweetal.tue.nl ([127.0.0.1]) by localhost (kweetal.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68811-06 for ; Sat, 3 Sep 2005 11:44:34 +0200 (CEST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by kweetal.tue.nl (Postfix) with ESMTP id 60E3C13B815 for ; Sat, 3 Sep 2005 11:44:34 +0200 (CEST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.13.4/8.13.4/Submit) id j839iYsD072483 for freebsd-arch@freebsd.org; Sat, 3 Sep 2005 11:44:34 +0200 (CEST) (envelope-from stijn) Date: Sat, 3 Sep 2005 11:44:34 +0200 From: Stijn Hoop To: freebsd-arch@freebsd.org Message-ID: <20050903094434.GA852@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! X-Virus-Scanned: amavisd-new at tue.nl Subject: pam_krb5 / pam_sm_setcred not getting called with PAM_ESTABLISH_CRED 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, 03 Sep 2005 09:44:37 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm debugging a problem on 5-STABLE where I've setup a KDC using Heimdal in the base system, and activated pam_krb5 in /etc/pam.d/sshd. It turns out that pam_krb5 does not establish the credential cache for the authenticated user. After reinstalling pam with DEBUG & PAM_DEBUG, it turns out that pam_sm_setcred is only called with PAM_REINITIALIZE_CRED as flags, and never with PAM_ESTABLISH_CRED, which is the only case for which a credential cache will be saved (in all other cases, PAM_SUCCESS is returned immediatel= y, which is why I don't have a cache). My questions: - is this due to my pam setup? I've used the default /etc/pam.d/ssh while uncommenting the pam_krb5 entries, and I've also tried having only pam_kr= b5 as being required for all types. Both setups did not make any difference. - shouldn't pam_krb5 re-establish the credential cache when called with PAM_REINITIALIZE_CRED, instead of just returning PAM_SUCCESS? I'm a total pam newbie so I'm going only by the name of the flag; I couldn't find a manpage that made the semantics of these flags more clear. --Stijn --=20 "What if everything you see is more than what you see -- the person next to you is a warrior and the space that appears empty is a secret door to anoth= er world? What if something appears that shouldn't? You either dismiss it, or = you accept that there is much more to the world than you think. Perhaps it real= ly is a doorway, and if you choose to go inside, you'll find many unexpected things." -- Shigeru Miyamoto --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDGXCCY3r/tLQmfWcRAmQBAKCNkjaFc0DCb1X/i++MCOGGk/EF9wCgi98f spyf8yojg3mUiwOA3LdfgvE= =ohry -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 14:55:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5972416A41F for ; Sat, 3 Sep 2005 14:55:09 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.3.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDDC943D46 for ; Sat, 3 Sep 2005 14:55:08 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from localhost (localhost [127.0.0.1]) by kweetal.tue.nl (Postfix) with ESMTP id CB61D13B6F8 for ; Sat, 3 Sep 2005 16:55:07 +0200 (CEST) Received: from kweetal.tue.nl ([127.0.0.1]) by localhost (kweetal.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89524-03 for ; Sat, 3 Sep 2005 16:55:07 +0200 (CEST) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by kweetal.tue.nl (Postfix) with ESMTP id 0817C13B6E4 for ; Sat, 3 Sep 2005 16:55:07 +0200 (CEST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.13.4/8.13.4/Submit) id j83Et6ia073764 for freebsd-arch@freebsd.org; Sat, 3 Sep 2005 16:55:06 +0200 (CEST) (envelope-from stijn) Date: Sat, 3 Sep 2005 16:55:06 +0200 From: Stijn Hoop To: freebsd-arch@freebsd.org Message-ID: <20050903145506.GB852@pcwin002.win.tue.nl> References: <20050903094434.GA852@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline In-Reply-To: <20050903094434.GA852@pcwin002.win.tue.nl> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! X-Virus-Scanned: amavisd-new at tue.nl Subject: Re: pam_krb5 / pam_sm_setcred not getting called with PAM_ESTABLISH_CRED' 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, 03 Sep 2005 14:55:09 -0000 --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 03, 2005 at 11:44:34AM +0200, Stijn Hoop wrote: > I'm debugging a problem on 5-STABLE where I've setup a KDC using Heimdal > in the base system, and activated pam_krb5 in /etc/pam.d/sshd. It turns o= ut > that pam_krb5 does not establish the credential cache for the authenticat= ed > user. After reinstalling pam with DEBUG & PAM_DEBUG, it turns out that > pam_sm_setcred is only called with PAM_REINITIALIZE_CRED as flags, and > never with PAM_ESTABLISH_CRED, which is the only case for which a credent= ial > cache will be saved (in all other cases, PAM_SUCCESS is returned immediat= ely, > which is why I don't have a cache). Further digging reveals that this is due to the sshd code; it turns out that unless PrivilegeSeparation is off, it will not 'establish' credentials, only 'reinitialize' them. Found in src/crypto/openssh/auth-pam= .c and session.c. I really wouldn't know if this is appropriate or not, but it seems confusing to me. The second question still stands: > - shouldn't pam_krb5 re-establish the credential cache when called with > PAM_REINITIALIZE_CRED, instead of just returning PAM_SUCCESS? I'm a tot= al > pam newbie so I'm going only by the name of the flag; I couldn't find a > manpage that made the semantics of these flags more clear. Or of course someone pointing out the correct way to get an initialized Kerberos 5 ticket cache upon succesful ssh login... --Stijn --=20 "Diane, 2:15 in the afternoon, November 14. Entering town of Twin Peaks. Five miles south of the Canadian border, twelve miles west of the state line. Never seen so many trees in my life. As W.C. Fields would say, I'd rather be here than Philadelphia." -- Special Agent Dale Cooper, "Twin Peaks" --+g7M9IMkV8truYOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDGblKY3r/tLQmfWcRAvl5AJsElgZtcmlnBsn7e3nlE0QT/n/GmQCfWvKY GYZgL7W/8vVTKzzrqVCqd6Y= =2fgs -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 16:40:04 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB3FB16A41F for ; Sat, 3 Sep 2005 16:40:04 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8AA843D45 for ; Sat, 3 Sep 2005 16:40:03 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j83Gdjeg010107; Sat, 3 Sep 2005 19:39:45 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sat, 3 Sep 2005 19:39:45 +0300 (EEST) From: Dmitry Pryanishnikov To: Bruce Evans In-Reply-To: <20050902205456.S2885@delplex.bde.org> Message-ID: <20050903190632.S1788@atlantis.atlantis.dp.ua> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> <20050902205456.S2885@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 16:40:04 -0000 Hello! On Fri, 2 Sep 2005, Bruce Evans wrote: >> on maximum number of files for 32-bit architectures. E.g., on FreeBSD/ia64 >> u_int is 64 bits, and thus it would be no problem for it's API to create >> and handle more than 4G files/fs. But such a file system will be >> incompatible > > Actually u_int is 32 bits for ia64, and the ino_t API/ABI is indenpendent > of the size of u_int. ino_t is uint32_t. Hmm, what about other 64-bit architectures (e.g. alpha)? I used to think that on 64-bit CPUs type int should have 64 bits. > Neither u_int nor off_t has anything to do with the correct storage > size here. off_t is a signed integer type suitable for representing --------------^^^^^^^^^^^^^^^^^ Yes, it is (at least on i386): /usr/include/machine/_types.h: typedef long long __int64_t; /usr/include/sys/_types.h: typedef __int64_t __off_t; /* file offset */ > offsets within files. Sicne off_t is unsigned, it is unsuitable for -------------------------------^^^^^^^^^^^^^^^^^ No, it's signed ;) > representing offsets within file systems. It just happens to work > because it is 64 bits and an offset of 2^63-1 bytes is enough for > anyone ;-). (Actually it is not even enough for offsets within files > since offsets in /dev/kmem are often > 2^63 on 64-bit systems.) ino_t I think that any file system should be flexible enough to support maximum file size as large as file system size (ideally). So if off_t is suitable for representing offset within single file, it should also be suitable for representing offset within filesystem, because their maximum sizes are almost the same. Also, I don't understand why signedness of the type makes any difference: whe're working with offsets from the start of our media, so all offsets are positive. I'm trying to be as general as possible. Size of direct access media (disks) tends to increase, so (in order not to rewrite disk layers every 5 years) we should have a basic data type which is suitable to hold media size in bytes. In fact I think that we already have this type (off_t). Also, it's clear that no media can contain more files than it's size in bytes, so this data type should also represent file number (inode number, if this sounds better ;). > is closer to being the correct type. The type of v_hash certainly needs > to be larger than ino_t. My main point is that although it could be > larger so that file systems can easily create a (unique) id from things > like (dirclust, diroffset) pairs, it is not useful for it to be larger > since file systems need to create an id for the inode number anyway. > (Creation in some file system, e.g. ffs, is just copying the inode > number from the inode.) Of course, size of ino_t should also be upgraded. But I understand that it isn't an easy task. >>> So all current file systems need to generate unique 32-bit inode >>> numbers. This may be difficult, but once it is done I think the inode >> ^^^^^^^^^^^^^^^^ >> >> ...and may be close-to-impossible. What if e.g. Microsoft invites say >> FAT-2005 with variable-length directory entries? I'm not sure that for >> every third-party filesystem it would be possible to generate 32-bit >> pseudoinode. And it's very bad that we can't handle >4Gfiles/fs at all. > > It already invented variable-length entries for long names in 1990-1995 :-). > But the sizes of the entries are multiples of 32. This is required for > compatibility and won't change. But even this fact doesn't rescue us when we talk about FAT32 slices > 128Gb... > I think I said that the inode number in msdosfs should be the cluster > number of the first cluster in the file. This would be broken by > variable-sized clusters (unlikely, and even less useful) or new file > types like symlinks (useful and not so unlikely -- FreeBSD could add > them as an extension). Yes, I agree with this. While this fs has being called FAT32, it's cluster number will fit in 32-bit word. > Indeed. The only important cases are ffs and some network file systems > that already support >= 4G files. I think interoperability with other OSes is also important, and if, e.g. Microsoft will invent FAT64, we will return to this topic ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 16:51:56 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71C216A41F for ; Sat, 3 Sep 2005 16:51:56 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32BB43D45 for ; Sat, 3 Sep 2005 16:51:55 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j83Gpj0w013870; Sat, 3 Sep 2005 19:51:45 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sat, 3 Sep 2005 19:51:45 +0300 (EEST) From: Dmitry Pryanishnikov To: Bruce Evans In-Reply-To: <20050903190632.S1788@atlantis.atlantis.dp.ua> Message-ID: <20050903194401.E1788@atlantis.atlantis.dp.ua> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> <20050902205456.S2885@delplex.bde.org> <20050903190632.S1788@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 16:51:56 -0000 On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >> I think I said that the inode number in msdosfs should be the cluster >> number of the first cluster in the file. This would be broken by >> variable-sized clusters (unlikely, and even less useful) or new file >> types like symlinks (useful and not so unlikely -- FreeBSD could add >> them as an extension). > > Yes, I agree with this. While this fs has being called FAT32, > it's cluster number will fit in 32-bit word. Ups, how about empty files? They haven't any allocated clusters, have they? So, alas, we can't go this route. > I think interoperability with other OSes is also important, and if, e.g. > Microsoft will invent FAT64, we will return to this topic ;) Or, more realistically, NTFS will support >4Gfiles/fs... I won't even be surprised if they already do. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 21:14:15 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6534B16A41F for ; Sat, 3 Sep 2005 21:14:15 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id D014243D48 for ; Sat, 3 Sep 2005 21:14:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83LE06v030275; Sun, 4 Sep 2005 07:14:00 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83LDwuB019937; Sun, 4 Sep 2005 07:14:00 +1000 Date: Sun, 4 Sep 2005 07:13:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Dmitry Pryanishnikov In-Reply-To: <20050903194401.E1788@atlantis.atlantis.dp.ua> Message-ID: <20050904065305.T2366@epsplex.bde.org> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> <20050902205456.S2885@delplex.bde.org> <20050903190632.S1788@atlantis.atlantis.dp.ua> <20050903194401.E1788@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 21:14:15 -0000 On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: > On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >>> I think I said that the inode number in msdosfs should be the cluster >>> number of the first cluster in the file. This would be broken by >>> variable-sized clusters (unlikely, and even less useful) or new file >>> types like symlinks (useful and not so unlikely -- FreeBSD could add >>> them as an extension). >> >> Yes, I agree with this. While this fs has being called FAT32, >> it's cluster number will fit in 32-bit word. > > Ups, how about empty files? They haven't any allocated clusters, have > they? So, alas, we can't go this route. Urk. It also doesn't work for cd9660. So the block number can be used at most as a hint getting a unique fake inode number, and in msdosfs file systems don't have to be much larger than 128GB to have >= 4G files -- a 128+GB file system can consist of 128GB of directories all containing empty files :-). Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 21:17:45 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E11616A41F for ; Sat, 3 Sep 2005 21:17:45 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0223743D46 for ; Sat, 3 Sep 2005 21:17:44 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id D418EBC66; Sat, 3 Sep 2005 21:17:40 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 04 Sep 2005 07:13:58 +1000." <20050904065305.T2366@epsplex.bde.org> Date: Sat, 03 Sep 2005 23:17:40 +0200 Message-ID: <44604.1125782260@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 21:17:45 -0000 In message <20050904065305.T2366@epsplex.bde.org>, Bruce Evans writes: >On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: > >> On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >>>> I think I said that the inode number in msdosfs should be the cluster >>>> number of the first cluster in the file. This would be broken by >>>> variable-sized clusters (unlikely, and even less useful) or new file >>>> types like symlinks (useful and not so unlikely -- FreeBSD could add >>>> them as an extension). >>> >>> Yes, I agree with this. While this fs has being called FAT32, >>> it's cluster number will fit in 32-bit word. >> >> Ups, how about empty files? They haven't any allocated clusters, have >> they? So, alas, we can't go this route. > >Urk. It also doesn't work for cd9660. So the block number can be >used at most as a hint getting a unique fake inode number, and in >msdosfs file systems don't have to be much larger than 128GB to have >>= 4G files -- a 128+GB file system can consist of 128GB of directories >all containing empty files :-). Uhm, did none of you guys see my email about how this must be done correctly the say way NFS does it correctly ? To repeat: NFS has the same sort of problem, it has 16 or 32 *bytes* filehandles that need to hash to 32 bit "inode numbers". If you look at vfs_hash_get calls in sys/nfsclient you can see that it calculates a 32bit hash but then provides a "nfs_vncmpf" function to do the actual comparison to resolve hash collisions. You need to do the same thing. Making the hashes be 64bit is pointless since no filesystems will have that many inodes and it still doesn't solve the problem properly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 22:59:42 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D580616A41F for ; Sat, 3 Sep 2005 22:59:42 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F85A43D45 for ; Sat, 3 Sep 2005 22:59:42 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j83MxfBd000900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 Sep 2005 15:59:42 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <431A2C7A.6080005@errno.com> Date: Sat, 03 Sep 2005 16:06:34 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 802.11 status and futures 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, 03 Sep 2005 22:59:42 -0000 We're getting closer to 6.0 and the next STABLE branch. This will define another ABI freeze which will have significant impact on my importing 802.11 work so I figure it's time to review where we are and describe what's going on in terms of future development. 6.0 will be the first release that has WPA support included in the base system. While the support has been working (for some definition of "working") for >18 months it's only been available to CURRENT users so this is a major milestone. The ath driver is well-tested in this regard; a few other drivers have minimal WPA support (e.g. no h/w crypto is yet supported). I have fixes pending in other depots to address miscellaneous bugs and resolve compliance issues (the linux version of the code has passed many standard compliance suites and some of the changes from that code base have not been back-merged). These changes will be rolled into HEAD as time permits and all will be MFC'd to RELENG_6 if possible. As soon as it's ok to have HEAD diverge I want to bring in an entirely new framework for doing scanning. This supports things like background scanning (scanning for ap's while associated), roaming, and enables station mode power save operation. These changes affect all drivers so committing them won't happen until I get help in updating and testing other drivers. Also these changes cannot be MFC'd because they would break existing API's. Past the scanning-related changes I have an entirely new architecture for the 802.11 layer that I described at BSDCan 2005. Slides are available at: http://www.freebsd.org/~sam/BSDCan2005.pdf These changes enable things like support for multiple ssid and bssid on a single device (e.g. so you can have a virtual ap using WPA operating in parallel with an ap that uses open authentication), WDS repeater operation, and mesh networks (this was designed with 802.11s in mind). The virtual ap (or vap) code has been in development for nearly a year and is about to be released for linux (and has gone through extensive testing). Getting this code in the tree will again require help from folks to update and test drivers. And again this cannot be MFC'd because of API changes. While not directly related to the above work I will soon commit an update to the Atheros hal that will add support for some of their most recent parts that people are encountering in retail products. This will be MFC'd to REELNG_6; I haven't decided yet whether to backport it to other branches (by the time I can consider RELENG_5 it may be irrelevant). The above may change depending on my time and work commitments. Sam From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 22:59:48 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C86316A424 for ; Sat, 3 Sep 2005 22:59:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEEF243D45 for ; Sat, 3 Sep 2005 22:59:47 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83MxfY1029275; Sun, 4 Sep 2005 08:59:41 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83MxeUx012363; Sun, 4 Sep 2005 08:59:40 +1000 Date: Sun, 4 Sep 2005 08:59:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Dmitry Pryanishnikov In-Reply-To: <20050903190632.S1788@atlantis.atlantis.dp.ua> Message-ID: <20050904071431.N2366@epsplex.bde.org> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> <20050902205456.S2885@delplex.bde.org> <20050903190632.S1788@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 22:59:48 -0000 On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: > On Fri, 2 Sep 2005, Bruce Evans wrote: >> Actually u_int is 32 bits for ia64, and the ino_t API/ABI is indenpendent >> of the size of u_int. ino_t is uint32_t. > > Hmm, what about other 64-bit architectures (e.g. alpha)? I used to think > that on 64-bit CPUs type int should have 64 bits. They all use 32-bit for binary and (badly written) source compatiblity. I tend to agree that ints should be 64 bits on true 64 bit machines, since longs should be twice as large as the register size and that leaves nothing except ints among the standard integer types for actually using plain 64-bit registers. >> offsets within files. Sicne off_t is unsigned, it is unsuitable for > -------------------------------^^^^^^^^^^^^^^^^^ > > No, it's signed ;) Oops. >> representing offsets within file systems. It just happens to work >> because it is 64 bits and an offset of 2^63-1 bytes is enough for >> anyone ;-). (Actually it is not even enough for offsets within files >> since offsets in /dev/kmem are often > 2^63 on 64-bit systems.) ino_t > > I think that any file system should be flexible enough to support maximum > file size as large as file system size (ideally). So if off_t is suitable > for representing offset within single file, it should also be suitable > for representing offset within filesystem, because their maximum sizes > are almost the same. Also, I don't understand why signedness of the type > makes any difference: whe're working with offsets from the start of > our media, so all offsets are positive. off_t is also needed to represent negative offsets for SEEK_EOF. Thus it must be a signed type, and its range must be from -(signed)(maxfilesize+1) to maxfilesize+1. 2's complement types can't do that right without retricting the max file size to about half of the range of the corresponding unsigned type. So 64-bit registers/off_t's give a max file size limit of 2^63-2, not 2^64-1 (-2 so that 1 can be added to maxfileize -- the offset is maxfilesize+1 at EOF for a file with max size), and 64-bit address spaces cannot be addressed by 64-bit off_t's without kludges; even a 65-bit off_t is 1 or 2 values short since 1 more value is needed for 2^64 and another for an out-of-band error return value. > I'm trying to be as general as possible. Size of direct access media (disks) > tends to increase, so (in order not to rewrite disk layers every 5 years) > we should have a basic data type which is suitable to hold media size > in bytes. In fact I think that we already have this type (off_t). Also, > it's clear that no media can contain more files than it's size in bytes, > so this data type should also represent file number (inode number, if > this sounds better ;). The latter is not clear :-). Lots of compression is possible. >> is closer to being the correct type. The type of v_hash certainly needs >> to be larger than ino_t. My main point is that although it could be >> larger so that file systems can easily create a (unique) id from things >> like (dirclust, diroffset) pairs, it is not useful for it to be larger >> since file systems need to create an id for the inode number anyway. >> (Creation in some file system, e.g. ffs, is just copying the inode >> number from the inode.) > > Of course, size of ino_t should also be upgraded. But I understand that > it isn't an easy task. phk pointed out the simple method (already needed and used for nfs) for fixing vnode lookup. This leaves the problem of fixing inode numbers for userland. cd9660 has much the same problems as msdosfs. udf seems to get a fileid off the media. I wonder if fileids off media can be trusted for vnode lookup. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 23:43:50 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D1B116A41F for ; Sat, 3 Sep 2005 23:43:50 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871D543D45 for ; Sat, 3 Sep 2005 23:43:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83NhY1R017681; Sun, 4 Sep 2005 09:43:34 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j83NhVHJ023858; Sun, 4 Sep 2005 09:43:33 +1000 Date: Sun, 4 Sep 2005 09:43:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Poul-Henning Kamp In-Reply-To: <44604.1125782260@phk.freebsd.dk> Message-ID: <20050904090740.L2820@epsplex.bde.org> References: <44604.1125782260@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 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, 03 Sep 2005 23:43:50 -0000 On Sat, 3 Sep 2005, Poul-Henning Kamp wrote: > In message <20050904065305.T2366@epsplex.bde.org>, Bruce Evans writes: >> On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >> >>> On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >>>>> I think I said that the inode number in msdosfs should be the cluster >>>>> number of the first cluster in the file. This would be broken by >>> Ups, how about empty files? They haven't any allocated clusters, have >>> they? So, alas, we can't go this route. >> >> Urk. It also doesn't work for cd9660. So the block number can be >> used at most as a hint getting a unique fake inode number, and in >> msdosfs file systems don't have to be much larger than 128GB to have >>> = 4G files -- a 128+GB file system can consist of 128GB of directories >> all containing empty files :-). > > Uhm, did none of you guys see my email about how this must be > done correctly the say way NFS does it correctly ? Yes. I even mentioned it in my reply. > To repeat: > > NFS has the same sort of problem, it has 16 or 32 *bytes* filehandles > that need to hash to 32 bit "inode numbers". > > If you look at vfs_hash_get calls in sys/nfsclient you can see that > it calculates a 32bit hash but then provides a "nfs_vncmpf" function > to do the actual comparison to resolve hash collisions. > > You need to do the same thing. This doesn't handle the problem of getting unique inode numbers for user APIs. The vnode hashing is much easier because collisions are permitted, the number of vnodes is relatively limited, and the final hash number doesn't have to live longer than the vnode. > Making the hashes be 64bit is pointless since no filesystems will > have that many inodes and it still doesn't solve the problem properly. Never? :-) nfs file systems can probably have 2^33 inodes now, and nfsv3 handles this poorly by blindly truncating to "long va_fileid" or "uint32_t d_fileno". The former actually works on 64-bit machines, but then stat() blindly truncates to "ino_t st_ino". nfsv4 may be better. It converts directly to 32 bits by ORing bits 32-63 into bits 0-31 and only setting 32 bits in va_fileid or d_fileno (except cookies are sometimes used for d_fileid). This conversion looks more like a simple hash than part of a protocol (I don't understand the protocol). The d_fileno (readdir()) case shows that we shouldn't try very hard to adjust the id passed by the server. The server's id must be trusted to be unique for d_fileno (for POSIXish file systems) since we would have to read much more than directory entries to fix up non-uniqueness. setattr() must produce the same fileids as readdir(), so more can't be done when we have full vnode info. Bruce