From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 03:27:49 2003 Return-Path: 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 F065216A4B3 for ; Sun, 28 Sep 2003 03:27:49 -0700 (PDT) Received: from fafoe.narf.at (chello212186121237.14.vie.surfer.at [212.186.121.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id F35E044013 for ; Sun, 28 Sep 2003 03:27:48 -0700 (PDT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.2.102]) by fafoe.narf.at (Postfix) with ESMTP id 905513FAA; Sun, 28 Sep 2003 12:27:38 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 86FB35E; Sun, 28 Sep 2003 12:27:37 +0200 (CEST) Date: Sun, 28 Sep 2003 12:27:37 +0200 From: Stefan Farfeleder To: Adam Migus Message-ID: <20030928102735.GI802@wombat.fafoe.narf.at> References: <20030925092319.H5418@gamplex.bde.org> <49939.204.254.155.35.1064593320.squirrel@mail.migus.org> <20030927080420.N18558@gamplex.bde.org> <20030927105241.GG802@wombat.fafoe.narf.at> <3F75DBD1.70600@migus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F75DBD1.70600@migus.org> User-Agent: Mutt/1.5.4i cc: arch@FreeBSD.org Subject: Re: sys/conf/DEFAULT[S] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 10:27:50 -0000 On Sat, Sep 27, 2003 at 02:49:53PM -0400, Adam Migus wrote: > Actually, while the error is not simply an "off-by-one" error, this > patch is not sufficient to fix the nested case: > > Below is the output of running config (with or without this patch) on my > set of kernels, one of which includes twice on the first line. This > language specification, in fact, fails to handle an include, immediately > followed by anything other than a blank line or comment. Thus the fix > is a little more complicated. I can't reproduce this here. I have no problem with 'include FOO; include BAR' on a single line. Can you make your config files available? Stefan From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 10:20:24 2003 Return-Path: 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 9A3B016A4B3 for ; Sun, 28 Sep 2003 10:20:24 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A3E44025 for ; Sun, 28 Sep 2003 10:20:23 -0700 (PDT) (envelope-from adam@migus.org) Received: from garple.migus.org ([68.55.83.94]) by comcast.net (sccrmhc11) with ESMTP id <20030928172021011002s11ee>; Sun, 28 Sep 2003 17:20:21 +0000 Received: by garple.migus.org (Postfix, from userid 80) id C5FB58FC30; Sun, 28 Sep 2003 13:20:21 -0400 (EDT) Received: from 192.168.4.2 (SquirrelMail authenticated user adam) by mail.migus.org with HTTP; Sun, 28 Sep 2003 13:20:21 -0400 (EDT) Message-ID: <49720.192.168.4.2.1064769621.squirrel@mail.migus.org> In-Reply-To: <20030928102735.GI802@wombat.fafoe.narf.at> References: <20030925092319.H5418@gamplex.bde.org> <49939.204.254.155.35.1064593320.squirrel@mail.migus.org> <20030927080420.N18558@gamplex.bde.org> <20030927105241.GG802@wombat.fafoe.narf.at> <3F75DBD1.70600@migus.org> <20030928102735.GI802@wombat.fafoe.narf.at> Date: Sun, 28 Sep 2003 13:20:21 -0400 (EDT) From: "Adam C. Migus" To: "Stefan Farfeleder" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20030928132021_47004" X-Priority: 3 Importance: Normal cc: arch@freebsd.org Subject: Re: sys/conf/DEFAULT[S] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 17:20:24 -0000 ------=_20030928132021_47004 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Stefan Farfeleder said: > > > I can't reproduce this here. I have no problem with > 'include FOO; include BAR' on a single line. Can you make your > config > files available? > > Stefan > Sure. Here they are. -- Adam - (http://people.migus.org/~amigus/) Migus Dot Org - (http://www.migus.org/) ------=_20030928132021_47004 Content-Type: application/octet-stream; name="DISKLESS_SMP_MAC" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DISKLESS_SMP_MAC" aW5jbHVkZSBTTVBfTUFDCgppZGVudAkJRElTS0xFU1NfU01QX01BQwoKb3B0aW9ucyAJQk9PVFAK b3B0aW9ucyAJQk9PVFBfTkZTUk9PVApvcHRpb25zIAlCT09UUF9ORlNWMwo= ------=_20030928132021_47004 Content-Type: application/octet-stream; name="SMP_MAC" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SMP_MAC" aW5jbHVkZSBNQUMKCmlkZW50CQlTTVBfTUFDCgojIFRvIG1ha2UgYW4gU01QIGtlcm5lbCwgdGhl IG5leHQgdHdvIGFyZSBuZWVkZWQKb3B0aW9ucyAJQVBJQ19JTwkJCSMgU3ltbWV0cmljIChBUElD KSBJL08Kb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsCg== ------=_20030928132021_47004 Content-Type: application/octet-stream; name="MAC" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MAC" IwojIE1BQyAtLSBHZW5lcmljIGtlcm5lbCBjb25maWd1cmF0aW9uIGZpbGUgZm9yIEZyZWVCU0Qv aTM4NgojCiMgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyBmaWxlLCBwbGVhc2UgcmVhZCB0 aGUgaGFuZGJvb2sgc2VjdGlvbiBvbgojIEtlcm5lbCBDb25maWd1cmF0aW9uIEZpbGVzOgojCiMg ICAgaHR0cDovL3d3dy5GcmVlQlNELm9yZy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hhbmRi b29rL2tlcm5lbGNvbmZpZy1jb25maWcuaHRtbAojCiMgVGhlIGhhbmRib29rIGlzIGFsc28gYXZh aWxhYmxlIGxvY2FsbHkgaW4gL3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sKIyBpZiB5b3UndmUgaW5z dGFsbGVkIHRoZSBkb2MgZGlzdHJpYnV0aW9uLCBvdGhlcndpc2UgYWx3YXlzIHNlZSB0aGUKIyBG cmVlQlNEIFdvcmxkIFdpZGUgV2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELm9yZy8pIGZv ciB0aGUKIyBsYXRlc3QgaW5mb3JtYXRpb24uCiMKIyBBbiBleGhhdXN0aXZlIGxpc3Qgb2Ygb3B0 aW9ucyBhbmQgbW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbnMgb2YgdGhlCiMgZGV2aWNlIGxpbmVz IGlzIGFsc28gcHJlc2VudCBpbiB0aGUgLi4vLi4vY29uZi9OT1RFUyBhbmQgTk9URVMgZmlsZXMu IAojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9m IGEgbGluZSwgY2hlY2sgZmlyc3QgCiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogc3JjL3N5cy9p Mzg2L2NvbmYvTUFDLHYgMS4zNzQgMjAwMy8wMS8yNiAwNjozNzo0MyBqZWZmIEV4cCAkCgptYWNo aW5lCQlpMzg2CmNwdQkJSTQ4Nl9DUFUKY3B1CQlJNTg2X0NQVQpjcHUJCUk2ODZfQ1BVCmlkZW50 CQlNQUMKbWF4dXNlcnMJMAoKI1RvIHN0YXRpY2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5n IGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNoaW50cwkJIk1BQy5oaW50cyIJCSNEZWZh dWx0IHBsYWNlcyB0byBsb29rIGZvciBkZXZpY2VzLgoKbWFrZW9wdGlvbnMJREVCVUc9LWcJCSNC dWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoKb3B0aW9ucyAJTUFDCm9wdGlv bnMgCU1BQ19ERUJVRwpvcHRpb25zIAlVRlNfRVhUQVRUUgpvcHRpb25zIAlVRlNfRVhUQVRUUl9B VVRPU1RBUlQKb3B0aW9ucyAgICAgICAgIFNDSEVEXzRCU0QgICAgICAgICAgICAgICM0QlNEIHNj aGVkdWxlcgpvcHRpb25zIAlJTkVUCQkJI0ludGVyTkVUd29ya2luZwpvcHRpb25zIAlJTkVUNgkJ CSNJUHY2IGNvbW11bmljYXRpb25zIHByb3RvY29scwpvcHRpb25zIAlGRlMJCQkjQmVya2VsZXkg RmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjRW5hYmxlIEZGUyBzb2Z0IHVw ZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJI1N1cHBvcnQgZm9yIGFjY2VzcyBjb250 cm9sIGxpc3RzCm9wdGlvbnMgCVVGU19ESVJIQVNICQkjSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBi aWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAJTURfUk9PVAkJCSNNRCBpcyBhIHBvdGVudGlhbCByb290 IGRldmljZQpvcHRpb25zIAlORlNDTElFTlQJCSNOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50CiNv cHRpb25zIAlORlNTRVJWRVIJCSNOZXR3b3JrIEZpbGVzeXN0ZW0gU2VydmVyCm9wdGlvbnMgCU5G U19ST09UCQkjTkZTIHVzYWJsZSBhcyByb290IGRldmljZSwgcmVxdWlyZXMgTkZTQ0xJRU5UCm9w dGlvbnMgCU1TRE9TRlMJCQkjTVNET1MgRmlsZXN5c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjSVNP IDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlQUk9DRlMJCQkjUHJvY2VzcyBmaWxlc3lzdGVtIChy ZXF1aXJlcyBQU0VVRE9GUykKb3B0aW9ucyAJUFNFVURPRlMJCSNQc2V1ZG8tZmlsZXN5c3RlbSBm cmFtZXdvcmsKb3B0aW9ucyAJQ09NUEFUXzQzCQkjQ29tcGF0aWJsZSB3aXRoIEJTRCA0LjMgW0tF RVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJI0NvbXBhdGlibGUgd2l0aCBGcmVl QlNENApvcHRpb25zIAlTQ1NJX0RFTEFZPTE1MDAwCSNEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9i aW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJI2t0cmFjZSgxKSBzdXBwb3J0Cm9wdGlvbnMgCVNZ U1ZTSE0JCQkjU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjU1lT Vi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJI1NZU1Ytc3R5bGUgc2Vt YXBob3JlcwpvcHRpb25zIAlfS1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcgI1Bvc2l4IFAxMDAz XzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0 YWxsIGEgQ0RFViBlbnRyeSBpbiAvZGV2Cm9wdGlvbnMgCUFIQ19SRUdfUFJFVFRZX1BSSU5UCSMg UHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4x MjhrIHRvIGRyaXZlci4Kb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdp c3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFkZHMgfjIxNWsgdG8gZHJp dmVyLgoKIyBEZWJ1Z2dpbmcgZm9yIHVzZSBpbiAtY3VycmVudApvcHRpb25zIAlBTFRfQlJFQUtf VE9fREVCVUdHRVIKb3B0aW9ucyAJQlJFQUtfVE9fREVCVUdHRVIKb3B0aW9ucyAJRERCCQkJI0Vu YWJsZSB0aGUga2VybmVsIGRlYnVnZ2VyCm9wdGlvbnMgCUlOVkFSSUFOVFMJCSNFbmFibGUgY2Fs bHMgb2YgZXh0cmEgc2FuaXR5IGNoZWNraW5nCm9wdGlvbnMgCUlOVkFSSUFOVF9TVVBQT1JUCSNF eHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElO VkFSSUFOVFMKb3B0aW9ucyAJV0lUTkVTUwkJCSNFbmFibGUgY2hlY2tzIHRvIGRldGVjdCBkZWFk bG9ja3MgYW5kIGN5Y2xlcwpvcHRpb25zIAlXSVRORVNTX1NLSVBTUElOCSNEb24ndCBydW4gd2l0 bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkCgojIFRvIG1ha2UgYW4gU01QIGtlcm5lbCwgdGhl IG5leHQgdHdvIGFyZSBuZWVkZWQKI29wdGlvbnMgCVNNUAkJCSMgU3ltbWV0cmljIE11bHRpUHJv Y2Vzc29yIEtlcm5lbAojb3B0aW9ucyAJQVBJQ19JTwkJCSMgU3ltbWV0cmljIChBUElDKSBJL08K CmRldmljZQkJaXNhCmRldmljZQkJZWlzYQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCmRl dmljZQkJZmRjCgojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0YQpkZXZpY2UJCWF0 YWRpc2sJCQkjIEFUQSBkaXNrIGRyaXZlcwpkZXZpY2UJCWF0YXBpY2QJCQkjIEFUQVBJIENEUk9N IGRyaXZlcwpkZXZpY2UJCWF0YXBpZmQJCQkjIEFUQVBJIGZsb3BweSBkcml2ZXMKZGV2aWNlCQlh dGFwaXN0CQkJIyBBVEFQSSB0YXBlIGRyaXZlcwpvcHRpb25zIAlBVEFfU1RBVElDX0lECQkjU3Rh dGljIGRldmljZSBudW1iZXJpbmcKCiMgU0NTSSBDb250cm9sbGVycwpkZXZpY2UJCWFoYgkJIyBF SVNBIEFIQTE3NDIgZmFtaWx5CmRldmljZQkJYWhjCQkjIEFIQTI5NDAgYW5kIG9uYm9hcmQgQUlD N3h4eCBkZXZpY2VzCmRldmljZQkJYWhkCQkjIEFIQTM5MzIwLzI5MzIwIGFuZCBvbmJvYXJkIEFJ Qzc5eHggZGV2aWNlcwpkZXZpY2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQp KQpkZXZpY2UJCWlzcAkJIyBRbG9naWMgZmFtaWx5CmRldmljZQkJbXB0CQkjIExTSS1Mb2dpYyBN UFQtRnVzaW9uCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3ltYmlvcyBMb2dpYwpkZXZpY2UJCXN5bQkJ IyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMgKyB0aG9zZSBvZiBgbmNyJykKZGV2 aWNlCQl0cm0JCSMgVGVrcmFtIERDMzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoKZGV2aWNlCQlh ZHYJCSMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycwpkZXZpY2UJCWFkdwkJIyBBZHZhbnN5cyB3aWRl IFNDU0kgYWRhcHRlcnMKZGV2aWNlCQlhaGEJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMK ZGV2aWNlCQlhaWMJCSMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFkYXB0ZXJzLCBBSUMtNlsyM102 MC4KZGV2aWNlCQlidAkJIyBCdXNsb2dpYy9NeWxleCBNdWx0aU1hc3RlciBTQ1NJIGFkYXB0ZXJz CgpkZXZpY2UJCW5jdgkJIyBOQ1IgNTNDNTAwCmRldmljZQkJbnNwCQkjIFdvcmtiaXQgTmluamEg U0NTSS0zCmRldmljZQkJc3RnCQkjIFRNQyAxOEMzMC8xOEM1MAoKIyBSQUlEIGNvbnRyb2xsZXJz IGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vic3lzdGVtCmRldmljZQkJYXNyCQkjIERQVCBTbWFy dFJBSUQgViwgVkkgYW5kIEFkYXB0ZWMgU0NTSSBSQUlECmRldmljZQkJY2lzcwkJIyBDb21wYXEg U21hcnQgUkFJRCA1KgpkZXZpY2UJCWRwdAkJIyBEUFQgU21hcnRjYWNoZSBJSUksIElWIC0gU2Vl IE5PVEVTIGZvciBvcHRpb25zIQpkZXZpY2UJCWlpcgkJIyBJbnRlbCBJbnRlZ3JhdGVkIFJBSUQK ZGV2aWNlCQltbHkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRAoKIyBTQ1NJIHBlcmlw aGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkKQpkZXZpY2UJCWNoCQkj IFNDU0kgbWVkaWEgY2hhbmdlcnMKZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykK ZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpCmRldmljZQkJY2QJCSMg Q0QKZGV2aWNlCQlwYXNzCQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNz KQpkZXZpY2UJCXNlcwkJIyBTQ1NJIEVudmlyb25tZW50YWwgU2VydmljZXMgKGFuZCBTQUYtVEUp CgojIFJBSUQgY29udHJvbGxlcnMKZGV2aWNlCQlhYWMJCSMgQWRhcHRlYyBGU0EgUkFJRApkZXZp Y2UJCWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pCmRldmlj ZQkJYW1yCQkjIEFNSSBNZWdhUkFJRApkZXZpY2UJCWlkYQkJIyBDb21wYXEgU21hcnQgUkFJRApk ZXZpY2UJCW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5CmRldmljZQkJcHN0CQkjIFByb21pc2Ug U3VwZXJ0cmFrIFNYNjAwMApkZXZpY2UJCXR3ZQkJIyAzd2FyZSBBVEEgUkFJRAoKIyBhdGtiZGMw IGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUgUFMvMiBtb3VzZQpkZXZpY2UJCWF0 a2JkYwkJIyBBVCBrZXlib2FyZCBjb250cm9sbGVyCmRldmljZQkJYXRrYmQJCSMgQVQga2V5Ym9h cmQKZGV2aWNlCQlwc20JCSMgUFMvMiBtb3VzZQoKZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNh cmQgZHJpdmVyCgpkZXZpY2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2 ZXIgc3VwcG9ydAoKIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNl bWJsaW5nIGFuIFNDTyBjb25zb2xlCmRldmljZQkJc2MKCiMgRW5hYmxlIHRoaXMgZm9yIHRoZSBw Y3Z0IChWVDIyMCBjb21wYXRpYmxlKSBjb25zb2xlIGRyaXZlcgojZGV2aWNlCQl2dAojb3B0aW9u cyAJWFNFUlZFUgkJCSMgc3VwcG9ydCBmb3IgWCBzZXJ2ZXIgb24gYSB2dCBjb25zb2xlCiNvcHRp b25zIAlGQVRfQ1VSU09SCQkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29yCgpkZXZpY2UJCWFncAkJ IyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEZsb2F0aW5nIHBvaW50IHN1cHBvcnQg LSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgKCiMgUG93ZXIgbWFuYWdlbWVudCBzdXBwb3J0 IChzZWUgTk9URVMgZm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJYXBtCiMgQWRkIHN1c3BlbmQv cmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1NC4KZGV2aWNlCQlwbXRpbWVyCgojIFBDQ0FSRCAo UENNQ0lBKSBzdXBwb3J0CiMgUGNtY2lhIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0CmRldmlj ZQkJY2JiCQkJIyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlCiNkZXZpY2UJCXBjaWMJCQkjIEV4Q0Eg SVNBIGFuZCBQQ0kgYnJpZGdlcwpkZXZpY2UJCXBjY2FyZAkJCSMgUEMgQ2FyZCAoMTYtYml0KSBi dXMKZGV2aWNlCQljYXJkYnVzCQkJIyBDYXJkQnVzICgzMi1iaXQpIGJ1cwoKIyBTZXJpYWwgKENP TSkgcG9ydHMKZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZbNDVdNTAgYmFzZWQgc2VyaWFsIHBvcnRz CgojIFBhcmFsbGVsIHBvcnQKZGV2aWNlCQlwcGMKZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBw b3J0IGJ1cyAocmVxdWlyZWQpCmRldmljZQkJbHB0CQkjIFByaW50ZXIKZGV2aWNlCQlwbGlwCQkj IFRDUC9JUCBvdmVyIHBhcmFsbGVsCmRldmljZQkJcHBpCQkjIFBhcmFsbGVsIHBvcnQgaW50ZXJm YWNlIGRldmljZQojZGV2aWNlCQl2cG8JCSMgUmVxdWlyZXMgc2NidXMgYW5kIGRhCgoKIyBQQ0kg RXRoZXJuZXQgTklDcy4KZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcn KQpkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIGFkYXB0ZXIgR2lnYWJpdCBFdGhlcm5ldCBD YXJkCmRldmljZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykKZGV2aWNlCQl2eAkJ IyAzQ29tIDNjNTkwLCAzYzU5NSAoYGBWb3J0ZXgnJykKCiMgUENJIEV0aGVybmV0IE5JQ3MgdGhh dCB1c2UgdGhlIGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4KIyBOT1RFOiBCZSBzdXJl IHRvIGtlZXAgdGhlICdkZXZpY2UgbWlpYnVzJyBsaW5lIGluIG9yZGVyIHRvIHVzZSB0aGVzZSBO SUNzIQpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQKZGV2aWNlCQlkYwkJIyBERUMv SW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29ya2FsaWtlcwpkZXZpY2UJCWZ4cAkJIyBJbnRlbCBF dGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKZGV2aWNlCQlwY24JCSMgQU1EIEFt NzlDOTd4IFBDSSAxMC8xMDAgKHByZWNlZGVuY2Ugb3ZlciAnbG5jJykKZGV2aWNlCQlybAkJIyBS ZWFsVGVrIDgxMjkvODEzOQpkZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3RhcmZp cmUnJykKZGV2aWNlCQlzaXMJCSMgU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9T aVMgNzAxNgpkZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBUWCkK ZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVyTEFOCmRldmljZQkJdHgJCSMg U01DIEV0aGVyUG93ZXIgSUkgKDgzYzE3MCBgYEVQSUMnJykKZGV2aWNlCQl2cgkJIyBWSUEgUmhp bmUsIFJoaW5lIElJCmRldmljZQkJd2IJCSMgV2luYm9uZCBXODlDODQwRgpkZXZpY2UJCXhsCQkj IDNDb20gM2M5MHggKGBgQm9vbWVyYW5nJycsIGBgQ3ljbG9uZScnKQpkZXZpY2UJCWJnZQkJIyBC cm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVybmV0CgojIElTQSBFdGhlcm5ldCBOSUNzLiAg cGNjYXJkIG5pY3MgaW5jbHVkZWQuCmRldmljZQkJY3MJCSMgQ3J5c3RhbCBTZW1pY29uZHVjdG9y IENTODl4MCBOSUMKIyAnZGV2aWNlIGVkJyByZXF1aXJlcyAnZGV2aWNlIG1paWJ1cycKZGV2aWNl CQllZAkJIyBORVsxMl0wMDAsIFNNQyBVbHRyYSwgM2M1MDMsIERTODM5MCBjYXJkcwpkZXZpY2UJ CWV4CQkjIEludGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsKZGV2aWNlCQllcAkJ IyBFdGhlcmxpbmsgSUlJIGJhc2VkIGNhcmRzCmRldmljZQkJZmUJCSMgRnVqaXRzdSBNQjg2OTZ4 IGJhc2VkIGNhcmRzCmRldmljZQkJbG5jCQkjIE5FMjEwMCwgTkUzMi1WTCBMYW5jZSBFdGhlcm5l dCBjYXJkcwpkZXZpY2UJCXNuCQkjIFNNQydzIDkwMDAgc2VyaWVzIG9mIGV0aGVybmV0IGNoaXBz CmRldmljZQkJeGUJCSMgWGlyY29tIHBjY2FyZCBldGhlcm5ldAoKIyBJU0EgZGV2aWNlcyB0aGF0 IHVzZSB0aGUgb2xkIElTQSBzaGltcwojZGV2aWNlCQlsZQoKIyBXaXJlbGVzcyBOSUMgY2FyZHMK ZGV2aWNlCQl3bGFuCQkjIDgwMi4xMSBzdXBwb3J0CmRldmljZQkJYW4JCSMgQWlyb25ldCA0NTAw LzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3MuIApkZXZpY2UJCWF3aQkJIyBCYXlTdGFjayA2NjAg YW5kIG90aGVycwpkZXZpY2UJCXdpCQkjIFdhdmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3 aXJlbGVzcyBOSUNzLgojZGV2aWNlCQl3bAkJIyBPbGRlciBub24gODAyLjExIFdhdmVsYW4gd2ly ZWxlc3MgTklDLgoKIyBQc2V1ZG8gZGV2aWNlcyAtIHRoZSBudW1iZXIgaW5kaWNhdGVzIGhvdyBt YW55IHVuaXRzIHRvIGFsbG9jYXRlLgpkZXZpY2UJCXJhbmRvbQkJIyBFbnRyb3B5IGRldmljZQpk ZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpkZXZpY2UJCWV0aGVyCQkjIEV0aGVybmV0 IHN1cHBvcnQKI2RldmljZQkJc2wJCSMgS2VybmVsIFNMSVAKI2RldmljZQkJcHBwCQkjIEtlcm5l bCBQUFAKZGV2aWNlCQl0dW4JCSMgUGFja2V0IHR1bm5lbC4KZGV2aWNlCQlwdHkJCSMgUHNldWRv LXR0eXMgKHRlbG5ldCBldGMpCmRldmljZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKI2RldmljZQkJ Z2lmCQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nCiNkZXZpY2UJCWZhaXRoCQkjIElQdjYtdG8t SVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pCgojIFRoZSBgYnBmJyBkZXZpY2UgZW5hYmxlcyB0 aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4KIyBCZSBhd2FyZSBvZiB0aGUgYWRtaW5pc3RyYXRp dmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5 IHBhY2tldCBmaWx0ZXIKCiMgVVNCIHN1cHBvcnQKZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5V U0IgaW50ZXJmYWNlCmRldmljZQkJb2hjaQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZp Y2UJCXVzYgkJIyBVU0IgQnVzIChyZXF1aXJlZCkKI2RldmljZQkJdWRicAkJIyBVU0IgRG91Ymxl IEJ1bGsgUGlwZSBkZXZpY2VzCmRldmljZQkJdWdlbgkJIyBHZW5lcmljCmRldmljZQkJdWhpZAkJ IyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiCmRldmljZQkJdWtiZAkJIyBLZXlib2FyZApkZXZp Y2UJCXVscHQJCSMgUHJpbnRlcgpkZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAt IFJlcXVpcmVzIHNjYnVzIGFuZCBkYQpkZXZpY2UJCXVtcwkJIyBNb3VzZQpkZXZpY2UJCXVyaW8J CSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXIKZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5uZXJz CiMgVVNCIEV0aGVybmV0LCByZXF1aXJlcyBtaWkKZGV2aWNlCQlhdWUJCSMgQURNdGVrIFVTQiBl dGhlcm5ldApkZXZpY2UJCWN1ZQkJIyBDQVRDIFVTQiBldGhlcm5ldApkZXZpY2UJCWt1ZQkJIyBL YXdhc2FraSBMU0kgVVNCIGV0aGVybmV0Cg== ------=_20030928132021_47004-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 14:22:11 2003 Return-Path: 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 E812216A4B3; Sun, 28 Sep 2003 14:22:11 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB9744011; Sun, 28 Sep 2003 14:22:10 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8SLM7LG000654; Sun, 28 Sep 2003 23:22:08 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Date: Sun, 28 Sep 2003 23:22:07 +0200 Message-ID: <653.1064784127@critter.freebsd.dk> Subject: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 21:22:12 -0000 I am in the process of adding ref-counting and locking to dev_t, and would very much prefer if we could get this step completed soon before 5-STABLE gets branched. All this will be transparent to the majority of device drivers, as the refcounting will happen in the make_dev() and destroy_dev() family of calls and normal drivers need not know more about it. But there are a few remaining users of makedev() which get in the way of this effort, and we must get these fixed. Basically: 1. Do not call makedev(). 2. If you do cloning, please look at the patches I posted for if_tun/if_tap for how to do it. 3. If you do a "normal" device driver, cache the result from when you call make_dev(). 4. If you translate "foreign dev_t's", ie emulators or compat code, contact me. I'm not sure I understand how this works and should work and we need to talk. 5. If anything else or in doubt, ask me. Can I see some volounteers and/or maintainers please ? ./alpha/osf1/osf1_misc.c badly named local macro ? ./compat/linux/linux_stats.c ./compat/svr4/svr4_types.h compat code, not sure that this is correct now. Must be supported by new "finddev" semantics. ./dev/ata/atapi-cd.c cloning related to root mount. gets fixed when phk GEOMify the driver. ./dev/sound/midi/midi.h Not sure. ./dev/nmdm/nmdm.c pseudo-cloning. Should do real cloning. ./dev/syscons/syscons.c Related to console initialization. Maybe tricky. ./dev/sound/pcm/dsp.c ./dev/sound/pcm/mixer.c ./dev/usb/ugen.c ./dev/usb/uscanner.c Failure to cache result of make_dev() ./dev/vinum Failure to cache result of make_dev() ? Thanks in advance! -- 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 Sun Sep 28 16:00:22 2003 Return-Path: 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 3991B16A4B3; Sun, 28 Sep 2003 16:00:22 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDEC544005; Sun, 28 Sep 2003 16:00:11 -0700 (PDT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 26F442BD41; Mon, 29 Sep 2003 09:00:10 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 448F451836; Mon, 29 Sep 2003 08:30:08 +0930 (CST) Date: Mon, 29 Sep 2003 08:30:08 +0930 From: Greg 'groggy' Lehey To: Poul-Henning Kamp Message-ID: <20030928230008.GF11520@wantadilla.lemis.com> References: <653.1064784127@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yRA+Bmk8aPhU85Qt" Content-Disposition: inline In-Reply-To: <653.1064784127@critter.freebsd.dk> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 23:00:22 -0000 --yRA+Bmk8aPhU85Qt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: > Basically: > > 3. If you do a "normal" device driver, cache the result > from when you call make_dev(). > ... > > ./dev/vinum > Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. --yRA+Bmk8aPhU85Qt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/d2f4IubykFB6QiMRAtOjAKCy3rqkpXqlVw5agPI79MRIas32WgCeLZHP ZHxDJyRTuPKCbv3tyIiOdM0= =i3ZG -----END PGP SIGNATURE----- --yRA+Bmk8aPhU85Qt-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 16:38:36 2003 Return-Path: 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 AE2B916A4B3; Sun, 28 Sep 2003 16:38:36 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7E8A44015; Sun, 28 Sep 2003 16:38:34 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h8SNcPFs078206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 29 Sep 2003 01:38:30 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h8SNcOWZ080261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2003 01:38:25 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h8SNcOrY014878; Mon, 29 Sep 2003 01:38:24 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h8SNcNwT014877; Mon, 29 Sep 2003 01:38:23 +0200 (CEST) Date: Mon, 29 Sep 2003 01:38:23 +0200 From: Bernd Walter To: Poul-Henning Kamp Message-ID: <20030928233823.GJ90598@cicely12.cicely.de> References: <653.1064784127@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <653.1064784127@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 23:38:36 -0000 On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: > > I am in the process of adding ref-counting and locking to dev_t, > and would very much prefer if we could get this step completed > soon before 5-STABLE gets branched. > > All this will be transparent to the majority of device drivers, as > the refcounting will happen in the make_dev() and destroy_dev() > family of calls and normal drivers need not know more about it. > > But there are a few remaining users of makedev() which get in the > way of this effort, and we must get these fixed. > > Basically: > > 1. Do not call makedev(). > > 2. If you do cloning, please look at the patches I posted > for if_tun/if_tap for how to do it. > > 3. If you do a "normal" device driver, cache the result > from when you call make_dev(). > > 4. If you translate "foreign dev_t's", ie emulators or > compat code, contact me. I'm not sure I understand > how this works and should work and we need to talk. > > 5. If anything else or in doubt, ask me. > > Can I see some volounteers and/or maintainers please ? > > ./alpha/osf1/osf1_misc.c > badly named local macro ? Unused code. umakedev is used within a macro but nowhere defined it seems. makedev is used as a macroname, but ifdef'ed 0. Shouldn't hurt. Maybe someone with knowledge about OSF1 emulation should decide what happens with them in the long run. > ./dev/usb/ugen.c > ./dev/usb/uscanner.c > Failure to cache result of make_dev() I'll take those. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 16:46:51 2003 Return-Path: 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 2DD4516A4B3; Sun, 28 Sep 2003 16:46:51 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2079F44022; Sun, 28 Sep 2003 16:46:50 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h8SNkK7R086827; Sun, 28 Sep 2003 19:46:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h8SNkKju086824; Sun, 28 Sep 2003 19:46:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 28 Sep 2003 19:46:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Greg 'groggy' Lehey" In-Reply-To: <20030928230008.GF11520@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: current@FreeBSD.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 23:46:51 -0000 On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: > On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: > > Basically: > > > > 3. If you do a "normal" device driver, cache the result > > from when you call make_dev(). > > ... > > > > ./dev/vinum > > Failure to cache result of make_dev() ? > > Where should this be cached? Can you point to example code? Actually, it looks like Vinum is caching the dev_t's, but it's not always using them to get back to the dev_t--sometimes it's invoking makedev() instead. However, this appears to happen only in the vinumrevive.c code, so I'm not sure if that's a property of the cached reference being unavailable -- it looks like it should be available in that context though. I.e., using sd->dev instead of VINUM_SD() -- it looks like there is a valid (struct sd *) reference there to follow, so you can get to the dev_t without doing a makedev(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 16:59:12 2003 Return-Path: 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 AA0F916A4B3; Sun, 28 Sep 2003 16:59:12 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C2674403F; Sun, 28 Sep 2003 16:59:11 -0700 (PDT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 44B7E2BD41; Mon, 29 Sep 2003 09:59:09 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 73D0351836; Mon, 29 Sep 2003 09:29:06 +0930 (CST) Date: Mon, 29 Sep 2003 09:29:06 +0930 From: Greg 'groggy' Lehey To: Robert Watson Message-ID: <20030928235906.GG11520@wantadilla.lemis.com> References: <20030928230008.GF11520@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S5HS5MvDw4DmbRmb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: current@FreeBSD.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2003 23:59:12 -0000 --S5HS5MvDw4DmbRmb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 28 September 2003 at 19:46:20 -0400, Robert Watson wrote: > > On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: > >> On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: >>> Basically: >>> >>> 3. If you do a "normal" device driver, cache the result >>> from when you call make_dev(). >>> ... >>> >>> ./dev/vinum >>> Failure to cache result of make_dev() ? >> >> Where should this be cached? Can you point to example code? > > Actually, it looks like Vinum is caching the dev_t's, Ah, you mean saving the results rather than calling make_dev() every time? Yes, it only calls make_dev() once for any device. > but it's not always using them to get back to the dev_t--sometimes > it's invoking makedev() instead. However, this appears to happen > only in the vinumrevive.c code, so I'm not sure if that's a property > of the cached reference being unavailable it looks like it should be > available in that context though. No, it should always be available. I was going to say "I don't see any references to make_dev() in vinumrevive.c, nor any references to makedev() at all", but I see that VINUM_SD includes both. > I.e., using sd->dev instead of VINUM_SD() -- it looks like there is > a valid (struct sd *) reference there to follow, so you can get to > the dev_t without doing a makedev(). Yes, this is a bug (and an indication of the dangers of using macros :-) I'll fix it. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. --S5HS5MvDw4DmbRmb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/d3XKIubykFB6QiMRAm5CAKCPLcOmXQlsNb4IVNsJz2Wx1ip2SQCfTBtE E5DAbhM6C3Lms7NO/7/bJn0= =SbzM -----END PGP SIGNATURE----- --S5HS5MvDw4DmbRmb-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 28 22:12:25 2003 Return-Path: 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 0E92B16A4B3; Sun, 28 Sep 2003 22:12:25 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B02F44015; Sun, 28 Sep 2003 22:12:23 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8T5CKLG004323; Mon, 29 Sep 2003 07:12:21 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Greg 'groggy' Lehey" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 29 Sep 2003 08:30:08 +0930." <20030928230008.GF11520@wantadilla.lemis.com> Date: Mon, 29 Sep 2003 07:12:20 +0200 Message-ID: <4322.1064812340@critter.freebsd.dk> cc: arch@FreeBSD.org cc: current@FreeBSD.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2003 05:12:25 -0000 In message <20030928230008.GF11520@wantadilla.lemis.com>, "Greg 'groggy' Lehey" writes: > >--yRA+Bmk8aPhU85Qt >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: >> Basically: >> >> 3. If you do a "normal" device driver, cache the result >> from when you call make_dev(). >> ... >> >> ./dev/vinum >> Failure to cache result of make_dev() ? > >Where should this be cached? Can you point to example code? Almost any other device driver. It is usually stored in the softc structure. -- 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 Mon Sep 29 18:01:33 2003 Return-Path: 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 908EC16A4B3; Mon, 29 Sep 2003 18:01:33 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E33E343FFD; Mon, 29 Sep 2003 18:01:32 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8U11Sgg031863; Mon, 29 Sep 2003 18:01:28 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8U11SML031862; Mon, 29 Sep 2003 18:01:28 -0700 Date: Mon, 29 Sep 2003 18:01:28 -0700 From: Brooks Davis To: arch@freebsd.org, net@freebsd.org Message-ID: <20030930010128.GA31222@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 01:01:33 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Six years and eight months ago, net/if.h was split into if.h and if_var.h. At the time, if_var.h was included at the end if if.h as follows (this is the current code, but it's equivalent): #ifdef _KERNEL struct thread; /* XXX - this should go away soon. */ #include #endif Unfortunately, "soon" hasn't happened yet and it is now tripping me up. To add the if_dev member to struct ifnet (see the forthcoming post on that subject), it is necessary for sys/bus.h to be included in net/if_var.h which in turn requires that if_var.h NOT be included in genassym.c. Since if.h must be included for nfsdiskless support, this means we need to finish the job and remove the include if_var.h from if.h. It involves editing a large number of files, but over all it's pretty mechanical as it simple includes adding and include of if_var.h after the if.h include in files that break after the change. Does this sound reasonable? -- Brooks P.S. The alternative is to add a second typedef of device_t to if_var.h. It's an ugly solution since it and the definition in sys/bus.h would have to look like the one below, but it would be a heck of a lot easier. #ifndef _DEVICE_T_DECLARED typedef struct device *device_t; #define _DEVICE_T_DECLARED #endif --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eNXlXY6L6fI4GtQRArpKAJ9renTX9Wzn1Ui/mMg0wKCGANXpngCfQhu1 ACJ4kydQbKRn3SJuqNmFtRY= =eusb -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 18:03:44 2003 Return-Path: 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 346C816A4B3; Mon, 29 Sep 2003 18:03:44 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7405344003; Mon, 29 Sep 2003 18:03:43 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8U13dgg032414; Mon, 29 Sep 2003 18:03:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8U13deH032400; Mon, 29 Sep 2003 18:03:39 -0700 Date: Mon, 29 Sep 2003 18:03:39 -0700 From: Brooks Davis To: arch@freebsd.org, net@freebsd.org Message-ID: <20030930010327.GB31222@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 01:03:44 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Previously posted to -net in another form.] I propose to add an if_dev member to struct ifnet. It would be of type device_t and be defined to point to the device for the interface or NULL if there is no device (or if there was not an easy way to get access to one). This change would codify the the relationship between an interface and the underlying physical device. It also would get rid of the existing abuses of if_name to look up the driver associated with an interface and simplify a number of messy cases in the conversion from if_unit and if_name to if_xname. Does this seem like a reasonable thing to do? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eNY0XY6L6fI4GtQRAvgoAKDB7TmwAKtFcJiIA0DdfHM1GSrciACdFisT 0J9J5j/DNVyvh3P9BDxu8jI= =UIKO -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 19:39:13 2003 Return-Path: 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 0FBEE16A4B3; Mon, 29 Sep 2003 19:39:13 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A6A04400F; Mon, 29 Sep 2003 19:39:12 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p1/8.12.9) with ESMTP id h8U2dAAD083646; Mon, 29 Sep 2003 20:39:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 29 Sep 2003 20:39:12 -0600 (MDT) Message-Id: <20030929.203912.32174985.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20030930010128.GA31222@Odin.AC.HMC.Edu> References: <20030930010128.GA31222@Odin.AC.HMC.Edu> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 02:39:13 -0000 In message: <20030930010128.GA31222@Odin.AC.HMC.Edu> Brooks Davis writes: : Six years and eight months ago, net/if.h was split into if.h and : if_var.h. At the time, if_var.h was included at the end if if.h as : follows (this is the current code, but it's equivalent): ... : Does this sound reasonable? I'd go ahead and finish the split. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 23:45:11 2003 Return-Path: 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 4F3F116A4B3; Mon, 29 Sep 2003 23:45:11 -0700 (PDT) Received: from mwinf0603.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E1BD43FA3; Mon, 29 Sep 2003 23:45:10 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from venus.vincentjardin.net (AVelizy-102-1-2-196.w217-128.abo.wanadoo.fr [217.128.206.196]) by mwinf0603.wanadoo.fr (SMTP Server) with ESMTP id 8EE93240010C; Tue, 30 Sep 2003 08:45:08 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Brooks Davis , arch@freebsd.org, net@freebsd.org Date: Tue, 30 Sep 2003 10:45:15 +0200 User-Agent: KMail/1.4.3 References: <20030930010327.GB31222@Odin.AC.HMC.Edu> In-Reply-To: <20030930010327.GB31222@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200309301045.15776.vjardin@wanadoo.fr> Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 06:45:11 -0000 Le Mardi 30 Septembre 2003 03:03, Brooks Davis a =E9crit : > [Previously posted to -net in another form.] > > I propose to add an if_dev member to struct ifnet. It would be of type > device_t and be defined to point to the device for the interface or NUL= L > if there is no device (or if there was not an easy way to get access to > one). > > This change would codify the the relationship between an interface and > the underlying physical device. It also would get rid of the existing > abuses of if_name to look up the driver associated with an interface > and simplify a number of messy cases in the conversion from if_unit and > if_name to if_xname. > > Does this seem like a reasonable thing to do? Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover= it=20 sounds a good idea to have the if_dev field into the ifnet structure. Regards, Vincent From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 00:10:59 2003 Return-Path: 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 3D19816A4B3; Tue, 30 Sep 2003 00:10:59 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA96043FA3; Tue, 30 Sep 2003 00:10:57 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8U7AsOP008476; Tue, 30 Sep 2003 09:10:54 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Vincent Jardin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Sep 2003 10:45:15 +0200." <200309301045.15776.vjardin@wanadoo.fr> Date: Tue, 30 Sep 2003 09:10:54 +0200 Message-ID: <8475.1064905854@critter.freebsd.dk> cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 07:10:59 -0000 In message <200309301045.15776.vjardin@wanadoo.fr>, Vincent Jardin writes: >Le Mardi 30 Septembre 2003 03:03, Brooks Davis a écrit : >> [Previously posted to -net in another form.] >> >> I propose to add an if_dev member to struct ifnet. It would be of type >> device_t and be defined to point to the device for the interface or NULL >> if there is no device (or if there was not an easy way to get access to >> one). >> >> This change would codify the the relationship between an interface and >> the underlying physical device. It also would get rid of the existing >> abuses of if_name to look up the driver associated with an interface >> and simplify a number of messy cases in the conversion from if_unit and >> if_name to if_xname. >> >> Does this seem like a reasonable thing to do? > >Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover it >sounds a good idea to have the if_dev field into the ifnet structure. Somebody please explain how this would work for non-hardware interfaces like if_loop, if_tun, if_tap etc ? device_t is what we use to hitch drivers to hardware. ifnet is what we use to hitch drivers to the netstack. They should not be tangled. -- 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 Tue Sep 30 01:24:12 2003 Return-Path: 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 53F4F16A4B3; Tue, 30 Sep 2003 01:24:12 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA83743F93; Tue, 30 Sep 2003 01:24:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id SAA04609; Tue, 30 Sep 2003 18:23:57 +1000 Date: Tue, 30 Sep 2003 18:22:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Brooks Davis In-Reply-To: <20030930010128.GA31222@Odin.AC.HMC.Edu> Message-ID: <20030930172536.U3713@gamplex.bde.org> References: <20030930010128.GA31222@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 08:24:12 -0000 On Mon, 29 Sep 2003, Brooks Davis wrote: > Six years and eight months ago, net/if.h was split into if.h and > if_var.h. At the time, if_var.h was included at the end if if.h as > follows (this is the current code, but it's equivalent): > > #ifdef _KERNEL > struct thread; > > /* XXX - this should go away soon. */ > #include > #endif > > Unfortunately, "soon" hasn't happened yet and it is now tripping me > up. To add the if_dev member to struct ifnet (see the forthcoming > post on that subject), it is necessary for sys/bus.h to be included in > net/if_var.h That would be namespace pollution, so it is not permitted :-). Requiring all files that include (and especially to include would be interface breakage so it is even less permitted. > which in turn requires that if_var.h NOT be included in > genassym.c. Do you mean in userland? There don't seem to be any immediate problems for genassym.c or any other file in the kernel from including unconditionally in . However, the pollution may be harmful for userland. In fact, including would just not work for userland, since the declaration of device_t is only made in the _KERNEL case, so use of it in struct ifnet (which is exported to userland for some reason) would be a syntax error in userland whether or not is included. Oops, doesn't include in the !_KERNEL case, so the problem is a little different... > Since if.h must be included for nfsdiskless support, this > means we need to finish the job and remove the include if_var.h from > if.h. It involves editing a large number of files, but over all it's > pretty mechanical as it simple includes adding and include of if_var.h > after the if.h include in files that break after the change. Mechanical removal wouldn't help userland. It has already been done for userland, but too mechanically to actually address the problem of abusing kernel interfaces in in userland. E.g., struct ifnet is (ab)used in netstat at least, so struct ifnet is outside of the _KERNEL ifdef in and adding a device_t to struct ifnet would expose even more kernel internals to userland. Since correctly doesn't declare device-t in the !_KERNEL case, clients like netstat would have to become aware of new magic to declare device_t if doesn't do it itself by some means other than including > P.S. The alternative is to add a second typedef of device_t to if_var.h. > It's an ugly solution since it and the definition in sys/bus.h would > have to look like the one below, but it would be a heck of a lot easier. > > #ifndef _DEVICE_T_DECLARED > typedef struct device *device_t; > #define _DEVICE_T_DECLARED > #endif That's one alternative. (Far too) many places already use the simple alternative of just using "struct device *". Grep shows 68 lines containing "struct device" in *.h and 32 in *.c. For "device_t", the numbers are 2140 in *.h and 5089 in *.c. This is in a sys tree with about 1000 matches of "device_t" in generated files. There are non-bogus uses of "struct device" to avoid namespace pollution in . Most other uses are just bogus (modulo the existence of device_t being non-bogus -- its opaqueness is negative since anything that wants to use it must include and thus can see its internals. style(9) says to not use negatively opaque typedefs). exports lots more kernel internals to userland than 6 years ago. It now exports labels, mutexes and locks. I have only fixed part of this: %%% Index: if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.58 diff -u -2 -r1.58 if_var.h --- if_var.h 1 Jan 2003 18:48:54 -0000 1.58 +++ if_var.h 7 Aug 2003 16:47:54 -0000 @@ -46,7 +46,8 @@ * received from its medium. * - * Output occurs when the routine if_output is called, with three parameters: + * Output occurs when the routine if_output is called: * (*ifp->if_output)(ifp, m, dst, rt) - * Here m is the mbuf chain to be sent and dst is the destination address. + * Here m is the mbuf chain to be sent, dst is the destination address, + * and rt is XXX. * The output routine encapsulates the supplied datagram if necessary, * and then transmits it on its medium. @@ -63,25 +64,23 @@ */ -#ifdef __STDC__ -/* - * Forward structure declarations for function prototypes [sic]. - */ -struct mbuf; -struct thread; +struct ether_header; struct rtentry; struct rt_addrinfo; struct socket; -struct ether_header; -#endif +struct thread; -#include /* struct label */ -#include /* get TAILQ macros */ +#include /* XXX XXX */ +#include #ifdef _KERNEL -#include -#endif /* _KERNEL */ -#include /* XXX */ -#include /* XXX */ -#include /* XXX */ +#include /* XXX */ +#include /* XXX XXX */ +#include /* XXX XXX */ +#include /* XXX XXX */ +#else +#include /* XXX */ +#include /* XXX */ +#include /* XXX */ +#endif TAILQ_HEAD(ifnethead, ifnet); /* we use TAILQs so that the order of */ @@ -116,5 +115,5 @@ * struct ifnet ac_if; * ... - * } ; + * } ; * ... * }; @@ -125,5 +124,4 @@ * Unfortunately devices' softc are opaque, so we depend on this layout * to locate the struct ifnet from the softc in the generic code. - * */ struct ifnet { %%% This only significantly reduces pollution in the !_KERNEL case. Reducing it in the _KERNEL case is much harder. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 07:33:41 2003 Return-Path: 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 1810A16A4C0 for ; Tue, 30 Sep 2003 07:33:41 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E1143FAF for ; Tue, 30 Sep 2003 07:33:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1033 invoked from network); 30 Sep 2003 14:33:38 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Sep 2003 14:33:38 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8UEXY6Y058230; Tue, 30 Sep 2003 10:33:35 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030930172536.U3713@gamplex.bde.org> Date: Tue, 30 Sep 2003 10:33:40 -0400 (EDT) From: John Baldwin To: Bruce Evans X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 14:33:41 -0000 On 30-Sep-2003 Bruce Evans wrote: > On Mon, 29 Sep 2003, Brooks Davis wrote: > >> Six years and eight months ago, net/if.h was split into if.h and >> if_var.h. At the time, if_var.h was included at the end if if.h as >> follows (this is the current code, but it's equivalent): >> >> #ifdef _KERNEL >> struct thread; >> >> /* XXX - this should go away soon. */ >> #include >> #endif >> >> Unfortunately, "soon" hasn't happened yet and it is now tripping me >> up. To add the if_dev member to struct ifnet (see the forthcoming >> post on that subject), it is necessary for sys/bus.h to be included in >> net/if_var.h > > That would be namespace pollution, so it is not permitted :-). Requiring > all files that include (and especially to > include would be interface breakage so it is even less > permitted. Well, if if.h stops including if_var.h, then only kernel files that include net/if_var.h would need sys/bus.h. I think that's manageable. >> which in turn requires that if_var.h NOT be included in >> genassym.c. > > Do you mean in userland? There don't seem to be any immediate problems > for genassym.c or any other file in the kernel from including > unconditionally in . However, the pollution may be harmful > for userland. In fact, including would just not work for > userland, since the declaration of device_t is only made in the _KERNEL > case, so use of it in struct ifnet (which is exported to userland for > some reason) would be a syntax error in userland whether or not > is included. Oops, doesn't include > in the !_KERNEL case, so the problem is a little different... The problem is that the newbus foo_if.h files don't exist when genassym is compiled and used. sys/bus.h needs bus_if.h and device_if.h, hence the breakage. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 07:33:48 2003 Return-Path: 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 5D4C116A4B3 for ; Tue, 30 Sep 2003 07:33:48 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA46243F85 for ; Tue, 30 Sep 2003 07:33:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28020 invoked from network); 30 Sep 2003 14:33:46 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Sep 2003 14:33:46 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8UEXg6Y058235; Tue, 30 Sep 2003 10:33:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <8475.1064905854@critter.freebsd.dk> Date: Tue, 30 Sep 2003 10:33:48 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org cc: Vincent Jardin cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 14:33:48 -0000 On 30-Sep-2003 Poul-Henning Kamp wrote: > In message <200309301045.15776.vjardin@wanadoo.fr>, Vincent Jardin writes: >>Le Mardi 30 Septembre 2003 03:03, Brooks Davis a écrit : >>> [Previously posted to -net in another form.] >>> >>> I propose to add an if_dev member to struct ifnet. It would be of type >>> device_t and be defined to point to the device for the interface or NULL >>> if there is no device (or if there was not an easy way to get access to >>> one). >>> >>> This change would codify the the relationship between an interface and >>> the underlying physical device. It also would get rid of the existing >>> abuses of if_name to look up the driver associated with an interface >>> and simplify a number of messy cases in the conversion from if_unit and >>> if_name to if_xname. >>> >>> Does this seem like a reasonable thing to do? >> >>Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover it >>sounds a good idea to have the if_dev field into the ifnet structure. > > Somebody please explain how this would work for non-hardware > interfaces like if_loop, if_tun, if_tap etc ? > > device_t is what we use to hitch drivers to hardware. > > ifnet is what we use to hitch drivers to the netstack. > > They should not be tangled. You mean like dev_t and device_t shouldn't be tangled like we do with si_drv1? Oh, wait... -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 08:08:38 2003 Return-Path: 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 EA93816A4B3; Tue, 30 Sep 2003 08:08:38 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8529744017; Tue, 30 Sep 2003 08:08:37 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8UF8YOP011375; Tue, 30 Sep 2003 17:08:35 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Sep 2003 10:33:48 EDT." Date: Tue, 30 Sep 2003 17:08:34 +0200 Message-ID: <11374.1064934514@critter.freebsd.dk> cc: arch@FreeBSD.org cc: Vincent Jardin cc: net@FreeBSD.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 15:08:39 -0000 In message , John Baldwin writes: >>>Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover it >>>sounds a good idea to have the if_dev field into the ifnet structure. >> >> Somebody please explain how this would work for non-hardware >> interfaces like if_loop, if_tun, if_tap etc ? >> >> device_t is what we use to hitch drivers to hardware. >> >> ifnet is what we use to hitch drivers to the netstack. >> >> They should not be tangled. > >You mean like dev_t and device_t shouldn't be tangled like we do >with si_drv1? Oh, wait... I don't think any correctly written driver stores it's device_t in a dev_t. It should store it's softc structure, which should contain pointers to both. Even if there is a driver which does do that, it happens inside the device driver, and it does not handicap the remaining device drivers with its choice. If you stick a newbus requirement on "struct ifnet" you suddenly make demands that a lot of our network drivers cannot satisfy. The problem with propagating newbus above the device drivers is that we start postulating a specific relationship between logical devices and physical (ie: a ifnet has exactly one device_t). There is nothing in the "data-model" of the kernel that says that a network interface corresponds to exactly one hardware device and more importantly: there shouldn't be either. If_tun _has_ no physical device, and it would be totally insane to invent a device_t for if_tun, considering that it would not serve any purpose at all, apart from satisfying some peoples craving to have device_t in all data structures in the system. Demanding such a relationship will only make our life more difficult when we get to deal with all the non-standard devices like if_sl, if_ppp, if_ng, if_tun, if_tap which have no device_t, or musycc, a network card where you have to juggle two device_t's, one for the framer and one for the line encoder. As it is now, device_t and newbus provides a good model for our attachment of device drivers to hardware, it's not quite perfect, but it is good enough that nobody can be bothered to sit down and write something perfect. We have "struct ifnet" which describes a network interface, it describes it based on the access model, and it does in fact not care a hoot what implements that interface, hardware, software or bongo drums, it doesn't matter. Similarly, we have "dev_t" to descripe filesystem accessed devices, and it describes those in the terms of the access model, not in terms of what is behind them, hardware, software or bongo drums. If all you want is an extra field in "struct ifnet" to hang driver information on, then by all means add that field. As long as you give it type "void *" and make it private to the driver I have no problem with that. -- 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 Tue Sep 30 08:30:46 2003 Return-Path: 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 B657D16A4BF; Tue, 30 Sep 2003 08:30:46 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0F9344013; Tue, 30 Sep 2003 08:30:41 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id BAA17679; Wed, 1 Oct 2003 01:30:30 +1000 Date: Wed, 1 Oct 2003 01:29:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: Message-ID: <20031001011119.U1245@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 15:30:46 -0000 On Tue, 30 Sep 2003, John Baldwin wrote: > On 30-Sep-2003 Bruce Evans wrote: > > On Mon, 29 Sep 2003, Brooks Davis wrote: > >> Unfortunately, "soon" hasn't happened yet and it is now tripping me > >> up. To add the if_dev member to struct ifnet (see the forthcoming > >> post on that subject), it is necessary for sys/bus.h to be included in > >> net/if_var.h > > > > That would be namespace pollution, so it is not permitted :-). Requiring > > all files that include (and especially to > > include would be interface breakage so it is even less > > permitted. > > Well, if if.h stops including if_var.h, then only kernel files that > include net/if_var.h would need sys/bus.h. I think that's manageable. All userland files that include net/if_var.h would also need it (except they would only need device_t). > >> which in turn requires that if_var.h NOT be included in > >> genassym.c. > > > > Do you mean in userland? There don't seem to be any immediate problems > > for genassym.c or any other file in the kernel from including > > unconditionally in . However, the pollution may be harmful > ... > The problem is that the newbus foo_if.h files don't exist when genassym > is compiled and used. sys/bus.h needs bus_if.h and device_if.h, hence > the breakage. I see. This is a bug in the dependencies for genassym.o and .depend. "make depend" creates *_if.h but it also creates genassym.o. There aren't enough dependencies so the order is mostly accidental. genassym.o happens to get created first, so it doesn't compile unless *_if.h already exist. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:14:34 2003 Return-Path: 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 829B516A4BF for ; Tue, 30 Sep 2003 10:14:34 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB2A43FF5 for ; Tue, 30 Sep 2003 10:14:33 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13174 invoked from network); 30 Sep 2003 17:14:32 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Sep 2003 17:14:32 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8UHES6Y058924; Tue, 30 Sep 2003 13:14:29 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031001011119.U1245@gamplex.bde.org> Date: Tue, 30 Sep 2003 13:14:34 -0400 (EDT) From: John Baldwin To: Bruce Evans X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:14:34 -0000 On 30-Sep-2003 Bruce Evans wrote: > On Tue, 30 Sep 2003, John Baldwin wrote: > >> On 30-Sep-2003 Bruce Evans wrote: >> > On Mon, 29 Sep 2003, Brooks Davis wrote: >> >> Unfortunately, "soon" hasn't happened yet and it is now tripping me >> >> up. To add the if_dev member to struct ifnet (see the forthcoming >> >> post on that subject), it is necessary for sys/bus.h to be included in >> >> net/if_var.h >> > >> > That would be namespace pollution, so it is not permitted :-). Requiring >> > all files that include (and especially to >> > include would be interface breakage so it is even less >> > permitted. >> >> Well, if if.h stops including if_var.h, then only kernel files that >> include net/if_var.h would need sys/bus.h. I think that's manageable. > > All userland files that include net/if_var.h would also need it (except > they would only need device_t). Is struct ifnet exposed to userland? Ugh, why do we export such things? I guess because ifconfig grovels around in the kernel due to a lack of APIs between the kernel and userland. *sigh* >> >> which in turn requires that if_var.h NOT be included in >> >> genassym.c. >> > >> > Do you mean in userland? There don't seem to be any immediate problems >> > for genassym.c or any other file in the kernel from including >> > unconditionally in . However, the pollution may be harmful >> ... >> The problem is that the newbus foo_if.h files don't exist when genassym >> is compiled and used. sys/bus.h needs bus_if.h and device_if.h, hence >> the breakage. > > I see. This is a bug in the dependencies for genassym.o and .depend. > "make depend" creates *_if.h but it also creates genassym.o. There aren't > enough dependencies so the order is mostly accidental. genassym.o happens > to get created first, so it doesn't compile unless *_if.h already exist. I think that genassym shouldn't need anything that includes *_if.h headers, and that if we find ourselves in that situation, perhaps some huge header needs to be split up instead. :) We shouldn't be going near new-bus or kobj in assembly files. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:14:39 2003 Return-Path: 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 6704016A4BF for ; Tue, 30 Sep 2003 10:14:39 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D3A43FBF for ; Tue, 30 Sep 2003 10:14:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5310 invoked from network); 30 Sep 2003 17:14:37 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Sep 2003 17:14:37 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8UHEX6Y058932; Tue, 30 Sep 2003 13:14:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <11374.1064934514@critter.freebsd.dk> Date: Tue, 30 Sep 2003 13:14:39 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org cc: net@FreeBSD.org cc: Vincent Jardin Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:14:39 -0000 On 30-Sep-2003 Poul-Henning Kamp wrote: > In message , John Baldwin writes: > >>>>Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreover it >>>>sounds a good idea to have the if_dev field into the ifnet structure. >>> >>> Somebody please explain how this would work for non-hardware >>> interfaces like if_loop, if_tun, if_tap etc ? >>> >>> device_t is what we use to hitch drivers to hardware. >>> >>> ifnet is what we use to hitch drivers to the netstack. >>> >>> They should not be tangled. >> >>You mean like dev_t and device_t shouldn't be tangled like we do >>with si_drv1? Oh, wait... > > I don't think any correctly written driver stores it's device_t in > a dev_t. It should store it's softc structure, which should contain > pointers to both. Even if there is a driver which does do that, > it happens inside the device driver, and it does not handicap the > remaining device drivers with its choice. Fair enough. I think that Brooks planned to use a NULL device_t for interfaces w/o a backing new-bus device. However, that means you still need if_name for all the non-newbus devices, so this seems somewhat pointless if if_name is the only reason. Another counterpoint is that the new-bus namespace and the netif namespace aren't the same anyway and that seemed to be the point of this linkage. The dev_t <> softc <> device_t linkages aren't about unifying namespaces. > There is nothing in the "data-model" of the kernel that says that > a network interface corresponds to exactly one hardware device > and more importantly: there shouldn't be either. Agreed. > If all you want is an extra field in "struct ifnet" to hang driver > information on, then by all means add that field. As long as you > give it type "void *" and make it private to the driver I have no > problem with that. Fair enough, though I don't think this is what Brooks was after. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:25:59 2003 Return-Path: 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 40D1116A4B3; Tue, 30 Sep 2003 10:25:59 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACEF4400E; Tue, 30 Sep 2003 10:25:55 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h8UHPpFH049801; Tue, 30 Sep 2003 18:25:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h8UHPcAc097455; Tue, 30 Sep 2003 18:25:50 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Bruce Evans In-Reply-To: <20030930172536.U3713@gamplex.bde.org> References: <20030930010128.GA31222@Odin.AC.HMC.Edu> <20030930172536.U3713@gamplex.bde.org> Content-Type: text/plain Message-Id: <1064942737.14476.8.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 30 Sep 2003 18:25:38 +0100 Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:25:59 -0000 On Tue, 2003-09-30 at 09:22, Bruce Evans wrote: > That's one alternative. (Far too) many places already use the simple > alternative of just using "struct device *". Grep shows 68 lines > containing "struct device" in *.h and 32 in *.c. For "device_t", the > numbers are 2140 in *.h and 5089 in *.c. This is in a sys tree with > about 1000 matches of "device_t" in generated files. There are non-bogus > uses of "struct device" to avoid namespace pollution in . > Most other uses are just bogus (modulo the existence of device_t being > non-bogus -- its opaqueness is negative since anything that wants to > use it must include and thus can see its internals. style(9) > says to not use negatively opaque typedefs). The internals of struct device are not contained in - it is completely opaque to users outside subr_bus.c. The main 'bug' here is the idea that its a good thing to export kernel data structures (struct ifnet) to userland. The layout of struct ifnet is an implementation detail - it shouldn't form part of the userland api. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:48:25 2003 Return-Path: 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 CFAB516A4BF; Tue, 30 Sep 2003 10:48:25 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C674D43FE9; Tue, 30 Sep 2003 10:48:24 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UHmKDH024717; Tue, 30 Sep 2003 10:48:20 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UHmKua024715; Tue, 30 Sep 2003 10:48:20 -0700 Date: Tue, 30 Sep 2003 10:48:19 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20030930174815.GC31908@Odin.AC.HMC.Edu> References: <11374.1064934514@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org cc: Poul-Henning Kamp cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:48:26 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 01:14:39PM -0400, John Baldwin wrote: >=20 > Fair enough. I think that Brooks planned to use a NULL device_t for > interfaces w/o a backing new-bus device. However, that means you > still need if_name for all the non-newbus devices, so this seems > somewhat pointless if if_name is the only reason. Another counterpoint > is that the new-bus namespace and the netif namespace aren't the same > anyway and that seemed to be the point of this linkage. The > dev_t <> softc <> device_t linkages aren't about unifying namespaces. The idea here is that virtually all uses of if_name/if_unit that aren't just there for the users benefit are actually references to the underlying driver not name of the interface. Currently they are the same (i.e. ifname is nearly always device_get_name(dev) or a bug prone manual version there of), but I would like to separate them so we can rename interfaces. Since device_t is as close to a repository of driver/instance information as we've got, I though using it would be a reasonable way to go. As a side benefit, most drivers have a copy of it in their softc already so you'd have a standard place to put it. I suppose a usable alternative would be to revive if_name and if_unit as something like if_drvname and if_drvunit. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ecHeXY6L6fI4GtQRAoM3AKCoaXbVJIwWuCegOL01REpap2jrfwCgiNiO vPGLE0NwLisRNtuK8jp0e2g= =S9HB -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:52:49 2003 Return-Path: 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 53D7516A4B3; Tue, 30 Sep 2003 10:52:49 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D2C943FB1; Tue, 30 Sep 2003 10:52:48 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:smmsp@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UHpLDV025768; Tue, 30 Sep 2003 10:52:32 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UHUYfq018048; Tue, 30 Sep 2003 10:30:34 -0700 Date: Tue, 30 Sep 2003 10:30:33 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20030930173033.GB31908@Odin.AC.HMC.Edu> References: <20031001011119.U1245@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@FreeBSD.org cc: net@FreeBSD.org Subject: Re: finishing the if.h/if_var.h split X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:52:49 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 01:14:34PM -0400, John Baldwin wrote: >=20 > On 30-Sep-2003 Bruce Evans wrote: > > On Tue, 30 Sep 2003, John Baldwin wrote: > >=20 > >> On 30-Sep-2003 Bruce Evans wrote: > >> > On Mon, 29 Sep 2003, Brooks Davis wrote: > >> >> Unfortunately, "soon" hasn't happened yet and it is now tripping me > >> >> up. To add the if_dev member to struct ifnet (see the forthcoming > >> >> post on that subject), it is necessary for sys/bus.h to be included= in > >> >> net/if_var.h > >> > > >> > That would be namespace pollution, so it is not permitted :-). Requ= iring > >> > all files that include (and especially to > >> > include would be interface breakage so it is even less > >> > permitted. > >> > >> Well, if if.h stops including if_var.h, then only kernel files that > >> include net/if_var.h would need sys/bus.h. I think that's manageable. > >=20 > > All userland files that include net/if_var.h would also need it (except > > they would only need device_t). >=20 > Is struct ifnet exposed to userland? Ugh, why do we export such things? > I guess because ifconfig grovels around in the kernel due to a lack of > APIs between the kernel and userland. *sigh* ifconfig is actually OK, it uses sysctl. netstat and ifmcstat do go grovling around in there as do 4-5 ports. If someone fixed our userland that would provide the template to fix the ports since they are all just netstat in some form or another. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eb20XY6L6fI4GtQRApTwAJ0ZGFspAr0NJYMOOCghsYurtntxlACeKILY 4kch6VFEGstPNOfkb/ZFr38= =jHza -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:53:04 2003 Return-Path: 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 6EE5316A4B3; Tue, 30 Sep 2003 10:53:04 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95E1C43F85; Tue, 30 Sep 2003 10:53:02 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:smmsp@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UHpLDX025768; Tue, 30 Sep 2003 10:52:48 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UHFa4c011339; Tue, 30 Sep 2003 10:15:36 -0700 Date: Tue, 30 Sep 2003 10:15:36 -0700 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20030930171535.GA31908@Odin.AC.HMC.Edu> References: <200309301045.15776.vjardin@wanadoo.fr> <8475.1064905854@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <8475.1064905854@critter.freebsd.dk> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@FreeBSD.org cc: net@FreeBSD.org cc: Vincent Jardin Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:53:04 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 09:10:54AM +0200, Poul-Henning Kamp wrote: > In message <200309301045.15776.vjardin@wanadoo.fr>, Vincent Jardin writes: > >Le Mardi 30 Septembre 2003 03:03, Brooks Davis a =E9crit : > >> [Previously posted to -net in another form.] > >> > >> I propose to add an if_dev member to struct ifnet. It would be of type > >> device_t and be defined to point to the device for the interface or NU= LL > >> if there is no device (or if there was not an easy way to get access to > >> one). > >> > >> This change would codify the the relationship between an interface and > >> the underlying physical device. It also would get rid of the existing > >> abuses of if_name to look up the driver associated with an interface > >> and simplify a number of messy cases in the conversion from if_unit and > >> if_name to if_xname. > >> > >> Does this seem like a reasonable thing to do? > > > >Yes, if it helps to remove if_name/if_unit, it is a thing to do. Moreove= r it=20 > >sounds a good idea to have the if_dev field into the ifnet structure. >=20 > Somebody please explain how this would work for non-hardware > interfaces like if_loop, if_tun, if_tap etc ? if_dev would be NULL when a device_t was not available. Code which used this feature would be required to either check that if_dev was non-NULL before trying to use it or have special knowldege that it only gets called with struct ifnet instances which have a non-NULL if_dev member. For instance, driver routines which take a struct ifnet would know that they are only called on their own ifnet so they could assume they had filled it in. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ebnzXY6L6fI4GtQRAlveAJ9ZoFSGyyHg317JC6z+Wrgp2K+/2QCdGID2 ttlbZccT/fcmYswywjaqA1o= =HbMf -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 10:56:46 2003 Return-Path: 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 6279C16A4B3; Tue, 30 Sep 2003 10:56:46 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C0F944011; Tue, 30 Sep 2003 10:56:45 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8UHufOP013248; Tue, 30 Sep 2003 19:56:42 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Brooks Davis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Sep 2003 10:15:36 PDT." <20030930171535.GA31908@Odin.AC.HMC.Edu> Date: Tue, 30 Sep 2003 19:56:41 +0200 Message-ID: <13247.1064944601@critter.freebsd.dk> cc: arch@FreeBSD.org cc: net@FreeBSD.org cc: Vincent Jardin Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 17:56:46 -0000 In message <20030930171535.GA31908@Odin.AC.HMC.Edu>, Brooks Davis writes: >> Somebody please explain how this would work for non-hardware >> interfaces like if_loop, if_tun, if_tap etc ? > >if_dev would be NULL when a device_t was not available. Code which used >this feature would be required to either check that if_dev was non-NULL >before trying to use it or have special knowldege that it only gets >called with struct ifnet instances which have a non-NULL if_dev member. >For instance, driver routines which take a struct ifnet would know that >they are only called on their own ifnet so they could assume they had >filled it in. So you'd still have to keep the if_name + if_unit around for the drivers which do not have a device_t ? -- 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 Tue Sep 30 11:23:06 2003 Return-Path: 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 214B216A4B3 for ; Tue, 30 Sep 2003 11:23:06 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 920494400E for ; Tue, 30 Sep 2003 11:23:04 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13306 invoked from network); 30 Sep 2003 18:23:03 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Sep 2003 18:23:03 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8UIMv6Y059221; Tue, 30 Sep 2003 14:22:58 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030930174815.GC31908@Odin.AC.HMC.Edu> Date: Tue, 30 Sep 2003 14:23:02 -0400 (EDT) From: John Baldwin To: Brooks Davis X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org cc: Poul-Henning Kamp cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 18:23:06 -0000 On 30-Sep-2003 Brooks Davis wrote: > On Tue, Sep 30, 2003 at 01:14:39PM -0400, John Baldwin wrote: >> >> Fair enough. I think that Brooks planned to use a NULL device_t for >> interfaces w/o a backing new-bus device. However, that means you >> still need if_name for all the non-newbus devices, so this seems >> somewhat pointless if if_name is the only reason. Another counterpoint >> is that the new-bus namespace and the netif namespace aren't the same >> anyway and that seemed to be the point of this linkage. The >> dev_t <> softc <> device_t linkages aren't about unifying namespaces. > > The idea here is that virtually all uses of if_name/if_unit that aren't > just there for the users benefit are actually references to the > underlying driver not name of the interface. Currently they are the > same (i.e. ifname is nearly always device_get_name(dev) or a bug prone > manual version there of), but I would like to separate them so we can > rename interfaces. > > Since device_t is as close to a repository of driver/instance > information as we've got, I though using it would be a reasonable way > to go. As a side benefit, most drivers have a copy of it in their softc > already so you'd have a standard place to put it. > > I suppose a usable alternative would be to revive if_name and if_unit > as something like if_drvname and if_drvunit. Are these uses all within the driver itself? If so, then just giving ifnet a void * that is private to the driver would allow ifnet devices hung off of new-bus devices to cache their device_t w/o requiring the rest of the kernel to know what that private variable is. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 11:24:03 2003 Return-Path: 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 49BCE16A4BF; Tue, 30 Sep 2003 11:24:03 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7589D43FB1; Tue, 30 Sep 2003 11:24:02 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UIO0DH005560; Tue, 30 Sep 2003 11:24:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UINxci005559; Tue, 30 Sep 2003 11:23:59 -0700 Date: Tue, 30 Sep 2003 11:23:59 -0700 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20030930182359.GD31908@Odin.AC.HMC.Edu> References: <20030930171535.GA31908@Odin.AC.HMC.Edu> <13247.1064944601@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d9ADC0YsG2v16Js0" Content-Disposition: inline In-Reply-To: <13247.1064944601@critter.freebsd.dk> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@FreeBSD.org cc: net@FreeBSD.org cc: Vincent Jardin Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 18:24:03 -0000 --d9ADC0YsG2v16Js0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 07:56:41PM +0200, Poul-Henning Kamp wrote: > In message <20030930171535.GA31908@Odin.AC.HMC.Edu>, Brooks Davis writes: >=20 > >> Somebody please explain how this would work for non-hardware > >> interfaces like if_loop, if_tun, if_tap etc ? > > > >if_dev would be NULL when a device_t was not available. Code which used > >this feature would be required to either check that if_dev was non-NULL > >before trying to use it or have special knowldege that it only gets > >called with struct ifnet instances which have a non-NULL if_dev member. > >For instance, driver routines which take a struct ifnet would know that > >they are only called on their own ifnet so they could assume they had > >filled it in. >=20 > So you'd still have to keep the if_name + if_unit around for the > drivers which do not have a device_t ? Not today, since none of them get used in the paths that do this. In general the network code doesn't care what you call an interface. There are a few corners where it does, but nothing that isn't specific to a certain set of drivers. Additionally, it is necessary to not have members called if_name and if_unit if we have if_xname as the primary driver name. It's also worth noting that one of the things I want to do is break the driver+unit mapping for certain types of pseudo devices. Specifically vlan devices should be allocatable by creating an interface with a name like fxp0.100 so while you could synthesize a unit number, it wouldn't have any useful meaning. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --d9ADC0YsG2v16Js0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eco2XY6L6fI4GtQRAuwDAKCe31Th8L2pVT14zAG+ZhB6LcnLtgCfZwWC S7NMTkdh6BZHwpbsmj/FSL8= =7Rec -----END PGP SIGNATURE----- --d9ADC0YsG2v16Js0-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 11:29:08 2003 Return-Path: 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 0BEF616A4B3; Tue, 30 Sep 2003 11:29:08 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B9F43FF9; Tue, 30 Sep 2003 11:29:06 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UIT2DH006492; Tue, 30 Sep 2003 11:29:03 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UIT26w006491; Tue, 30 Sep 2003 11:29:02 -0700 Date: Tue, 30 Sep 2003 11:29:02 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20030930182902.GE31908@Odin.AC.HMC.Edu> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MIdTMoZhcV1D07fI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: net@FreeBSD.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 18:29:08 -0000 --MIdTMoZhcV1D07fI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 02:23:02PM -0400, John Baldwin wrote: >=20 > On 30-Sep-2003 Brooks Davis wrote: > > On Tue, Sep 30, 2003 at 01:14:39PM -0400, John Baldwin wrote: > >>=20 > >> Fair enough. I think that Brooks planned to use a NULL device_t for > >> interfaces w/o a backing new-bus device. However, that means you > >> still need if_name for all the non-newbus devices, so this seems > >> somewhat pointless if if_name is the only reason. Another counterpoint > >> is that the new-bus namespace and the netif namespace aren't the same > >> anyway and that seemed to be the point of this linkage. The > >> dev_t <> softc <> device_t linkages aren't about unifying namespaces. > >=20 > > The idea here is that virtually all uses of if_name/if_unit that aren't > > just there for the users benefit are actually references to the > > underlying driver not name of the interface. Currently they are the > > same (i.e. ifname is nearly always device_get_name(dev) or a bug prone > > manual version there of), but I would like to separate them so we can > > rename interfaces. > >=20 > > Since device_t is as close to a repository of driver/instance > > information as we've got, I though using it would be a reasonable way > > to go. As a side benefit, most drivers have a copy of it in their softc > > already so you'd have a standard place to put it. > >=20 > > I suppose a usable alternative would be to revive if_name and if_unit > > as something like if_drvname and if_drvunit. >=20 > Are these uses all within the driver itself? If so, then just giving > ifnet a void * that is private to the driver would allow ifnet devices > hung off of new-bus devices to cache their device_t w/o requiring the > rest of the kernel to know what that private variable is. All are within other code. One example is in dev/mii/brgphy.c which a phy feature is not enabled when it is attached to some MACs. A messier example is in the new ATM code where interfaces are looked up by name. In all cases, usage is limited to a narrow set of code, but it's not generally in the driver itself (in those cases, the softc is often already used, say to hold the unit). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --MIdTMoZhcV1D07fI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ecttXY6L6fI4GtQRAjiVAJsFh1JBTe0MwR1XSCM5Jw+01j1lpgCghipY 9jOMGlXMubzG5yARuH2mFsw= =KO8S -----END PGP SIGNATURE----- --MIdTMoZhcV1D07fI-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 15:58:44 2003 Return-Path: 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 D58B116A4C1; Tue, 30 Sep 2003 15:58:44 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22B9143FDF; Tue, 30 Sep 2003 15:58:43 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UMwcDH007509; Tue, 30 Sep 2003 15:58:38 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UMwbJu007508; Tue, 30 Sep 2003 15:58:37 -0700 Date: Tue, 30 Sep 2003 15:58:37 -0700 From: Brooks Davis To: Brooks Davis Message-ID: <20030930225826.GD14082@Odin.AC.HMC.Edu> References: <20030930010327.GB31222@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FFoLq8A0u+X9iRU8" Content-Disposition: inline In-Reply-To: <20030930010327.GB31222@Odin.AC.HMC.Edu> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 22:58:45 -0000 --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Since there are some objections to this proposal, I have an alternative one for consideration. I would add two new members to ifnet, if_dname and if_dunit, containing the driver name and unit which would be similar to the current if_name and if_unit with the exception that if_dunit would be an int to match unit in device_t. Negative values of unit would mean "no unit" for pseudo devices where units don't really make sense. Because this would add annoying overhead to the init routine, I would also propose adding an if_initname() function that would hide the initialization of these variables and (if MFC'd) aid portability between 4 and 5. Is this a better or worse idea then adding if_dev? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/egqGXY6L6fI4GtQRAppjAKDhX7AxkI82GY1tOTTuuBEpkhLLlwCggWbp jKuVQDNjutcNd/F/caXYX+Y= =D74r -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 18:20:17 2003 Return-Path: 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 2879516A4F4; Tue, 30 Sep 2003 18:20:17 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id B921D43FDF; Tue, 30 Sep 2003 18:20:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by comcast.net (sccrmhc13) with ESMTP id <20031001012014016005m212e>; Wed, 1 Oct 2003 01:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA31125; Sun, 28 Sep 2003 14:53:35 -0700 (PDT) Date: Sun, 28 Sep 2003 14:53:34 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp In-Reply-To: <653.1064784127@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 01:20:17 -0000 On Sun, 28 Sep 2003, Poul-Henning Kamp wrote: > Basically: > > 1. Do not call makedev(). > > 2. If you do cloning, please look at the patches I posted > for if_tun/if_tap for how to do it. > show an actual document please, explaining how this works from the user's POV.. > 3. If you do a "normal" device driver, cache the result > from when you call make_dev(). > > 4. If you translate "foreign dev_t's", ie emulators or > compat code, contact me. I'm not sure I understand > how this works and should work and we need to talk. > > 5. If anything else or in doubt, ask me. more docs on how you invisage clonign to work. > > Can I see some volounteers and/or maintainers please ? > > ./dev/nmdm/nmdm.c > pseudo-cloning. Should do real cloning. > If the documentation is easily available and it does what I want I'll convert it.. It may be available but I haven't seen it.. man make_dev(9) doesn't have any 'see also' section that helps.. So, why should I not revoke a vnode that now refers to nothing? From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 00:34:29 2003 Return-Path: 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 A5CD516A4B3; Wed, 1 Oct 2003 00:34:29 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id F099C43FF5; Wed, 1 Oct 2003 00:34:27 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h917YM623152; Wed, 1 Oct 2003 09:34:23 +0200 (MEST) Date: Wed, 1 Oct 2003 09:34:22 +0200 (CEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20030930182902.GE31908@Odin.AC.HMC.Edu> Message-ID: <20031001093334.S113@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20030930182902.GE31908@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 07:34:29 -0000 On Tue, 30 Sep 2003, Brooks Davis wrote: BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>phy feature is not enabled when it is attached to some MACs. A messier BD>example is in the new ATM code where interfaces are looked up by name. Where is this? harti BD>In all cases, usage is limited to a narrow set of code, but it's not BD>generally in the driver itself (in those cases, the softc is often BD>already used, say to hold the unit). BD> BD>-- Brooks BD> BD> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 09:40:46 2003 Return-Path: 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 019DA16A4B3; Wed, 1 Oct 2003 09:40:46 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C0C743FF2; Wed, 1 Oct 2003 09:40:45 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h91GebDH005761; Wed, 1 Oct 2003 09:40:37 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h91Gea9C005760; Wed, 1 Oct 2003 09:40:36 -0700 Date: Wed, 1 Oct 2003 09:40:36 -0700 From: Brooks Davis To: Harti Brandt Message-ID: <20031001164036.GA1263@Odin.AC.HMC.Edu> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20030930182902.GE31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20031001093334.S113@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 16:40:46 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 01, 2003 at 09:34:22AM +0200, Harti Brandt wrote: > On Tue, 30 Sep 2003, Brooks Davis wrote: >=20 > BD>All are within other code. One example is in dev/mii/brgphy.c which a > BD>phy feature is not enabled when it is attached to some MACs. A messier > BD>example is in the new ATM code where interfaces are looked up by name. >=20 > Where is this? One example would be in sys/netatm/atm_if.c around line 1081. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ewOEXY6L6fI4GtQRAkTlAKCQDJ+ecD3jUCeH1YA+D1Iuen3qrACgg1nL 6lrYQ3dwuti2dhEgSaRq3W4= =X5ax -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 11:38:17 2003 Return-Path: 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 ECF6E16A4B3 for ; Wed, 1 Oct 2003 11:38:17 -0700 (PDT) Received: from mwinf0502.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A37543F93 for ; Wed, 1 Oct 2003 11:38:16 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from mercure.vincentjardin.net (AVelizy-102-1-4-9.w80-11.abo.wanadoo.fr [80.11.204.9]) by mwinf0502.wanadoo.fr (SMTP Server) with ESMTP id C333DE800204; Wed, 1 Oct 2003 20:38:14 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Brooks Davis , Harti Brandt Date: Wed, 1 Oct 2003 20:38:13 +0200 User-Agent: KMail/1.4.3 References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> <20031001164036.GA1263@Odin.AC.HMC.Edu> In-Reply-To: <20031001164036.GA1263@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200310012038.14062.vjardin@wanadoo.fr> cc: arch@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 18:38:18 -0000 > > messier BD>example is in the new ATM code where interfaces are looked= up > > by name. > > > > Where is this? > > One example would be in sys/netatm/atm_if.c around line 1081. Do you mean pif_name and pif_unit ? This code could be updated. It uses pif_unit and pif_name that could beco= me=20 pif_xname. for (pip =3D atm_interface_head; pip; pip =3D pip->pif_next) { if (strcmp(pip->pif_xname, n) =3D=3D 0) break; } instead of for (pip =3D atm_interface_head; pip; pip =3D pip->pif_next) { if ((pip->pif_unit =3D=3D unit) && (strcmp(pip->pif_name, n)= =3D=3D 0)) break; } Moreover, a PIF (Physical IF) is not an ifnet. It is the ATM device. The = ATM=20 PVC are the NIF (Network IF -> ifnet). They are many NIF (PVC) over a sin= gle=20 PIF (ATM device). With the ATM stack, the main issue is related to AIOCS_SET_NIF. It sets t= he=20 ifp's if_name to the NIF's nif_name and the ifp's if_unit to a regular=20 counter. In fact we could change the following code strcpy ( nip->nif_name, asr->asr_nif_pref ); nip->nif_sel =3D count; ifp->if_name =3D nip->nif_name; ifp->if_unit =3D count; to snprintf(nip->nif_xname, sizeof(nip->nif_xname), "%s%= d", asr->asr_nif_pref, count); nip->nif_sel =3D count; /* we need to keep a selector= to=20 build the UNI ATM address */ ifp->if_xname =3D nip->nif_xname; #if 0 ifp->if_unit =3D count; /* it is not required anymore= */ #endif Regards, Vincent From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 11:55:16 2003 Return-Path: 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 3F6B716A4B3 for ; Wed, 1 Oct 2003 11:55:16 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72DD643FCB for ; Wed, 1 Oct 2003 11:55:15 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h91IswDH002429; Wed, 1 Oct 2003 11:54:58 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h91Isw01002424; Wed, 1 Oct 2003 11:54:58 -0700 Date: Wed, 1 Oct 2003 11:54:58 -0700 From: Brooks Davis To: Vincent Jardin Message-ID: <20031001185458.GA29576@Odin.AC.HMC.Edu> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> <20031001164036.GA1263@Odin.AC.HMC.Edu> <200310012038.14062.vjardin@wanadoo.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <200310012038.14062.vjardin@wanadoo.fr> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 18:55:16 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 01, 2003 at 08:38:13PM +0200, Vincent Jardin wrote: > > > messier BD>example is in the new ATM code where interfaces are looked= up > > > by name. > > > > > > Where is this? > > > > One example would be in sys/netatm/atm_if.c around line 1081. >=20 > Do you mean pif_name and pif_unit ? Yes. > This code could be updated. It uses pif_unit and pif_name that could beco= me=20 > pif_xname. I've done something like this in my perforce branch (//depot/user/brooks/xname/...), but it isn't a real solution because I plan to follow up by breaking the assumption that if_xname remains constant for the life of the interface. If either if_dev or if_d{name,unit} are added, you could use those as you do now. You might consider using if_index instead since that's both unchanged over the life of the device and quick to check. > snprintf(nip->nif_xname, sizeof(nip->nif_xname), "%s%= d", > asr->asr_nif_pref, count); > nip->nif_sel =3D count; /* we need to keep a selector= to=20 > build the UNI ATM address */ >=20 > ifp->if_xname =3D nip->nif_xname; Actually, this needs to be a strlcpy. if_xname is stored in the ifnet, not as a pointer, but that's a minor detail. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/eyL/XY6L6fI4GtQRAjR0AKC+BARVRdZeT5uHjYtNnTBf6jQrrQCgnXJw mwHbpb9/pYIFiQnSTz0RR9E= =3h0Y -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 13:05:40 2003 Return-Path: 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 AA6C616A4B3 for ; Wed, 1 Oct 2003 13:05:40 -0700 (PDT) Received: from mwinf0104.wanadoo.fr (smtp8.wanadoo.fr [193.252.22.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90FC543FF9 for ; Wed, 1 Oct 2003 13:05:37 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from mercure.vincentjardin.net (AVelizy-102-1-4-9.w80-11.abo.wanadoo.fr [80.11.204.9]) by mwinf0104.wanadoo.fr (SMTP Server) with ESMTP id F287F1BEEAB3; Wed, 1 Oct 2003 22:05:35 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Brooks Davis Date: Wed, 1 Oct 2003 22:05:35 +0200 User-Agent: KMail/1.4.3 References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <200310012038.14062.vjardin@wanadoo.fr> <20031001185458.GA29576@Odin.AC.HMC.Edu> In-Reply-To: <20031001185458.GA29576@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200310012205.35111.vjardin@wanadoo.fr> cc: arch@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 20:05:40 -0000 > I've done something like this in my perforce branch > (//depot/user/brooks/xname/...), but it isn't a real solution because > I plan to follow up by breaking the assumption that if_xname remains > constant for the life of the interface. If either if_dev or > if_d{name,unit} are added, you could use those as you do now. > You might consider using if_index instead since that's both unchanged > over the life of the device and quick to check. In this case, I agree that using if_index would be a better choice ;-) Regards, Vincent From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 20:32:05 2003 Return-Path: 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 39E5F16A4B3 for ; Wed, 1 Oct 2003 20:32:05 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-12.noos.net [212.198.2.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3597543FEC for ; Wed, 1 Oct 2003 20:32:01 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 5852895 invoked by uid 0); 2 Oct 2003 03:31:59 -0000 Received: (qmail 71991304 invoked by uid 0); 28 Sep 2003 23:39:36 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for ; 28 Sep 2003 23:39:36 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 3968758AB1; Sun, 28 Sep 2003 16:39:02 -0700 (PDT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1275E16A59E; Sun, 28 Sep 2003 16:38:44 -0700 (PDT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE2B916A4B3; Sun, 28 Sep 2003 16:38:36 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7E8A44015; Sun, 28 Sep 2003 16:38:34 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h8SNcPFs078206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 29 Sep 2003 01:38:30 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h8SNcOWZ080261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2003 01:38:25 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h8SNcOrY014878; Mon, 29 Sep 2003 01:38:24 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h8SNcNwT014877; Mon, 29 Sep 2003 01:38:23 +0200 (CEST) Date: Mon, 29 Sep 2003 01:38:23 +0200 From: Bernd Walter To: Poul-Henning Kamp Message-ID: <20030928233823.GJ90598@cicely12.cicely.de> References: <653.1064784127@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <653.1064784127@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org Reply-To: ticso@cicely.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2003 03:32:05 -0000 On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: > > I am in the process of adding ref-counting and locking to dev_t, > and would very much prefer if we could get this step completed > soon before 5-STABLE gets branched. > > All this will be transparent to the majority of device drivers, as > the refcounting will happen in the make_dev() and destroy_dev() > family of calls and normal drivers need not know more about it. > > But there are a few remaining users of makedev() which get in the > way of this effort, and we must get these fixed. > > Basically: > > 1. Do not call makedev(). > > 2. If you do cloning, please look at the patches I posted > for if_tun/if_tap for how to do it. > > 3. If you do a "normal" device driver, cache the result > from when you call make_dev(). > > 4. If you translate "foreign dev_t's", ie emulators or > compat code, contact me. I'm not sure I understand > how this works and should work and we need to talk. > > 5. If anything else or in doubt, ask me. > > Can I see some volounteers and/or maintainers please ? > > ./alpha/osf1/osf1_misc.c > badly named local macro ? Unused code. umakedev is used within a macro but nowhere defined it seems. makedev is used as a macroname, but ifdef'ed 0. Shouldn't hurt. Maybe someone with knowledge about OSF1 emulation should decide what happens with them in the long run. > ./dev/usb/ugen.c > ./dev/usb/uscanner.c > Failure to cache result of make_dev() I'll take those. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 23:00:32 2003 Return-Path: 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 0F17E16A4B3; Wed, 1 Oct 2003 23:00:32 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B8943FF3; Wed, 1 Oct 2003 23:00:30 -0700 (PDT) (envelope-from adam@migus.org) Received: from garple.migus.org ([68.55.83.94]) by comcast.net (sccrmhc13) with ESMTP id <2003100206003001600knqaue>; Thu, 2 Oct 2003 06:00:30 +0000 Received: by garple.migus.org (Postfix, from userid 80) id 2DCFC8FC30; Thu, 2 Oct 2003 02:00:30 -0400 (EDT) Received: from 192.168.4.2 (SquirrelMail authenticated user adam) by mail.migus.org with HTTP; Thu, 2 Oct 2003 02:00:30 -0400 (EDT) Message-ID: <49955.192.168.4.2.1065074430.squirrel@mail.migus.org> In-Reply-To: <20030927080420.N18558@gamplex.bde.org> References: <20030925092319.H5418@gamplex.bde.org><49939.204.254.155.35.1064593320.squirrel@mail.migus.org> <20030927080420.N18558@gamplex.bde.org> Date: Thu, 2 Oct 2003 02:00:30 -0400 (EDT) From: "Adam C. Migus" To: "Bruce Evans" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20031002020030_35080" X-Priority: 3 Importance: Normal cc: arch@freebsd.org Subject: Re: sys/conf/DEFAULT[S] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2003 06:00:32 -0000 ------=_20031002020030_35080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Bruce Evans said: > On Fri, 26 Sep 2003, Adam C. Migus wrote: > >> Bruce Evans said: >> > Do we actually gave the abiltity to include other config files? >> It >> > was >> > quite broken last time I tried to use it for anything more >> > complicated >> > than the example in "SMP". >> >> I use the include feature quite a bit, nested in some cases. It >> works great for me for creating combinations of debug, diskless, >> mac >> and smp kernels for example. > > My example written last Februry still shows that even simple > includes > don't work: > > %%% > Script started on Tue Feb 25 14:16:01 2003 > ttyp0:bde@besplex:/usr/src/sys/i386/conf> cat FOOBAR > include FOO > ttyp0:bde@besplex:/usr/src/sys/i386/conf> cat FOO > machine i386 > cpu I486_CPU > ident FOO > ttyp0:bde@besplex:/usr/src/sys/i386/conf> config FOOBAR > config: FOO:1: syntax error > ttyp0:bde@besplex:/usr/src/sys/i386/conf> config FOO > Kernel build directory is ../compile/FOO > Don't forget to do a ``make depend'' > ttyp0:bde@besplex:/usr/src/sys/i386/conf> exit > > Script done on Tue Feb 25 14:16:23 2003 > %%% > > Similarly with FOOBAR's contents identical with SMP's contents > except > for including FOO instead of GENERIC. So the bug must be related to > the file being included ... adding an empty or comment line to the > beginning of FOO works around it. I guess there is an off-by-1 byte > or line error switching the input stream. > > Bruce > This patch works for me, please let me know if there's any problems with it or you'd like a PR. -- Adam - (http://people.migus.org/~amigus/) Migus Dot Org - (http://www.migus.org/) ------=_20031002020030_35080 Content-Type: application/octet-stream; name="config.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="config.diff" PT09PSAvL2RlcG90L3VzZXIvYW1pZ3VzL2ZyZWVic2QtYW1pZ3VzL3NyYy91c3Iuc2Jpbi9jb25m aWcvY29uZmlnLnkjMSAtIC9zcmMvcDQvdXNlci9hbWlndXMvcGVyZm9yY2UuZnJlZWJzZC5vcmcv ZnJlZWJzZC1hbWlndXMvdXNyLnNiaW4vY29uZmlnL2NvbmZpZy55ID09PT0KQEAgLTExOCw2ICsx MTgsOCBAQAogCQl8CiAJQ29uZmlnX3NwZWMgU0VNSUNPTE9OCiAJCXwKKwlJbmNsdWRlCisJCXwK IAlTRU1JQ09MT04KIAkJfAogCWVycm9yIFNFTUlDT0xPTgpAQCAtMTY0LDkgKzE2Niw3IEBACiAJ ICAgICAgPSB7CiAJCSAgICAgIGhpbnRzID0gJDI7CiAJCSAgICAgIGhpbnRtb2RlID0gMTsKLQkg ICAgICAgIH0gfAotCUlOQ0xVREUgSUQKLQkgICAgICA9IHsgaW5jbHVkZSgkMiwgMCk7IH07CisJ ICAgICAgICB9OwogCiBTeXN0ZW1fc3BlYzoKIAlDT05GSUcgU3lzdGVtX2lkIFN5c3RlbV9wYXJh bWV0ZXJfbGlzdApAQCAtMjY1LDYgKzI2NSwxMSBAQAogCQlybWRldigkMik7CiAJCX0gOwogCitJ bmNsdWRlOgorCUlOQ0xVREUgSUQKKwkgICAgICA9IHsgaW5jbHVkZSgkMiwgMCk7IH07CisKKwog JSUKIAogdm9pZAo= ------=_20031002020030_35080-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 00:45:23 2003 Return-Path: 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 870C716A4B3; Thu, 2 Oct 2003 00:45:23 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F5543FBD; Thu, 2 Oct 2003 00:45:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h927jH627125; Thu, 2 Oct 2003 09:45:18 +0200 (MEST) Date: Thu, 2 Oct 2003 09:45:17 +0200 (CEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20031001164036.GA1263@Odin.AC.HMC.Edu> Message-ID: <20031002093437.S11328@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> <20031001164036.GA1263@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2003 07:45:23 -0000 On Wed, 1 Oct 2003, Brooks Davis wrote: BD>On Wed, Oct 01, 2003 at 09:34:22AM +0200, Harti Brandt wrote: BD>> On Tue, 30 Sep 2003, Brooks Davis wrote: BD>> BD>> BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>> BD>phy feature is not enabled when it is attached to some MACs. A messier BD>> BD>example is in the new ATM code where interfaces are looked up by name. BD>> BD>> Where is this? BD> BD>One example would be in sys/netatm/atm_if.c around line 1081. Well, that's the old ATM code (HARP). An this place is not a problem, because HARP physical interfaces live in their own name space - they don't have a struct ifnet. A worse example is around line 1125. But, I suppose we could just use the usual way to lookup an interface via it's name and after that check that it is an HARP nif. A more serious problem is how HARP allocates NIFs: the user specifies a prefix and a number N. HARP then generates interfaces with names from prefix0 to prefixN. This is the only place, where HARP really needs a name and a unit number, but this is only to create a name for new interfaces - the names are not parsed after that, so it should be no problem to keep this stuff, except that we stuff the complete name into if_xname. All the other uses of if_name seem to be (...."%s%d", if_name, if_unit)... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 00:57:26 2003 Return-Path: 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 36ABE16A4B3 for ; Thu, 2 Oct 2003 00:57:26 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B790043FDD for ; Thu, 2 Oct 2003 00:57:24 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h927vL601258; Thu, 2 Oct 2003 09:57:21 +0200 (MEST) Date: Thu, 2 Oct 2003 09:57:21 +0200 (CEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20031001185458.GA29576@Odin.AC.HMC.Edu> Message-ID: <20031002095404.C11328@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001164036.GA1263@Odin.AC.HMC.Edu> <20031001185458.GA29576@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Vincent Jardin Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2003 07:57:26 -0000 On Wed, 1 Oct 2003, Brooks Davis wrote: BD>On Wed, Oct 01, 2003 at 08:38:13PM +0200, Vincent Jardin wrote: BD>> > > messier BD>example is in the new ATM code where interfaces are looked up BD>> > > by name. BD>> > > BD>> > > Where is this? BD>> > BD>> > One example would be in sys/netatm/atm_if.c around line 1081. BD>> BD>> Do you mean pif_name and pif_unit ? BD> BD>Yes. BD> BD>> This code could be updated. It uses pif_unit and pif_name that could become BD>> pif_xname. BD> BD>I've done something like this in my perforce branch BD>(//depot/user/brooks/xname/...), but it isn't a real solution because BD>I plan to follow up by breaking the assumption that if_xname remains BD>constant for the life of the interface. If either if_dev or BD>if_d{name,unit} are added, you could use those as you do now. I think we need one of those to support SNMP semantics for interfaces. The SNMP RFC says, that the interface index to physical instance binding must be persistant even if the interface is renamed. This requires an identification for the interface that is tied to the hardware. BD>You might consider using if_index instead since that's both unchanged BD>over the life of the device and quick to check. The PIF has no ifnet and hence no if_index. harti BD> BD>> snprintf(nip->nif_xname, sizeof(nip->nif_xname), "%s%d", BD>> asr->asr_nif_pref, count); BD>> nip->nif_sel = count; /* we need to keep a selector to BD>> build the UNI ATM address */ BD>> BD>> ifp->if_xname = nip->nif_xname; BD> BD>Actually, this needs to be a strlcpy. if_xname is stored in the ifnet, BD>not as a pointer, but that's a minor detail. BD> BD>-- Brooks BD> BD> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Fri Oct 3 18:44:30 2003 Return-Path: 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 C35C716A4C0 for ; Fri, 3 Oct 2003 18:44:30 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-06.noos.net [212.198.2.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2930543F3F for ; Fri, 3 Oct 2003 18:44:27 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 58386434 invoked by uid 0); 4 Oct 2003 00:59:35 -0000 Received: (qmail 59857497 invoked by uid 0); 2 Oct 2003 07:46:28 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.75 (qmail-ldap-1.03) with SMTP for ; 2 Oct 2003 07:46:28 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 27E11566DB; Thu, 2 Oct 2003 00:45:59 -0700 (PDT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 959ED16A4EC; Thu, 2 Oct 2003 00:45:57 -0700 (PDT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 870C716A4B3; Thu, 2 Oct 2003 00:45:23 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F5543FBD; Thu, 2 Oct 2003 00:45:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h927jH627125; Thu, 2 Oct 2003 09:45:18 +0200 (MEST) Date: Thu, 2 Oct 2003 09:45:17 +0200 (CEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20031001164036.GA1263@Odin.AC.HMC.Edu> Message-ID: <20031002093437.S11328@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> <20031001164036.GA1263@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2003 01:44:31 -0000 On Wed, 1 Oct 2003, Brooks Davis wrote: BD>On Wed, Oct 01, 2003 at 09:34:22AM +0200, Harti Brandt wrote: BD>> On Tue, 30 Sep 2003, Brooks Davis wrote: BD>> BD>> BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>> BD>phy feature is not enabled when it is attached to some MACs. A messier BD>> BD>example is in the new ATM code where interfaces are looked up by name. BD>> BD>> Where is this? BD> BD>One example would be in sys/netatm/atm_if.c around line 1081. Well, that's the old ATM code (HARP). An this place is not a problem, because HARP physical interfaces live in their own name space - they don't have a struct ifnet. A worse example is around line 1125. But, I suppose we could just use the usual way to lookup an interface via it's name and after that check that it is an HARP nif. A more serious problem is how HARP allocates NIFs: the user specifies a prefix and a number N. HARP then generates interfaces with names from prefix0 to prefixN. This is the only place, where HARP really needs a name and a unit number, but this is only to create a name for new interfaces - the names are not parsed after that, so it should be no problem to keep this stuff, except that we stuff the complete name into if_xname. All the other uses of if_name seem to be (...."%s%d", if_name, if_unit)... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 15:43:58 2003 Return-Path: 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 CE23D16A4BF for ; Sat, 4 Oct 2003 15:43:58 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-07.noos.net [212.198.2.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBA143FBD for ; Sat, 4 Oct 2003 15:43:55 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 74638602 invoked by uid 0); 4 Oct 2003 22:43:49 -0000 Received: (qmail 73573312 invoked by uid 0); 2 Oct 2003 07:46:15 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for ; 2 Oct 2003 07:46:15 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 51E3E564C8; Thu, 2 Oct 2003 00:45:58 -0700 (PDT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 169CE16A4E5; Thu, 2 Oct 2003 00:45:57 -0700 (PDT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 870C716A4B3; Thu, 2 Oct 2003 00:45:23 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F5543FBD; Thu, 2 Oct 2003 00:45:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h927jH627125; Thu, 2 Oct 2003 09:45:18 +0200 (MEST) Date: Thu, 2 Oct 2003 09:45:17 +0200 (CEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20031001164036.GA1263@Odin.AC.HMC.Edu> Message-ID: <20031002093437.S11328@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20031001093334.S113@beagle.fokus.fraunhofer.de> <20031001164036.GA1263@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2003 22:43:59 -0000 On Wed, 1 Oct 2003, Brooks Davis wrote: BD>On Wed, Oct 01, 2003 at 09:34:22AM +0200, Harti Brandt wrote: BD>> On Tue, 30 Sep 2003, Brooks Davis wrote: BD>> BD>> BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>> BD>phy feature is not enabled when it is attached to some MACs. A messier BD>> BD>example is in the new ATM code where interfaces are looked up by name. BD>> BD>> Where is this? BD> BD>One example would be in sys/netatm/atm_if.c around line 1081. Well, that's the old ATM code (HARP). An this place is not a problem, because HARP physical interfaces live in their own name space - they don't have a struct ifnet. A worse example is around line 1125. But, I suppose we could just use the usual way to lookup an interface via it's name and after that check that it is an HARP nif. A more serious problem is how HARP allocates NIFs: the user specifies a prefix and a number N. HARP then generates interfaces with names from prefix0 to prefixN. This is the only place, where HARP really needs a name and a unit number, but this is only to create a name for new interfaces - the names are not parsed after that, so it should be no problem to keep this stuff, except that we stuff the complete name into if_xname. All the other uses of if_name seem to be (...."%s%d", if_name, if_unit)... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"