[RFC] what to do next
rmk+pcmcia at arm.linux.org.uk
Sun Oct 12 21:28:37 BST 2003
On Sun, Oct 12, 2003 at 06:54:00PM +0200, Dominik Brodowski wrote:
> On Sat, Oct 11, 2003 at 11:09:02PM +0100, Russell King wrote:
> > I think "what to do next" is to solve the various bug reports which
> > keep popping up, as well as actively trying to find bugs.
> > The latest one (see my [CFT] mail) is pretty serious since it can
> > cause memory corruption in any other part of the kernel (dependent
> > on what your workload is.)
> > I've passed to Pat Mochel the information concerning the annoying device
> > model restriction which historically kept on causing the deadlocks with
> > cardbus cards inserted at boot time. Pat seems willing to tweak the
> > driver model to allow PCI-like devices to be registered from a PCI
> > drivers ->probe function. Once this is done, we can get rid of some of
> > the fragile work-around code that we're currently carrying - but that's
> > a job for post-2.6.0.
> > I really suggest that we try to sort some of this stuff out and make
> > the core more robust before we start adding more driver model code to
> > PCMCIA.
> 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 talking there about fixing the problems that have been introduced
in last year or so since PCMCIA attracted peoples attention. Of course
the remainder of PCMCIA has issues, but for the most part they're not
causing 99% of the problems people are seeing.
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.
> 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.
> 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
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.
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
More information about the linux-pcmcia