Date   

API meeting: agenda

Carles Cufi
 


Re: large data arrays within .c source

Nashif, Anas
 

Hi,

I suggest reviewing this document which will be discussed in the TSC this week:

 

https://docs.google.com/document/d/1heqcv7dzGvM5rA9xpTMW3kyKJLpZsl2Gjsmr5eqBje8/edit

 

Look at the “Allowed types” section.

 

Anas

 

From: devel@... <devel@...> on behalf of Keith.Wheeler@... <Keith.Wheeler@...>
Date: Friday, January 7, 2022 at 4:46 PM
To: devel@... <devel@...>
Subject: [Zephyr-devel] large data arrays within .c source

Good day,

 

Our board support requires a .c file that is essentially a large data array.  If the source file includes appropriate open source wording in the comments, is this acceptable?

 

Thank you,

 

-Keith Wheeler

Principal Engineer, Infineon


Re: large data arrays within .c source

Jack Rosenthal
 

I think in general, we should push vendors away from binary blobs if we can, which would help keep the contribution guidelines to a high standard. Simply rejecting the vendors' blobs during the code review process will force them to reconsider how to submit source code instead of a binary.

We can learn from the coreboot project, which has been trying to define their own policies around binary blobs recently.

On Mon, Jan 10, 2022 at 8:56 AM Rasmussen, Torsten via lists.zephyrproject.org <torsten.rasmussen=nordicsemi.no@...> wrote:

Hi,

I wonder how an array containing binary data created from source code with an unknown license can be said to conform to this:
https://docs.zephyrproject.org/latest/contribute/external.html#software-license

> Integrating code into the Zephyr Project from other projects that use a license other than the Apache 2.0 license
> needs to be fully understood in context and approved by the Zephyr governing board, as described in the
> Zephyr project charter. The board will automatically reject licenses that have not been approved by the
> Open Source Initiative (OSI). See the Submission and review process section for more details.

/torsten


Now: Zephyr: Toolchain Working Group - 01/10/2022 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr: Toolchain Working Group

When:
01/10/2022
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Re: large data arrays within .c source

Rasmussen, Torsten
 

Hi,

I wonder how an array containing binary data created from source code with an unknown license can be said to conform to this:
https://docs.zephyrproject.org/latest/contribute/external.html#software-license

> Integrating code into the Zephyr Project from other projects that use a license other than the Apache 2.0 license
> needs to be fully understood in context and approved by the Zephyr governing board, as described in the
> Zephyr project charter. The board will automatically reject licenses that have not been approved by the
> Open Source Initiative (OSI). See the Submission and review process section for more details.

/torsten


Re: large data arrays within .c source

Keith.Wheeler@...
 

Carles,

 

Our board has a separate connectivity (WiFi/BT) radio IC. The array is patch/executable required by the external device, which must be loaded on to the external device by the host processor.

 

-Keith

 

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, January 10, 2022 2:32 AM
To: Wheeler Keith (CYSC CSS ICW SW T 1) <Keith.Wheeler@...>; devel@...
Subject: RE: large data arrays within .c source

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

Hi Keith,

 

What does the data array represent or contain?

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Keith.Wheeler via lists.zephyrproject.org
Sent: 07 January 2022 22:20
To: devel@...
Subject: [Zephyr-devel] large data arrays within .c source

 

Good day,

 

Our board support requires a .c file that is essentially a large data array.  If the source file includes appropriate open source wording in the comments, is this acceptable?

 

Thank you,

 

-Keith Wheeler

Principal Engineer, Infineon


Event: Zephyr: Toolchain Working Group - 01/10/2022 #cal-reminder

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Reminder: Zephyr: Toolchain Working Group

When:
01/10/2022
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

An RSVP is requested. Click here to RSVP

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Re: large data arrays within .c source

Carles Cufi
 

Hi Keith,

 

What does the data array represent or contain?

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Keith.Wheeler via lists.zephyrproject.org
Sent: 07 January 2022 22:20
To: devel@...
Subject: [Zephyr-devel] large data arrays within .c source

 

Good day,

 

