68k?
Hello, Does anyone know whether NuttX was ever ported to the 68k or ColdFire? I thought I remember seeing an early port some time ago, but I may be mistaken. Regards, -david
Re: The new Apache NuttX Logo
Before it's too late, I'd like to pose the question: Is there no-one who prefers NuttX be spelled with lower-case "utt"? Respectfully, -david On Wed, May 27, 2020 at 3:01 PM Nathan Hartman wrote: > On Wed, May 27, 2020 at 5:15 PM Gregory Nutt wrote: > > > > > > Well, it could be a gift certificate of some kind. Seems like it must > > > be embedded RTOS themed in some way, however. > > > > > > Or maybe a trophy? > > > > Better... a T-shirt or hoody with the selected logo on it. > > > That's a neat idea! > > Nathan >
Re: The new Apache NuttX Logo
I feel strongly about this. "NuttX" preserves the origin of NuttX and the name of Mr. Gregory Nutt. I think we need a logo that respects both. On Sat, Apr 18, 2020 at 12:47 AM Alan Carvalho de Assis wrote: > Good point David! > > I got all logos from PDF and put it publicly visible: > > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > > None of those logo respect the original N and X and lowercase utt of NuttX. > > I think Mr. Greg never enforced it too much, although he almost always > wrote NuttX. > > I recall Mr. Wolfgang Denx in the U-Boot mailing list always to scold > on people who misspelling it as uboot, u-boot, uBoot, etc. > > So I always called "NuttX as NuttX" and as you can see even in the URL > of NuttX Channel it is present: > > https://www.youtube.com/c/NuttXChannel > > BR, > > Alan > > On 4/14/20, David Alessio wrote: > > I don’t wish to offend anyone but I object to all options on the basis > that > > “NuttX” should be spelled with capital ‘N’ and ‘X’, lowercase “utt”. > > > > Regards, > > -david > > > > Sent from my iPhone > > > >> On Apr 13, 2020, at 7:42 PM, Xiang Xiao > >> wrote: > >> > >> The new logo could be viewed online here: > >> https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > >> Please give your feedback and suggestoion. > >> > >> Thanks > >> > >> Xiang > >> > >>> On Tue, Apr 14, 2020 at 5:54 AM Justin Mclean < > jus...@classsoftware.com> > >>> wrote: > >>> > >>> Hi, > >>> > >>> It would be easy to put the image on your wiki / confluence. > >>> > >>> Justin > > >
Re: The new Apache NuttX Logo
I don’t wish to offend anyone but I object to all options on the basis that “NuttX” should be spelled with capital ‘N’ and ‘X’, lowercase “utt”. Regards, -david Sent from my iPhone > On Apr 13, 2020, at 7:42 PM, Xiang Xiao wrote: > > The new logo could be viewed online here: > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > Please give your feedback and suggestoion. > > Thanks > > Xiang > >> On Tue, Apr 14, 2020 at 5:54 AM Justin Mclean >> wrote: >> >> Hi, >> >> It would be easy to put the image on your wiki / confluence. >> >> Justin
NuttX Networking capable of dual home?
Hello, Has anyone successfully set up a dual home (two IP addresses and subnets) on an Ethernet interface? Regards, -david
Re: [VOTE] Remove Windows Native support?
+1 Native windows support doesn't solve any problem that isn't already covered by other, more standard/POSIX solutions; and will always be a maintanance headache. On Tue, Jan 21, 2020 at 4:44 AM Alin Jerpelea wrote: > -1 > > On Mon, Jan 20, 2020 at 3:20 PM Gregory Nutt wrote: > > > The [DISCUSS] phase has complete and comments have been received. It is > > time to vote for or against removing Windows native support from the > > NuttX RTOS. > > > > Anyone in the community may vote on this question to express their > > opinion. However, only votes form PPC members will used to determine > > the outcome. A minimum of 3 PPMC +1 votes and more +1 PPMC votes than > > -1 PPMC are required to pass this vote. > > > > You may vote one of the following: > > > > [ ] +1 Remove all support for the Windows native build from the RTOS > > [ ] 0 No strong opinion > > [ ] -1 Retain support for the Windows native build in the RTOS > > > > Voting will close in 72 hours. > > > > >
Re: [nuttx][PATCH] Added Support for RTC & IPV6 on RX65N
Anjana, Please remove the Disclaimer from your email, it's incorrect -- you're sending files containing source code to an open-source project and claiming confidentiality and intended use by an individual... Regards, -david On Mon, Jan 13, 2020 at 10:02 PM Anjana wrote: > Hi All, > > We have uploaded patch for arch/renesas & boards/. > > The patch is created for the code version dated 08th Jan 2020 (Downloaded > on 08th Jan 2020). > > This patch adds support for the following : > > >1. Added Support for RTC driver in RX65N >2. Added support for IPV6. > > > Regards, > > Anjana > -- > *Disclaimer: This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to whom they > are addressed. If you are not the intended recipient of this message , or > if this message has been addressed to you in error, please immediately > alert the sender by reply email and then delete this message and any > attachments. If you are not the intended recipient, you are hereby notified > that any use, dissemination, copying, or storage of this message or its > attachments is strictly prohibited. Email transmission cannot be guaranteed > to be secure or error-free, as information could be intercepted, corrupted, > lost, destroyed, arrive late or incomplete, or contain viruses. The sender, > therefore, does not accept liability for any errors, omissions or > contaminations in the contents of this message which might have occurred as > a result of email transmission. If verification is required, please request > for a hard-copy version. * > -- >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
On Mon, Jan 13, 2020 at 4:24 PM Gregory Nutt wrote: > > >> To Greg's point: how is it that master is broken? How did we allow any > >> merge that hadn't yet been checked (at least to compile, if not > function)? > >> It seems to me that somewhere in our workflow discussion(s) we've > >> put Descartes before the horse. > > We need help getting that workflow document finished. Would you be able > to > > help with that? > > In particular the automated workflow. I think the basic submit and > merge PRs is covered in detail. > > Haitao Liu is the person in charge of developing the automated workflow, > but we will start off simple. He is currently setting up some Jenkins > CI. I know that he also plans to trigger a coding standard and license > check when the PR is submitted. But I don't know any more than that. > There has been discussion of more targeted builds to assure that new > changes don't break the build and discussion of hooks future > hardware/simulator in loop testing. That is all a little vage. Without > a specification for testing to be performed in the automated workflow, > I'm not sure how we give guidance. > > Greg > > I don't know HaiTao, but from the discussions here that I've read, I'm very supportive of his approach. The point I'd like to make, is that I'd much rather the whole world stop turning, nothing get merged into master until we sort out the process; rather than allow anything to break master. I'd like for us to adopt a philosophy that "Nothing is worse than breaking Master." Now, that's just me, I welcome counterarguments (and even flames). -david
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Forgive me, I'm just returning from a much-needed holiday break with family and still trying to sort through 1400+ email msgs... To Greg's point: how is it that master is broken? How did we allow any merge that hadn't yet been checked (at least to compile, if not function)? It seems to me that somewhere in our workflow discussion(s) we've put Descartes before the horse. Confused, -david On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt wrote: > > > I have ran the build tests and do not know of any other cases like > > this. ... > > That needs clarification. I have been starting the build tests everyday > for the past weeks, but there has been no successful, complete run of > the ARM builds in the past 3 weeks. The build has been broken every day > for the past three weeks and the breakage appears to be getting worse, > not better. > > This weekend was the due date for the 8.4 release of NuttX. That has > now gone by. I will not be doing any further releases. That is now the > responsibility of the PPMC. The next NuttX release will be the first > Apache release. > > When should we do this first Apache release? How do we do this? Who is > the release manager? (hint: not me) Since the breakage is coming on a > daily basis, how/when can we get a stable enough system to even consider > a release. > > I required two weeks of stable builds with no new bugs reported before a > release. We are not ready to do a release right now. I don't think I > have ever seen the OS so unstable as it is right now. It does not build > correctly. There are more and more reports of old stable functionality > that is now broken. I have no idea how to get there... at least not > without some proper workflow definition and some qualification tools in > place. > > Folks, we are destroying this OS. > > Greg > > >
Re: Atomic git tagging (was RE: Project Emails)
> Is there reason for me to be concerned? Unfortunately, yes. As much as I like Confluence, if not properly organized and managed, it can quickly grow into an unnavigable mess. I suppose it's like anything else we do, it requires a process and disciplined maintainer... On Fri, Dec 13, 2019 at 2:42 PM Gregory Nutt wrote: > > > Absolutely, Confluence would be great -- it'd be good place to create > live > > documents and tutorials that could evolve along with the code base... > > The original plan was to integrate the existing DocuWiki at nuttx.org to > Confluence. If we begin using Confluence in an ad hoc way then I have > some concern that it will interfere with the clean port of the existing > Wiki. My hope is that we could have a clean Confluence website. Is > there reason for me to be concerned? > > > >
Re: Atomic git tagging (was RE: Project Emails)
Absolutely, Confluence would be great -- it'd be good place to create live documents and tutorials that could evolve along with the code base... On Fri, Dec 13, 2019 at 2:02 PM Justin Mclean wrote: > Hi, > > > So where in Apache is an appropriate place to put shared documents, the > Apache public equivalent of my shared drive? I have been trying to scare > people into action on this workflow here for days now, but I guess this a > brave group or just completely blind to what is coming. > > Best place is confluence. We would need to set up a space for NuttX but > that’s easily done. Do you want me to go ahead and do that? > > Thanks, > Justin
Re: Atomic git tagging (was RE: Project Emails)
WRT to this build issue, it used to work without a git repo. Disclaimer:
I responsible for the original commit, a portion of which Greg reverted
today...
This is a good opportunity to discuss a larger topic -- this is just one
instance of a class of problems that can be minimized [or even avoided]
with the proper process.
I believe that process should be based on the best practices of Bitbucket,
Github, and git. I may be stating the obvious here, but I'd like to
suggest the following few simple rules:
1. Master should always build and, to the extent possible, "just work
right."
2. all development happens on a specific development branch for one
particular feature or bug. Features are developed on a branch named
"feature/". Bug fixes are developed on a branch named
"bugfix/". Branches and commits must be coherent with
minimal coupling.
Note: This is important so that commits can be cherry-picked into
other branches and back-ported as hotfixes to previous releases.
3. A pull request triggers a review (review committees TBD according to
domain). A successful review might be N approvals and no rejections. In
any case, the testing, debate, and correction happens on that branch before
merge.
4. releases could be managed similarly, as a branch off of Master, i.e.
"release/9.1" (we're at 8.2.* IIRC). If a bug is then discovered in 9.1,
a branch "hotfix/some-silly-bug" would be taken off "release/9.1"
Comments? [donning flame retardant suit]
Cheers,
-david
On Fri, Dec 13, 2019 at 1:23 PM Nathan Hartman
wrote:
> To add to the patch-to-merge workflow discussion, an anecdote.
>
> Earlier today I jokingly wrote "For the build system we should
> require more PMC votes than we have PMC members!!"
>
> Soon after, I grabbed the latest updates and tried to build my
> configurations and... the build was broken!
>
> I wrote:
>
> [[[
>
> Uh oh, commit 1c91aec6ae77b49608741e5aa30b8b6876017934 ("tools/ and
> fs/procfs: Simplify .version file generation") breaks the build if
> not in a git clone:
>
> $ make
> Create .version
> fatal: not a git repository (or any parent up to mount point /home/nate)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> Missing versioning information
> USAGE: tools/version.sh [-d|-h] [-b ] [-v ]
>
> Try 'tools/version.sh -h' for more information
> make: *** [tools/Makefile.unix:266: /home/nate/nuttx/.version] Error 1
>
> If git is not available or building a copy of NuttX which is not a git
> clone, the create version logic should degrade gracefully in a way
> that does not break the build!
>
> ]]]
>
> Thankfully, Greg fixed this at warp speed with commits
> 3e4450e2376bb99da2ed5a3f0380044ce868e564 and
> 10b8c01abfa58276f006c282e1d88481fb0a4a8e.
>
> The point is, though, that this is precisely why we need to qualify
> what gets into the system. I feel pretty strongly that we can be
> flexible with things like drivers, hacking on architectural support
> for new chips and boards, etc. The impact of bugs or incomplete code
> there will be minimal and those are easy to catch and fix. I would
> like to make it easy for contributors to get their code out there and
> to feel like there's incentive to contribute, and not to put too many
> roadblocks in the way that would become a deterrent for contributors.
>
> BUT!!
>
> The core of the OS and the build system need the highest level of
> qualification. Screwups there are really disruptive!
>
> Problems in the build system might quickly become apparent.
>
> Problems in the core OS could go undetected until intermittent
> problems that are extremely hard to trace appear in the field. Since
> NuttX goes to places like space, "in the field" might be kind of,
> slightly, REALLY far away!
>
> So we definitely need to continue discussing what process changes to
> these critical parts should undergo on their way into NuttX.
>
> Cheers,
> Nathan
>
