Question: if they're almost the same, do we really need an extra directory layer, or simply have different files for the parts that differ in the same directory ? That would prevent directory prolifer

Folks, Not that big of a change for a lot of people, but I pushed a revision to documentation yesterday that enforces a 8-char tabs/80 column coding style. Basically, this makes our coding style the s

Hang on on this, I'm cleaning up a GDB server implementation that we want to upstream, and it uses at least dynamic exceptions. I'll see if I can refactor it to use static ones instead.

I think -ENOTSUP is a 1-1 match here: ENOTSUP Operation not supported (POSIX.1)

Because of the pointer dereference, the check for NULL and the function call ? It's probably OK. And you could turn the check into an __ASSERT() if you want to save a bit or both code space and time.

Maybe it did not come clear in my reply, but what I proposed did not have a global logging level, or rather, the global level is always "OFF". Each subsystem that you want to log has to enable it, wit

+1

I don't think you need this expired flag: delta_ticks_from_prev is either 0 or -1 when the timeout expires (-1 I think). I would prefer if we had a nano_timer object that is a wrapper around a _nano_t

I think he got that from scs.h, which uses 'val' and 'bit'. Maybe we should rename 'val' to 'raw' there as well.

I agree this sounds awkward. Why aren't the component themselves providing a kconfig option that can be tweaked on a per-component basis. e.g. CONFIG_I2C_LOG_LEVEL="DEBUG" CONFIG_PWM_LOG_LEVEL="ERROR"

Hi Maciek, Very cool! Cortex-M4 should work as well, since the M4 is a superset of the M3. The first board we supported is the Freescale FRDM-K64F, which is an M4. For M0, you have to do an arch port

Again, do we want to take over _another_ namespace ? Maybe it should be sys_debug or sys_dbg or sys_dbg_log ? The sample implementation is adding all these in logging.h, which is a public API file: DB

Yeah, that would do it: the task has to yield to the fiber somehow, since it will never pend (in a nanokernel context). Hmm, I would counter this with the argument that passing the current fiber conte

Sure.

We're just returning a thread ID when we start a fiber now, you can ignore it. I don't see an issue here...

Ugh, you're right, it's a nano_thread_id_t.

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

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 error.

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, the outpu