An attempt at migration of capability before EOF seems to be reasonable 
planning.

Are there USB interfaces on known affected platforms where USB flash drive 
support is functional enough to provide equivalent storage capability? If so, 
then this cares for storage concerns.

Do the systems adversely affected by the PCMCIA purge, which leverage older 
WiFi cards, offer a USB slot where there is an upgrade path to leverage working 
WiFi usb sticks with supported Illumos drivers for them? If WiFi USB is working 
under Illumos, then this cares for this concern.

A lot of portable equipment without Ethernet often have PCMCIA & CardBus 
interfaces - so it is probably a good idea to give those systems an upgrade 
path. I use Intel laptops with such card support running Solaris 10, but don't 
use the slots because I could never make them functional.

I have some working SPARC platforms with an Illumos based kernel now - I would 
be willing to buy some WiFi USB sticks to test with, if there would be some 
support from the list. I think this is a reasonable approach 

Sent from my iPhone

On Sep 26, 2013, at 1:35 AM, Garrett D'Amore <[email protected]> wrote:

> Forwarding this to discuss -- if you care about PCMCIA (16-bit!) speak up.  
> I'm of the opinion we'll be better off without it, but this gives anyone 
> actually *using* this stuff a chance to make a case for saving it...
> 
>       - Garrett
> 
> Begin forwarded message:
> 
>> From: Garrett D'Amore <[email protected]>
>> Subject: Proposal: EOF pcmcia bits
>> Date: September 25, 2013 11:21:54 AM PDT
>> To: "[email protected] Developer" <[email protected]>
>> Cc: Bart Coddens <[email protected]>
>> 
>> I would like to propose (and maybe this was done previously) the final EOF 
>> of the PCMCIA bits.  Its important to note that this proposal *only* affects 
>> 16-bit PCMCIA.  The 32-bit Cardbus support (while also crufty) is not 
>> included in this proposal.
>> 
>> The proposal specifically is for the removal of:
>> 
>>      * pcan - Cisco Aeronet 802.11b driver. 
>>      * pcwl - Intersil Prism 802.11b driver
>>      * pcata/pcide and friends
>>      * sys/pccard.h
>>      * csx_ card CardServices kernel routines
>>      * pcs place holder driver
>> 
>> Further, it would be impossible to support 16-bit PCMCIA on illumos after 
>> this proposal integrates.
>> 
>> A bit more detail.
>> 
>> 1. PCMCIA is 16-bit only
>> 2. PCMCIA does not support DMA, so all these devices use incredibly slow PIO
>> 3. pcan in theory also supports a PCI card, but I've never seen one in the 
>> wild.  It was never a very popular device, because they were pretty 
>> expensive compared to the Prism cards.
>> 4. pcwl devices *were* popular (probably the most common 802.11b PC card.) 
>> Additionally the driver "supports" a miniPCI variant (PRISM 2.5).  However, 
>> the miniPCI variant has a nasty erratum which can hard hang easily, and the 
>> pcwl driver lacks the fix for this.  (I have some information on fixing it, 
>> but I never got around to getting this work done for the open pcwl driver as 
>> I didn't get approval from Intersil or Tadpole to open source the equivalent 
>> work I did for the Tadpole driver for the same chip.)
>> 5. Neither pcan nor pcwl support modern WPA (never mind WPA2).  This makes 
>> them mostly useless for anything except wide open wireless networks.
>> 6. pcata and friends are for PCMCIA memory cards, the most common variant of 
>> which was CF.  However, all modern systems that still have CF support do so 
>> over much faster IDE, SATA, or USB interfaces.   The only exceptions to 
>> these are certain embedded platforms (e.g. MIPS Alchemy boards) that have no 
>> chance of ever running illumos.
>> 
>> The main motivation for this change is general housekeeping -- this code is 
>> thoroughly bitrotten and I don't know of anyone who's used any of this stuff 
>> in the last several years.  (I was probably one of the last users on certain 
>> SPARC hardware, but that was about 5 years ago now, I guess, and I removed 
>> the SPARCLE platform support from illumos years ago.)  The other thing is 
>> that these interfaces -- the pcmcia nexus in particular, make use of some 
>> other legacy kernel interfaces, which we would like to clean up.  Removing 
>> the pcmcia nexus support will allow the existing cardbus stack to be cleaned 
>> up, and will allow some of the underlying legacy interfaces to also be 
>> cleaned up and simplified.  (In particular, the interfaces most directly 
>> benefiting from this will be the legacy power management interfaces;   see 
>> illumos bug 680.
>> 
>> So, with that goal stated, please indicate any specific reasons for 
>> objecting to this change, with supporting details.  Such reasons might 
>> indicate current or planned use of these interfaces (seems unlikely), or any 
>> reason(s) that anyone knows of specific risks.
>> 
>> As a follow up, I'd also like to hear (more as a matter of a survey than 
>> anything else) if anyone out there is using CardBus.  My guess is that even 
>> that has fallen by the way side, having been thoroughly supplanted by 
>> ExpressCard and USB.  If it turns out that even CardBus is of little or not 
>> use, I'd be happy to nuke that as well -- frankly it would make the task 
>> easier if I don't have to extricate cardbus and could just nuke the entire 
>> pcic nexus. :-)
>> 
>> Thanks.
>> 
>>      - Garrett
> 
> illumos-discuss | Archives  | Modify Your Subscription         



-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com

Reply via email to