Subject: Re: pcmcia stuff: what's next?
To: None <tech-kern@NetBSD.ORG>
From: Stefan Grefen <grefen@convex.com>
List: tech-kern
Date: 02/06/1996 01:26:18
In message <9602051523.AA03925@banana>  John Kohl wrote:
> 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

  - MSB/LSB issues in the ISA/pcic code, maybe in the CIS parser

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

	+ this is mostly a problem of accesible hardware. 

> 	- no card/socket services model

	+ The UNIX version came out after I had my stuff running

> 	- no hot swapping support

	+ was working in 1.0 (but not without manualy shutting down
	  the device before) 
	  Real hot swap requires lots of hacks in the drivers
	  to make it foolproof 

> 	- (general issue, not just pcmcia): configuration framework
> 	  needs adjustment or extensions to handle loaded device
> 	  drivers/configurations

	+ I second this there is also no way to remove a device
	  and to deal with autoconfiguring devices (some pcmcia devices
	  realy don't care where they are configured)

> 	- support only for i82365 or clones

	+ Just a missing driver, again no hardware to test on
	  pcmcia_pcic is the driver for i82365.

> 	- If ISA configuration model will be changing, how does that
> 	  affect this work?

	+ if it gets more flexible it makes it easier ...

> 	- any multi-platform gotchas waiting in the wings?

	+ I hope not (besides LSB/MSB) none of the (besides the glue)
	  is realy i386 specific. pcmcia_isa and pcmcia_pcic both in
	  dev/isa should probably go to arch/i386/isa
	   
> 
> I have proposed doing some work to integrate the Linux pcmcia drivers
> and user daemons, primarily because I believe they work on most hardware,
> they appear to have a good service model.

The problem with the Linux approach is (and I think the  card/socket service
model too) that it needs the system up and running. I want to 
be able to boot diskless or nearly diskless (just a kernel,mount and ifconfig
on a disk) or on an system with only a pcmcia-hardisk.
That's why I think the kernel should be able to detect and configure
PCMCIA devices on it's own, without help from userland. My framework
has hooks for userland daemons, but they are mostly just existing not
working. Configuring from userland works.
Some ugliness comes from my goal to change as few things as possible 
from the master-tree. It is an unoffical addition and changing as few
things as possible ensures that upgrades don't become nightmares.

So much in 'defense' of my code. I know it has deficits, is not properly
maintained (thats why my Laptop still runs a 1.0-current version) etc.
I stopped working on it some time ago due to workload. The card/socket
model (Linux, slowaris) has the advantage that more drivers may be available
(I doubt that ...) but on the other hand there are often some quality 
differences between Joe Bozos XXX driver and the XXX driver in NetBSD.
(like the ed-driver and some other NE2000/3com/WD stuff I've seen).

As long as the pcmcia framework doesn't get worse and my boot-requirements
are met I don't care if you take my code, pieces of my code or none of it
at all. (I'm not offended if it's replaced by better code, 
I wouldn't be unhappy though if it would be integrated).

> 
> We should also examine the existing FreeBSD pcmcia work to see if their
> work is close enough to what we want.

I haven't look at their code for a long time.

> 
> So, take this as an invitation to chime in on how "we" should proceed.
> 
> ==John
> 

Stefan

--
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270
"Anything that can go wrong will. It's more fun that way"
 -- Sayings of Murphitus, ancient Husaquahrian philosopher
   (Jack L. Chalker "Vengeance of the Dancing Gods")