I hope that you assure that this works in the PROTECTED mode. In that
mode, tow libraries are built: A kernel library and a user library.
On 12/29/2020 2:50 PM, Abdelatif Guettouche wrote:
We can only do so much from the application, we want to have some unit
tests for the hardware drivers, that we will also hook to our internal
CI.
The driver can be instantiated and instead of binding it with an upper
layer we use it as part of our testing.
We can then have boards' entry points that run the unit tests.
At least this is the idea so far.
On Mon, Dec 28, 2020 at 8:22 PM Brennan Ashton
<bash...@brennanashton.com> wrote:
You would need to explain more. It would be very difficult to separate the
drivers from the underlying hardware interface. What exactly are you
wanting to test? You can always violate the kernel boundary for testing
much like is done with some of the other tests in apps.
On Mon, Dec 28, 2020, 11:13 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
The interface is actually configurable.
We want to use that for some unit testing for the drivers, any
alternatives?
On Mon, Dec 28, 2020, 20:05 Gregory Nutt <spudan...@gmail.com> wrote:
Unity also uses application only interfaces such as printf() that would
be inappropriate for use within the OS.
On 12/28/2020 1:00 PM, Brennan Ashton wrote:
I don't think so any testing will be part of an application. There is
nothing in the OS that would ever make use of it directly. Even if you
were to make something like ostest use it the right place would still
be
as
an application.
--Brennan
On Mon, Dec 28, 2020, 10:40 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
Unity (https://github.com/ThrowTheSwitch/Unity) is a test harness
that
we can use both for applications and OS code. Isn't it better to have
it in libs/libtesting instead of apps/testing?
