s/forgot/forget/
On 6/22/21, Alan Carvalho de Assis <acas...@gmail.com> wrote: > 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 >
