On Mon, 2011-03-21 at 17:24 +0100, Michael BÃsch wrote: > 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. > I just realized that Arend was in the To: field. The text was mainly addressed to Rafal and George. Probably Greg as well. -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
