Re: new utility kernel module for detecting cores in newer chipsets

["Michael Büsch" <mb@bu3sch.de>]

On Mon, 2011-03-21 at 16:05 +0100, Arend van Spriel wrote: 
> To summarize this, my main issue (and Michael's, I think) is with the  
> dependency being imposed between ai and ssb.

That's part of my main issue, right.

> Having two completely independent modules really makes more sense.

I do think that any attempt to merge legacy-ssb with ai subsystems
or even share significant amounts of code between these subsystems
will result in a maintenance nightmare.

There are times where a fork or a rewrite is the best thing to do.
And I think that is the case here.

SSB hardware is dead. Let the software die, too.
You just need to realize that having ai code completely separate from
ssb code makes life easier for you guys.
Win: You don't need to take care about backwards compatibility.
Win: You don't break our legacy devices.

Just look at the patches you guys already sent. Look at that TMSLOW
abstraction layer, for instance. That's just a pain in the arms.
Look at that:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/66590
You're carrying old legacy cruft into the shiny new subsystem
(PCMCIA support, for instance) just to avoid duplicating a trivial
100 line function.

Please keep in mind that any attempt to merge SSB with AI code means
that _you_ guys will have to maintain backwards compatibility
with devices designed 10 years ago.

I really don't understand why you are so resistant against a fork
or a rewrite, because it makes _your_ life easier (and mine, too).

PS: I do _not_ know whether the brcmaix code is reasonable or even
useful
as base to build up the new broadcom SOC bus subsystem, so I'm not
going to pass and judgement on that code.

-- 
Greetings Michael.