Our board support requires a .c file that is essentially a large data array.  If the source file includes appropriate open source wording in the comments, is this acceptable?

 

Thank you,

 

-Keith Wheeler

Principal Engineer, Infineon


large data arrays within .c source

Keith.Wheeler@...
 

Good day,

 

Our board support requires a .c file that is essentially a large data array.  If the source file includes appropriate open source wording in the comments, is this acceptable?

 

Thank you,

 

-Keith Wheeler

Principal Engineer, Infineon


Event: Zephyr: Power Management Sync - 01/06/2022 #cal-reminder

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Reminder: Zephyr: Power Management Sync

When:
01/06/2022
11:00am to 12:00pm
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:


________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,677440320# United States, Orlando
Phone Conference ID: 677 440 320#
 
________________________________________________________________________________


Event: Zephyr Project: Dev Meeting - 01/06/2022 #cal-reminder

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Reminder: Zephyr Project: Dev Meeting

When:
01/06/2022
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dev Review Agenda - Jan 6, 2022

Maureen Helm
 

Hi again,

 

I messed up the GitHub filter and didn’t see any Issues with the dev-review label (I only saw PRs). Here’s an updated agenda and filter:

 

 

All open PRs/Issues with the dev-review label:

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aopen+label%3Adev-review+sort%3Aupdated-desc

 

 

From: devel@... <devel@...> On Behalf Of Maureen Helm
Sent: Wednesday, January 5, 2022 4:12 PM
To: devel@...
Subject: [Zephyr-devel] Dev Review Agenda - Jan 6, 2022

 

Hi everyone,

 

Happy New Year! Starting this week, I’m taking over Dev Review meeting responsibilities from Kumar. We’ll continue the dev-review label in GitHub to tag PRs or Issues for discussion. Please also try to ensure that relevant stakeholders (i.e., contributors, collaborators, or maintainers for the impacted area or subsystem) can attend when you have a topic on the agenda. Let me know if you need help with this.

 

Agenda for Jan 6, 2022:

 

Teams meeting:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZmMwZDAwMjQtNDQxOC00ZmI3LWEwNzYtNjc2OWI5ZmE0ZjIw%40thread.v2/0?context=%7b

 

Minutes:

https://docs.google.com/document/d/13YxmRsaZ7u0tarhQ31Ca_MeHcg9M9e_GyHJqSYfnSpQ

 

All open PRs/Issues with the dev-review label:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Aopen+sort%3Aupdated-desc+label%3Adev-review

 

Regards,

Maureen


Re: #gettingstartedguide #gettingstartedguide

Graydon, Connor Jameson <connor.graydon@...>
 

If the Windows long path doesn’t prove to be the issue, you might check your west.yml and make sure that the repo is listed in that manifest. The “ERROR: update failed for project trusted-firmware-m” bit looks a lot like what you would see if the repo info isn’t present in the west.yml file or has an incorrect URL/SHA, etc.

 

- name: trusted-firmware-m

      revision: 7c88781953ce7146878bd8bd724e175fdbc298c5

      path: modules/tee/tf-m/trusted-firmware-m

 

Another potential issue could be some kind of git/github creds issue. Occasionally refreshing git creds will fix this kind of thing, too.

 

Connor

 

 

From: devel@... <devel@...> on behalf of Derek Snell <derek.snell@...>
Date: Wednesday, December 29, 2021 at 9:13 AM
To: devel@... <devel@...>
Subject: Re: [Zephyr-devel] #gettingstartedguide

Hi Srikanth,

 

I don’t know if this is causing your problem.  But I see your Windows path is somewhat long at C:/Users/vimel/SRIKANTH/my_workspace/projects/Projects_2021/ZEPHYR/SOFTWARE/zephyrproject.  I know Windows sometimes has issues with long paths.  Have you tried installing Zephyr in a different directory that has a shorter path?

 

 


Dev Review Agenda - Jan 6, 2022

Maureen Helm
 

Hi everyone,

 

