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

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 3 Feb 2001, Miles Lane wrote:

> Well, would care to elaborate on what the PCI mess is, exactly?  

See attached patch. 

> I like the idea of not overloading drivers, if overloading leads to 
> horribly complex or unmaintainable code.  Is there any generic code in
> the 
> i82365 driver that you think should be split out and included in drivers
> for the various bridge drivers?

Some, yes. But I'm not sure there's enough there to justify doing so.

> Why do you think the codebase needs to be jettisoned?

It appears to be based on the PCMCIA spec. It allows for silly legacy 
drivers which work with only certain IRQs and IO addresses - sort of 
ioremap(MAP_FIXED) stuff. It's complex, racy, overdesigned, the layering 
is wrong... oh and it uses sleep_on() :)

I don't want that to come across as a criticism of David Hinds; there are 
reasons why some of it was specified like that, and maybe the code for 
other operating systems actually requires some of the stuff which appears 
in Linux to be superfluous. 

In another conversation, Linus has agreed with my assessment. 

> Which do you think should happen first:  you develop an exploratory 
> implementation or have a general discussion of design issues?

I'm in the middle of writing JFFS2 at the moment. An exploratory 
implementation isn't going to happen for a while. I think a discussion of 
design issues is worth having.

Bearing in mind that it's first thing on a Sunday morning and I haven't 
really fleshed this out very much yet (i.e. be kind), here's my basic 
idea.

Remove cardmgr completely. It doesn't do anything that can't be done from
an improved /sbin/hotplug usermodehelper.

We use the 'hotplug isapnp' concept. Pick fields which can be used in 
place of manufacturer and device ID to identify devices and match them 
with drivers. PCMCIA devices actually have mfr and device IDs - I'm not 
sure how reliable they are. They can also have a text string.

As with PCI, drivers register with the core PCMCIA code a pcmcia_device_id
table which identifies a superset of the devices they want to drive.  
Further elimination is done by the driver's probe() routine, which can 
check the CIS if it needs to, or check for the existing of the letters 
'modem' in the text string, etc. 

Upon arrival of a card, the CIS is parsed by the core code and turned into 
a set of resource structs in the pcmcia_dev_t, just like PCI. If 
necessary, a driver can fix these up before calling 
pcmcia_enable_device(). We probably want a way for resources to be enabled 
individually, rather than in one go with pcmcia_enable_device. Especially 
because some of them (attribute memory space/normal memory space) are 
mutually exclusive. 

The 'bus' abstraction is useful - see include/pcmcia/bus_ops.h. But also 
'grep --context=2 doesn include/linux/mtd/map.h' :) But now might not be 
the time to push that, as apparently Linus doesn't like it. I don't want 
that argument to get in the way. 

Core PCMCIA code has functions for parsing a CIS, doing the necessary 
resets and delays when cards are inserted, etc. Nothing on top of the 
socket drivers like ds.o at the moment. 

Expose the CIS to userspace via /proc/bus/pcmcia as a whole. We don't care 
if we have to duplicate the CIS parsing code in userspace and it's 
already in the kernel. 

Some way for userspace to override which driver gets to 'bind' to a
particular card? Maybe, but not with the ugly 'bind' stuff we already
have, and not by requiring userspace to get involved every time. Maybe
just 'echo drivername > /proc/bus/pcmcia/00/driver' and use 'drivername'
as an extra field to match in the core code when seeking a driver to go
with any particular card?


-- 
dwmw2




_______________________________________________
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