Xilinx git tree at source.mvista.com

[John Williams]

Hi Wolfgang,

Wolfgang Reissnegger wrote:
> David H. Lynch Jr. wrote:
> 
>>For me the most significant issue is the bazillion layers of nested
>>macro's and includes.
> 
> 
> I don't see the macros as an issue, just look at the implementation of,
> for example, spin_lock_irq() and Xilinx's macros seem like child's play :-)
> As for includes, yes, there are a few too many header files. But, as
> time progresses and the need arises they can be merged into fewer files.

It seems the kernel.org decision has been made re: the style issue. 
None of the *_i.[ch], *_g.[ch] + adapter.c drivers will make it to 
mainline.

I understand why Xilinx did it this way, but to be honest never agreed 
with it myself either.  Style issues aside, three levels of function 
calls in an interrupt handler might be portable, but it still isn't a 
good thing!

The effort to refactor these drivers is not huge, but it is an effort. 
If Xilinx is committed to good quality Linux support for their silicon, 
it will require tangible investment in the form of labour or resources. 
I know you understand this, but Xilinx as an company still needs a good 
hard shove in this direction.

Alternatively, drivers will trickle into kernel.org as the community 
gets around to it, witness the uartlite and system ace drivers.

Same old story, if you want it "some day", then it will be free, if you 
want it now, you've got to pay!

Cheers,

John