On 02/18/2016 10:03 AM, Benjamin Walsh wrote:

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal error
handler upon the detection of failure. Otherwise we duplicate the
overhead of calling the fatal error handler in each device
initialization routine.

Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.

For the kind of systems we are targeting, do we really expect the
application to handle devices not initializing correctly, being designed
so that parts are disabled if some parts of the initialization fail
(devices or others), or do we expect applications to require everything
to be present for them to function correctly ? I would have thought the
latter, but I can be convinced.

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 can't be contacted (network server).

The application may be able to still do useful work albeit with reduced
functionality.

Then, if the latter, do we expect the application catching the errors at
runtime when deployed or during development (basically catching software
errors mostly) not malfunctionning hardware. Here, I was thinking the
latter as well, which is why I was proposing __ASSERT() calls catching
initialization errors in debug loads only. And this fits with one of the
core values of the OS, which is small footprint.

Both models are useful for different reasons :-D

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.

Agreed we need to pick and stay with it for some amount of time until
we see a few real uses/applications/platforms.

How we could/should report this type of error is an open question :-).

Brainstorming:

If we want to let the application handle the initialization issues, we
probably need some kind of queue that gets filled by the init system
when init functions return errors, and that the application drains to
see what failed. We might want to queue the associated device objects,
and have an errno field in there, or something like that.

How about having the driver return an error code saying whether the
failure is a fatal error or not. For the drivers that we have now where
we *know* that if it fails it is a hardware or configuration error
which is fatal. So we go with the _NanoFatalErrorHandler() error path.

If a non-fatal error occurred (may work at next reset) just ignore it
an move on. The application can detect if the device is dead/not
present by the return codes from the driver call(s). Then the
application can decide what and how to report the error to the user.

Hi Ravi,

anyone else run into this error?

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 output goes into the 'outdir' directory, and the builds
cannot coexist in there. You can chose where the output goes via the O=
makefile variable.

e.g.

$ make O=out-x86
$ make O=out-arm BOARD=qemu_cortex_m3

Or you can clean by doing 'make pristine' between them.

Cheers,
Ben

thanks,
Ravi

