Notes about PCMCIA in the 2.4 kernel When compiling the standalone PCMCIA package, the Configure script decides whether or not to build any kernel modules by looking at the value of the CONFIG_PCMCIA option in your kernel configuration. If CONFIG_PCMCIA is enabled, then by default, no driver components are built. If CONFIG_PCMCIA is disabled, then all the modules will be built and installed. It is safe to compile the user tools (cardmgr, cardctl, etc) in a PCMCIA package whose version number differs from the PCMCIA version number in the kernel source tree. The kernel PCMCIA header files take precedence over the ones included in the PCMCIA package, if CONFIG_PCMCIA is enabled. The following tables show the correspondence between PCMCIA client driver names, and kernel configuration options. Network drivers: 3c589_cs 3Com 3c589 CONFIG_PCMCIA_3C589 3c574_cs 3Com 3c574 CONFIG_PCMCIA_3C574 axnet_cs Asix AX88190 chipset CONFIG_PCMCIA_AXNET fmvj18x_cs Fujitsu FMV-J18x CONFIG_PCMCIA_FMVJ18X nmclan_cs New Media CONFIG_PCMCIA_NMCLAN pcnet_cs NE2000 compatible CONFIG_PCMCIA_PCNET smc91c92_cs SMC 91Cxx CONFIG_PCMCIA_SMC91C92 xirc2ps_cs Xircom 16-bit CONFIG_PCMCIA_XIRC2PS ibmtr_cs IBM PCMCIA tokenring CONFIG_PCMCIA_IBMTR ray_cs Aviator/Raytheon 2.4MHz CONFIG_PCMCIA_RAYCS netwave_cs Xircom Netwave AirSurfer CONFIG_PCMCIA_NETWAVE orinoco_cs Hermes chipset 802.11 CONFIG_PCMCIA_HERMES wavelan_cs AT&T/Lucent Wavelan CONFIG_PCMCIA_WAVELAN Character drivers: serial_cs PCMCIA serial device CONFIG_PCMCIA_SERIAL_CS SCSI low-level drivers: aha152x_cs Adaptec AHA152X CONFIG_PCMCIA_AHA152X qlogic_cs Qlogic CONFIG_PCMCIA_QLOGIC fdomain_cs Future Domain CONFIG_PCMCIA_FDOMAIN Other drivers: ide-cs ATA/IDE devices CONFIG_BLK_DEV_IDECS All CardBus drivers have been folded into their corresponding regular PCI drivers using the new "hot plug PCI" interface. Here is a mapping from old CardBus drivers to new hot plug drivers: 3c575_cb 3c59x 3c59x/3c90x/3x575 series CONFIG_VORTEX tulip_cb tulip DECchip Tulip (dc21x4x) CONFIG_TULIP epic_cb epic100 SMC EtherPower II CONFIG_EPIC100 serial_cb serial Standard/generic serial CONFIG_SERIAL apa1480_cb aic7xxx Adaptec AIC7xxx SCSI CONFIG_SCSI_AIC7XXX There are two drivers for Xircom CardBus cards: xircom_tulip_cb Xircom Tulip-like CardBus CONFIG_PCMCIA_XIRTULIP xircom_cb Xircom CardBus (new driver) CONFIG_PCMCIA_XIRCOM Hot plug PCI drivers are not managed by cardmgr; they are managed by the "hotplug" subsystem. See http://linux-hotplug.sourceforge.net for information about this facility. When cardmgr sees a card that is owned by a hot plug PCI driver, it will ignore that card. There will be one beep when these cards are inserted/ejected, but they will be identified only as a "CardBus hotplug device" in the log files. Known problems and limitations: o Some of the less widely used client drivers, like the memory card drivers, have not been ported into the 2.4 driver tree yet. o The yenta_socket driver does not have the /proc interface of the i82365 driver, so the dump_exca and dump_cardbus tools do not work. It actually has no built-in debugging aids at all. o The kernel PCMCIA package cannot be configured to use PnP BIOS calls for resource management. Recent kernels do have PnP BIOS support but the "glue" hasn't been written. o With the introduction of the Hot Plug PCI subsystem, CardBus drivers now no longer act like other PCMCIA drivers; most obviously, they don't interact with the PCMCIA device configuration scripts. These devices are configured using the "hotplug" scripts. Answers to some common questions: Q: Are these two versions of PCMCIA both going to continue with active development? A: The kernel PCMCIA subsystem should be the focus for ongoing development. The standalone pcmcia-cs drivers are still being maintained but the focus has shifted from adding functionality, towards just bug fixes. Q: Which should I use / which is better? The kernel PCMCIA, or the standalone PCMCIA? A: The client drivers should generally behave the same. At this point, most current distributions use the kernel PCMCIA subsystem, and I recommend sticking with that unless you have a particular need that is only met by the standalone drivers. Q: What should I do as a driver developer? A: I will not be including any significant new functionality in the standalone PCMCIA package. In some cases it might still make sense to develop contributed drivers for the standalone package first if backwards compatibility with 2.2 kernels is useful. Q: I'm using the kernel PCMCIA subsystem but want to use a driver that isn't included in the kernel yet. Why can't I compile that driver from the standalone PCMCIA package? A: The Makefiles are set up to discourage this, mainly to prevent people from trying combinations that don't make sense. Things in the "modules" directory of the standalone package will not work with the kernel PCMCIA subsystem. However, you can build client drivers by doing a "make install" in either the "clients" or "wireless" subdirectories after a normal "make config". Q: Who is maintaining the kernel PCMCIA subsystem? A: I am not playing a central role in maintaining the kernel modules as I have with the standalone package. I have periodically updated some of the core modules and client drivers with fixes from the standalone package. Linus Torvalds wrote the yenta_socket driver more or less from scratch and he has been maintaining that bit. Jeff Garzik has been working on the hot plug PCI adaptations for the tulip_cb, 3c575_cb, and epic_cb drivers. Q: What about 2.5, 2.6, and beyond? A: The PCMCIA subsystem in 2.5 has been extensively rewritten, thanks to the work of Russell King, Dominik Brodowski, and others. There is a mailing list devoted to discussion of new PCMCIA development at http://lists.infradead.org/mailman/listinfo/linux-pcmcia. The standalone pcmcia-cs modules will probably not be ported beyond 2.4 kernels, due the number of API changes.