AW: PCMCIA patches - unsuccessful so far

[linux at brodo.de]

> First of all, I suggest that we keep the mailing list in Cc: so that we
> can have the discussions documented.  Also, Russell and other people
would
> be able to join.
Sorry, was accidental -- the web-mailing interface I use at university
doesn't understand group-reply :( ...

> The real question is how far we want to break things before 2.6.0.
> Another question is whether we want to make it really hard to adapt
third
> party drivers.  The scenario I'm afraid of is that we force updating
all
> drivers but don't make it easier to write new drivers and don't provide
> infrastructure to support embedded and feature-limited bridges better
than
> we do now.

I definitiely do not want to break that much before 2.6.0, but I want to
make it easier to support new drivers (which won't need changes in
/etc/pcmcia/ any more) and clean up the core (locking, CodingStyle,
functionality, bugs, etc.) -- by incremental patches, so that we won't
have to argue about inclusion of "one big patch" even during the next
development cycle. 

> Well, it seems we misunderstand each other.  Of course I didn't mean
> hardcoding.  I mean something like this:
> 
> 1) Card driver determines that the card needs e.g. 2Mb of memory
> (4k-aligned) and 0x40 bytes of I/O space starting at 0xXXXX0300.  The
> card formulates requests where all those requirements are represented
in
> some way.
> 
> 2) pcmcia_core redirects the requests to the socket driver.
> 
> 3) Socket driver (and not pcmcia_core!) determines whether the hardware
> can provide the windows of the required size and with required
alignment.
> SS_CAP_STATIC_MAP and io_offset should be obsoleted.
> 
> 4) Socket driver requests the necessary resources from the kernel
resource
> pool.  Successful request locks the resource immediately.
> 
> 5) Socket driver programs the hardware to decode addresses in the
> allocated range.
> 
> 6) Card driver starts using the new memory and I/O windows.
> 
> In other words, there are two factors determining whether the resource
> allocation request can succeed:
> 
> 1) Capability of the socket.
> 
> 2) Free space in the kernel resource pool.

cc'ed rmk so that he can comment on this. As I said, I have not yet taken
a look at the resource management code itself; so I'm not in the position
to judge _any_ approach yet. But it really does sound like a good way to
go...

And my sysfs_resource patch really doesn't _change_ anything we do wrt
resources; just the way the information is passed from user- to
kernelspace.

   userspace                                             kernel
   /etc/pcmcia/config.opts                             rsrc_mgr.c
                -------------- OLD: ioctl ---------------->
                - TEMPORARY "proof of concept": sysfs ---->

However, the sysfs interface (which I needed to show that cardmgr is not
needed any longer) will be dropped for 2.5.68 - so no need to argue about
it any longer :)

> > And while it's easily possible to tell what resources cannot be used
on
> > a "legacy-free" modern notebook, it's easier to tell what's available
on
> > ARM -- at least that's what Russell said, IIRC.
> 
> Userspace software should have no business here.  It should be possible
to
> reserve resources occupied by non-PnP devices for all purposes, not
just
> for PCMCIA.

Indeed. There already is a kernel boot parameter for this (resources or
something, I forgot, sorry.)

> > Do you know why third-party-drivers aren't pushed into the kernel
tree?
> 
> 1) Development cycle.  Not everybody wants to way years for the next
major
> kernel release to make a major overhaul.

I guess I'm preaching to the choir here, but:

Drivers are updated much more regularly, just the core interfaces tend to
stay the same... and external drivers still use the pcmcia-cs package, I
suspect, which hasn't had big changes in many months....

    Dominik