Hi,
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
On Fri, 2 Feb 2001, Miles Lane wrote:
> 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.
[...]
> Anyone willing to sign up for some of this effort?
I'll convert all the network drivers once a design is agreed upon.
Jeff
Jeff Garzik wrote:
>
> On Fri, 2 Feb 2001, Miles Lane wrote:
> > 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.
> [...]
> > Anyone willing to sign up for some of this effort?
>
> I'll convert all the network drivers once a design is agreed upon.
Would you write up a proposal for this design that we could work
from to come to a agreed design? You are probably the best person
to start this process.
Thanks!
Miles
Miles Lane wrote:
>
> Jeff Garzik wrote:
> >
> > On Fri, 2 Feb 2001, Miles Lane wrote:
> > > 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.
> > [...]
> > > Anyone willing to sign up for some of this effort?
> >
> > I'll convert all the network drivers once a design is agreed upon.
>
> Would you write up a proposal for this design that we could work
> from to come to a agreed design? You are probably the best person
> to start this process.
I'm going to finish my current projects first :)
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
As we look into developing PCMCIA support in the
2.4/2.5 kernel trees, in addition to reading the
pcmcia-cs code to learn about problems with specific
devices that need to be handled, David Hinds also
a reference page that lists some a bunch of issues
that are in varying degrees of resolution:
http://pcmcia-cs.sourceforge.net/ftp/BUGS
This may be a useful resource. I'll see whether
David has time to update this page with a bit more
detailed explanations of the problems. Some of the
items are pretty vague. For example,
the Asix AX88190 chipset, which has
several serious bugs and incompatibilities
that render the regular pcnet_cs driver
unusable
It would be nice to know exactly what those bugs
and incompatibilities are. :-)
Anyhow, I hope this helps,
Miles