Following the discussion related to the "inline" keyword usage in common code. I have done draft changes in https://github.com/apache/incubator-nuttx/pull/5201 with an approach that possibly can be used to get rid of "inline" in common code. But I'm not even sure if this is needed to anyone, since there are no reports about compilation issues for any of the supported platforms. This means that the platforms are either not used (projects not updated to the latest NuttX release) or all used compilers support "inline" (and maybe C99). I would appreciate it if people can give feedback should I continue changing 7000 other places, or just drop this activity.
Best regards, Petro пн, 10 січ. 2022 р. о 17:17 Nathan Hartman <hartman.nat...@gmail.com> пише: > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > > Speaking of the Z80, would it be possible to run NuttX in a Grant > Searle > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt > > > require banked memory? > > > > > > > I don't know if it is possible or not. I don't know if NuttX is viable > on > > any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs > > were programmed in highly tuned assembly language. it is hard to imagine > > running an OS that is almost as big as the addressable memory and being > > able to do anything meaningful. NuttX may have outgrown these platforms. > > > > I think that z80 architecture support is still important because there > are > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next ( > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80 > > with a extended address space using an MMU similar to the z180 but with > > smaller pages. Other derivatives like the z300 and the ez80 just > support a > > wider address space. I have done a couple of ezo ports recently (like > > http://z20x.computer/). > > > > I appreciate this discussion about protecting the NuttX supported > platforms. > > I think non-arch-specific code should stick with C89 and we should not > be too eager to remove architectures that have these needs. > > It's not too hard to tell people that non-arch-specific code needs to be > C89. > > We can catch it more easily in precheck by passing the C89 flag to the > compiler. > > Only in the case where an architecture is incomplete, unmaintained, > and NuttX isn't really viable for it anymore, should we consider > removing it. > > We should have a rule that removing an arch should require a process > that makes it highly likely that we'd hear from any users who consider > that arch important. > > For example, get the word out for some period of time and solicit > feedback. If no feedback, then mark the arch deprecated, produce > build-time warnings, require users to activate some kind of > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get > their attention. And then, have a mandatory waiting period to allow > enough time to either attract maintainers or be able to declare the > arch dead with a clear conscience. > > > > So many RTOS are just for arm. > > The whole point why I adopted NuttX is because of being able to move > my applications from one arch to another. > > > Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing > > enthusiast. But nowadays, it is dominated by businesses with business > value > > systems that are sometimes not compatible with the needs or interests of > > hobbyists. That is why there is such a long discussion in the > > INVIOLABLE.md under "All Users Matter." That was essentially the > contract > > I made when I agreed to give the OS to the community. But it is going to > > take some strong leadership to keep those values since the OS is > controlled > > completely by businesses now and businesses tend to think only of their > own > > needs. > > We need more hobbyist/DIYer committers and PMC. > > We need a short and professional presentation, targeted specifically > to business users, that clearly explains why it is in their best > interests to play nice with the community. > > Cheers, > Nathan >
