Time to retire PC Card (but not CardBus)

[Rodney W. Grimes]

> On Thu, May 23, 2019 at 7:48 PM Rodney W. Grimes <
> freebsd-rwg at 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 at freebsd.org