Happy New Year! Starting this week, I’m taking over Dev Review meeting responsibilities from Kumar. We’ll continue the dev-review label in GitHub to tag PRs or Issues for discussion. Please also try to ensure that relevant stakeholders (i.e., contributors, collaborators, or maintainers for the impacted area or subsystem) can attend when you have a topic on the agenda. Let me know if you need help with this.

 

Agenda for Jan 6, 2022:

 

Teams meeting:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZmMwZDAwMjQtNDQxOC00ZmI3LWEwNzYtNjc2OWI5ZmE0ZjIw%40thread.v2/0?context=%7b

 

Minutes:

https://docs.google.com/document/d/13YxmRsaZ7u0tarhQ31Ca_MeHcg9M9e_GyHJqSYfnSpQ

 

All open PRs/Issues with the dev-review label:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Aopen+sort%3Aupdated-desc+label%3Adev-review

 

Regards,

Maureen


Mesh Node with a BLE scanner

Omar Morceli
 

Hi 

We are trying to scan BLE beacons with a Bluetoorh Mesh Node.
We have added the part of the code of the BLE scanner and we get this error code.
Scanning failed to start (err -11)

thanks


Re: API documentation convention

Gerard Marull Paretas
 

Multiple issues have been raised over time related to this topic. I opened this one ~1y ago: https://github.com/zephyrproject-rtos/zephyr/issues/30466

So to summarize, there are no established rules now. Answers to your questions below:

On Wed, Jan 5, 2022 at 1:14 AM Keith Short via lists.zephyrproject.org <keithshort=google.com@...> wrote:
Is there a preferred convention for documenting APIs?

As a typical example, a driver provides an API structure of function pointers that is filled out by each driver instance.  The driver then provides public routines that simply wraps the function pointers.

e.g.
struct my_driver_api {
    int (*init)(const struct device *dev);
}
static inline my_init(const struct device *dev)
{
    return api->init(dev);
}

My specific questions:
1. Should the driver create typedefs for all the function pointers in struct my_driver_api?  This seems to be common, but there are counter examples (uart.h)

IMO typedefs are redundant and could be deleted. They're likely a result of copy & paste.
 
2. If typedefs are created, should the typedef  or the public routine, or both get documented? i2c.h documents only the public API, not the typedef, pwm.h documents both.

I think that both typedefs and the struct holding the API ops are really internal details that should not be rendered in the Doxygen output. So I'd vote for just documenting the API calls.
 

Regards,
Keith



--

Gerard Marull-Paretas
Teslabs Engineering S.L.
teslabs.com T. +34 622 321 312

CONFIDENTIALITY NOTICE:
The contents of this email message and any attachments are intended solely for the addressee(s)
and may contain confidential and/or privileged information and may be legally protected from
disclosure. If you are not the intended recipient of this message or their agent, or if this message
has been addressed to you in error, please immediately alert the sender by reply email and then
delete this message and any attachments. If you are not the intended recipient, you are hereby
notified that any use, dissemination, copying, or storage of this message or its attachments is
strictly prohibited. 


API documentation convention

Keith Short
 

Is there a preferred convention for documenting APIs?

As a typical example, a driver provides an API structure of function pointers that is filled out by each driver instance.  The driver then provides public routines that simply wraps the function pointers.

e.g.
struct my_driver_api {
    int (*init)(const struct device *dev);
}
static inline my_init(const struct device *dev)
{
    return api->init(dev);
}

My specific questions:
1. Should the driver create typedefs for all the function pointers in struct my_driver_api?  This seems to be common, but there are counter examples (uart.h)
2. If typedefs are created, should the typedef  or the public routine, or both get documented? i2c.h documents only the public API, not the typedef, pwm.h documents both.

Regards,
Keith


Event: Zephyr Project: APIs - 01/04/2022 #cal-reminder

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Reminder: Zephyr Project: APIs

When:
01/04/2022
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Event: Zephyr: Networking Forum - 01/04/2022 #cal-reminder

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Reminder: Zephyr: Networking Forum

When:
01/04/2022
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: tsc@...

An RSVP is requested. Click here to RSVP

Description:


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 458 216 365#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 

261 - 280 of 8574