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. -- 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
