> > > > 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 :-) >
It's actually worse than that. You can use C99 comments at the end of a line but not at the beginning frobnicate(); // this is accepted // this is an error This is perfectly legal C99. That's 20+ years ago and was widely accepted before then. I'd venture that the number of significant (not a college kid's project) RISC-V compilers that don't accept C99 is zero. I see // comments in 48 *.[ch] files. That ship has sailed. >> 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. > Parlance breakdown, but, yes. I've iterated on that same PR. I found that the build is assuming that a specific -Wbarf flag is implied by -Wall, when in the official RISC-V GCC builds, it's not, so I never saw the warning/error. In my own project, I've found -Wall almost useless because it varies from version to version. Better to turn on the -W flags you actually care about so they're version controlled. So I've kicked that back in, but it appears I have to wait for a (gasp) human to push a button. I assume this is to stop script kiddies from submitting bitcoin harvesters in the presubmit, but it really hoses a workflow as it's like submitting a box of punched cards across the table into the Holy Room where computing is done and then awaiting a stack of greenbar with the results later in the day. Hopefully, you're convinced I'm an actual human at this point (even if I complain too much :-) so can someone please clear my bozo bit so I wrap these up and carry on? I don't want to be another patch sitting in a year-long review queue. > 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. > This should set off alarms. If you can't teach the leading code parser/formatters the convention, it should be a hint that the convention is weird. (Sorry.) I sure can't find an easy way to set editor preferences in Sublime, vi, or the like so I'm back to counting spaces by hand. I won't keep grinding my bootheel on this, but I'll say it out loud: it's really off putting for contributors. Probably like most pros, I can look past Google style vs. LLVM vs Chrome or whatever because I've seen (and written) mountains of code in it, but the mental burden is pushed to the tools. Here, you're just adding a barrier to entry. In my own project, I had a pet style that I tried to enforce. I found it solve a lot of problems to just reformat the whole thing one day, declare clang-format style=google to be the one way, and never worry about whether a curly is a trailer or a header again. Leave it to the tools and let developers focus on developing instead of counting spaces and stars in a formatted box. >> 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, > It looks like adding a new board (that's trivially different from other boards) is 55+ files added or created. There are also files marked "don't edit" that you have to edit. Again, it's a barrier to entry. On the plus side, while I'm not a fan of the kconfig system, the actual build is nice and speedy once the dependencies are generated. They parallelize nicely and the build mostly stays out of the way. That's pretty sweet. Setting an fswatch on the generated image and restarting the emulator to reboot makes it all really seamless. >> https://github.com/apache/incubator-nuttx/pull/2822 > I think you don't need to care about it now, just submit your work and > OK, I'll just keep adding to the pileup. Ok, but an issue by time. First is your PR #3965 :-) > Yep. Once that's landed, I'll accept nominations/guidance on where to go next. This board is beefier than most of the targets in Nuttx. It has a network interface and USB host and the ability to do virtual memory and so on. I can't find other ports enabling RV39 so that may just be out of scope for Nuttx. I know IRQs need work and it needs a real GPIO system. (I have boards <https://github.com/BBBSnowball/beaglev-chewtoy> arriving next week that'll help with that once I get them soldered up.) I have it passing the parallel prime number test. Enabling SMP would probably be reasonable. (It'd be easier with Device Tree, but that doesn't seem within easy reach right now.) Do you have a handy way to bootstrap filesystem and storage? I don't really want to be flashing SD cards and rebooting after every build. What's the easiest way to bring that up in Nuttx? I think the network controller is a Cadence (Synopsis?) NIC core that's pasted in. I haven't looked to see if you already have drivers for that. Linux did, of course, since this board's U74 is a direct descendant of the U540 used in HiFive Unleashed. Is there a really strong model citizen of similar vintage that you can point to and say "Do a configure board:whatever and see what gets built. Here's how it's tested. Reach that level of zen and you're good." This board is more comparable to, say, a Pi 3 than a STM32F100 or ATMega. It won't really have video until the JH7110 versions hit in a few months. We're advised to handle that as a separate chip, so I've tried to allow for that. We'll have two different "Beagle V Starlight" boards that have two different CPUs, different peripheral sets, different memory maps, etc. > > 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 > After separating stm32l4, f7, etc, brings are easy to fix, but it > generates the duplication issue, sometimes a fix needs to be applied > It's probably messy enough that no one person can test all the affected hardware on a change. I'll see if I can reign in at least some of the instances of 16550's on a RISC-V hardware I do have. Maybe I'll also just let that go since it's not bothering anyone else and everyone knows how to write a driver for an 8250 mutant and it's easy enough to borrow a missing hunk or fix from another driver if you need it. > This doesn't seem to trouble anyone else, so maybe I should let that go, > For sure! Unless you want to suffer a lot of pain to fix everything ;-) > Yeppers. I can see I need to stay in my own little sandbox here and not have a nervous breakdown about things that aren't bothering the installed base and developers. > 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! :-) > So noted. I'd rather do five fly-by OS ports than get mired in elephant hunting. > s/forgot/forget/ In general, I don't grade on spelling in prose. It's fine. You'll hopefully be forgiving when I do the same. :-) Thanx, RJL
