I asked David Hinds to write up an outline of the things that
will be needed to get PCMCIA support cleanly and completely
integrated into the kernel tree.
David has expressed that he'll not be able to participate in
this work. He has his hands full with his day job and his
role as maintainer/developer of the pcmcia-cs package.
David, I would appreciate one additional layer of information that is
not present in your list. Would add the names of a few representative
devices for each of your bullet points? For example, for the last
list item, what are the names of the major (non-CardBus) PCI-to-PCMCIA
bridges?
Here is David's list:
> To include 16-bit PCMCIA cards in the hot plug framework would require
> few driver changes; the only mandatory changes would be in how drivers
> register themselves and are hooked up with appropriate devices:
>
> -- Make up pcmcia_device_id and pcmcia_driver types, and write new
> register/unregister calls to parallel PCI and USB drivers. This
> would eventually take over for the "ds" module and cardmgr.
>
> -- Rewrite all PCMCIA client drivers to have MODULE_DEVICE_TABLE
> entries and use the new driver services. This can all be done
> incrementally, with ds/cardmgr handling old-style drivers.
>
> -- The CIS override functionality in the PCMCIA package is unpleasant
> to support in a completely in-kernel framework.
>
> Missing functionality in the hot plug framework:
>
> -- Only new network devices generate /sbin/hotplug events now. Modify
> all other device types to also do so: the ones currently handled by
> PCMCIA include serial, parallel, SCSI (all types), and IDE.
>
> -- There is no mechanism to request a card eject in the new framework.
> This is required for clean shutdown of SCSI and IDE adapters.
>
> -- The PCMCIA device configuration scripts have a lot of capabilities
> that the hotplug scripts do not have yet. At the moment, the
> extent of device-specific hotplug configuration is running "ifup".
>
> Missing functionality in the 2.4 PCMCIA drivers:
>
> -- The yenta driver can't handle CardBus adapter cards for desktop
> systems. Many require explicit overrides for the default interrupt
> delivery settings, and a few require other special bridge settings.
>
> -- The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA bridges
> any more. Some of the PCI code in the old i82365 driver needs to
> be put back.
This list does seem to break out the work into chunks that can
be tackled more or less independently.
Anyone willing to sign up for some of this effort?
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/