[RFC] setting resources available to pcmcia

Dominik Brodowski linux at brodo.de
Thu Jun 12 23:15:34 BST 2003

Hi Pavel,

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

Assuming that the kernel knows what resources are available, yes. However, I
seem to recall that this is too risky an assumption to be a viable solution.
Russell or others, please correct me if I'm wrong.

However, we might do the following:

a) hope all is correct mode

Assume that the kernel knows what resources are available [all should
remember the command line argument which allows resources to be reserved]

b) fallback mode == a), b) or c) in the RFC

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

Currently, what you suggest is impossible anyways. So it won't be a
regression. And early userspace is long _before_ init starts. This way much
if not all of what you suggest will become true -- even though PCMCIA is
handled seperately.

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

It's not cardctl that's evil, it's that any other IOCTL may happen while the
resource setting is in progress. IMHO it's a theoretical problem, we should
concentrate on getting rid of cardmgr / cardctl anyways so that this problem
won't exist in future.

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

See above. I _hope_ I can agree with you, but I think it's not possible :-(

> > #!/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. 

No, please not! I want to get rid of that ioctl as a whole. And that
includes no cardctl any longer.

> I don't quite understand the need to separate setting resources and
> starting the PCMCIA subsystem.
So that ds.c knows whether you're done with setting the resources.


More information about the linux-pcmcia mailing list