On Fri, 2011-02-18 at 14:39 +0200, George Kashperko wrote: > Does this mean RFC subject in its current state is rejected ? I am not in charge to reject anything. But I just noticed that you sent the patches to the list. So I'll have a look at it. You should improve your CC lists in general for all your mails. Most of us don't have the time to read all mail on the list, so it's always a good idea to maintain a CC list of people who already commented on the RFC for patch submissions. > > So I'm supporting Henry in that SSB is legacy and EOL. Let's simply > > start over and don't carry old cruft over. > > > > Note that this does not mean that we need to duplicate the MIPS, > > common and probably pci core drivers. A hybrid module can be done, > > if that's desired to avoid code duplication. > Well, any plans or even maybe ETA on this ? No. > > And I also think that you're worrying _way_ too much about a few > > if/else statements in the drivers. (Look at the TMSLOW discussion). > > The SSB/AI->driver interface is trivial and tiny. There will be maybe > > 10 if/else statements. It's really _not_ worth introducing major > > abstraction code in the SSB and AI code to avoid a few if/else > > statements in the drivers. > > The bulk of the SSB->driver interface _is_ already abstracted inside > > of the drivers (b43_read/write...). The rest is negligible. > Well, not like I really worry alot about those if/elses :) > Just in this particular case of SSB in its current design I don't really > see much differences in where bus implementation-specific management > must be abstracted if only AI support over SSB is implemented. If there > will be just b43 relying on such an abstraction then no doubt lets do it > in b43 driver. But its not. You should also look into the future. I don't know what broadcom's plans are, but a rough guess would be that AI will diverge more and more from SSB, so that more and more hacks will be needed. So I'm in favor of making a clean cut. -- Greetings Michael. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
