Date   

Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Tomasz Bursztyka
 

Hi Daniel and Anas,

and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".
The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.
Saving even a minimal amount of bytes is good to consider, as long as it
does not reduce
features etc... and that RFC is actually fixing things.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.
IMO the driver interface is still considered public APIs.
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.
How long are we supposed to support this API 1.0? Can't we drop some of
its specifics in, let's say, 1.5?
The more we will have to support all of it, the less we will be able to
proceed on some interesting changes. :(

Tomasz


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Tomasz Bursztyka
 

Hi Ramesh,

The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
Not sure how the method in the RFC differentiates between critical and
non-critical errors. Isn't the driver also*not* passing on the
non-critical error status to the app by not setting device_api = NULL in
those cases? Then how will the app know that it needs to do something to
correct such non-critical errors?

If this is merely a way to indicate that the driver is in an unusable
error state, then how is it different from critical error? - which is
not expected to happen in production releases.
The idea is to let the driver decide whether it is still functioning or not.
Unusable state is a critical error to me.
A non critical error, means it is still ok to work, thus the driver API
will be set.
If the driver stops at non-critical error and do not set the API, it's
not really a non-critical error then.
(or it's a bug)

I don't see much trouble with that. Up to drivers to decide

And anyway, in 99.9% of the drivers: there will be critical errors only
I guess (unable to get
a device binding, to configure some register...).

Tomasz


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Thomas, Ramesh
 

On Mon, 2016-04-11 at 09:23 -0700, Daniel Leung wrote:
On Mon, Apr 11, 2016 at 09:37:25AM +0200, Tomasz Bursztyka wrote:
Hi Daniel,

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of
initialization functions.
Ok I missed that discussion.
You can follow the link and go to the top message. The idea was first proposed by
Benjamin Walsh to get rid of return values. This RFC was just a tiny part of that.


The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
Not sure how the method in the RFC differentiates between critical and
non-critical errors. Isn't the driver also *not* passing on the
non-critical error status to the app by not setting device_api = NULL in
those cases? Then how will the app know that it needs to do something to
correct such non-critical errors?

If this is merely a way to indicate that the driver is in an unusable
error state, then how is it different from critical error? - which is
not expected to happen in production releases.

really care).
Your RFC patch was not clear about that. It would require to change the
init function signature
and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".
The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.


----------
Daniel Leung


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Nashif, Anas
 

Hi




On 12/04/2016, 00:23, "Daniel Leung" <daniel.leung(a)intel.com> wrote:

and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".
The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.
IMO the driver interface is still considered public APIs.
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.


Anas



----------
Daniel Leung


Re: state of development and participation

Maureen Helm
 

-----Original Message-----
From: Kalowsky, Daniel [mailto:daniel.kalowsky(a)intel.com]
Sent: Wednesday, April 06, 2016 7:28 PM
To: Idupsle <idupsle(a)gmail.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: state of development and participation

-----Original Message-----
From: Idupsle [mailto:idupsle(a)gmail.com]
Sent: Wednesday, April 6, 2016 8:50 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] state of development and participation

Hello,

I'm still wondering about this project. Is it right, that most work is
from intel? I was hoping, that NXP is continuing it's work on it - or
was it only for the early- support?
Having just spent the last few days with NXP at Open IoT / Embedded Linux
Conference, I can say that they are still active on the project. I will let the
member of NXP on the mailing list share their own thoughts about this.
NXP is a founding member of the Zephyr project, so yes we will definitely continue working on it. We're still in the early stages though and will be ramping up in the coming months.

Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core api -
is it wiser to wait a few months? I really would like to contribute a
litte bit in my sparse spare time to get this board a little bit more
usable :)
I'd encourage you to submit such patches. The APIs should no longer be
bouncing around. If they are, please call us out on when it is happening.
What APIs are you most interested in using with the K64?


Re: RFC: Timer/Timeout API

Dmitriy Korovkin
 

On Fri, 8 Apr 2016, Luiz Augusto von Dentz wrote:

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.
I am not quite sure I understand the problem. Kernel keeps the track of
nanokernel timers and timeouts. If needed, each fiber can wait on a
timer (one fiber per timer). Not sure, what is the need for a separate
fiber that runs through the timers.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
Depends on what is needed. If this is a global change (apility for
multiple fibers to wait on one timer, for instance), this should be
global.

- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
As the kernel keeps track of the timers, there may be something else is
needed.

Regards,
/Dmitriy


Re: Building on Windows with MinGW

Carles Cufi
 

Hi Juan,

-----Original Message-----
From: Cruz Alcaraz, Juan M [mailto:juan.m.cruz.alcaraz(a)intel.com]
Sent: Monday, April 11, 2016 18:43
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: RE: Building on Windows with MinGW

Carles,

Carles, thanks for digging into the issue. There is a JIRA report
already reporting this behavior (ZEP-177).
Please follow the development of ZEP-177 to get a resolution to the
issue.
Thanks for the pointer.

I've added my observations to the Jira issue.

Carles


Re: Building on Windows with MinGW

Cruz Alcaraz, Juan M <juan.m.cruz.alcaraz@...>
 

Carles,

Carles, thanks for digging into the issue. There is a JIRA report already reporting this behavior (ZEP-177).
Please follow the development of ZEP-177 to get a resolution to the issue.

-----Original Message-----
From: Cufi, Carles [mailto:Carles.Cufi(a)nordicsemi.no]
Sent: Monday, April 11, 2016 10:23 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Building on Windows with MinGW

Hi there,

I've followed the steps outlined here:

https://www.zephyrproject.org/doc/getting_started/installation_win.html

to compile Zephyr on Windows.

The first problem I encountered was that the regex library could not be
found by MinGW's gcc, so I had to add the following to my .bash_profile:

export CPATH="C:/mingw/msys/1.0/include"
export LIBRARY_PATH="C:/mingw/msys/1.0/lib"

Not sure if this is due to the way one installs MinGW, but it was required for
me.

The second problem I see is that no matter how I configure my build (both
manually or adding my own Makefile.toolchain) the build always fails with an
error similar to:

Error processing
'c:/cygwin64/home/cacu/src/nordic/git/cacu/zp/c:\cygwin64\home\cacu\src
\nordic\git\cacu\zp\arch\x86\soc\atom\Kconfig' #123.

Obviously my git repo lives in
c:\cygwin64\home\cacu\src\nordic\git\cacu\zp.

After digging a bit, I found out that win_process_files in zconf.lex.c_shipped
gets the following path when the error occurs:

c:\cygwin64\home\cacu\src\nordic\git\cacu\zp\arch\x86\soc\atom\Kconfig

which obviously does not exist (I see no "Kconfig" file in x86\soc\atom). Since
there is no wildcard, there is no chance that file is going to be found, and
then win_process_files tries a second path by doing:

env = getenv(SRCTREE);
if (env) {
sprintf(fullname, "%s/%s", env, expanded);
}

But that doesn't work either, since it results in a path concatenation.

It is worth mentioning that the folders that *do* contain a Kconfig file, such
as c:\cygwin64\home\cacu\src\nordic\git\cacu\zp\arch\x86\core\Kconfig,
seem to be processed fine.

Any idea on what could be causing this?

Thanks!

Carles


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Daniel Leung <daniel.leung@...>
 

On Mon, Apr 11, 2016 at 09:37:25AM +0200, Tomasz Bursztyka wrote:
Hi Daniel,

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of
initialization functions.
Ok I missed that discussion.
You can follow the link and go to the top message. The idea was first proposed by
Benjamin Walsh to get rid of return values. This RFC was just a tiny part of that.


The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
really care).
Your RFC patch was not clear about that. It would require to change the
init function signature
and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".
The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.


----------
Daniel Leung


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Building on Windows with MinGW

Carles Cufi
 

Hi there,

I've followed the steps outlined here:

https://www.zephyrproject.org/doc/getting_started/installation_win.html

to compile Zephyr on Windows.

The first problem I encountered was that the regex library could not be found by MinGW's gcc, so I had to add the following to my .bash_profile:

export CPATH="C:/mingw/msys/1.0/include"
export LIBRARY_PATH="C:/mingw/msys/1.0/lib"

Not sure if this is due to the way one installs MinGW, but it was required for me.

The second problem I see is that no matter how I configure my build (both manually or adding my own Makefile.toolchain) the build always fails with an error similar to:

Error processing 'c:/cygwin64/home/cacu/src/nordic/git/cacu/zp/c:\cygwin64\home\cacu\src\nordic\git\cacu\zp\arch\x86\soc\atom\Kconfig' #123.

Obviously my git repo lives in c:\cygwin64\home\cacu\src\nordic\git\cacu\zp.

