Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane <miles@megapathdsl.net>]

Here's an overview of where we are now.

David Hinds wrote:

> On Wed, Jan 31, 2001 at 08:19:56PM -0800, Miles Lane wrote:
> 
>> Would you be willing to outline all the major things that
>> need to addressed to get full PCMCIA support in 2.5?
> 
> 
> Here is a short 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.

(Jeff Garzik has volunteered to make required changes to
the PCMCIA network device drivers.  Perhaps he could make
these pcmcia_device_id and pcmcia_driver changes to the 
network drivers, thus creating a reference implementation that 
could then migrate rapidly to the other driver families?)

> -- 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.

Yes.  This seems straightforward.

> -- The CIS override functionality in the PCMCIA package is unpleasant
>    to support in a completely in-kernel framework.

(Discussion has started on linux-hotplug-devel)

===============

> Missing functionality in the hotplug framework:

> 1. 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.

Is it true that doing this is fairly straightforward and
is it something that one person could do?

(No discussion or volunteers for this, yet)

--------------

> 2. There is no mechanism to request a card eject in the new framework.
>    This is required for clean shutdown of SCSI and IDE adapters.

(Rusty Russell and other kernel developers are looking into 
related improvements.  Also, discussion has started on 
linux-hotplug-devel)

--------------

> 3. 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".

Well, solving this problem for PCMCIA devices alone might
be the wrong way to go.  Don't want to meet the need for 
flexible configuration for the general case of all drivers 
for all devices on all hotpluggable busses, if possible?  
If so, then the interesting question is whether any 
configuration needs are unique to PCMCIA configuration.

Perhaps we need two things:  a good outline of the
configuration functionality in pcmcia-cs and a list
of the types of configuration handling we need for
the general hotplug system.

I'm afraid I don't have a very good handle on how this
should all work.  Suggestions?

===============
> Missing functionality in the 2.4 PCMCIA drivers:

> 1. 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.

Huh?  You mean that the driver can't handle _some_ Cardbus adapter
cards, right?  Mine work fine.  As for the issue of many drivers
requiring overrides and special settings, could you please give us
a few examples?  Also, if you would elaborate on why this is a flaw 
in yenta, that would be really helpful.  I'd also like to know if 
you have any thoughts regarding how this flaw might be fixed (vague 
handwaving would be okay, if others could extrapolate from it).

---------------

> 2. 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.

(David Woodhouse will explore fixing this problem)
(Discussion has started on linux-hotplug-devel)


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel