[2nd RFC] setting resources available to pcmcia

[Dominik Brodowski]

OK, as I said in my last e-mail, I've been thinking about it a lot
more.

a) Even windowed sockets may have fixed, static resources with no
reason to worry about ISA clashes etc. [see dwmw2's exaple]

b) There should be no assumption on whether all sockets behave one way
or other -- it's a per-socket matter.

c) As it's a _socket_ matter, it should not be done at any other level.

d) This means that any new interface which allows resources to be set
should be located in rsrc_mgr.c or (better) mapwindow.c.
(see http://patches.arm.linux.org.uk/pcmcia/pcmcia-20030423-8.diff )

e) Backwards compatibility with cardmgr-3.2.{3,4} is important, as
users should only have to upgrade their tools when cardmgr isn't
needed any longer. I think that this goal can be reached wihtin 4
months -- most of the code already exists.

f) The only way to know whether cardmgr is done with setting the
resources is by recognizing a different ioctl. This is the
BIND_REQUEST command after a PCMCIA card was inserted or found in
a socket. This means we can't block the insert call (as rmk's patch
does, IIRC) as long as we are in "compatibility mode".

g) Therefore I suggest the following:


Ia.) Add a flag to struct pcmcia_socket indicating whether resources
are available on this socket. It is assumed (at first?) that resources
don't disappear. If this flag is set, the new stuff I intend to add to
ds.c (in-kernel-matching etc.) will proceed unblocked, even way before
/sbin/init is called.

Maintainers of socket drivers which either are MAP_STATIC or can be
limited to I/O or mem windows which are 100% outside ISA space
[dwmw2's case] are encouraged to set this flag. However, until
mapstatic.c/mapwindow.c (see II) are merged there will still be severe
issues on these sockets. [no regression, though...]


Ib.) Implement cardmgr compatibility mode - This is exactly the same 
mode I suggested yesterday: 

The resources are set by the existing ds.c ioctl
DS_ADJUST_RESOURCE_INFO. Once a different command is issued, we assume
all resources have been set, and disallow all further
DS_ADJUST_RESOURCE_INFO calls. From then on ds.c may do all sort of
stuff on its own, e.g. its own driver matching, binding, etc. 

Of course, an user who runs cardmgr and cardctl at the same time
while the resources are set might be able to break things. Also note
that until the new interface (II) is implemented the setting of
available resources will be limited: resources can't be re-set until
a kernel reboot or module unload/load cycle. IMO we should
accept this, though. In-kernel PCMCIA is broken anyways, and we're
fixing it; this semi-breakage [>99% of all users won't recognize it]
should not be a reason against it.



II.)  Add all sorts of new features to ds.c (in-kernel-matching etc.);
in parallel update the socket drivers to use mapstatic.c /
mapwindow.c, and integrate a new interface on how to set the available
resources on sockets where we have no choice but to request this
userspace input. This should be a part of mapwindow.c, AFAICS.



III.) Once II. is sorted out, we need no help by _cardmgr_ any
longer. Offer a new tool which sets the resources on the sockets which
need it [shell script should suffice, but maybe a parser that converts
the existing /etc/pcmcia/config.opts would be nice]. Remove the
cardmgr ioctl, or (at least) make it a compile option and deprecate it.





If there are not too many screams against this proposal I'll provide a
patch for Ia and Ib and also some pieces for ds.c in II for inclusion
very soon.

     Dominik