Subject: pcmcia stuff: what's next?
To: None <tech-kern@NetBSD.ORG>
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
List: tech-kern
Date: 02/06/1996 18:17:37
   Date: Mon, 5 Feb 1996 10:23:33 -0500
   From: John Kohl <jtk@atria.com>

   Various folks have been posting on current-users and port-i386 about
   pcmcia support issues.

   My understanding of the current state is:
   * Stefan Grefen wrote some support code, starting about 2 years ago
   * His latest snapshot from July 1995 has been fit into a 1.1 kernel
     source tree at least once (by me), and probably also by others
   * I do not recall any i386-specific parts to his work, but I'm not 100% sure
   * various NetBSDers have expressed uneasiness with the current
     implementation. My own issues are:
	   - fragility in probing: I have seen apparent hangs when some
	     cards are used; I have seen a consistent failure to
	     configure a slot when warm-booting without detaching a card first
	   - no card/socket services model
	   - no hot swapping support
	   - (general issue, not just pcmcia): configuration framework
	     needs adjustment or extensions to handle loaded device
	     drivers/configurations

I took Stefan Grevens code, as transformed by you to -1.1, and
re-enabled the if_ep support. On my inquiry to core I got the answer
that they'd be glad to see some work done on this. From what I
understand, there are a few conditions, most important that it'll be
made more BSD-config-friendly.

To make that more clear: Stefan uses (not everywhere, but in some
places) lots of his own code for services which the autoconf stuff
could provide . While I quite happily use his code, it makes
integrating, e.g., a new architecture (Amiga Technologies promised to
give me information on the A1200's PCMCIA port as soon as they find
it) a bit more difficult than would be necessary.

Anyway, I started to read around in the code and design a few
substantial changes:

a) use the autoconf stuff for configuration. IMHO, this can easily be
used for later addition of devices (just reprobe the pcmcia-bus in
question). 

b) make (on Intel machines) each chip its own PCMCIA bus. This fits
more easily with the autoconf mechanism, IMO.

As for:	   - support only for i82365 or clones

I looked at the Freebsd code; I intend to use it as a doc how to
integrate a few chip variants to the pcic driver. I hear their code is
quite stable, but it isn't as modular as we -- on a multi platform OS
-- would want it to be. Same argument applies to the Linux stuff.

c) as for removal of cards: We would add a detach method to the device
struct of the bus driver, accessible for the drivers through the
parent pointers. (Christos Zoulas is interested in the PCMCIA
integration, and was not totally shocked by the idea).

d) To clean up the code, I'd move some stuff out of privatly designed
structures and into the device structures, as necessary. This has not
top priority.

If a) is done, stuff like 
	   - If ISA configuration model will be changing, how does that
	     affect this work?
and
	   - any multi-platform gotchas waiting in the wings?

will be much easier to handle. 

What do you think of that?

Regards,
	Ignatios Souvatzis