AW: PCMCIA patches - unsuccessful so far

[Pavel Roskin]

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.

On Wed, 16 Apr 2003 linux at brodo.de wrote:

> permission not, but AFAICT he doesn't like the current state of PCMCIA.
> The 2.5.67 patchset is more or less "prove-of-concept", and includes
> some things which really should not be done the way they are done. The
> next patchset will be much better!

OK, let's see.

> yesterday) are in the kernel, I'll start cutting out sensible pieces and
> feed them to Russell and Linus.

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 think this approach is wrong.  Resource handling should be done in
> the
> > kernel.  It's better to specify what resources cannot be used.  And by
> the
> > way, it's very platform-specific.
> That's why it can't be hardcoded in the kernel.

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.

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

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

2) Integration with userspace software.  Not everybody wants to add a
backward compatibility layer to the userspace software to deal with older
drivers still in use.

3) Non-free firmware included with the driver.

4) Non-free binary object files included with the driver.

-- 
Regards,
Pavel Roskin