AW: PCMCIA patches - unsuccessful so far
linux at brodo.de
linux at brodo.de
Thu Apr 17 00:41:06 BST 2003
> 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
> 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
> party drivers. The scenario I'm afraid of is that we force updating
> drivers but don't make it easier to write new drivers and don't provide
> infrastructure to support embedded and feature-limited bridges better
> 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
> 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
> 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
> SS_CAP_STATIC_MAP and io_offset should be obsoleted.
> 4) Socket driver requests the necessary resources from the kernel
> 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
And my sysfs_resource patch really doesn't _change_ anything we do wrt
resources; just the way the information is passed from user- to
-------------- 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
> > a "legacy-free" modern notebook, it's easier to tell what's available
> > ARM -- at least that's what Russell said, IIRC.
> Userspace software should have no business here. It should be possible
> reserve resources occupied by non-PnP devices for all purposes, not
> 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
> 1) Development cycle. Not everybody wants to way years for the next
> 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....
More information about the linux-pcmcia