On Fri, Aug 15, 2008 at 11:16 PM, Woodruff, Richard <[EMAIL PROTECTED]> wrote: > Hi Felipe, > >> [EMAIL PROTECTED] On Behalf Of Felipe Contreras > > <snip> > >> >> As part of contributing this code there has been a lot of reworking >> of the code. Last I had heard checkpatch and sparse warnings had been >> killed. There was also a lot of work in making sure there would be no >> legal impact to the kernel to clear its ability to be contributed. >> > >> > Not true: 13 errors, 246 warnings. > > Today another set of warning changes is in queue. Will have to check what the > current number has become. It will be low. The start number a while back was > defiantly very high. > > Checkpatch.pl is just a guide. Completely changing code for the tool isn't > probably a good idea. It might even get you severally flamed on LKML :) The > recent threads are informative (ok to read, bad to be in). > > Incidentally, when I asked the person working these changes, they had > reported 0 functional errors had been fixed by the checkpatch changes. A lot > of the noise was typedef reduction.
I'm not familiar with checkpatch, but I guess the purpose is not to highlight functional issues. However, there are functional issues, but it makes sense to cleanup the code first: there's no point in analyzing code that is never used. > <snip> > >> Err, I got confused about the CE/Link, I meant the xdctools... or >> whatever is needed to compile DSP nodes. AFAIK the DSP compiler is not >> enough. > > You are correct that the internal DSP architecture is not opened up only the > ARM side and the peripherals. DSP internals is another topic. You should be > able to compile the ARM side. Indeed, if I put myself the open source cap I can create ARM side applications, but then I need something running on the DSP in order to test them. If I put my corporate cap I can do that, and see that effectively, my ARM application works. But how are maintainers supposed to test this? At the very least I would expect a base image binary, and a dummy dsp node that simply copies the buffers received so that anyone can get their hands dirty with the dsp bridge. Otherwise it's just some code that nobody can test (hard to merge that way). > A few years back I had heard about some people even successfully running > Linux on the C6x DSP. I think it ran well, but kind of neat all the same. > DSPBIOS or other tiny OSes work much better there. Interesting, another platform to conquer for Linux ;) Best regards. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