rlsahita(a)ubuntu:~/zeph/zephyr-project/samples/hello_world/microkernel$ make BOARD=qemu_cortex_m3 ARCH=arm
make[1]: Entering directory `/home/rlsahita/zeph/zephyr-project'
make[2]: Entering directory `/home/rlsahita/zeph/zephyr-project/samples/hello_world/microkernel/outdir'
Using /home/rlsahita/zeph/zephyr-project as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
In file included from /home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:37:0:
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h: In function 'nanoArchInit':
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:168:2: warning: implicit declaration of function '_InterruptStackSetup' [-Wimplicit-function-declaration]
_InterruptStackSetup();
^
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:169:2: warning: implicit declaration of function '_ExcSetup' [-Wimplicit-function-declaration]
_ExcSetup();
^
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h: In function 'fiberRtnValueSet':
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:192:6: error: dereferencing pointer to incomplete type 'tESF {aka struct __esf}'
pEsf->a1 = value;
^
In file included from /home/rlsahita/zeph/zephyr-project/include/toolchain.h:29:0,
from /home/rlsahita/zeph/zephyr-project/kernel/nanokernel/include/gen_offset.h:86,
from /home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:36:
/home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c: In function '_OffsetAbsSyms':
/home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:67:40: error: invalid application of 'sizeof' to incomplete type 'tESF {aka struct __esf}'
GEN_ABSOLUTE_SYM(__tESF_SIZEOF, sizeof(tESF));
^
/home/rlsahita/zeph/zephyr-project/include/toolchain/gcc.h:272:43: note: in definition of macro 'GEN_ABSOLUTE_SYM'
"\n\t.type\t" #name ",@object" : : "n"(value))
^
make[3]: *** [arch/arm/core/offsets/offsets.o] Error 1
make[2]: *** [prepare] Error 2
make[2]: Leaving directory `/home/rlsahita/zeph/zephyr-project/samples/hello_world/microkernel/outdir'
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/rlsahita/zeph/zephyr-project'
make: *** [all] Error 2
rlsahita(a)ubuntu:~/zeph/zephyr-project/samples/hello_world/microkernel$

--
Benjamin Walsh, SMTS
Wind River Rocket
Zephyr kernel maintainer
zephyrproject.org
www.windriver.com

anyone else run into this error?

thanks,
Ravi

rlsahita(a)ubuntu:~/zeph/zephyr-project/samples/hello_world/microkernel$ make BOARD=qemu_cortex_m3 ARCH=arm
make[1]: Entering directory `/home/rlsahita/zeph/zephyr-project'
make[2]: Entering directory `/home/rlsahita/zeph/zephyr-project/samples/hello_world/microkernel/outdir'
Using /home/rlsahita/zeph/zephyr-project as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
In file included from /home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:37:0:
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h: In function 'nanoArchInit':
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:168:2: warning: implicit declaration of function '_InterruptStackSetup' [-Wimplicit-function-declaration]
_InterruptStackSetup();
^
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:169:2: warning: implicit declaration of function '_ExcSetup' [-Wimplicit-function-declaration]
_ExcSetup();
^
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h: In function 'fiberRtnValueSet':
/home/rlsahita/zeph/zephyr-project/arch/arm/include/nano_private.h:192:6: error: dereferencing pointer to incomplete type 'tESF {aka struct __esf}'
pEsf->a1 = value;
^
In file included from /home/rlsahita/zeph/zephyr-project/include/toolchain.h:29:0,
from /home/rlsahita/zeph/zephyr-project/kernel/nanokernel/include/gen_offset.h:86,
from /home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:36:
/home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c: In function '_OffsetAbsSyms':
/home/rlsahita/zeph/zephyr-project/arch/arm/core/offsets/offsets.c:67:40: error: invalid application of 'sizeof' to incomplete type 'tESF {aka struct __esf}'
GEN_ABSOLUTE_SYM(__tESF_SIZEOF, sizeof(tESF));
^
/home/rlsahita/zeph/zephyr-project/include/toolchain/gcc.h:272:43: note: in definition of macro 'GEN_ABSOLUTE_SYM'
"\n\t.type\t" #name ",@object" : : "n"(value))
^
make[3]: *** [arch/arm/core/offsets/offsets.o] Error 1
make[2]: *** [prepare] Error 2
make[2]: Leaving directory `/home/rlsahita/zeph/zephyr-project/samples/hello_world/microkernel/outdir'
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/rlsahita/zeph/zephyr-project'
make: *** [all] Error 2
rlsahita(a)ubuntu:~/zeph/zephyr-project/samples/hello_world/microkernel$

Hi all,

While we were discussing about adding a new error code for device.h (see
"[RFC] Add DEV_NOT_IMPLEMENTED error code" thread), we had an initial
agreement that it does make sense to use error codes from errno.h instead
of the ones from include/device.h. Since this topic deserves its own RFC,
I'm sending this email so we can have a proper discussion.

So the main points in favor of this change are 1) errno.h is a well-known
error convention which pretty much all developer is familiar with, 2)
errno.h codes address what we need, 3) no need to create new codes such
as DEV_NOT_IMPLEMENTED for instance, and 4) changing the current drivers
to use errno.h codes instead of DEV_* is a feasible task.

The initial discussion was about using errno.h codes at the driver's layer
but I think we can expand it to the whole system. Actually, errno.h codes
are already used in net/bluetooth and net/ip.

Regards,

Andre

Because my main dev box has been in a steady state of failing for a while now, I moved everything over to a new (to me) development machine (dleung’s dregs, thanks Daniel!) with a fresh install of Fedora 23.

While following the directions on ZephyrProject.org, I questioned the need for the required packages. I believe these portions are left over requirements from the days when we built our own cross-compiler toolchain.

Is there any reason why these are still needed?

The short answer is yes. We still need these for the build tools/system to work.

Why is Zephyr’s SDK not capable of compiling everything for the OS?
Why are we still dependent upon the host computer having GCC when we just downloaded a version of it?

Seems like we just required someone to download a 350 MB SDK, plus all the dev tools for their platform at an additional 300 MB.

For some reason, the signature of functions passed to the
DEVICE_INIT() <init_fn> parameter has a return type of 'int', but
the return value is never checked within
_sys_device_do_config_level(). Some init functions do return an
error code, such as the ARC init code and the bluetooth init
routines, but that just gets ignored.

Question: should we have init functions of return type 'void' then ?
That would shave a few bytes in every init function if we don't have
to return a value.

We generally try to operate under the assumption that failures will
not occur. That being said, we do have some instances where we do
check for errors, and some of these are considered fatal.

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal error
handler upon the detection of failure. Otherwise we duplicate the
overhead of calling the fatal error handler in each device
initialization routine.

Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.

For the kind of systems we are targeting, do we really expect the
application to handle devices not initializing correctly, being designed
so that parts are disabled if some parts of the initialization fail
(devices or others), or do we expect applications to require everything
to be present for them to function correctly ? I would have thought the
latter, but I can be convinced.

Then, if the latter, do we expect the application catching the errors at
runtime when deployed or during development (basically catching software
errors mostly) not malfunctionning hardware. Here, I was thinking the
latter as well, which is why I was proposing __ASSERT() calls catching
initialization errors in debug loads only. And this fits with one of the
core values of the OS, which is small footprint.

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.

How we could/should report this type of error is an open question :-).

Brainstorming:

If we want to let the application handle the initialization issues, we
probably need some kind of queue that gets filled by the init system
when init functions return errors, and that the application drains to
see what failed. We might want to queue the associated device objects,
and have an errno field in there, or something like that.

Hello!

I just cloned the Zephyr repository and saw that the 6LoWPAN stack was the same as the one I am used to - e,g, the Contiki 6LoWPAN stack. How are you planning to develop it further? Are you going to sync it from Contiki or would you like Contiki developers to post pull-requests to fixes also to Zephyr?

Anyway - congratulations - it looks like an exciting project and I will be happy contribute to it!

-- Joakim Eriksson, SICS

On 02/18/2016 06:42 AM, Jesus Sanchez-Palencia wrote:

Hi,


On Thu, 18 Feb 2016 09:11:59 -0200
Andre Guedes <andre.guedes(a)intel.com> wrote:

Hi Daniel,

Quoting Kalowsky, Daniel (2016-02-17 05:09:07)

DEV_NO_SUPPORT seems to cover the concept. Not sure we need a

DEV_NOT_IMPLEMENTED. Or as Peter points out ENOSYS works as well.

Yes, DEV_NO_SUPPORT might cover the concept however it brings another
connotation which is "the hardware actually lacks support" (e.g. the
controller doesn't support that feature) and for that case I think the error
code DEV_INVALID_OP might be more suitable.

Good point. You're alternate point (in another post) of ENOSYS not matching is also valid.

I think ENOSYS would perfectly match what we want here since it means
"Function not implemented" (as Peter pointed in the other reply).

Speaking of which, I was talking to Dirk in the other day and we both agreed
that it would be a good idea we use errno.h codes instead of DEV_* at the
driver's layer. The main points are 1) errno.h is a well-known error convention
which pretty much all developer is familiar with, 2) errno.h codes address what
we need, 3) no need to create new codes such as DEV_NOT_IMPLEMENTED for instance,
and 4) changing the current drivers to use errno.h codes instead of DEV_* is a
feasible task.

A good first step is to redefine DEV_* in terms of -E* error codes :-)

Adding the include of errno.h and the removal of DEV_* can happen
at our leisure :-) The apps will be getting a consistent set of error
codes in any case.

