Hi Robert, On 6/22/21, Robert Lipe <robertl...@gmail.com> wrote: > On Mon, Jun 14, 2021 at 1:02 PM Alan Carvalho de Assis <acas...@gmail.com> > wrote: > >> Normally only common code on NuttX needs to follow the C89 standard >> > > The presubmit flips out about C99 comments. Even that's too radical. So > much for being king. :-) >
You can use C99, but you cannot forgot to follow the Coding Style, // comments shouldn't be used :-) > >> Also should use tools/checkpatch.sh to check your patch/files before >> submitting the PR. >> > > Yes, I should have. Presubmit kicked it back. > You don't need to submit a new PR, you can fix the current one and push force it. > I'm guessing with a name like "inviolables", I'm going to change nothing by > saying it, but > this whitespace convention is totally alien to me. There is just So Much > Whitespace. Yes, but it makes the code more pleasant to read and easier to stop issues. > Is there a clang format or something that implements this? > Not yet, some people already tried it, but the NuttX Coding Style is not easy to fulfill, its needs someone with deep knowledge about formatting tool to get it done correctly. Until now everybody who tried failed miserably. >> There's a LOT of duplication within arch/risc-v and where there is > > See my recent PR for an example of just how much redundant, copy-paste, > machine-edit is really necessary for a new port. > Well, if you spot codes that should be removed you can move it do /common, but you need to adapt other boards using it. > >> And even a draft PR: >> https://github.com/apache/incubator-nuttx/pull/2822 > > That's a PR that seems to have collapsed under its own weight. What needs > to happen to get that going? Should I separate the "delete files" from > "edit files" and resubmit that as two different, hopefully more reviewable > PRs? > I think you don't need to care about it now, just submit your work and someone taking care of PR #2822 will need to take care of you board files later. > That doesn't even really scratch the surface of the problem, though. Look > at how many copies of everything exists within the various risc-v > directories. You can't even really tell what's the same because all the > #defines have the target name in them, though. > Ok, but an issue by time. First is your PR #3965 :-) > If we climb ot of the the risc-v trees, it looks like we have dozens of > different 16550 implementations, each that was created as a copy + machine > edit. > Well, if they are common code defined in the specification, then it should be moved to common code. If it is similar peripheral drivers, sometime duplication could be a good thing, it will avoid hundreds of #ifdef. See the arch/stm32 people tried to put all together, but ST already make some small modifications in a family of other that breaks other devices. After separating stm32l4, f7, etc, brings are easy to fix, but it generates the duplication issue, sometimes a fix needs to be applied to all arch/stm32yxx. > This doesn't seem to trouble anyone else, so maybe I should let that go, > too. > For sure! Unless you want to suffer a lot of pain to fix everything ;-) > Re: device tree, there's a PR that's been pending for a year almost to the > day. That also seems to have coasted to a halt without a clear rejection or > path to acceptance. Working Device Tree would have made most of the BeagleV > - and the upcoming D1 - ports almost trivial. > > I'm probably rocking too many boats at once. Maybe I should tuck my head > down and go with this project's One True Ways. > Exactly, the bast way to each an elephant is a bit by time! :-) BR, Alan
