From owner-freebsd-arch@freebsd.org Fri May 24 03:04:17 2019 Return-Path: Delivered-To: freebsd-arch@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 116411594ECA for ; Fri, 24 May 2019 03:04:17 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 665DF70830 for ; Fri, 24 May 2019 03:04:16 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 23D221594EC3; Fri, 24 May 2019 03:04:16 +0000 (UTC) Delivered-To: arch@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 F40561594EC1 for ; Fri, 24 May 2019 03:04:15 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CE507082D for ; Fri, 24 May 2019 03:04:15 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4O349hB093720; Thu, 23 May 2019 20:04:09 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4O349bH093719; Thu, 23 May 2019 20:04:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905240304.x4O349bH093719@gndrsh.dnsmgr.net> Subject: Re: Time to retire PC Card (but not CardBus) In-Reply-To: To: Warner Losh Date: Thu, 23 May 2019 20:04:09 -0700 (PDT) CC: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 5CE507082D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 03:04:17 -0000 > On Thu, May 23, 2019 at 7:48 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > I must ask that you first retire the lack of a formal > > deprecation policy and document, you promised this to > > us over a year ago. I made a gentlemans barter with you > > on no resistance to lua being merged and on by default > > in 12, you have failed to hold your end of the barter up. > > > > We have now done several deprecation cycles and no document > > or policy is in place. > > > > Thankfully a great deal was learned through FCP 101, but > > there is always more to learn. > > > > Sure. But please pick a week to ask me that I've not put an extra 50 hours > into the project putting out non-technical fires and am feeling behind... Your totally in control of this time, I just ask that the order be deprecation policy, even a published draft, then PC card killing. > I have a PC Card specific document that I can post that I wrote about the > same time as FCP 101. > > > > > Greetings, > > > > > > Now that a number of 16-bit drivers have been retired, I think it's time > > to > > > retire 16-bit PC Card / PCMCIA cards. The 32-bit CardBus cards are still > > > alive and kicking, but the need for 16-bit PC Cards has passed. It's time > > > to retire it. > > > > > > I've floated this idea before, and there was broad support for it. I've > > > held off until after FCP 101 deprecation was playing out. We've not > > pushed > > > that into the tree. This is the logical next step. FreeBSD 12.x will be > > the > > > last release with 16-bit PC Card support. > > > > > > My plan is to add deprecation notices to the remaining PC Card drivers, > > > merge those back to FreeBSD 11 and 12. Once that's done, I plan on > > removing > > > the 16-bit support. I have a few minor bug fixes to that which I'll push > > in > > > before I retire it, and merge those fixes. > > > > > > My plan is to give about a month for the community to discuss this plan > > > before I add the warnings. If there's resistance, we'll go with more > > formal > > > data collection and deprecation. If there's none, I'll go ahead. > > > > > > This affects the following drivers: an, cmx, fdc, puc, uart, wi, bt3c, > > ata. > > > > fdc, puc, uart, ata? Huh? > > Or are there PCMCIA stubs in these that need to die? > > > > Just the PC Card attachments to those devices. cmx and bt3c, however, will > be removed. Ok, clarity on that would be useful: This affects the PCMCIA code in the following drivers: an, fdc, puc uart, wi, and complete removal of cmx and bt3c. > > > iirc, the an come in a PCI adapter card with a PLX asic on them > > to bridge them into what kinda looks like a PCI card, would this > > kill that suppor too? > > > wi and an both were like that. Only wi I have is actual wi ISA cards, ancient Hermes, and for some reason I thought that was wl, but not finding that driver, and not finding an ISA card hermes listed in the wi driver. Meh, not important, dead stuff. > an had isa and pci attachments. The isa version was for a PLX chip that > made the PCMCIA card just appear on the ISA bus. the driver did minimal > PCMCIA power-up in the attachment. There was a late minipci an card. It > didn't support anything newer 802.11b, and has no modern crypto (nothing > newer than WEP) > > wi also had similar kludges. it too didn't support anything newer. > > I'd be inclined to just kill both of these drivers, but am looking for > feedback from actual users. I still have the an hardware, both ISA and PCI, but, as before, I shall discount myself from any inclusion in device counts as an aberation rather than a norm. If they do get saved I'll retain the hardware incase testing is needed. > Warner -- Rod Grimes rgrimes@freebsd.org