From owner-freebsd-net@freebsd.org Wed Mar 28 17:15:21 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3530AF6D038 for ; Wed, 28 Mar 2018 17:15:21 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE0B67838F for ; Wed, 28 Mar 2018 17:15:20 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id DBEF35A9F17; Wed, 28 Mar 2018 17:15:19 +0000 (UTC) Date: Wed, 28 Mar 2018 17:15:19 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Subject: Re: removal of token-ring infrastructure coming soon Message-ID: <20180328171519.GE88362@spindle.one-eyed-alien.net> References: <20180328160353.GC88362@spindle.one-eyed-alien.net> <201803281616.w2SGGNJb057759@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: <201803281616.w2SGGNJb057759@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 17:15:21 -0000 --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2018 at 09:16:23AM -0700, Rodney W. Grimes wrote: > > On Tue, Mar 27, 2018 at 04:56:32PM -0700, Rodney W. Grimes wrote: > > > > I have posted a revision which removes support for token-ring netwo= rking > > > > from the tree. There have been no such devices for some time. > > > >=20 > > > > https://reviews.freebsd.org/D14875 > > > >=20 > > >=20 > > > Arcnet coming soon? > > > and probably FDDI? > >=20 > > That's my plan. I started with token ring as it doesn't even have > > drivers (Arcnet and FDDI have one driver each, but ISA and 32-bit PCI > > respectively AFACT). >=20 > I fully support that arcnet and FDDI are dead. >=20 >=20 > Please be a bit carefull with what your calling "32 bit PCI" as > those are also often embedded devices in chipsets that may not > have cards avaliable, but are infact built in to systems. I absolutely agree. In this case it's indicative of the fact that this "high-performance" interface didn't get new silicon since the fastest bus it ever ran on was was 32-bit PCI. It's only one of several indicators. > Also I have become aware that axing the bt946 support may not > be a real good idea, as that is/was a common hypervisor emulation > device and just recently found myself using it in to access > a disk that was created with a scsi controller that had odd > translation and the ata layer would not do the right thing > for me. (32 sector, 64 head, which is not really odd for > scsi, thats common translation for many scsi cards). >=20 > I ended up using vmware with a bt946 emulation on scsi with > the drive image attached to it, and booted FreeBSD from an > ahci attached disk. If the bt946 drive was missing from=20 > 11.1 I would of been stuck. >=20 > As far as I am aware both vmware and virtualbox have support > for bt946 emulation, which is also a superset of aha154x. One of the problems we have in the project is that we don't have a way to track how popular devices are and what sort of applications they ended up in. It would be nice if we could find a way to collect information including: Busses: ISA, PCI, PCI-X, PCIe Form factors: ISA, PCMCIA, CardBus, PCI, PCI-X, PCIe, embedded[0], emulated Last ship or product announcement date: Ship volume: FreeBSD users with meaningful deployments: [0] Deployments at scale, not just parts available. I don't know how we'd got about collecting this information, but it would be good to find a way to croudsource it. The cost of maintaining each individual device isn't usually all that high, but it's really frustrating to spend the majority of time on an infrastructure change fixing issues in devices that shouldn't have survived the last release branch (or the one before that). Devices or technologies that failed in the market are the worst because they tend to have drivers with cargo-cult copy-and-paste from the wrong example that never gets fixed. -- Brooks --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJau82nAAoJEKzQXbSebgfAancH/1Cl8SZWGHA0IAQXhjEMqJCs MH748Iw9TUMuPcdBvpCo+buyKMX1kAFqLcP49ZEV1VmqyStzPV/K2Ta7E/yGHa3u K4T6nS9r5J5M0LOlQROSexkQYSRAZaiOQs+w6DZYDypz29zzVWhjzrYukJvMKHeI 3Jnnq4m4gQHldT1Pr9LKwNj4LneOsZnmhB7ngSCVE+SmTNBEs//S5uINC78MmlnV QMRpJ2V54524ky7xsc0+T4yrwok/65RPCklfldyrqIdGqway/FeaPqGbWspwJ/b1 7cuMekean5iyojjHkf+CQgBcyhImRidNfVxeIrMZMoGSBZmqc+ERZYsSE7CESxU= =g7Zp -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6--