The way to port pcmciamodem.c it is to get rid of it completely.  On the bitsy,
a user level program open's /dev/pcm0ctl and writes a string like:

	configure #xspec arg [ index ]

into it.  The '#xspec' is a device specifier like you'ld use in bind, e.g.,
#l0.  'x's configure routine is called as:

	devtab[].config(int on, char *spec, DevConf *cp)

where 'on' == 1 means to configure and enable the card and == 0 means disable and unconfigure it.
      'spec' is the same as for bind's, for example, 0 or 1 to indicate ether 0
			or ether 1,
      'cp->mem' is where the pcmcia chip has configured the memory to be
      'cp->port' is where the pcmcia chip has mapped the io ports
      'cp->irq' is where the pcmcia chip has mapped the interrupt
      'cp->type' is the 'arg' that the user wrote

This allows us to flavor the card after the fact rather than at boot time
or to disable it so that we can pull it out.

Look at the config routine in devether.c.  The equivalent to pcmciamodem.c
is adding a config routine in port/devuart.c.

I did this model after I did the PC and like it a lot more.  It means that the
drivers don't have to know about all the different names a card can be called by
and allows us to pull cards out and insert new ones without rebooting.  Its
what I should have done in the first place.  I'm currently rewriting pc/devpccard.c
and pc/devi82365.c to be a single driver with exactly that interface.  All the
pcmciaxxxx.c files will disappear.  boot/bootip.c will configure in the card if
it needs to.

If you rewrite devuart.c to do this, I'll be happy to pick it up as soon as I
finish the pc conversion.  If not, I'll do it anyways since I want to try
our gprs card on the bitsies.  Might make them a bit more useful than the
802.11 card does or at least useful in different situations.  Of course, until
we can put the suckers to sleep and wake them up successfully, they're only
useful for a few hours at most.