After digging a bit, I found out that win_process_files in zconf.lex.c_shipped gets the following path when the error occurs:

c:\cygwin64\home\cacu\src\nordic\git\cacu\zp\arch\x86\soc\atom\Kconfig

which obviously does not exist (I see no "Kconfig" file in x86\soc\atom). Since there is no wildcard, there is no chance that file is going to be found, and then win_process_files tries a second path by doing:

env = getenv(SRCTREE);
if (env) {
sprintf(fullname, "%s/%s", env, expanded);
}

But that doesn't work either, since it results in a path concatenation.

It is worth mentioning that the folders that *do* contain a Kconfig file, such as c:\cygwin64\home\cacu\src\nordic\git\cacu\zp\arch\x86\core\Kconfig, seem to be processed fine.

Any idea on what could be causing this?

Thanks!

Carles


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn
- https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch one data type
- https://gerrit.zephyrproject.org/r/1342 : cc2520: Enable hardware filtering all the time
- https://gerrit.zephyrproject.org/r/1339 : Revert "Bluetooth: Fix compare logic in ATT read rsp"
- https://gerrit.zephyrproject.org/r/1338 : drivers/nble: Correct auth configuration for No Input / Output
- https://gerrit.zephyrproject.org/r/1337 : gpio: dw: Activate by default on D2000

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1304 : net: Test random is necessary to use CC2520 as radio driver
- https://gerrit.zephyrproject.org/r/1263 : build: support icx llvm compiler
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1305 : cc2520: Set short address and ieee address from the driver
- https://gerrit.zephyrproject.org/r/1306 : cc2520: Make AUTOACK working
- https://gerrit.zephyrproject.org/r/997 : Bluetooth: BR/EDR: Move up code in conn.c
- https://gerrit.zephyrproject.org/r/999 : Bluetooth: BR/EDR: Initiate encryption on link
- https://gerrit.zephyrproject.org/r/1034 : Bluetooth: BR/EDR: Notify about pairing while JustWorks
- https://gerrit.zephyrproject.org/r/998 : Bluetooth: BR/EDR: Initiate authentication
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server commands with sequence params
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1307 : net: contiki: Enable 802.15.4 auto-ack for null RDC
- https://gerrit.zephyrproject.org/r/1316 : nano_fifo: Fix problem with nano_fifo and timeouts

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1336 : Revert "net: Use TICKS_UNLIMITED if there are no timers"
- https://gerrit.zephyrproject.org/r/1055 : Bluetooth: shell: Use same config for arm and x86 build
- https://gerrit.zephyrproject.org/r/992 : Bluetooth: BR/EDR: Refactor internals of 'Cancel' authentication API
- https://gerrit.zephyrproject.org/r/1332 : Bluetooth: Export helpers for defining buffer pools
- https://gerrit.zephyrproject.org/r/1123 : Bluetooth: BR/EDR: Rename pair method field
- https://gerrit.zephyrproject.org/r/1330 : Bluetooth: Refactor buffer handling for non-host managed buffers


Re: RFC: Timer/Timeout API

Luiz Augusto von Dentz
 

Hi Marcel,

Do you have anything to add? Or is this something that came out while
discussing with Daniel due to my MSR?

On Fri, Apr 8, 2016 at 8:48 PM, Kalowsky, Daniel
<daniel.kalowsky(a)intel.com> wrote:
+ Marcel, as he mentioned some changes to both areas (I think) at OpenIoT.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz(a)gmail.com]
Sent: Friday, April 8, 2016 4:38 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Timer/Timeout API

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
- Where would be the best location in the source tree?

--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Tomasz Bursztyka
 

Hi Daniel,

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of
initialization functions.
Ok I missed that discussion.

The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
really care).
Your RFC patch was not clear about that. It would require to change the
init function signature
and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".

Tomasz


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1330 : Bluetooth: Refactor buffer handling for non-host managed buffers
- https://gerrit.zephyrproject.org/r/1332 : Bluetooth: Export helpers for defining buffer pools

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1334 : Bluetooth: L2CAP: Fix logs to account for BR/EDR signaling channel
- https://gerrit.zephyrproject.org/r/1335 : Bluetooth: L2CAP: Store BR/EDR fixed channel mask per channel
- https://gerrit.zephyrproject.org/r/1333 : Bluetooth: L2CAP: Fix missing line termination
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1310 : Bluetooth: BR/EDR: Refactor bt_l2cap_connected handler
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CAP CID limits
- https://gerrit.zephyrproject.org/r/1309 : Bluetooth: BR/EDR: Add register routine for L2CAP fixed channel
- https://gerrit.zephyrproject.org/r/1308 : Bluetooth: Rename bt_l2cap_fixed_chan_register()


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-186] ISSM - ARC support
https://jira.zephyrproject.org/browse/ZEP-186

