Hi Anas, Quoting Nashif, Anas (2016-02-19 14:07:36) Yes, I agree. I'm not a gerrit expert but from I could understand, this is related to the 'forge author' settings from submitter rights. I'm CCing

How about something like this: diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c index f86f95f..82774c4 100644 --- a/kernel/nanokernel/device.c +++ b/kernel/nanokernel/device.c @@

Makes sense but why not tell the compiler the truth about the type?

Thanks for documenting this but I don't think forcing people to use git-review is the right approach. It worked for us before in many other projects, why is this different and why can't I use vanilla

Sounds good, but we need to do it in away that keeps APIs compatible I guess. Anas

Looks like it. You want to do the implementation yourself Jukka ?

What I was proposing in my last reply, too keep things simple, is one Kconfig option to enable/disable handling of error codes by init functions. If it's disabled, nothing is handled automatically and

Hi Joakim, I have not measured this. At the moment the IP stack is configured to have separate TX and RX buffers. So in minimal configuration there would be one TX and one RX buffer vs. in Contiki

Hi Jukka! Ok, yes - I expected that there would be quite som changes. But I guess that they will be the same changes at each sync! I will take a look at the codebase and see how much differences you

Hi, No comments -> no objects -> perhaps we can continue with this route then? Cheers, Jukka

Hi Joakim, The plan is to sync it from Contiki when applicable. If you look the code, we needed to make lot of changes to uIP stack in order to make it work in Zephyr. The biggest change is that the

that worked - thanks Ben! Ravi

Zephyr kernel provides debug hooks to allow debugging tools to access nanokernel and microkernel objects (FIFO, LIFO, semaphores, etc.) and display their attributes for content

For those non-fatal errors, what should we do for runtime driver behaviors? Should the drivers themselves fail API calls? Or should we let device_get_binding() return NULL? ----- Daniel Leung

OK, following your proposal below, what we could put in place is standardizing on error codes that init routines must return if they want the kernel init system to automatically trigger a fatal

How about a CONFIG option to determine if kernel should abort boot? The behavior should be determined by the kind of application. Some can live with less features while for others it is all or

Hi all, I was having some trouble to submit a change to Gerrit which depends on someone else's change. If I use the 'git push' command as described in [1], I get the following error: remote: ERROR:

The following is proposed to permit microkernel tasks to pend on nanokernel objects. Background: ----------- When the nanokernel's background task must wait for a nanokernel object (N.O.) it polls.

Delving into the realm of the hypothetical :-) What about devices that have drivers in the system but are not present (pluggable) or can't initialize because some resource external to the device

Hi Ravi, You probably built for one target, then built for a different one without cleaning up the first build. e.g. $ make <- x86 by default $ make BOARD=qemu_cortex_m3 <- bombs Be default,