What do you think?

Just so we avoid mixing two different topics, it looks like this deserves a separate RFC.

The original problem I raised on that code review a few weeks ago -- not having a defined return
code to state that a given driver API impl is dummy -- seems to have had some conclusion reached
here already. Looks like adding DEV_NOT_IMPLEMENTED has some appeal in the end. I also support that
meanwhile the errno idea is not discussed.

I think you've convinced me. The challenge now is to make sure it's used appropriately. As we've shown, we'll need to be explicit with why some functions actually need to return DEV_OK or whatever vs DEV_NO_SUPPORT.

Yes, this is the challenge. I volunteer to review and fix what we have
upstream. However, we have to pay attention for this kind of things
while reviewing new patches on Gerrit to ensure they are merged with
the proper return codes.

Agreed

Guidelines, folks. Let's make sure this is documented somewhere so we can just copy&paste a link on
reviews afterwards and people can refer to it when coding.

Great idea! This will help with readability of driver code and if the
app developer actually tries to decode the error they will know where
to get the *meaning*

Thanks for preparing this RFC, by the way!

Regards,
jesus

Thanks,

Andre

Hi Jesus,

Quoting Jesus Sanchez-Palencia (2016-02-18 12:42:07)

Just so we avoid mixing two different topics, it looks like this deserves a separate RFC.

Yes. I already had this in mind and I'm going to send the errno.h RFC later
today.

I was basically replying Daniel's comment and took the opportunity to get an
early feedback from him.

Regards,

Andre

On 02/12/2016 11:38 AM, Mitsis, Peter wrote:

See [Peter]

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: February-12-16 1:37 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: return type of functions passed to DEVICE_INIT()

Folks,

For some reason, the signature of functions passed to the DEVICE_INIT()
<init_fn> parameter has a return type of 'int', but the return value is never
checked within _sys_device_do_config_level(). Some init functions do return an
error code, such as the ARC init code and the bluetooth init routines, but that
just gets ignored.

Question: should we have init functions of return type 'void' then ?
That would shave a few bytes in every init function if we don't have to return a
value.

[Peter] - We generally try to operate under the assumption that failures will not occur.
That being said, we do have some instances where we do check for errors, and some of these are considered fatal.

My take on it is that for Zephyr a failed device initialization should be considered a fatal event.
My expectation is that the Zephyr user will only be enabling relevant (and important) devices to their project.
If one of these devices should fail, then that is a serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to save a few bytes then I would think that it would be better to have the device initialization routines return a failure code and have _sys_device_do_config_level() check for it and invoke the fatal error handler upon the detection of failure. Otherwise we duplicate the overhead of calling the fatal error handler in each device initialization routine.

Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.

How we could/should report this type of error is an open question :-).

Just my two cents.

Cheers,
Ben

--
Benjamin Walsh, SMTS
Wind River Rocket
Zephyr kernel maintainer
www.windriver.com

Hi,


On Thu, 18 Feb 2016 09:11:59 -0200
Andre Guedes <andre.guedes(a)intel.com> wrote:

Hi Daniel,

Quoting Kalowsky, Daniel (2016-02-17 05:09:07)

DEV_NO_SUPPORT seems to cover the concept. Not sure we need a

DEV_NOT_IMPLEMENTED. Or as Peter points out ENOSYS works as well.

Yes, DEV_NO_SUPPORT might cover the concept however it brings another
connotation which is "the hardware actually lacks support" (e.g. the
controller doesn't support that feature) and for that case I think the error
code DEV_INVALID_OP might be more suitable.

Good point. You're alternate point (in another post) of ENOSYS not matching is also valid.

I think ENOSYS would perfectly match what we want here since it means
"Function not implemented" (as Peter pointed in the other reply).

Speaking of which, I was talking to Dirk in the other day and we both agreed
that it would be a good idea we use errno.h codes instead of DEV_* at the
driver's layer. The main points are 1) errno.h is a well-known error convention
which pretty much all developer is familiar with, 2) errno.h codes address what
we need, 3) no need to create new codes such as DEV_NOT_IMPLEMENTED for instance,
and 4) changing the current drivers to use errno.h codes instead of DEV_* is a
feasible task.

