[RFC] what to do next

[Dominik Brodowski]

On Sun, Oct 12, 2003 at 08:28:37PM +0100, Russell King wrote:
> > Well, even though I think that this is kind of a sisyphus-approach 
> > (instead of fixing the core problems trying to cure the symptoms) I know we
> > are in a stability-freeze-phase now.
> 
> I'm not happy with that description of what are facts - in fact it's
> bordering on insulting.

I'm deeply sorry if I offended you in any way in my original e-mail. 
However, it is my impression that there are several bugs (like memory leakage) 
especially related to 16-bit PCMCIA which can only be solved by making 
invasive changes to the core. I also noted that such changes cannot be done
now because of the stability freeze, even though that might be the "easier" 
approach [see below].

> For example, cardbus deadlocks, PCMCIA cards being recognised as
> "memory_cs", IRQ routing, use-after-free in ds.c, etc the list goes
> on.  All these are not due to problems in the old code, but are due
> to the _new_ code.

I admit that the patches I sent included several bad bugs, and I'm glad that
you've done such a great work fixing these bugs up.

> > So, I'll probably delay the fun stuff for 2.7., but then I really want
> > to clean up A LOT.
> 
> If you pile cleanup on top of cleanup on top of cleanup, you end up
> with a pile of crap.  You need to ensure that stuff gets reasonable
> testing and debugged between each cleanup to stop this happening.

Wrt testing: Well, any of my patches have been thoroughly tested on my 
own notebook - but as I only own two 16-bit cards, this is not enough.
The question here is how long to wait for results vs. how speedy the 
development moves forward.

Wrt wait-between-cleanups: if the state of the codes _hinders_ bugfixes,
a cleanup, even though it has rough edges, and even though it affects
large portions of code, can make the bugfixing of both the old and new b
ugs easier.

For example the several levels of indirection between cs, ds and cardmgr
on card insertion and card removal make it difficult to add a) proper
locking, b) proper reference counting, c) avoid memory leakage, or
use-after-freeing d) ...

But let's agree to disagree on this issue?! As I said before, I share your
view on what to _do_ now and what to do later, even though the reasons might
differ...

> > Also, I think we have orthogonal views on the driver model -- while you
> > consider it to _cause_ trouble, it is the road to and of the cleanup in my
> > opinion...
> 
> You've completely missed my point.  The driver model is great, but it
> has a rather large wart which are causing a cancer in PCMCIA.

I'm glad that you share my view about the driver model, and I regret that I
mis-interpreted your mind in this regard.

	Dominik