That's pretty much what I talked about - that with new requirements and
challenges, we may find out that a well-known and proven API like BSD Sockets
is a very good way to address them, instead of continuing to add complexity to
existing adhoc APIs.

What I stated is that when faced with an existing Zephyr API that works only in supervisor mode, rather than do a parallel implementation in user mode, first see if the C library already provides a suitable equivalent.
I don't know if this is a valid comparison to whatever your agenda is with BSD sockets API, my feeling is that it isn't, but at any rate I am strictly neutral on that matter. You need to talk to Jukka.

And above you write about protecting kernel from userspace, but is there a
requirement to protect one userspace entity (a thread in our case, as we don't
support processes) from another? I hope there's, because it doesn't make much
sense to go so long way of kernel vs userspace separation and don't think about
task separation. Just imagine that the could be a thread running OTA, and
another thread running an application level 3rd-party lib. We don't want
vulnerability in the latter to compromise OTA process.

You're not going to believe this, but we did actually consider this situation.
The memory domain APIs exist for this purpose. User threads otherwise only have access to their own stack. They are in-tree and documented, although only working on ARM at the moment.

Andrew

Hello,

A usecase (one of many): I want to see what network interface structures
go into my Zephyr binary. Of course, I look at the linker map file,
and ... see nothing:

net_if 0x000000000041fa80 0x2a0 load address 0x00000000000150bc
0x000000000041fa80 __net_if_start = .
*(.net_if.*)
.net_if.data 0x000000000041fa80 0x2a0 drivers/built-in.o
*(SORT(.net_if.*))
0x000000000041fd20 __net_if_end = .

That's because netif structures are defined as static, and GNU linker
takes that as an incentive to conceal them from the map file. This
issue was reported few years ago as
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 with no
feedback, so apparently nothing is going to happen.


Proposal:

Let's have

#define STATIC static

And use STATIC everywhere a static var is defined. This way, it can be
redefined in one place to produce a relevant map file (let's also have
unique names for all variables, yeah).


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi,

I have been thinking about different ways to add persistent storage to
bluetooth mesh. I would like to add this with as few changes to the
library as possible. I would store the data in flash using a
handle-value method.

I am however doubting the best way to trigger the writing to flash:

Option 1: trigger a writing to flash directly in the existing routines.
Option 2: add a "needs_flashing" variable to the structures, I would
add these to bt_mesh_elem, bt_mesh_cfg,(bt_mesh_health),
bt_mesh_model, bt_mesh_net, bt_mesh_friend, bt_mesh_lpn,
bt_mesh_app_key, bt_mesh_subnet,(bt_mesh_rpl). And starting a loop in
idle time checking for items that need flashing.

My preference goes to option 2, but my experience is limited, so if
someone has ideas about this please comment.

Kind regards,

Jehudi

Hello Andrew,

On Wed, 11 Oct 2017 18:53:24 +0000
"Boie, Andrew P" <andrew.p.boie@...> wrote:

There has not been any public talk in mailing list about
userspace/kernel separation and how it affects IP stack etc. so
it is a bit difficult to say anything about this.

That's true, but we can/should think how it may be affected, or
we'll be caught in the cold water with them, and may come up with
random on-spot designs to address such future requirements, instead
of something well thought out.

The userspace work has progressed to the point where we have enough
confidence in the API design to open up the design discussion to a
larger audience; until now enough things have been in flux (or
uncertain) such that we've kept the discussion to the working group
we established for it.

What we are trying to do is get something feature-complete into the
tree for the upcoming 1.10 release, with partial test case coverage
and initial documentation, on an 'experimental' basis; i.e. APIs and
policies are subject to change. Then polish everything up for the
1.11 release, which would be the official debut of this feature.

I have to admit my knowledge of the network stack is quite poor, but
broadly speaking here are a set of slides recently drafted which goes
into some detail about what sort of kernel objects are accessible
from user threads and the sort of restrictions they have. We expect
to expose a subset of existing kernel APIs to user threads, and all
driver APIs which don't involve registration of callbacks. Please
feel free to leave comments in the document, or on this list.

https://docs.google.com/presentation/d/195ciwFwv7s0MX4AvL0KFB1iHm1_gRoXmn54mjS5fki8/edit?usp=sharing

Thanks for sharing these. What caught my attention is "No good way to
assert validity of k_mem_block object passed to k_mem_pool_free() - Just
tell userspace to use heap memory APIs in newlib! No need to re-invent
the C library..."

That's pretty much what I talked about - that with new requirements and
challenges, we may find out that a well-known and proven API like BSD
Sockets is a very good way to address them, instead of continuing to
add complexity to existing adhoc APIs.

I suspect the biggest implication for the network stack is that it
uses registration of callbacks heavily, and it's forbidden to allow
user threads to directly register callbacks that run in supervisor
mode. But you can get around this (for example) by having the
callback do minimal processing of the incoming data and signal a
semaphore to have a user mode worker thread do the rest of the work.

That's half of the work BSD Sockets do - they put network packets as
delivered via a callback into per-socket fifo.

We are also looking into supporting user-mode workqueues. We also
don't (yet) have a clear picture on what support for k_poll APIs we
will have for userspace.

There's also the question of memory buffers, there would need to be
some care taken that any buffers used by the stack that are exposed
to the application contain purely data and no internal data
structures private to the kernel. This constraint is why we don't
provide system call interfaces to k_queue APIs.

net_pkt's and net_buf's as used by native networking API do share this
problem - they have internal kernel data. Not only that, they are also
allocated from the pool, and are small objects, which can't be
protected by MPU or MMU individually. Which means that one application
could have access/corrupt networking data for other apps.