What do you think?

Just so we avoid mixing two different topics, it looks like this deserves a separate RFC.

The original problem I raised on that code review a few weeks ago -- not having a defined return
code to state that a given driver API impl is dummy -- seems to have had some conclusion reached
here already. Looks like adding DEV_NOT_IMPLEMENTED has some appeal in the end. I also support that
meanwhile the errno idea is not discussed.

I think you've convinced me. The challenge now is to make sure it's used appropriately. As we've shown, we'll need to be explicit with why some functions actually need to return DEV_OK or whatever vs DEV_NO_SUPPORT.

Yes, this is the challenge. I volunteer to review and fix what we have
upstream. However, we have to pay attention for this kind of things
while reviewing new patches on Gerrit to ensure they are merged with
the proper return codes.

Guidelines, folks. Let's make sure this is documented somewhere so we can just copy&paste a link on
reviews afterwards and people can refer to it when coding.

Thanks for preparing this RFC, by the way!

Regards,
jesus

Thanks,

Andre

Hi Daniel,

Quoting Kalowsky, Daniel (2016-02-17 05:09:07)

DEV_NO_SUPPORT seems to cover the concept. Not sure we need a

DEV_NOT_IMPLEMENTED. Or as Peter points out ENOSYS works as well.

Yes, DEV_NO_SUPPORT might cover the concept however it brings another
connotation which is "the hardware actually lacks support" (e.g. the
controller doesn't support that feature) and for that case I think the error
code DEV_INVALID_OP might be more suitable.

Good point. You're alternate point (in another post) of ENOSYS not matching is also valid.

I think ENOSYS would perfectly match what we want here since it means
"Function not implemented" (as Peter pointed in the other reply).

Speaking of which, I was talking to Dirk in the other day and we both agreed
that it would be a good idea we use errno.h codes instead of DEV_* at the
driver's layer. The main points are 1) errno.h is a well-known error convention
which pretty much all developer is familiar with, 2) errno.h codes address what
we need, 3) no need to create new codes such as DEV_NOT_IMPLEMENTED for instance,
and 4) changing the current drivers to use errno.h codes instead of DEV_* is a
feasible task.

What do you think?

I think you've convinced me. The challenge now is to make sure it's used appropriately. As we've shown, we'll need to be explicit with why some functions actually need to return DEV_OK or whatever vs DEV_NO_SUPPORT.

Yes, this is the challenge. I volunteer to review and fix what we have
upstream. However, we have to pay attention for this kind of things
while reviewing new patches on Gerrit to ensure they are merged with
the proper return codes.

Thanks,

Andre

On Wed, 17 Feb 2016 14:35:24 -0500, Benjamin Walsh wrote:

For some reason, the signature of functions passed to the
DEVICE_INIT() <init_fn> parameter has a return type of 'int', but
the return value is never checked within
_sys_device_do_config_level(). Some init functions do return an
error code, such as the ARC init code and the bluetooth init
routines, but that just gets ignored.

Question: should we have init functions of return type 'void' then
? That would shave a few bytes in every init function if we don't
have to return a value.

We generally try to operate under the assumption that failures will
not occur. That being said, we do have some instances where we do
check for errors, and some of these are considered fatal.

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices
to their project. If one of these devices should fail, then that is
a serious system error and _NanoFatalErrorHandler() should be
invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal
error handler upon the detection of failure. Otherwise we duplicate
the overhead of calling the fatal error handler in each device
initialization routine.

Drivers' initialization routines can use __ASSERT() if they want to
catch an error in a debug build.

I have not received any other feedback w.r.t. this: silence implies
consent ? :)

Fine by me, on both accounts.

