In message <199510091705.NAA25473@cs1.boston.deshaw.com>  Charles Hannum wrote:
> 
>    On Thu, 5 Oct 1995 11:02:13 -0400  Charles Hannum wrote:
>    > 
>    > * PCMCIA support.  This is going to be difficult in its current state.
> 
>    I use this, so I have interest :-)
> 
>    Why will it be difficult?
> 
> I looked at the code again over the weekend, and most of my complaints
> about it seem to have been addressed.  The remaining problems are:
> 
> 1) Its configuration model is somewhat wrong.  It should be more like
> the current SCSI code, where you have something like:
> 
> pcic (PCMCIA controller chip) -->
> pcmciabus (crossbar) -->
> ed, ep, etc. (PCMCIA devices)
> 

It's not there because it would have required to change the config program.
Thats a thing I avoided for an 'unofficial' modification. It's the right 
thing to do if it's in the main tree.

> The pcmciabus should be able to have as many subdevices as that
> controller supports, which may not be limited to 2.  In addition, you
> should be able to have an `infinite' number of controller chips in a
> single machine.

The pcic-chip can have only 2 devices. 
And unless I goofed somewhere the limit is on the chip-driver and not
in the pcmciabus framework.

> 
> 2) It doesn't notice when a device is removed or added; you have to
> tell it manually.

This is nice to have feature, and not very hard to implement.
Just add a interrupt handler for the card-change interrupt on the
pcic chip, and start a unconfig/off or on/config according to the
slot-state after the interrupt. A daemon to wakeup would be nice 
for additional setup after the event (ifconfig up/down etc.).

One warning, as most have figured out there is a bug removing/unconfiguring
code on the all -current versions of my code. If haven't had time to track it 
down.

The main reason for it' absence is, that you need to modify all drivers
used with PCMCIA, to not crash or hang the system if the card is removed.
Again something that needs a lot of modifications to the 'official' code,
which I didn't want to have (and maintain) in an unofficial modification.


> 
> Probably neither of these are sufficient to prevent committing the
> code, but they should be fixed at some point.
> 

The last one is rarely needed by most people using the system today,
but I fear may be needed if more 'non technical' people are using the system.

Stefan

--
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270
fortune: "You can't make a program without broken egos."