[RFC] setting resources available to pcmcia

[Pavel Roskin]

Hello, Dominik!

First of all, thank you very much for your work on PCMCIA.  I didn't have
a chance recently to test the patches you are sending, but the
descriptions sound very good.  Don't feel alone in your struggle for
better PCMCIA support.

> 1.) We need to deal with both static and window sockets -- and
>   only the latter is done correctly with current code. This is
>   something that Russell's mapstatic.c and mapwindow.c will take care
>   of. However, I think this might be the second step   _after_ what I
>   propose here.
>
> 2.) Setting the resources available for usage by windowed sockets
>   needs to be done by userspace. It might be moved to early userspace
>   once that gets usable.

I don't understand that.  I see no reason for PCMCIA to be different from
all other buses, which can be configured completely in the kernel space.

I can mount the root filesystem over NFS using a PCI network card, but not
a PCMCIA card unless I use an initial ramdrive.  It may sound like a bad
idea, but some embedded devices may need to use a PCMCIA card because
there are no better connectors on the board or because only PCMCIA cards
support the necessary protocol (e.g. GPRS).

Another realistic example would be a filesystem on the ATA CompactFlash.
I've seen boards where it was firmly connected and non-removable.

I believe that whatever PCMCIA devices are found at startup should be run
by the kernel not just before init starts, but before the filesystem
containing init is mounted.

The user can take control of the devices later.

> 3.) The ds.c subsystem may only start when all resources are
>   available for windowed sockets. Also, I'd prefer not to implement
>   coldplugging from the beginning, so I'd like to add the reqirement
>   that the ds.c subsystem may only start after userspace hotplugging
>   has been started.

You may want to explain your preferences.  It's fine with me if it's a
temporary solution and there is no regression in features.

> 4.) Russell: are there any (different) requirements for the cardbus
>   subsystem?
>
> 5.) Also, I want to keep a "compatibility code" which allows current
>   userspace cardmgr's (3.2.3 or 3.2.4) to run.

That's fine as long as it works.

> Of course, an user which runs cardmgr and cardctl at the same time
> while the resources are set might be able to break things. So print a
> warning "you're using a version of cardmgr which might not be the best
> suited for this business", and ask all power-users to use mode b) or c)
> instead.

Some cardctl commands could be disallowed if they are problematic.

> b) new mode [requires new userspace helper]
>
> The resources are set by passing some arguments to sysfs files. To
> even create the files neccessary to fill these arguments to the
> kernel, another sysfs file will need to be echo'ed 1
> (e.g. pcmcia_set_resources ); after all is done a command "echo 1 >
> pcmcia_start" is issued [1 to pcmcia_stop will be called upon
> shutdown], and then ds.c may start doing all sorts of wonderful stuff.

Oh, please!  Even microkernel OSes handle resources in the microkernel.
It seems to me that you are trying to replace cardmgr without replacing
the broken model behind it.

I have no problem with activating PCMCIA using sysfs, but I have a problem
with userspace telling the kernel which addresses to use.

> PART II. MAP_STATIC SOCKETS
>
> As we have no (working) compatibility stuff here, it gets easier:
>
> a) new mode [requires shell script]
>
> #!/bin/sh
> echo 1 > /sys/..../pcmcia_set_resources
> echo 1 > /sys/..../pcmcia_start

That's fine, although it would be great to have a new cardctl command for
that.  The problem with echo is that error reporting is limited to the
standard errno.  Not everybody checks kernel messages.

I don't quite understand the need to separate setting resources and
starting the PCMCIA subsystem.  Also, I think that the PCMCIA subsystem
should be running by default.

-- 
Regards,
Pavel Roskin