And above you write about protecting kernel from userspace, but is
there a requirement to protect one userspace entity (a thread in our
case, as we don't support processes) from another? I hope there's,
because it doesn't make much sense to go so long way of kernel vs
userspace separation and don't think about task separation. Just
imagine that the could be a thread running OTA, and another thread
running an application level 3rd-party lib. We don't want
vulnerability in the latter to compromise OTA process.

The solution to the problem is well known - don't try to export
kernel-level object (like network buffers) to userspace, just copy
*data* there as needed. That's 2nd part of what BSD Sockets do.

Ideally in the fullness of time, we could migrate some parts of the
network protocol stack to run in user mode, which I think would
enhance the security of the system.

At the moment, current implementation effort is centered around
getting our test cases running in user mode, and getting started on
the formal documentation.

HTH,
Andrew

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hello,

On Thu, 19 Oct 2017 03:26:09 +1300
Hui Yie Teh <hteh703@...> wrote:

Hi,

I am trying to get the current time using the following:

time_t rawtime;

struct tm *info;
time( &rawtime );
info = localtime( &rawtime );
printf("Current local time and date: %s", asctime(info));

However, this is giving me an error on Qemu:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x05252ff4

Did you try to run your app under debugger and see what happens there?

Is there a reason for this? Also, is there another way to get the
current time of the system in Zephyr?

Any help would be much appreciated.

Cheers,
Yie

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

On Oct 18, 2017, at 10:21 AM, Li, Jun R <jun.r.li@...> wrote:

Hi,
While I debug my application based on Zephyr, sometimes Fatal faults could happen on a specific thread, with the messages like below:

shell> ***** BUS FAULT *****
Executing thread ID (thread): 0x20001814
Faulting instruction address: 0x800ed96
Precise data bus error
Address: 0x746e65d2
Imprecise data bus error
Fatal fault in thread 0x20001814! Aborting.


I’m wondering if there is any macro I can enable to get more information output, like caller stack list at the moment when the crash happens?

Thank you!

Jun Li

This is something we need to implement on the various arch’s. Been wanting that myself.

- k

Hi Johan,

On Tue, 2017-10-17 at 21:39 +0300, Johan Hedberg wrote:

Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:

More ...

In looking at the log, it appears that the beacon_complete callback
never gets called from bt_mesh_adv_send. So, net_buf_unref never
gets
called and we run out of buffers.

It's still a mystery how that's related to the patch you found with
bisect. Did you try the v2 of my patch? The first version will not
make
any difference to you since it had the missing unref in a branch
that's
never taken in your case.

Johan

I looked at the recent commits and didn't see any connection either.That's why I gave up and did the bisect.

Is it possible that because the buffer wasn't released, subsequent
commands queued up and eventually used up all available buffers?

Steve

Thanks for the suggestions / information. I'll begin evaluating these.
This may be a great interim solution until the switch to CMake is made
and fully tested out.

- Pushpal

On Tue, Oct 17, 2017 at 11:03 AM, Yannis Damigos
<giannis.damigos@...> wrote:

On 10/17/2017 08:03 PM, Pushpal Sidhu wrote:

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.

Hi,

I am using the eclipse CDT standalone debugger without any issues.

Yannis


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

Hi all,


I have sent a proposal for a new HTTP API at https://github.com/zephyrp
roject-rtos/zephyr/pull/4243 so in order to get more comments and
feedback I am sending this mail.

The PR#4243 introduces a new HTTP API that differs a bit from the
current HTTP API:

* The new API is built on top of net-app API. This means that HTTPS
support can be removed from HTTP library as that is already provided by
net-app API. This will save some memory as almost duplicate code in
net-app and current HTTP API can be removed.

* Timeout handling is removed from HTTP API as that was cumbersome to
use and it should be handled by application anyway.

* Server HTTP handler callbacks are defined and handled differently
compared to current API.

* Current version in PR#4243 is still missing HTTP client API but I
will add that before the old API is removed.

* The PR#4243 still has the old HTTP API as is but it would be
removed/deprecated in next version of that patch set.

* Related PR#1271 adds websocket support that is built on top of this
new HTTP API. There is also PR#1311 that will then add console over
websocket support, this would mean that it would be possible to have
console in your HTTP browser.

I looked if it would be possible to keep the current HTTP API but there
were many changes needed so the new API is not compatible with it.
Changes are not too big but modifications are needed in application
side.

Feedback/comments?


Cheers,
Jukka

Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:

More ...

In looking at the log, it appears that the beacon_complete callback
never gets called from bt_mesh_adv_send. So, net_buf_unref never gets
called and we run out of buffers.

It's still a mystery how that's related to the patch you found with
bisect. Did you try the v2 of my patch? The first version will not make
any difference to you since it had the missing unref in a branch that's
never taken in your case.

Johan

On Tue, 2017-10-17 at 21:23 +0300, Johan Hedberg wrote:

Hi Steve,

On Tue, Oct 17, 2017, Johan Hedberg wrote:

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing
cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to
"n" in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could
you
please try the attached patch (while keeping
CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Here's version 2. The first attempt didn't take the account the jump
to
a label in the success case. So ignore the earlier and test this one,
please.

Johan

This patch fixed it.

Thanks,

Steve

Hi Johan,

On Tue, 2017-10-17 at 21:08 +0300, Johan Hedberg wrote:

Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing
cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n"
in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could you
please try the attached patch (while keeping CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Johan

More ...

In looking at the log, it appears that the beacon_complete callback
never gets called from bt_mesh_adv_send. So, net_buf_unref never gets
called and we run out of buffers.

Steve

Hi Steve,

On Tue, Oct 17, 2017, Johan Hedberg wrote:

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n" in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could you
please try the attached patch (while keeping CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Here's version 2. The first attempt didn't take the account the jump to
a label in the success case. So ignore the earlier and test this one,
please.

Johan