UPDATED JIRA items within last 24 hours: 2
[ZEP-16] Support TI CC2550 SPI based 802.15.4 chip
https://jira.zephyrproject.org/browse/ZEP-16
[ZEP-177] Windows build with MinGW
https://jira.zephyrproject.org/browse/ZEP-177

CLOSED JIRA items within last 24 hours: 3
[ZEP-175] (Fixed) send daily email to developer mailing lists with changes in gerrit
https://jira.zephyrproject.org/browse/ZEP-175
[ZEP-179] (Fixed) Create a digest of JIRA items
https://jira.zephyrproject.org/browse/ZEP-179


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1332 : Bluetooth: Export helpers for defining buffer pools
- https://gerrit.zephyrproject.org/r/1330 : Bluetooth: Refactor buffer handling for non-host managed buffers
- https://gerrit.zephyrproject.org/r/1325 : power_mgmt: Provide APIs for devices to signal busy to PM policy mgr
- https://gerrit.zephyrproject.org/r/1329 : openocd: make openocd variables overridable from env
- https://gerrit.zephyrproject.org/r/1313 : samples: A test app for spi flash
- https://gerrit.zephyrproject.org/r/1322 : doc: Fixed structure in collab guide
- https://gerrit.zephyrproject.org/r/1321 : doc: create subsystem section
- https://gerrit.zephyrproject.org/r/1320 : doc: move device driver to a new section
- https://gerrit.zephyrproject.org/r/1327 : doc: fix wording in device documentation
- https://gerrit.zephyrproject.org/r/1323 : docs: remove notes from bluetooth document
- https://gerrit.zephyrproject.org/r/1328 : doc: make naming conventions apply to none kernel functions
- https://gerrit.zephyrproject.org/r/1326 : power_mgmt: Sample usage of device_xxx__busy() APIs
- https://gerrit.zephyrproject.org/r/1316 : nano_fifo: Fix problem with nano_fifo and timeouts

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CAP CID limits
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1308 : Bluetooth: Rename bt_l2cap_fixed_chan_register()
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1309 : Bluetooth: BR/EDR: Add register routine for L2CAP fixed channel
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1324 : Makefile: Fix linking order of libraries
- https://gerrit.zephyrproject.org/r/1331 : benchmark: Remove trailing whitespaces.
- https://gerrit.zephyrproject.org/r/1315 : x86.ini: increase arduino_101 priority
- https://gerrit.zephyrproject.org/r/1319 : sanitycheck: fix test names to be same as before
- https://gerrit.zephyrproject.org/r/1318 : sanitycheck: be smarter about scanning for test cases
- https://gerrit.zephyrproject.org/r/1317 : sanitycheck: add ability to use arbitrary report for comparison
- https://gerrit.zephyrproject.org/r/1314 : arduino_101: defconfig: Limit UART defaults for Bluetooth H:4 driver
- https://gerrit.zephyrproject.org/r/1312 : script: jira query: add URL in message
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/1161 : doc: Add sensor section in API documentation
- https://gerrit.zephyrproject.org/r/1311 : gpio: dw: add support for D2000 board
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default CFLAGS
- https://gerrit.zephyrproject.org/r/1170 : galileo: Enable PCI enumeration
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1283 : script: query jira: removed issue type and priority from report.
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1282 : sanitycheck: parallelize binary size calculations


Re: RFC: Timer/Timeout API

Kalowsky, Daniel <daniel.kalowsky@...>
 

+ Marcel, as he mentioned some changes to both areas (I think) at OpenIoT.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz(a)gmail.com]
Sent: Friday, April 8, 2016 4:38 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Timer/Timeout API

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
- Where would be the best location in the source tree?

--
Luiz Augusto von Dentz


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-185] Nanokernel FIFO does not handle timeouts correctly

UPDATED JIRA items within last 24 hours: 1

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0

7861 - 7880 of 8331