Re: [RFC] AI support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, 

> There are plenty of examples in the kernel where code was simply forked
> for the development of a new technology. Look at b43/b43legacy or
> ext2/3/4 just for a few examples. The forks were made on purpose
> to avoid maintainability nightmares. Yes, at first sight, some code had
> to be duplicated. But I don't see that as an issue. The two codebases
> will diverge quickly from each other as development is done.
Does this mean RFC subject in its current state is rejected ?

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

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

> And if it turns out _afterwards_ that we could avoid a few if/else
> statements by introducing some additional abstraction layer, this
> thing can be introduced _afterwards_.
Almost exactly what I thought working on AI over SSB. 

> PS: Could you please stop stripping the CC list.
> 
Sorry for that.

Have nice day,
George


_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux