[nuttx] Serial driver hangs with assertion when nxsem_wait return -ECANCELED

[[e-mail] [nuttx]]

Hi,


I found strange behaviour for nxsem_wait, which can sometimes return -ECANCELLED, which is not documented to be returned. I have seen this several times when terminating the `cu` app using "~." keystroke.


I have updated my code to expect both EINTR and ECANCELLED, but deep in NuttX there is a lot of code like this (for example, in serial.c):

ret = nxsem_wait(sem);
DEBUGASSERT(ret == -EINTR);



So, where is the error: in nxsem itself or in code expecting it to return only -EINTR errors?

[[e-mail] [nuttx]]

The error is in this:

DEBUGASSERT(ret == -EINTR);

that should be:

DEBUGASSERT(ret == -EINTR || ret == -ECANCELED);

Cancellation point logic was added relatively recently. Before that, the only way that nxsem_wait() (or sem_wait()) could fail is be receiving an interrupt (EINTR). After that change they can also receive ECANCELED but not all of the locations that expected only EINTR have been updated to also expect -ECANCELED.

If you submit a patch to change the DEBUGASSERT commands that are causing you problems, I will be happy to apply the patch.

Greg

[[e-mail] [nuttx]]

Added a pull request on bitbucket.
I changed most places that I found with such pattern.

There are several places, where the change is not correct or enough, so I left them alone:


nuttx/drivers/net/slip.c:243 - function slip_write
nuttx/drivers/net/slip.c:528 - function slip_getc
There are far more errors other than EINTR that read() can return

nuttx/libc/wqueue/work_lock.c:87 - function work_lock
Not sure which errors can be returned from pthread_mutex_lock

[[e-mail] [nuttx]]

Yes, that change applies only nxsem_wait() and sem_wait(). Other interfaces l(ike read()) will never return -ECANCELED.


I merged all of the changes without really reviewing them because there were so many. I hope that you changed only tests for the return value of [nx]sem_wait()?


Greg

[Lorenz Meier [e-mail] [nuttx]]

Greg,

As you will be aware we’re using NuttX on drones. Our users are quite sensitive about stability and safety and I wanted to use the opportunity of your comment to check in on your vision regarding code reviews, QA and testing. We’ve re-qualified NuttX carefully after our updates so far but as we start to support more targets with NuttX that re-qualification gets intense and it makes sense to check in with the NuttX community what baseline could be available for NuttX in the future.

What we’re doing these days is:

- Every line contributed is reviewed
- All supported targets are built
- Code style is automatically checked
- Unit tests are run
- Flight simulations are run (different flight modes, different missions)
- For critical changes: Our 5-headcount flight test team goes out and flies the change. It logged 12’000 flights last year.

This is the baseline we’re operating against for all code we maintain. Every project is free to choose its level of testing (or can opt to not do reviews or testing and tell people to be aware of that).

What is the vision for NuttX on this going forward?

Thanks!

-Lorenz

[[e-mail] [nuttx]]

I do not plan any additional QA or testing measures. I don't personally have bandwidth to take on any additional responsibilities.


I have considered some sponsorship from industry and from other open source projects, but I did not go forward with any of those. No one has offered to sponsor NuttX without also coupling the support to the imposition of their will and direction over the project. That is not sponsorship; that is a hostile take over.


I still keep my eyes open, but I know of no way to improve the internal processes at the moment and also maintain the spirit of the project (and no, I am not interested in PX4 imposing their will any more than any other party).


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

Let's wait for Greg's opinion, because I may be completely wrong, but
let me quote a block of text that is present in multiple copies within
NuttX:

 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

etc etc

So, good thing you have a QA process in PX4, but that does not
necessarily need to be transposed upstream...

Sebastien

Post by Lorenz Meier ***@px4.io [nuttx]
 
Greg,
As you will be aware we’re using NuttX on drones. Our users are quite
sensitive about stability and safety and I wanted to use the
opportunity of your comment to check in on your vision regarding code
reviews, QA and testing. We’ve re-qualified NuttX carefully after our
updates so far but as we start to support more targets with NuttX that
re-qualification gets intense and it makes sense to check in with the
NuttX community what baseline could be available for NuttX in the future.
- Every line contributed is reviewed
- All supported targets are built
- Code style is automatically checked
- Unit tests are run
- Flight simulations are run (different flight modes, different missions)
- For critical changes: Our 5-headcount flight test team goes out and
flies the change. It logged 12’000 flights last year.
This is the baseline we’re operating against for all code we maintain.
Every project is free to choose its level of testing (or can opt to
not do reviews or testing and tell people to be aware of that).
What is the vision for NuttX on this going forward?
Thanks!
-Lorenz

[[e-mail] [nuttx]]

There is a need for more thorough regression testing, maintenance of documentation, more configuration management, general QA work. But there is no one available that can do that work. I already have more than I can do and most other people would like to have money for their work.


The end result of that effort would only be to make NuttX as stable as possible just out of a general sense of engineering pride. I would never modify my processes only for the intent of offloading work done by downstream users of the OS. I won't be integrating with other people's QA processes. That is just not my job nor my concern.

[Thiago Costa de Paiva [e-mail] [nuttx]]

Hi, Greg.

How could one help with this? I'm considering to make myself available, depending of the time and the resources needed.

Thanks,

Thiago

Post by ***@yahoo.com [nuttx]
There is a need for more thorough regression testing, maintenance of documentation, more configuration management, general QA work. But there is no one available that can do that work. I already have more than I can do and most other people would like to have money for their work.
The end result of that effort would only be to make NuttX as stable as possible just out of a general sense of engineering pride. I would never modify my processes only for the intent of offloading work done by downstream users of the OS. I won't be integrating with other people's QA processes. That is just not my job nor my concern.

[[e-mail] [nuttx]]

Thanks for the offer! But in my point of view, what is needed is nothing that could be provided with a part time effort. This is not just a matter of doing a couple of tasks, it requires a full dedication.


I think it needs a QA person that could do this:


- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden nuttx repository. All changes would be made in nuttx-dev and only merged into nuttx when they meet all QA requirements.
- Perform continuous build testing of all 400 or so board configurations. This current takes about a half a day to do on a high end PC under Linux. This time could be probably reduced with a build farm.
- Review and verify (to the extent reasonable) all PRs. Assure that all changes are 100% consistent with the coding style.
- Merge the verified code into nuttx. Assure that there is only a single commit per functional change and that the comments are pristine so that we can dispense with a separate ChangeLog.
- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to perform regression testing.
- And probably lots more.


That is a job description, not a task you can do part time. None of the above makes sense to do piecemeal if there is not a dedicated resource and a commitment to support the work over the long haul.


I think to do this we would need to:


- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

[Thiago Costa de Paiva [e-mail] [nuttx]]

Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel deal with this and I believe the answer is that the face the same problem. Old but maybe still relevant:

https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf

Question: do we need to have another repository for that? Would a devel (for developments) branch and a master (for stable code) branch not suffice?

Thiago

Post by ***@yahoo.com [nuttx]
Thanks for the offer! But in my point of view, what is needed is nothing that could be provided with a part time effort. This is not just a matter of doing a couple of tasks, it requires a full dedication.
- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden nuttx repository. All changes would be made in nuttx-dev and only merged into nuttx when they meet all QA requirements.
- Perform continuous build testing of all 400 or so board configurations. This current takes about a half a day to do on a high end PC under Linux. This time could be probably reduced with a build farm.
- Review and verify (to the extent reasonable) all PRs. Assure that all changes are 100% consistent with the coding style.
- Merge the verified code into nuttx. Assure that there is only a single commit per functional change and that the comments are pristine so that we can dispense with a separate ChangeLog.
- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to perform regression testing.
- And probably lots more.
That is a job description, not a task you can do part time. None of the above makes sense to do piecemeal if there is not a dedicated resource and a commitment to support the work over the long haul.
- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

[Sebastien Lorquet [e-mail] [nuttx]]

The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.

In NuttX Greg has to do all the validation.

The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid QA manager.

About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.

Sebastien

Post by Thiago Costa de Paiva ***@tecepe.eng.br [nuttx]
 
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem. Old
https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago

Thanks for the offer! But in my point of view, what is needed is nothing

that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication.

- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden

nuttx repository. All changes would be made in nuttx-dev and only merged into
nuttx when they meet all QA requirements.

- Perform continuous build testing of all 400 or so board configurations.

This current takes about a half a day to do on a high end PC under Linux. This
time could be probably reduced with a build farm.

- Review and verify (to the extent reasonable) all PRs. Assure that all

changes are 100% consistent with the coding style.

- Merge the verified code into nuttx. Assure that there is only a single

commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.

- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to

perform regression testing.

- And probably lots more.
That is a job description, not a task you can do part time. None of the

above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.

- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

--
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327

------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-***@yahoogroups.com
nuttx-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
nuttx-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Gregory Nutt [e-mail] [nuttx]]

My fear, and the thing that I will do everything in my power to avoid is
this:? Someone sets of some clever, arcane process based on
their-favorite-tools then disappears, leaving me holding the bag.? I
will have to refuse any strategy that could possibly lead to such a result.

No processes can be extended at all if there is no one committed to
doing the those new processes FOR ALL TIME.? The only way that I can
imagine anyone making such a commitment is if they were to be paid to do
that job.


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-***@yahoogroups.com
nuttx-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
nuttx-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Lorenz Meier [e-mail] [nuttx]]

Let’s take a step back.

What I’ve asked for is the vision, not the status quo. If you’re not striving towards extensive QA then it drives away the ones who do care about testing and who would be willing to offer their help. So without the clear vision towards it all the support you would be wanting will never materialize.

It’s also not helping the discussion to quote the BSD license disclaimer. A disclaimer is not a mission statement, its a legal protection mechanism. Everybody has that and yet most engineers strive for much higher goals in terms of quality.

What it would however require would be the commitment of both the maintainer as well as the development community to establish testing processes. That means running code through the CI system before merging it (which kind of forces the usage of pull requests, so it adds a constraint). It means that no code is merged that fails a test (so contributors will find that they need to fix their contributions regularly because the test system uncovers corner cases) and that at times you’re chasing issues with the test system instead of progressing on the core code.

If NuttX wanted to establish this, we would be able to help with engineering bandwidth and if there would be a foundation we would probably find companies which want to contribute funding to create quality.

But in my experience in creating an open source community you have to show the vision (and actions) first before companies do pitch in. We’re happy to contribute to building a proof-of-concept in terms of test setup if that helps.

Thanks!

-Lorenz

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.
In NuttX Greg has to do all the validation.
The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid QA manager.
About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.
Sebastien

Post by Thiago Costa de Paiva ***@tecepe.eng.br [nuttx]
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem. Old
https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago

Thanks for the offer! But in my point of view, what is needed is nothing

that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication.

- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden

nuttx repository. All changes would be made in nuttx-dev and only merged into
nuttx when they meet all QA requirements.

- Perform continuous build testing of all 400 or so board configurations.

This current takes about a half a day to do on a high end PC under Linux.. This
time could be probably reduced with a build farm.

- Review and verify (to the extent reasonable) all PRs. Assure that all

changes are 100% consistent with the coding style.

- Merge the verified code into nuttx. Assure that there is only a single

commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.

- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to

perform regression testing.

- And probably lots more.
That is a job description, not a task you can do part time. None of the

above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.

- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

--
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Embedded Systems [e-mail] [nuttx]]

I would be very happy to help with all i can.

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care
about testing and who would be willing to offer their help. So without the
clear vision towards it all the support you would be wanting will never
materialize.
It’s also not helping the discussion to quote the BSD license disclaimer.
A disclaimer is not a mission statement, its a legal protection mechanism..
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.
What it would however require would be the commitment of both the
maintainer as well as the development community to establish testing
processes. That means running code through the CI system before merging it
(which kind of forces the usage of pull requests, so it adds a constraint).
It means that no code is merged that fails a test (so contributors will
find that they need to fix their contributions regularly because the test
system uncovers corner cases) and that at times you’re chasing issues with
the test system instead of progressing on the core code.
If NuttX wanted to establish this, we would be able to help with
engineering bandwidth and if there would be a foundation we would probably
find companies which want to contribute funding to create quality.
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that
helps.
Thanks!
-Lorenz
The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.
In NuttX Greg has to do all the validation.
The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid QA manager.
About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.
Sebastien
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem..
Old
https://www.osadl.org/fileadmin/dam/presentations/
morton-hannover-2008-kernel-qa.pdf
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago
Thanks for the offer! But in my point of view, what is needed is nothing
that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication..
- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden
nuttx repository. All changes would be made in nuttx-dev and only merged into
nuttx when they meet all QA requirements.
- Perform continuous build testing of all 400 or so board configurations.
This current takes about a half a day to do on a high end PC under Linux. This
time could be probably reduced with a build farm.
- Review and verify (to the extent reasonable) all PRs. Assure that all
changes are 100% consistent with the coding style.
- Merge the verified code into nuttx. Assure that there is only a single
commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.
- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to
perform regression testing.
- And probably lots more.
That is a job description, not a task you can do part time. None of the
above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.
- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person
--
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Sebastien Lorquet [e-mail] [nuttx]]

yes but for how many days/weeks/years ? Not easy to answer, even if we all love
this project. What do we do if you quit after the process is started?


If we want to do anything we have to start with a helpful baby step in the right
direction, but with no awful consequence if we fail.


Some bot could be made to build/pull commits regularly, and send a notification
email if anything interesting happens. or tag the repository if not already
done. That could be installed at multiple locations in a redundant failsafe way.
Requirement: only commented bash scripts allowed, to keep it simple.

Sebastien

 
I would be very happy to help with all i can. 
 
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care
about testing and who would be willing to offer their help. So without the
clear vision towards it all the support you would be wanting will never
materialize.
It’s also not helping the discussion to quote the BSD license disclaimer.
A disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.
What it would however require would be the commitment of both the
maintainer as well as the development community to establish testing
processes. That means running code through the CI system before merging it
(which kind of forces the usage of pull requests, so it adds a
constraint). It means that no code is merged that fails a test (so
contributors will find that they need to fix their contributions regularly
because the test system uncovers corner cases) and that at times you’re
chasing issues with the test system instead of progressing on the core code.
If NuttX wanted to establish this, we would be able to help with
engineering bandwidth and if there would be a foundation we would probably
find companies which want to contribute funding to create quality.
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re happy
to contribute to building a proof-of-concept in terms of test setup if
that helps.
Thanks!
-Lorenz

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.
In NuttX Greg has to do all the validation.
The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid
QA manager.
About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.
Sebastien

Post by Thiago Costa de Paiva ***@tecepe.eng.br [nuttx]
 
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem. Old
https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf
<https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf>
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago

Thanks for the offer! But in my point of view, what is needed is nothing

that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication..

- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden

nuttx repository.. All changes would be made in nuttx-dev and only
merged into
nuttx when they meet all QA requirements.

- Perform continuous build testing of all 400 or so board configurations.

This current takes about a half a day to do on a high end PC under Linux. This
time could be probably reduced with a build farm.

- Review and verify (to the extent reasonable) all PRs. Assure that all

changes are 100% consistent with the coding style.

- Merge the verified code into nuttx. Assure that there is only a single

commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.

- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to

perform regression testing.

- And probably lots more.
That is a job description, not a task you can do part time. None of the

above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.

- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

-- 
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
   (Yahoo! ID required)

[Sebastien Lorquet [e-mail] [nuttx]]

My quote of the licence was not provocative.

This was a way to describe that QA is not always in the vision of the upstream
project and that's fine.

This non fitness clauses can be seen as a relief on the QA responsibilities of
the project main authors. Without it, we woud be FORCED to ensure QA, which
would prevent many open source projects to exist to begin with.


The problems are quite intricate:

Testing every commit is impossible as it would take a complete build farm and/or
multiple hours to test everything. Who maintains the build farm? Who contributes
money to build it? to fix it? to host it? Can it be distributed?

And that would just be a build test, not a runtime test. Who contributes money
to buy/maintains/hosts test boards and jtag adapters? Who maintains the testing
software?

An alternative is to push all contributed patches/PR without individual tests
and call that a "testing branch".

Then we can have build robots that validate some commits as often as possible
even if a test session lasts multiple days, and merge the validated commits to
the official QA tested master.

That would ensure that all tested commits are building for every config.

But it does not prove much without specific unit tests for every new integrated
feature.

That is becoming a bit heavy... not to mention that you need to test every
config on every hardware, and need to program every target automatically. not
obvious either.

Alan has started to look into build farms, let's wait for his opinion on this.

sebastien

Post by Lorenz Meier ***@px4.io [nuttx]
 
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not striving
towards extensive QA then it drives away the ones who do care about testing
and who would be willing to offer their help. So without the clear vision
towards it all the support you would be wanting will never materialize.
It’s also not helping the discussion to quote the BSD license disclaimer. A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that no
code is merged that fails a test (so contributors will find that they need to
fix their contributions regularly because the test system uncovers corner
cases) and that at times you’re chasing issues with the test system instead of
progressing on the core code.
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find companies
which want to contribute funding to create quality.
But in my experience in creating an open source community you have to show the
vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that helps.
Thanks!
-Lorenz

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.
In NuttX Greg has to do all the validation.
The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid QA manager.
About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.
Sebastien

Post by Thiago Costa de Paiva ***@tecepe.eng.br [nuttx]
 
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem. Old
https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago

Thanks for the offer! But in my point of view, what is needed is nothing

that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication..

- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden

nuttx repository. All changes would be made in nuttx-dev and only merged into
nuttx when they meet all QA requirements.

- Perform continuous build testing of all 400 or so board configurations.

This current takes about a half a day to do on a high end PC under Linux. This
time could be probably reduced with a build farm.

- Review and verify (to the extent reasonable) all PRs. Assure that all

changes are 100% consistent with the coding style.

- Merge the verified code into nuttx. Assure that there is only a single

commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.

- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to

perform regression testing.

- And probably lots more.
That is a job description, not a task you can do part time. None of the

above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.

- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

-- 
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Lorenz Meier [e-mail] [nuttx]]

Hi Sebastian,

I appreciate your concerns. We’ve done this successfully for PX4 with two part-time maintainers for the whole project, who only spent a fraction of their time on CI (one an engineer in industry and the other one a PhD student at a university). So it’s much smaller than anticipated.

Also CI systems like Travis CI, Circle CI or alike are free for open source projects, can be parallelized and are easy to configure and maintain. They can’t test on hardware, but they can ensure that stuff builds.

I’ve done this for NuttX a couple years ago - its a single commit and not hard to maintain:
https://github.com/PX4/NuttX/commit/3fe6b42b2192b992083514075f0ab90734b8437c <https://github.com/PX4/NuttX/commit/3fe6b42b2192b992083514075f0ab90734b8437c>

So no, its not taking a lot of effort nor does it cost a single $ for the servers. But it does require the commitment to stick to a test process (which can evolve over time - it doesn’t have to be the same forever).

Thanks!

-Lorenz

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
My quote of the licence was not provocative.
This was a way to describe that QA is not always in the vision of the upstream
project and that's fine.
This non fitness clauses can be seen as a relief on the QA responsibilities of
the project main authors. Without it, we woud be FORCED to ensure QA, which
would prevent many open source projects to exist to begin with.
Testing every commit is impossible as it would take a complete build farm and/or
multiple hours to test everything. Who maintains the build farm? Who contributes
money to build it? to fix it? to host it? Can it be distributed?
And that would just be a build test, not a runtime test. Who contributes money
to buy/maintains/hosts test boards and jtag adapters? Who maintains the testing
software?
An alternative is to push all contributed patches/PR without individual tests
and call that a "testing branch".
Then we can have build robots that validate some commits as often as possible
even if a test session lasts multiple days, and merge the validated commits to
the official QA tested master.
That would ensure that all tested commits are building for every config.
But it does not prove much without specific unit tests for every new integrated
feature.
That is becoming a bit heavy... not to mention that you need to test every
config on every hardware, and need to program every target automatically. not
obvious either.
Alan has started to look into build farms, let's wait for his opinion on this.
sebastien

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not striving
towards extensive QA then it drives away the ones who do care about testing
and who would be willing to offer their help. So without the clear vision
towards it all the support you would be wanting will never materialize...
It’s also not helping the discussion to quote the BSD license disclaimer. A
disclaimer is not a mission statement, its a legal protection mechanism..
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that no
code is merged that fails a test (so contributors will find that they need to
fix their contributions regularly because the test system uncovers corner
cases) and that at times you’re chasing issues with the test system instead of
progressing on the core code.
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find companies
which want to contribute funding to create quality.
But in my experience in creating an open source community you have to show the
vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that helps.
Thanks!
-Lorenz

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The difference is that Linux has subsystem maintainers that gather localized
changes, validate them, and submit them to Linus after review. I believe there
are multiple levels in this hierarchical structure.
In NuttX Greg has to do all the validation.
The problem we have if we want to follow this structure, is that we would need
seriously dedicated volunteers to handle subsystems in the long term. For the
moment we have none, that's why Greg suggested a foundation with a paid QA manager.
About the repository, a "staging" branch is probably enough for the final
validation by Greg before merge in the "gold" master, along with repos managed
by each subsystem maintainer.
Sebastien

Post by Thiago Costa de Paiva ***@tecepe.eng.br [nuttx]
Hi, Greg. Thanks for the thoughtful e-mail. I was wondering how Linux kernel
deal with this and I believe the answer is that the face the same problem. Old
https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf <https://www.osadl.org/fileadmin/dam/presentations/morton-hannover-2008-kernel-qa.pdf>
Question: do we need to have another repository for that? Would a devel (for
developments) branch and a master (for stable code) branch not suffice?
Thiago

Thanks for the offer! But in my point of view, what is needed is nothing

that could be provided with a part time effort. This is not just a matter of
doing a couple of tasks, it requires a full dedication..

- Develop a QA plan that address how every thing would be done
- Manage the repositories, separating NuttX into a nuttx-dev and a golden

nuttx repository. All changes would be made in nuttx-dev and only merged into
nuttx when they meet all QA requirements.

- Perform continuous build testing of all 400 or so board configurations.

This current takes about a half a day to do on a high end PC under Linux. This
time could be probably reduced with a build farm.

- Review and verify (to the extent reasonable) all PRs. Assure that all

changes are 100% consistent with the coding style.

- Merge the verified code into nuttx. Assure that there is only a single

commit per functional change and that the comments are pristine so that we can
dispense with a separate ChangeLog.

- Perform periodic releases.
- Develop plans for automated testing and some build and test farm to

perform regression testing.

- And probably lots more.
That is a job description, not a task you can do part time.. None of the

above makes sense to do piecemeal if there is not a dedicated resource and a
commitment to support the work over the long haul.

- Form a non-profit organization that can have employees,
- Obtain financial support, perhaps through SPI?
- Hire and manage the above-mentioned QA person

--
Thiago Costa de Paiva
FSF member: 11963
Linux User: 565327

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Lorenz,

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care about
testing and who would be willing to offer their help. So without the clear
vision towards it all the support you would be wanting will never
materialize.

I think everybody here wants to improve NuttX. I think the points that
Greg stated are very important and I think we need:

1) someone compromised to get the QA done;

2) it people need to assume long term support, he could throw the ball
and go away;

3) it should use default tools already used on NuttX (Makefile; bash
scripts, etc), so avoid the pretty old CMake and friends discussion;

Also beyond the QA test I think it is important to have a real farm of
supported boards to test the final binary.

I and Sebastien started working on a raspi farm to do that:

https://bitbucket.org/acassis/raspi-nuttx-farm

But we need to put it on production to test the final NuttX binary.

Post by Lorenz Meier ***@px4.io [nuttx]
It’s also not helping the discussion to quote the BSD license disclaimer. A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.

Yes, it is more a legal protection mechanism.

Today we have great competitors (FreeRTOS, Zephyr, etc), we should do
better than them, even with less resources available.

Post by Lorenz Meier ***@px4.io [nuttx]
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that
no code is merged that fails a test (so contributors will find that they
need to fix their contributions regularly because the test system uncovers
corner cases) and that at times you’re chasing issues with the test system
instead of progressing on the core code.

That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

Post by Lorenz Meier ***@px4.io [nuttx]
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find
companies which want to contribute funding to create quality.

Nice to hear it! I think PX4 more as NuttX fork, but I can deny all
contributions PX4 did along the years.

I hope PX4 become more integrated to mainline, it will be useful for
NuttX and for PX4 as well.

Post by Lorenz Meier ***@px4.io [nuttx]
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that
helps.

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mailing?

It should be very important and useful for NuttX community.

BR,

Alan

[Gregory Nutt [e-mail] [nuttx]]

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

[I just call it build testing. CI sounds like something more exotic than
it is.?? This is not rocket science.]

I don't think that there is any online build testing system that is
usable with NuttX.?? I mentioned before, running on a dedicated 8-core,
high performance Linux box, it requires about 6 hours to build ALL
existing board configurations that can be built under Linux.?? I believe
that all of the free, online services have strict limitations on CPU usage.

Build testing with NuttX is very different that building software that
has only a few configurations.?? Here we are talking about around 400
configurations that need to be built.?? Cutting that down to a small
subset of configurations would not be a useful build test;?? I have far
superior build testing in hand now.

[Alan Carvalho de Assis [e-mail] [nuttx]]

Normally I don't send another email to fix my typos, but because the
previous email was full of them I decided to fix some phrases to let
people understand what I was trying to say:

....

2) this person needs to assume long term support, he couldn't throw the ball
and go away;

....

Nice to hear it! I think PX4 more like NuttX fork, but I can't deny all
contributions PX4 did along the years.

....

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mainstream?

BR,

Alan

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Hi Lorenz,

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care about
testing and who would be willing to offer their help. So without the clear
vision towards it all the support you would be wanting will never
materialize.

I think everybody here wants to improve NuttX. I think the points that
1) someone compromised to get the QA done;
2) it people need to assume long term support, he could throw the ball
and go away;
3) it should use default tools already used on NuttX (Makefile; bash
scripts, etc), so avoid the pretty old CMake and friends discussion;
Also beyond the QA test I think it is important to have a real farm of
supported boards to test the final binary.
https://bitbucket.org/acassis/raspi-nuttx-farm
But we need to put it on production to test the final NuttX binary.

Post by Lorenz Meier ***@px4.io [nuttx]
It’s also not helping the discussion to quote the BSD license disclaimer. A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.

Yes, it is more a legal protection mechanism.
Today we have great competitors (FreeRTOS, Zephyr, etc), we should do
better than them, even with less resources available.

Post by Lorenz Meier ***@px4.io [nuttx]
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that
no code is merged that fails a test (so contributors will find that they
need to fix their contributions regularly because the test system uncovers
corner cases) and that at times you’re chasing issues with the test system
instead of progressing on the core code.

That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

Post by Lorenz Meier ***@px4.io [nuttx]
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find
companies which want to contribute funding to create quality.

Nice to hear it! I think PX4 more as NuttX fork, but I can deny all
contributions PX4 did along the years.
I hope PX4 become more integrated to mainline, it will be useful for
NuttX and for PX4 as well.

Post by Lorenz Meier ***@px4.io [nuttx]
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that
helps.

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mailing?
It should be very important and useful for NuttX community.
BR,
Alan

[Lorenz Meier [e-mail] [nuttx]]

Alan,

If you really think PX4 is a fork of NuttX I suggest to just dive into our repositories:
https://github.com/PX4-NuttX <https://github.com/PX4-NuttX>

In particular look at the commits and see for yourself if you see deviation from mainline:
https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39 <https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39>

I’m trying to be not insulted by a comment like that. What you’re saying is the equivalent of calling Redhat a Fork of Linux because they offer stable versions. Who else in this community has made upstream contributions for 6 years, including complete architecture ports? There are a few, but its not many.

What I’m trying to find out is a way to bring some of the experience we have in maintaining a very stable version to upstream. If you think through it that is exactly trying to prevent local versions / forks. The more upstream testing we can enable, the less we need to do ourselves in our stable versions.

This will largely inform our own roadmap how we maintain the stability of the RTOS portion of our distribution in the future.

Thanks!

-Lorenz

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Normally I don't send another email to fix my typos, but because the
previous email was full of them I decided to fix some phrases to let
....
2) this person needs to assume long term support, he couldn't throw the ball
and go away;
....
Nice to hear it! I think PX4 more like NuttX fork, but I can't deny all
contributions PX4 did along the years.
....
Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mainstream?
BR,
Alan

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Hi Lorenz,

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care about
testing and who would be willing to offer their help. So without the clear
vision towards it all the support you would be wanting will never
materialize.

I think everybody here wants to improve NuttX. I think the points that
1) someone compromised to get the QA done;
2) it people need to assume long term support, he could throw the ball
and go away;
3) it should use default tools already used on NuttX (Makefile; bash
scripts, etc), so avoid the pretty old CMake and friends discussion;
Also beyond the QA test I think it is important to have a real farm of
supported boards to test the final binary.
https://bitbucket.org/acassis/raspi-nuttx-farm <https://bitbucket.org/acassis/raspi-nuttx-farm>
But we need to put it on production to test the final NuttX binary.

Post by Lorenz Meier ***@px4.io [nuttx]
It’s also not helping the discussion to quote the BSD license disclaimer. A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.

Yes, it is more a legal protection mechanism.
Today we have great competitors (FreeRTOS, Zephyr, etc), we should do
better than them, even with less resources available.

Post by Lorenz Meier ***@px4.io [nuttx]
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that
no code is merged that fails a test (so contributors will find that they
need to fix their contributions regularly because the test system uncovers
corner cases) and that at times you’re chasing issues with the test system
instead of progressing on the core code.

That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

Post by Lorenz Meier ***@px4.io [nuttx]
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find
companies which want to contribute funding to create quality.

Nice to hear it! I think PX4 more as NuttX fork, but I can deny all
contributions PX4 did along the years.
I hope PX4 become more integrated to mainline, it will be useful for
NuttX and for PX4 as well.

Post by Lorenz Meier ***@px4.io [nuttx]
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re happy to
contribute to building a proof-of-concept in terms of test setup if that
helps.

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mailing?
It should be very important and useful for NuttX community.
BR,
Alan

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Lorenz,

It is not my intention to insulted you, or your project neither
anybody else, if you search the mailing list history you will see that
I'm not the kind of people that insult other people.

When I'm saying that I see PX4 as a fork I am basing on:

1) It uses a different building system;

2) It uses a driver model completely different from NuttX (PX4
develops low-end driver in C++) that cannot be used directly in the
mainline. The audio tone generator is based of PX4 driver and it
required many modifications/adaption to work on mainline;

3) It violates the NuttX's POSIX abstraction (as you can see now
there is not application on mainline that violates it).

But I'm happy to know you are willing to work with mainline to improve
its stability and I want to contribute with it as well.

Sorry if you felt offended, it is exact the opposite I want see PX4
really working more close to NuttX mainline.

BR,

Alan

Post by Lorenz Meier ***@px4.io [nuttx]
Alan,
https://github.com/PX4-NuttX <https://github.com/PX4-NuttX>
https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39
<https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39>
I’m trying to be not insulted by a comment like that. What you’re saying is
the equivalent of calling Redhat a Fork of Linux because they offer stable
versions. Who else in this community has made upstream contributions for 6
years, including complete architecture ports? There are a few, but its not
many.
What I’m trying to find out is a way to bring some of the experience we have
in maintaining a very stable version to upstream. If you think through it
that is exactly trying to prevent local versions / forks. The more upstream
testing we can enable, the less we need to do ourselves in our stable
versions.
This will largely inform our own roadmap how we maintain the stability of
the RTOS portion of our distribution in the future.
Thanks!
-Lorenz

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Normally I don't send another email to fix my typos, but because the
previous email was full of them I decided to fix some phrases to let
....
2) this person needs to assume long term support, he couldn't throw the ball
and go away;
....
Nice to hear it! I think PX4 more like NuttX fork, but I can't deny all
contributions PX4 did along the years.
....
Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mainstream?
BR,
Alan

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Hi Lorenz,

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care about
testing and who would be willing to offer their help. So without the clear
vision towards it all the support you would be wanting will never
materialize.

I think everybody here wants to improve NuttX. I think the points that
1) someone compromised to get the QA done;
2) it people need to assume long term support, he could throw the ball
and go away;
3) it should use default tools already used on NuttX (Makefile; bash
scripts, etc), so avoid the pretty old CMake and friends discussion;
Also beyond the QA test I think it is important to have a real farm of
supported boards to test the final binary.
https://bitbucket.org/acassis/raspi-nuttx-farm
<https://bitbucket.org/acassis/raspi-nuttx-farm>
But we need to put it on production to test the final NuttX binary.

Post by Lorenz Meier ***@px4.io [nuttx]
It’s also not helping the discussion to quote the BSD license
disclaimer.
A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.

Yes, it is more a legal protection mechanism.
Today we have great competitors (FreeRTOS, Zephyr, etc), we should do
better than them, even with less resources available.

Post by Lorenz Meier ***@px4.io [nuttx]
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that
no code is merged that fails a test (so contributors will find that they
need to fix their contributions regularly because the test system uncovers
corner cases) and that at times you’re chasing issues with the test system
instead of progressing on the core code.

That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

Post by Lorenz Meier ***@px4.io [nuttx]
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find
companies which want to contribute funding to create quality.

Nice to hear it! I think PX4 more as NuttX fork, but I can deny all
contributions PX4 did along the years.
I hope PX4 become more integrated to mainline, it will be useful for
NuttX and for PX4 as well.

Post by Lorenz Meier ***@px4.io [nuttx]
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re
happy
to
contribute to building a proof-of-concept in terms of test setup if that
helps.

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mailing?
It should be very important and useful for NuttX community.
BR,
Alan

[[e-mail] [nuttx]]

Hi Alan,

In response to your numbered points.


1. PX4 itself uses cmake, but still respects the NuttX build system and integrates with it via regular configure.sh and make. The difference is the top level PX4 build system explicitly calls NuttX make for each of the libs it requires. This allows safely building in parallel, tight integration (dependencies), and very fast builds (building PX4+NuttX is faster than building NuttX alone).


2. Is there a technical reason the low end drivers can't be written in C++? I personally like the additional type and memory safety you can get with modern c++.

The other reason PX4 drivers don't necessarily make sense for mainline NuttX is that they're often abstracted so that the bulk of same IMU driver can be used on Linux with spidev or i2c-dev. If there's a better way to structure this I'd love to discuss it.


3. Could you please expand on this? I'm interested.


Thanks,


Daniel






---In ***@yahoogroups.com, <***@...> wrote :

Hi Lorenz,

It is not my intention to insulted you, or your project neither
anybody else, if you search the mailing list history you will see that
I'm not the kind of people that insult other people.

When I'm saying that I see PX4 as a fork I am basing on:

1) It uses a different building system;

2) It uses a driver model completely different from NuttX (PX4
develops low-end driver in C++) that cannot be used directly in the
mainline. The audio tone generator is based of PX4 driver and it
required many modifications/adaption to work on mainline;

3) It violates the NuttX's POSIX abstraction (as you can see now
there is not application on mainline that violates it).

But I'm happy to know you are willing to work with mainline to improve
its stability and I want to contribute with it as well.

Sorry if you felt offended, it is exact the opposite I want see PX4
really working more close to NuttX mainline.

BR,

Alan

Alan,
https://github.com/PX4-NuttX https://github.com/PX4-NuttX <https://github.com/PX4-NuttX https://github.com/PX4-NuttX>
https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39 https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39
<https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39 https://github.com/PX4-NuttX/nuttx/commits/e89edd67848c4939021286ed2bd1fc5adb6cbc39>
I’m trying to be not insulted by a comment like that. What you’re saying is
the equivalent of calling Redhat a Fork of Linux because they offer stable
versions. Who else in this community has made upstream contributions for 6
years, including complete architecture ports? There are a few, but its not
many.
What I’m trying to find out is a way to bring some of the experience we have
in maintaining a very stable version to upstream. If you think through it
that is exactly trying to prevent local versions / forks. The more upstream
testing we can enable, the less we need to do ourselves in our stable
versions.
This will largely inform our own roadmap how we maintain the stability of
the RTOS portion of our distribution in the future.
Thanks!
-Lorenz

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Normally I don't send another email to fix my typos, but because the
previous email was full of them I decided to fix some phrases to let
....
2) this person needs to assume long term support, he couldn't throw the ball
and go away;
....
Nice to hear it! I think PX4 more like NuttX fork, but I can't deny all
contributions PX4 did along the years.
....
Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mainstream?
BR,
Alan

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Hi Lorenz,

Post by Lorenz Meier ***@px4.io [nuttx]
Let’s take a step back.
What I’ve asked for is the vision, not the status quo. If you’re not
striving towards extensive QA then it drives away the ones who do care about
testing and who would be willing to offer their help. So without the clear
vision towards it all the support you would be wanting will never
materialize.

I think everybody here wants to improve NuttX. I think the points that
1) someone compromised to get the QA done;
2) it people need to assume long term support, he could throw the ball
and go away;
3) it should use default tools already used on NuttX (Makefile; bash
scripts, etc), so avoid the pretty old CMake and friends discussion;
Also beyond the QA test I think it is important to have a real farm of
supported boards to test the final binary.
https://bitbucket.org/acassis/raspi-nuttx-farm https://bitbucket.org/acassis/raspi-nuttx-farm
<https://bitbucket.org/acassis/raspi-nuttx-farm https://bitbucket.org/acassis/raspi-nuttx-farm>
But we need to put it on production to test the final NuttX binary.

Post by Lorenz Meier ***@px4.io [nuttx]
It’s also not helping the discussion to quote the BSD license
disclaimer.
A
disclaimer is not a mission statement, its a legal protection mechanism.
Everybody has that and yet most engineers strive for much higher goals in
terms of quality.

Yes, it is more a legal protection mechanism.
Today we have great competitors (FreeRTOS, Zephyr, etc), we should do
better than them, even with less resources available.

Post by Lorenz Meier ***@px4.io [nuttx]
What it would however require would be the commitment of both the maintainer
as well as the development community to establish testing processes. That
means running code through the CI system before merging it (which kind of
forces the usage of pull requests, so it adds a constraint). It means that
no code is merged that fails a test (so contributors will find that they
need to fix their contributions regularly because the test system uncovers
corner cases) and that at times you’re chasing issues with the test system
instead of progressing on the core code.

That is other point, we need a CI that works with Bitbucket. Instead
of bothering Greg to move to github we should to find alternatives
that works with Bitbucket.

Post by Lorenz Meier ***@px4.io [nuttx]
If NuttX wanted to establish this, we would be able to help with engineering
bandwidth and if there would be a foundation we would probably find
companies which want to contribute funding to create quality.

Nice to hear it! I think PX4 more as NuttX fork, but I can deny all
contributions PX4 did along the years.
I hope PX4 become more integrated to mainline, it will be useful for
NuttX and for PX4 as well.

Post by Lorenz Meier ***@px4.io [nuttx]
But in my experience in creating an open source community you have to show
the vision (and actions) first before companies do pitch in. We’re
happy
to
contribute to building a proof-of-concept in terms of test setup if that
helps.

Do you want to build a proof-of-concept that uses only default tools
already used on NuttX mailing?
It should be very important and useful for NuttX community.
BR,
Alan

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Daniel,

Post by ***@agar.ca [nuttx]
1. PX4 itself uses cmake, but still respects the NuttX build system and
integrates with it via regular configure.sh and make. The difference is the
top level PX4 build system explicitly calls NuttX make for each of the libs
it requires. This allows safely building in parallel, tight integration
(dependencies), and very fast builds (building PX4+NuttX is faster than
building NuttX alone).

Sure. The original Makefiles on NuttX could be modified to support
parallel compilation as well.

Post by ***@agar.ca [nuttx]
2. Is there a technical reason the low end drivers can't be written in C++?

No, there is not, but when you do it we are dividing efforts, we need
to re-create drivers that PX4 already created in a different way.
It is not a big problem, but it should be nice to have this level of
cooperation.

Post by ***@agar.ca [nuttx]
I personally like the additional type and memory safety you can get with
modern c++.

I think a driver is low-level enough to force the developer to take
this level of care instead of believing that the language and compiler
will care of it.

The C++ could be more useful at high level to create applications,
just my opinion.

Post by ***@agar.ca [nuttx]
The other reason PX4 drivers don't necessarily make sense for mainline
NuttX is that they're often abstracted so that the bulk of same IMU driver
can be used on Linux with spidev or i2c-dev. If there's a better way to
structure this I'd love to discuss it.

Yes, the uORB could read the sensor data directly from /dev/[acc0,
gyro0, mag0, etc]. It could introduce some small latency, but it will
allow PX4 to share drivers with NuttX and vice-versa.

Post by ***@agar.ca [nuttx]
3. Could you please expand on this? I'm interested.

Right, in the PX4 applications are accessing kernel functions
directly. On NuttX the applications are enforced to follow POSIX
abstraction, it means all applications need to read/write data from/to
peripherals using the special device files at /dev, like it happen on
Linux and all Unix.

BR,

Alan

[Gregory Nutt [e-mail] [nuttx]]

Post by ***@agar.ca [nuttx]

Post by ***@agar.ca [nuttx]
2. Is there a technical reason the low end drivers can't be written

in C++?
No, there is not, ...

There are restrictions within the OS:   You cannot have any static
constructors nor can you use libstdc++.  Everything also has to have
"extern C".  And everything still has to conform with standard POSIX C
driver interfaces.  No C++ can be exported from the OS nor used by any
application.  That would break the portable POSIX interface (which is
all C).

Drivers are initialized very early in the boot-up sequence so they
cannot depend on anything be initialized in C++ world.  libstdc++ would
be accessible in the FLAT build, but not in the PROTECTED or KERNEL
builds.  So I could not accept any C++ driver upstream that does not
work in all build modes.

So, yes, you could theoretically use a C++ compiler to basically write C
code but "real" C++ is not permissible within the OS and, hence, will
not be accepted upstream.

[[e-mail] [nuttx]]

My thought is that the golden repository would not accept any forks or PRs. It would be strictly for clones. Nothing unreviewed would ever come into the golden repository and the screwed up history of the development repository would never be a part of the golden repository. The history would be clean, sanitized and suitable as the official ChangeLog from released version to version.


My experience is that it is impossible to isolate the mast branch from the the development branch. The master branch is always getting contaminated. I think the safest thing would be separate repositories.

[Thiago Costa de Paiva [e-mail] [nuttx]]

Hi, Greg, all.

I'll probably say things that people already know, but after some reading, I learned that Linux kernel strongly relies on community for testing.

As an example, several institutions (IBM, Cisco, Fujitsu, SUSE, Red Hat, Oracle and others) joined effort to provide the Linux Test Project (LTP) to "validate the reliability, robustness, and stability of Linux".

https://github.com/linux-test-project/ltp

There is also a "framework for fully automated test" called "avocado":

http://avocado-framework.github.io/

Since it doesn't seem very practical to have all the combination of processors and peripherals in a centralized place, I was wondering if we are interested on this kind of approach.

Sorry if this is something that we already have and I'm not aware or if that isn't a interesting path.

Thiago

[[e-mail] [nuttx]]

There is actually a problem with your change. Although it eliminates the assertion, it still leaves thread cancellation broken. Some additional design changes would be required. The changes are not complex, but the rationale is. So I have documented the issue on the Wiki site: http://www.nuttx.org/doku.php?id=wiki:nxinternal:cancellation-points&#design_issues

What I expect that you will see is that when you try to cancel the task/thread, it will no longer assert. However, it will not be cancelled either. Please see the Wiki page for the reason why and what you would have to do to fix the issue.