PCMCIA development and 2.6-test

[Pavel Roskin]

On Fri, 11 Jul 2003, Dominik Brodowski wrote:

> So, finally, Linus decided to switch to 2.6-test. What does this mean for
> us? Here's my suggestion:
>
> a) don't do anything wrt in-kernel matching, hotplug etc. It's too invasive
> for a soon-to-become-stable series. With a few exceptions and a few cleanups
> [most notably the register/unregister process] any out-of-tree 2.4. pcmcia
> driver should work with 2.6. too.

I agree with that, but it would be pity to stop exploring this approach in
the meantime.  Maybe we could have a CVS repository with the experimental
code?  I can help with makefiles to make it possible to build the new
PCMCIA modules straight from the CVS working directory.

I often want to test the patches that you post here, but I don't have time
to patch the kernel and then remember to remove those patches.  Having a
separate PCMCIA directory on CVS would encourage more testing.

Also, we could try eliminating hotplug in CVS and then if we may find
something that can be put safely to the 2.6 kernels to simplify changes in
2.7 kernels.  I mean, if there is something that every client driver
should do for hotplug support, it's better to require it now and have a
chance not to require any updates in the client drivers in 2.7 kernels.

In particular, it may be necessary for every driver to provide a unique ID
for every device so that different hotplug actions could be associated
with e.g. two network cards with different MAC addresses.

> b) continue the improvment of the socket handling, especially the socket
> resource handling. This includes the "turn rsrc_mgr on its head" patch, a
> mapstatic.c / mapwindow.c split-up, and some other work.

I think if client drivers are not affected, it should be OK, even if every
socket driver needs to be rewritten.  However, it would be nice to stop it
after 2.6.0 release if possible.

> c) give me a chainsaw for 2.7. so that cardmgr can die, pcmcia and cardbus
> can be seperated even more, #typedef's are removed, CodingStyle is adhered.

I think that most trivial changes should be allowed until 2.6.0 if they
are safe.  Replacing typedefs is trivial, in the sense that the
probability of breaking things accidentally is low.  Of course, if that
breaks client drivers, we should think twice and probably wait until 2.7
kernels.

Coding style can also be changed safely.

-- 
Regards,
Pavel Roskin