
		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 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 new 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 debugging support at all.
o The kernel PCMCIA package cannot be configured to use PnP BIOS calls
  for resource management.  This will not be fixed, but is rarely a
  serious issue.
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 mainly bug fixes.

Q: Which should I use / which is better?  The kernel PCMCIA, or the
   standalone PCMCIA?
A: It rarely matters.  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 be really picky about 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 because it is a stable platform; and then
   port to 2.4.

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.

Q: Who is maintaining the kernel PCMCIA subsystem?
A: I am not playing as central a 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.