For some reason, the signature of functions passed to the
DEVICE_INIT() <init_fn> parameter has a return type of 'int', but
the return value is never checked within
_sys_device_do_config_level(). Some init functions do return an
error code, such as the ARC init code and the bluetooth init
routines, but that just gets ignored.

Question: should we have init functions of return type 'void' then
? That would shave a few bytes in every init function if we don't
have to return a value.

We generally try to operate under the assumption that failures will
not occur. That being said, we do have some instances where we do
check for errors, and some of these are considered fatal.

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices
to their project. If one of these devices should fail, then that is
a serious system error and _NanoFatalErrorHandler() should be
invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal
error handler upon the detection of failure. Otherwise we duplicate
the overhead of calling the fatal error handler in each device
initialization routine.

Drivers' initialization routines can use __ASSERT() if they want to
catch an error in a debug build.

I have not received any other feedback w.r.t. this: silence implies
consent ? :)

Your proposal seems the simplest to me, the only advantage I see on the more complex one is flexibility, presets could provide settings for multiple scenarios rather than on|off.

I would add your observation as a 4th alternative and submit for consideration whether all the complexity previously proposed is worth it.

Folks,

When we start a fiber via the _fiber_start() API family, we don't get
back a handle on the created fiber. The fiber identifier is actually the
start of the fiber's stack. This hasn't been a problem until now since
no API requires a handle on the fiber, except one,
fiber_delayed_start_cancel(): that API is part of a pair, where the
other API, fiber_delayed_start() starts the fiber and returns a handle.

However, Jukka asked me an API could be created that cancels a
fiber_sleep() call, something like fiber_wakeup(). The implementation of
such an API is very simple, but it requires a handle on the fiber we
want to wake up. This in turn requires the signature of the
_fiber_start() family to return a handle to the fiber that gets started.

The signature of _fiber_start() et al. would then change from a void
return type to a void * return type.

Objections, comments, etc ?

Cheers,
Ben

--
Benjamin Walsh, SMTS
Wind River Rocket
Zephyr kernel maintainer
www.windriver.com

Hi,

I have a problem with minnowboard and it's uart (I use btshell sample for
testing and trying to communicate with Bluetooth module using H5 protocol).

The problem is, that there is no transmission on the TX pin of the minnowboard
(checked with logic analyzer) and no matter if the bt module is connected or
not. What is more, the console uart is working perfectly.

I was connecting CTS/RTS pins to module, or to ground, or to nothing in
different configurations - no effect.
Changed supporting of flow control in UEFI - no effect.
Also tried changing UART_1 address and IRQ in Zephyr Kconfig to:
- Port: 0x02f8, IRQ: 3
- Port: 0x03e8, IRQ: 4
- Port: 0x02e8, IRQ: 3
And also no effect.

Minnowboard isn't broken or something, all uarts work with Ubuntu, and almost
all with Fedora (couldn't open only UART1, rest was fine). BT modules are also
fine, they work on minnowboard with ftdi usb/serial converter with Fedora and
Ubuntu.

Any advise on getting UART_1 working with zephyr?

--
BR
Szymon Janc

Hi Dirk,

Quoting Dirk Brandewie (2016-02-12 13:32:31)

In the new model the functions would be required to be implemented, the
RFC included a null implementation for drivers to use if they had no
work to do during suspend/resume. Still a topic for discussion but the
null functions can just return success meaning I have done everything
I need to or can do :-).

Yes, sure. If we can use this 'null' implementation in drivers that don't
properly implement the suspend/resume callbacks (yet), this will fix the
issue I described in the other email.

However, the suspend/resume callbacks were just an example to bring the
discussion about having a "not implemented"-wise error code in device.h.
I didn't review all drivers, but it seems such error code would be suitable
in other situations like the interrupt-related callbacks from the
gpio_pcal9535a.c driver. These callbacks are not implemented yet and we
use DEV_INVALID_OP.

Thanks,

Andre