Date   

Cancelled Event: Zephyr: Power Management Sync - Thursday, December 16, 2021 #cal-cancelled

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

Cancelled: Zephyr: Power Management Sync

This event has been cancelled.

When:
Thursday, December 16, 2021
11:00am to 12:00pm
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams

Organizer: devel@...

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: Power Management Sync - 12/16/2021 #cal-reminder

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

Reminder: Zephyr: Power Management Sync

When:
12/16/2021
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#
 
________________________________________________________________________________


Re: MISRA

Simon Glass <sjg@...>
 

Hi Abramo,

On Thu, 16 Dec 2021 at 05:44, Abramo Bagnara <abramo.bagnara@...> wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
On Sun, 12 Dec 2021, Abramo Bagnara wrote:

Who in its right mind will believe that sprinkling typecasts around
would make the code any safer and understandable? And that's not
mentioning those _double_ typecasts being added too!!! We should instead
aim for cast _reduction_ to let the compiler warn more about type
mismatches and air the code, not add new ones!

Note: Sometimes double casts are necessary, but we do hide them behind
special accessors.
In the specific, double casts are needed in two situations:

1) A char argument to ctype predicates should be first converted to
unsigned char (as the C standard requires) and then converted to
int to avoid mixing of signed and unsigned. Said that, nothing
prevents us from using helpers that accept char argument or to
embed such double casts in, e.g.,

#define CTYPE_CHAR(c) ((int)(unsigned char)(c))
Unless we find a good place for this macro I'd be forced to leave double
cast. If it is preferred I can add a line of documentation before each
occurence.

And a real kicker is this change:

- * @return 0 on success, nonzero on failure
+ * @return false on success, true on failure

Who really thinks that the above is idiomatic and an improvement in code
understandability? It is not that MISRA does require it in this
particular case, but it certainly did skew the mindset of the person who
did that change.
I'd like very much you take a look to

https://github.com/Abramo-Bagnara/zephyr/commit/87a42d4185828fb1e651604b8ee878063fb6b08a

so to be sure I have intercepted correctly the community expectations.

Of course I cannot decide if the community wanted API is to return a
bool or to possibly return a nonzero error code, but if the intention is
the latter the commit accomplish that uniformingly and keeps integer and
boolean separate.
I think Nicolas makes some good points here.

Zephyr code is too different from Linux style for my liking, e.g. the
strange {} around single-line statements.

Things like 'if (rc != 0)' worsen readability also.

CTYPE_CHAR()...oh please no. Macros make the code harder to read. See
what Nicolas wrote, but if you must cast, cast.

Regards,
Simon


--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...





Event: Zephyr Project: Dev Meeting - 12/16/2021 #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When:
12/16/2021
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: MISRA

Abramo Bagnara
 

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
On Sun, 12 Dec 2021, Abramo Bagnara wrote:

Who in its right mind will believe that sprinkling typecasts around
would make the code any safer and understandable? And that's not
mentioning those _double_ typecasts being added too!!! We should instead
aim for cast _reduction_ to let the compiler warn more about type
mismatches and air the code, not add new ones!

Note: Sometimes double casts are necessary, but we do hide them behind
special accessors.
In the specific, double casts are needed in two situations:

1) A char argument to ctype predicates should be first converted to
unsigned char (as the C standard requires) and then converted to
int to avoid mixing of signed and unsigned. Said that, nothing
prevents us from using helpers that accept char argument or to
embed such double casts in, e.g.,

#define CTYPE_CHAR(c) ((int)(unsigned char)(c))
Unless we find a good place for this macro I'd be forced to leave double cast. If it is preferred I can add a line of documentation before each occurence.

And a real kicker is this change:

- * @return 0 on success, nonzero on failure
+ * @return false on success, true on failure

Who really thinks that the above is idiomatic and an improvement in code
understandability? It is not that MISRA does require it in this
particular case, but it certainly did skew the mindset of the person who
did that change.
I'd like very much you take a look to

https://github.com/Abramo-Bagnara/zephyr/commit/87a42d4185828fb1e651604b8ee878063fb6b08a

so to be sure I have intercepted correctly the community expectations.

Of course I cannot decide if the community wanted API is to return a bool or to possibly return a nonzero error code, but if the intention is the latter the commit accomplish that uniformingly and keeps integer and boolean separate.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...


Dev-review Agenda (Dec 16, 2021)

Kumar Gala
 

Agenda for this week's Dev-Review meeting:

Add iomux rt driver
- https://github.com/zephyrproject-rtos/zephyr/pull/40880

shields: add generic shield to use CDC ACM UART as backend
- https://github.com/zephyrproject-rtos/zephyr/pull/40645

Modularisation and Restructuring of Documentation
- https://github.com/zephyrproject-rtos/zephyr/issues/33725

and any other topics people might have.

- k


Re: MISRA

Nicolas Pitre <nico@...>
 

On Wed, 15 Dec 2021, Abramo Bagnara wrote:

Il 15/12/21 19:50, Nicolas Pitre ha scritto:
I appreciate your points, and similarly for a few others before yours,
but I think they are missing the point.

No one is against virtue.

Everybody wants the code base to be more consistent, more secure, etc.

But mechanically making the code MISRA compliant doesn't achieve that.

I persist in insisting that adding any more typecasts to a codebase
makes it worse. Typecasts should be _removed_ as much as possible, not
added. Thinking about how to avoid a cast produces better code almost
all the time. I would hardly trust "compliant" code for safety critical
applications if compliance came about due to added typecasts.
Are you really arguing that a commented explicit cast (for non obviously
value-preserving conversion) is worse than an implicit cast?
Absolutely! This is a great example of papering over what is most likely
a flaw in the code. Instead of questioning the fundamental of such
non-preserving conversion, the added cast gives the impression that the
code is legitimate while it most likely isn't. If there is a scanning
tool that spots those occurrences then great. But making them invisible
to the tool with typecasts is worse than doing nothing about it.

Avoiding so called "undefined" syntax when all existing compiler
implementations handle many of them just fine is stupid. Usually there
is a couple reasons why compilers still implement some "undefined"
behaviors: it is totally logical, uncontroversial, and also useful by
making the code clearer and easier to maintain. Instead of banning them
outright, we should instead implement a test safeguarding our reliance
on them.
Are you taking in account that although you can write tests for compiler
*extensions* (defining otherwise undefined behaviors), you definitely can not
write tests for compiler undefined and unspecified behaviors?
Extensions if you wish, although I can't find any extension in the gcc
manual that documents arithmetic operations on NULL pointers for
example, or more precisely typed pointers that may happen to test as
NULL. Yet this can easily be tested.

Incidentally, most dubious and truly undefined compiler behaviors tend
to exhibit themselves ... with the use of typecasts.

So let's stop thinking that XYZ conformance automatically makes the code
intrinsicly better. It doesn't. It may bring a false sense of security
though.
IMHO you are victim of an huge misunderstanding: the aim is *only*
better code quality and conformance is exclusively a mean to achieve
that.
Maybe *you* get it, but I'm under the impression that this is not fully
understood by some people/corporations that make it an acceptance
requirement. Therefore that paragraph of mine above was aimed at them.

When a specific instance of conformance to whatever rule hurts code quality it
should never been done, who says otherwise prove it does not know XYZ
(supposing it is a sane coding standard, like MISRA is).
Amen !

If you are able to present a single non-deviable MISRA rule that hurts code
quality and has been chosen for Zephyr community please present it, otherwise
we risk to talk about gut feelings.
I did. Twice and a half so far.

I'm not invested in the MISRA spec though, so pardon me if I didn't
discriminate on deviablility.

Similarily if you are able to present a single deviable MISRA rule that in
*any* instance hurts code quality/verificability/readability/understanding
and/or has no point to exists please talk about that under a pure technical
point of view.
Hopefully my arguments were technical enough.

In summary, I believe that to keep repeating "XYZ conformance stinks" does not
help.
It stinks when those things become political for commercial or similar
reasons. Personally I'm only interested in a technical debate.


Nicolas


Re: MISRA

Abramo Bagnara
 

Il 15/12/21 19:50, Nicolas Pitre ha scritto:
I appreciate your points, and similarly for a few others before yours,
but I think they are missing the point.
No one is against virtue.
Everybody wants the code base to be more consistent, more secure, etc.
But mechanically making the code MISRA compliant doesn't achieve that.
I persist in insisting that adding any more typecasts to a codebase
makes it worse. Typecasts should be _removed_ as much as possible, not
added. Thinking about how to avoid a cast produces better code almost
all the time. I would hardly trust "compliant" code for safety critical
applications if compliance came about due to added typecasts.
Are you really arguing that a commented explicit cast (for non obviously value-preserving conversion) is worse than an implicit cast?

Same thing for qualifying literals as unsigned. I made the demonstration
already showing how evil that is. And no, just saying that the MISRA
scan tool will spot mixed signedness and complain -- that's also missing
the point. It is just safer, clearer, lighter and more enjoyable to just
_not_ qualify literals when not required, and let the compiler promote
expressions to unsigned when the semantic-carrying non-literal part is
unsigned, at which point you don't need a tool to spot mixed signedness
because they're just OK. For those rare cases where mixed signedness is
bad there are tricks to spot them e.g. look at the Linux min() and max()
implementations where the constraint is encapsulated in one place and
not spread all over the entire code.
Avoiding so called "undefined" syntax when all existing compiler
implementations handle many of them just fine is stupid. Usually there
is a couple reasons why compilers still implement some "undefined"
behaviors: it is totally logical, uncontroversial, and also useful by
making the code clearer and easier to maintain. Instead of banning them
outright, we should instead implement a test safeguarding our reliance
on them.
Are you taking in account that although you can write tests for compiler *extensions* (defining otherwise undefined behaviors), you definitely can not write tests for compiler undefined and unspecified behaviors?

So let's stop thinking that XYZ conformance automatically makes the code
intrinsicly better. It doesn't. It may bring a false sense of security
though.
IMHO you are victim of an huge misunderstanding: the aim is *only* better code quality and conformance is exclusively a mean to achieve that.

When a specific instance of conformance to whatever rule hurts code quality it should never been done, who says otherwise prove it does not know XYZ (supposing it is a sane coding standard, like MISRA is).

If you are able to present a single non-deviable MISRA rule that hurts code quality and has been chosen for Zephyr community please present it, otherwise we risk to talk about gut feelings.

Similarily if you are able to present a single deviable MISRA rule that in *any* instance hurts code quality/verificability/readability/understanding and/or has no point to exists please talk about that under a pure technical point of view.

In summary, I believe that to keep repeating "XYZ conformance stinks" does not help.

On Wed, 15 Dec 2021, Gerard Marull Paretas wrote:

A few points from my side (probably nothing that has not been already said)

- MISRA mostly tries to avoid undefined behavior derived issues. Other
languages such as Rust have done a better job on this topic from the very
beginning.
- Not all rules are mandatory to make a codebase MISRA compliant, so a
project can decide to deviate where it makes sense.
- If seeking for MISRA compliance, the coding style used by a project
needs to introduce certain rules (e.g. if always needs to use braces). From
my perspective this is not a problem, I, personally, prefer consistent
codebases even if they have certain rules I'm not 100% happy with. If we
take for example the STM32 HAL (which is MISRA C 2012 compliant) one will
observe that code is much more consistent compared to Zephyr. Nowadays,
Zephyr just runs checkpatch, which loosely enforces Linux Kernel coding
style.
- Zephyr has the potential to target safety critical applications, so I
think it makes sense to certify core parts of the project. Without that,
there are markets that are simply out of the game. This is likely not a
concern for Linux.

Gerard

On Wed, Dec 15, 2021 at 2:35 PM Nashif, Anas <anas.nashif@...> wrote:

Olof,

Point taken, will start posting agenda the day before.



Anas



*From: *devel@... <devel@...> on
behalf of Olof Johansson <olof@...>
*Date: *Wednesday, December 15, 2021 at 2:14 AM
*To: *Hibberd, Amber M <amber.m.hibberd@...>
*Cc: *Abramo Bagnara <abramo.bagnara@...>, Benjamin Lindqvist <
benjamin.lindqvist@...>, Kevin Hilman <khilman@...>,
Pitre, Nicolas <npitre@...>, Zephyr Devel <
devel@...>
*Subject: *Re: [Zephyr-devel] MISRA





On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...>
wrote:

All,



1. As a reminder, the TSC agreed upon the Zephyr Project Coding
Guidelines
<https://docs.zephyrproject.org/latest/contribute/coding_guidelines/index.html>.
We are working towards compliance to the Project CG. Yes, they are a subset
of Misra, but we are not going for Misra compliance.

2. The Safety Committee, in driving toward the Project goal of
certification-ready, has partnered with Bugseng, as part of the community,
to help build momentum towards this goal.

3. There is a process for removing, revising, having exceptions, etc to
the CG rules. If you think a rule should be changed, open an issue in
Github.



The Safety Committee is bringing an update to the TSC tomorrow, where we
can have a discussion around the CG compliance work.



It’d be great to have a pre-read to frame the discussion and help us can
come prepared with questions based on said update (the linked Nov 10 email
in last week’s minutes is fairly high level).



Unfortunately, TSC agendas don’t seem to be communicated in a timely
fashion any more, usually sent out mere hours before the meeting (which is
early morning for us on the US west coast).



It makes it impossible to tell if it’s worth attending calls or not
beforehand, and I normally skip those kind of meetings to reduce meeting
overhead.



I hope we can change this to be a smoother process in the future and
optimize the value of a one hour weekly meeting.





-Olof







-Amber



*From:* devel@... <devel@...> *On
Behalf Of *Benjamin Lindqvist
*Sent:* Monday, December 13, 2021 2:44 PM
*To:* Abramo Bagnara <abramo.bagnara@...>
*Cc:* Pitre, Nicolas <npitre@...>; Zephyr Devel <
devel@...>; Kevin Hilman <khilman@...>
*Subject:* Re: [Zephyr-devel] MISRA



Well if code quality is truly the only goal of the steering committee and
there's no politics involved then I retract everything I said. Misra offers
less than nothing for this project. But I don't believe that's true. This
is 100% politics if you ask me.



Also before declaring the virtues of Misra, you'll be sure to clarify any
vested financial interest you might have in the matter, right? You know,
just to make sure you're not shilling.



On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...>
wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
I've also seen too many times a bug being introduced because the code
was modified just to make it [name your favorite static analysis tool /
coding standard here]-compliant. It is often the case that the code is
questionnably written in the first place, and adding typecasts to it
makes it worse even if the scanning tool is then happy.
I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

Hopefully most people in the community agree that many, if not most,
> Misra rules are outdated or even slightly harmful. But you optimize
> with the constraint being the way the world works, not how it should
> ideally work. If this is what it takes to get zephyr backed by Daimler
> and Volvo, I for one can't blame the steering committee for thinking
> the tradeoff is justified. I'd do the same thing probably, despite
> loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender
to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...



--

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






--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...


Re: MISRA

Nicolas Pitre <nico@...>
 

I appreciate your points, and similarly for a few others before yours,
but I think they are missing the point.

No one is against virtue.

Everybody wants the code base to be more consistent, more secure, etc.

But mechanically making the code MISRA compliant doesn't achieve that.

I persist in insisting that adding any more typecasts to a codebase
makes it worse. Typecasts should be _removed_ as much as possible, not
added. Thinking about how to avoid a cast produces better code almost
all the time. I would hardly trust "compliant" code for safety critical
applications if compliance came about due to added typecasts.

Same thing for qualifying literals as unsigned. I made the demonstration
already showing how evil that is. And no, just saying that the MISRA
scan tool will spot mixed signedness and complain -- that's also missing
the point. It is just safer, clearer, lighter and more enjoyable to just
_not_ qualify literals when not required, and let the compiler promote
expressions to unsigned when the semantic-carrying non-literal part is
unsigned, at which point you don't need a tool to spot mixed signedness
because they're just OK. For those rare cases where mixed signedness is
bad there are tricks to spot them e.g. look at the Linux min() and max()
implementations where the constraint is encapsulated in one place and
not spread all over the entire code.

Avoiding so called "undefined" syntax when all existing compiler
implementations handle many of them just fine is stupid. Usually there
is a couple reasons why compilers still implement some "undefined"
behaviors: it is totally logical, uncontroversial, and also useful by
making the code clearer and easier to maintain. Instead of banning them
outright, we should instead implement a test safeguarding our reliance
on them.

I don't care about braces everywhere. Well, that's not true: I do hate
them, but that I can live with and there is a technical argument in
favor of them and no real technical arguments against.

Etc. Etc.

So let's stop thinking that XYZ conformance automatically makes the code
intrinsicly better. It doesn't. It may bring a false sense of security
though.

On Wed, 15 Dec 2021, Gerard Marull Paretas wrote:

A few points from my side (probably nothing that has not been already said)

- MISRA mostly tries to avoid undefined behavior derived issues. Other
languages such as Rust have done a better job on this topic from the very
beginning.
- Not all rules are mandatory to make a codebase MISRA compliant, so a
project can decide to deviate where it makes sense.
- If seeking for MISRA compliance, the coding style used by a project
needs to introduce certain rules (e.g. if always needs to use braces). From
my perspective this is not a problem, I, personally, prefer consistent
codebases even if they have certain rules I'm not 100% happy with. If we
take for example the STM32 HAL (which is MISRA C 2012 compliant) one will
observe that code is much more consistent compared to Zephyr. Nowadays,
Zephyr just runs checkpatch, which loosely enforces Linux Kernel coding
style.
- Zephyr has the potential to target safety critical applications, so I
think it makes sense to certify core parts of the project. Without that,
there are markets that are simply out of the game. This is likely not a
concern for Linux.

Gerard

On Wed, Dec 15, 2021 at 2:35 PM Nashif, Anas <anas.nashif@...> wrote:

Olof,

Point taken, will start posting agenda the day before.



Anas



*From: *devel@... <devel@...> on
behalf of Olof Johansson <olof@...>
*Date: *Wednesday, December 15, 2021 at 2:14 AM
*To: *Hibberd, Amber M <amber.m.hibberd@...>
*Cc: *Abramo Bagnara <abramo.bagnara@...>, Benjamin Lindqvist <
benjamin.lindqvist@...>, Kevin Hilman <khilman@...>,
Pitre, Nicolas <npitre@...>, Zephyr Devel <
devel@...>
*Subject: *Re: [Zephyr-devel] MISRA





On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...>
wrote:

All,



1. As a reminder, the TSC agreed upon the Zephyr Project Coding
Guidelines
<https://docs.zephyrproject.org/latest/contribute/coding_guidelines/index.html>.
We are working towards compliance to the Project CG. Yes, they are a subset
of Misra, but we are not going for Misra compliance.

2. The Safety Committee, in driving toward the Project goal of
certification-ready, has partnered with Bugseng, as part of the community,
to help build momentum towards this goal.

3. There is a process for removing, revising, having exceptions, etc to
the CG rules. If you think a rule should be changed, open an issue in
Github.



The Safety Committee is bringing an update to the TSC tomorrow, where we
can have a discussion around the CG compliance work.



It’d be great to have a pre-read to frame the discussion and help us can
come prepared with questions based on said update (the linked Nov 10 email
in last week’s minutes is fairly high level).



Unfortunately, TSC agendas don’t seem to be communicated in a timely
fashion any more, usually sent out mere hours before the meeting (which is
early morning for us on the US west coast).



It makes it impossible to tell if it’s worth attending calls or not
beforehand, and I normally skip those kind of meetings to reduce meeting
overhead.



I hope we can change this to be a smoother process in the future and
optimize the value of a one hour weekly meeting.





-Olof







-Amber



*From:* devel@... <devel@...> *On
Behalf Of *Benjamin Lindqvist
*Sent:* Monday, December 13, 2021 2:44 PM
*To:* Abramo Bagnara <abramo.bagnara@...>
*Cc:* Pitre, Nicolas <npitre@...>; Zephyr Devel <
devel@...>; Kevin Hilman <khilman@...>
*Subject:* Re: [Zephyr-devel] MISRA



Well if code quality is truly the only goal of the steering committee and
there's no politics involved then I retract everything I said. Misra offers
less than nothing for this project. But I don't believe that's true. This
is 100% politics if you ask me.



Also before declaring the virtues of Misra, you'll be sure to clarify any
vested financial interest you might have in the matter, right? You know,
just to make sure you're not shilling.



On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...>
wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
I've also seen too many times a bug being introduced because the code
was modified just to make it [name your favorite static analysis tool /
coding standard here]-compliant. It is often the case that the code is
questionnably written in the first place, and adding typecasts to it
makes it worse even if the scanning tool is then happy.
I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

Hopefully most people in the community agree that many, if not most,
> Misra rules are outdated or even slightly harmful. But you optimize
> with the constraint being the way the world works, not how it should
> ideally work. If this is what it takes to get zephyr backed by Daimler
> and Volvo, I for one can't blame the steering committee for thinking
> the tradeoff is justified. I'd do the same thing probably, despite
> loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender
to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...



--

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






Re: MISRA

Flavio Ceolin
 

Hi,

I've written this email two days ago and somehow it never left my
outbox so I'm re-sending it because I think it is still relevant.

Well if code quality is truly the only goal of the steering committee and
there's no politics involved then I retract everything I said. Misra offers
less than nothing for this project. But I don't believe that's true. This is
100% politics if you ask me.
We should keep this discussion as much technical as possible. The code
guidelines rules we are following were discussed in the past involving
the whole community and not by small group of people.

That's being said, they are not written in stone, we can review them to
add changes or completely remove if we want, just open an issue and
expose technical reasons.

I really don't get this statement "offers less than nothing for this
project" ... Most MISRA guidelines address undefined / unspecified
behaviors in the C language. For a project that aims to support multiple
compilers and platforms this seems to be a good thing.


Also before declaring the virtues of Misra, you'll be sure to clarify any
vested financial interest you might have in the matter, right? You know, just
to make sure you're not shilling.
Abramo is putting technical arguments to justify the changes, please
challenge the arguments. Everyone here has its own interests.


On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...>
wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
> Misra rules are outdated or even slightly harmful. But you optimize
> with the constraint being the way the world works, not how it should
> ideally work. If this is what it takes to get zephyr backed by Daimler
> and Volvo, I for one can't blame the steering committee for thinking
> the tradeoff is justified. I'd do the same thing probably, despite
> loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender
to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...

Regards,
Flavio Ceolin


Re: MISRA

Gerard Marull Paretas
 

A few points from my side (probably nothing that has not been already said)
  • MISRA mostly tries to avoid undefined behavior derived issues. Other languages such as Rust have done a better job on this topic from the very beginning.
  • Not all rules are mandatory to make a codebase MISRA compliant, so a project can decide to deviate where it makes sense.
  • If seeking for MISRA compliance, the coding style used by a project needs to introduce certain rules (e.g. if always needs to use braces). From my perspective this is not a problem, I, personally, prefer consistent codebases even if they have certain rules I'm not 100% happy with. If we take for example the STM32 HAL (which is MISRA C 2012 compliant) one will observe that code is much more consistent compared to Zephyr. Nowadays, Zephyr just runs checkpatch, which loosely enforces Linux Kernel coding style.
  • Zephyr has the potential to target safety critical applications, so I think it makes sense to certify core parts of the project. Without that, there are markets that are simply out of the game. This is likely not a concern for Linux.
Gerard


On Wed, Dec 15, 2021 at 2:35 PM Nashif, Anas <anas.nashif@...> wrote:

Olof,

Point taken, will start posting agenda the day before.

 

Anas

 

From: devel@... <devel@...> on behalf of Olof Johansson <olof@...>
Date: Wednesday, December 15, 2021 at 2:14 AM
To: Hibberd, Amber M <amber.m.hibberd@...>
Cc: Abramo Bagnara <abramo.bagnara@...>, Benjamin Lindqvist <benjamin.lindqvist@...>, Kevin Hilman <khilman@...>, Pitre, Nicolas <npitre@...>, Zephyr Devel <devel@...>
Subject: Re: [Zephyr-devel] MISRA

 

 

On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...> wrote:

All,

 

1.   As a reminder, the TSC agreed upon the Zephyr Project Coding Guidelines. We are working towards compliance to the Project CG. Yes, they are a subset of Misra, but we are not going for Misra compliance.

2.   The Safety Committee, in driving toward the Project goal of certification-ready, has partnered with Bugseng, as part of the community, to help build momentum towards this goal.

3.   There is a process for removing, revising, having exceptions, etc to the CG rules. If you think a rule should be changed, open an issue in Github.

 

The Safety Committee is bringing an update to the TSC tomorrow, where we can have a discussion around the CG compliance work.

 

It’d be great to have a pre-read to frame the discussion and help us can come prepared with questions based on said update (the linked Nov 10 email in last week’s minutes is fairly high level).

 

Unfortunately, TSC agendas don’t seem to be communicated in a timely fashion any more, usually sent out mere hours before the meeting (which is early morning for us on the US west coast).

 

It makes it impossible to tell if it’s worth attending calls or not beforehand, and I normally skip those kind of meetings to reduce meeting overhead.

 

I hope we can change this to be a smoother process in the future and optimize the value of a one hour weekly meeting.

 

 

-Olof

 

 

 

-Amber

 

From: devel@... <devel@...> On Behalf Of Benjamin Lindqvist
Sent: Monday, December 13, 2021 2:44 PM
To: Abramo Bagnara <
abramo.bagnara@...>
Cc: Pitre, Nicolas <
npitre@...>; Zephyr Devel <devel@...>; Kevin Hilman <khilman@...>
Subject: Re: [Zephyr-devel] MISRA

 

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't believe that's true. This is 100% politics if you ask me.

 

Also before declaring the virtues of Misra, you'll be sure to clarify any vested financial interest you might have in the matter, right? You know, just to make sure you're not shilling. 

 

On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...> wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
 > Misra rules are outdated or even slightly harmful. But you optimize
 > with the constraint being the way the world works, not how it should
 > ideally work. If this is what it takes to get zephyr backed by Daimler
 > and Volvo, I for one can't blame the steering committee for thinking
 > the tradeoff is justified. I'd do the same thing probably, despite
 > loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl -
http://bugseng.com
mailto:
abramo.bagnara@...



--

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. 


Re: MISRA

Nashif, Anas
 

Olof,

Point taken, will start posting agenda the day before.

 

Anas

 

From: devel@... <devel@...> on behalf of Olof Johansson <olof@...>
Date: Wednesday, December 15, 2021 at 2:14 AM
To: Hibberd, Amber M <amber.m.hibberd@...>
Cc: Abramo Bagnara <abramo.bagnara@...>, Benjamin Lindqvist <benjamin.lindqvist@...>, Kevin Hilman <khilman@...>, Pitre, Nicolas <npitre@...>, Zephyr Devel <devel@...>
Subject: Re: [Zephyr-devel] MISRA

 

 

On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...> wrote:

All,

 

1.   As a reminder, the TSC agreed upon the Zephyr Project Coding Guidelines. We are working towards compliance to the Project CG. Yes, they are a subset of Misra, but we are not going for Misra compliance.

2.   The Safety Committee, in driving toward the Project goal of certification-ready, has partnered with Bugseng, as part of the community, to help build momentum towards this goal.

3.   There is a process for removing, revising, having exceptions, etc to the CG rules. If you think a rule should be changed, open an issue in Github.

 

The Safety Committee is bringing an update to the TSC tomorrow, where we can have a discussion around the CG compliance work.

 

It’d be great to have a pre-read to frame the discussion and help us can come prepared with questions based on said update (the linked Nov 10 email in last week’s minutes is fairly high level).

 

Unfortunately, TSC agendas don’t seem to be communicated in a timely fashion any more, usually sent out mere hours before the meeting (which is early morning for us on the US west coast).

 

It makes it impossible to tell if it’s worth attending calls or not beforehand, and I normally skip those kind of meetings to reduce meeting overhead.

 

I hope we can change this to be a smoother process in the future and optimize the value of a one hour weekly meeting.

 

 

-Olof

 

 

 

-Amber

 

From: devel@... <devel@...> On Behalf Of Benjamin Lindqvist
Sent: Monday, December 13, 2021 2:44 PM
To: Abramo Bagnara <
abramo.bagnara@...>
Cc: Pitre, Nicolas <
npitre@...>; Zephyr Devel <devel@...>; Kevin Hilman <khilman@...>
Subject: Re: [Zephyr-devel] MISRA

 

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't believe that's true. This is 100% politics if you ask me.

 

Also before declaring the virtues of Misra, you'll be sure to clarify any vested financial interest you might have in the matter, right? You know, just to make sure you're not shilling. 

 

On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...> wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
 > Misra rules are outdated or even slightly harmful. But you optimize
 > with the constraint being the way the world works, not how it should
 > ideally work. If this is what it takes to get zephyr backed by Daimler
 > and Volvo, I for one can't blame the steering committee for thinking
 > the tradeoff is justified. I'd do the same thing probably, despite
 > loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl -
http://bugseng.com
mailto:
abramo.bagnara@...


Re: MISRA

Olof Johansson
 



On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...> wrote:

All,

 

  1. As a reminder, the TSC agreed upon the Zephyr Project Coding Guidelines. We are working towards compliance to the Project CG. Yes, they are a subset of Misra, but we are not going for Misra compliance.
  2. The Safety Committee, in driving toward the Project goal of certification-ready, has partnered with Bugseng, as part of the community, to help build momentum towards this goal.
  3. There is a process for removing, revising, having exceptions, etc to the CG rules. If you think a rule should be changed, open an issue in Github.

 

The Safety Committee is bringing an update to the TSC tomorrow, where we can have a discussion around the CG compliance work.


It’d be great to have a pre-read to frame the discussion and help us can come prepared with questions based on said update (the linked Nov 10 email in last week’s minutes is fairly high level).

Unfortunately, TSC agendas don’t seem to be communicated in a timely fashion any more, usually sent out mere hours before the meeting (which is early morning for us on the US west coast).

It makes it impossible to tell if it’s worth attending calls or not beforehand, and I normally skip those kind of meetings to reduce meeting overhead.

I hope we can change this to be a smoother process in the future and optimize the value of a one hour weekly meeting.


-Olof


 

-Amber

 

From: devel@... <devel@...> On Behalf Of Benjamin Lindqvist
Sent: Monday, December 13, 2021 2:44 PM
To: Abramo Bagnara <abramo.bagnara@...>
Cc: Pitre, Nicolas <npitre@...>; Zephyr Devel <devel@...>; Kevin Hilman <khilman@...>
Subject: Re: [Zephyr-devel] MISRA

 

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't believe that's true. This is 100% politics if you ask me.

 

Also before declaring the virtues of Misra, you'll be sure to clarify any vested financial interest you might have in the matter, right? You know, just to make sure you're not shilling. 

 

On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...> wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
 > Misra rules are outdated or even slightly harmful. But you optimize
 > with the constraint being the way the world works, not how it should
 > ideally work. If this is what it takes to get zephyr backed by Daimler
 > and Volvo, I for one can't blame the steering committee for thinking
 > the tradeoff is justified. I'd do the same thing probably, despite
 > loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...


Re: MISRA

Hibberd, Amber M
 

All,

 

  1. As a reminder, the TSC agreed upon the Zephyr Project Coding Guidelines. We are working towards compliance to the Project CG. Yes, they are a subset of Misra, but we are not going for Misra compliance.
  2. The Safety Committee, in driving toward the Project goal of certification-ready, has partnered with Bugseng, as part of the community, to help build momentum towards this goal.
  3. There is a process for removing, revising, having exceptions, etc to the CG rules. If you think a rule should be changed, open an issue in Github.

 

The Safety Committee is bringing an update to the TSC tomorrow, where we can have a discussion around the CG compliance work.

 

-Amber

 

From: devel@... <devel@...> On Behalf Of Benjamin Lindqvist
Sent: Monday, December 13, 2021 2:44 PM
To: Abramo Bagnara <abramo.bagnara@...>
Cc: Pitre, Nicolas <npitre@...>; Zephyr Devel <devel@...>; Kevin Hilman <khilman@...>
Subject: Re: [Zephyr-devel] MISRA

 

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't believe that's true. This is 100% politics if you ask me.

 

Also before declaring the virtues of Misra, you'll be sure to clarify any vested financial interest you might have in the matter, right? You know, just to make sure you're not shilling. 

 

On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...> wrote:

Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
 > Misra rules are outdated or even slightly harmful. But you optimize
 > with the constraint being the way the world works, not how it should
 > ideally work. If this is what it takes to get zephyr backed by Daimler
 > and Volvo, I for one can't blame the steering committee for thinking
 > the tradeoff is justified. I'd do the same thing probably, despite
 > loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...


Re: Execute vendor-specific commands to initialize BT Controller

Nazar.Palamar@...
 

Hi Vinayak,

enhancement request https://github.com/zephyrproject-rtos/zephyr/issues/41140, lets continue discussion there.

Regards,
Nazar

 

From: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>
Sent: 14 грудня 2021 р. 3:34
To: Palamar Nazar (CSUKR CSS ICW SW CC ML 2) <Nazar.Palamar@...>; johan.hedberg@...; devel@...
Cc: Fyall Ian (CYSC CSS ICW SW T 1) <Ian.Fyall@...>
Subject: RE: [Zephyr-devel] Execute vendor-specific commands to initialize BT Controller

 

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

 

Hi Nazar,

 

Correct me, the requirement is

  1. to be able to use Vendor HCI command/Response on `bt_enable()` after a HCI device is open but before the `bt_init()`.
  2. to be able to handle asynchronous Vendor HCI Events, if need be.
  3. to be able to perform Device Firmware Update (DFU) or settings update, this would involve synchronization thereafter (similar to CONFIG_BT_WAIT_NOP).
  4. to be able to use the feature conditionally, build-time and/or runtime.
  5. to consider enhancements to Zephyr HCI Extensions

 

Agree that a discussion in an enhancement request will keep information collected. Do post the issue link and I can add my thoughts there.

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Nazar.Palamar via lists.zephyrproject.org
Sent: 13 December 2021 20:52
To: johan.hedberg@...; devel@...
Cc: Ian.Fyall@...
Subject: Re: [Zephyr-devel] Execute vendor-specific commands to initialize BT Controller

 

Hi Johan,
Thank you for your quick response. I will open a new enhancement request for this.

Regards,
Nazar

 

From: Hedberg, Johan <johan.hedberg@...>
Sent: 13 грудня 2021 р. 19:41
To: Palamar Nazar (CSUKR CSS ICW SW CC ML 2) <Nazar.Palamar@...>; devel@...
Cc: Fyall Ian (CYSC CSS ICW SW T 1) <Ian.Fyall@...>
Subject: Re: Execute vendor-specific commands to initialize BT Controller

 

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

 

Hi Nazar,

 

Adding such a feature to the Bluetooth stack sounds like a good idea, but I suspect we need to discuss a bit whether it should be a host extension using a __weak function, an extension to the HCI driver API or something else. Could you open a new enhancement request on github, providing initially the same information as in your email, and we’ll then continue the discussion there: https://github.com/zephyrproject-rtos/zephyr/issues/new/choose

 

Thanks!

 

Johan

 

From: devel@... <devel@...> on behalf of Nazar.Palamar@... <Nazar.Palamar@...>
Date: Monday, 13. December 2021 at 17.42
To: devel@... <devel@...>
Cc: Ian.Fyall@... <Ian.Fyall@...>
Subject: [Zephyr-devel] Execute vendor-specific commands to initialize BT Controller

Hello Devel team,

My name is Nazar. I am working for Infineon in the SW integration team. Currently, I am working on the integration of our CYW43xxx connectivity device into Zephyr (PSoC 6 family).

At the moment, I am working on the integration of the BT part. Wi-Fi will be the next step and I am going to use the HCI H4 driver. HCI H4 driver provides to the user _weak bt_hci_transport_setup to reset the Bluetooth IC. I will use it to power the CYW43xxx device.


The CYW43xxx device requires downloading the controller firmware (via vendor HCI commands) after a power-on. Unfortunately, I cannot do this from bt_hci_transport_setup because the bt hci interface does not start on time when bt_hci_transport_setup is called.


I see the solution as update of the Zephyr common_init() function in hci_core.c, where the add hook to execute the vendor-specific init sequence is:

int __weak  bt_hci_vendor_init_sequence(void)

{

    return 0;

}


static
int common_init(void)

{

    struct net_buf *rsp;

    int err;

  

    /* Execute vendor-specific commands to initialize the controller */

    err = bt_hci_vendor_init_sequence();

    if (err) {

        return err;

    }

...

}

My integration part will implement bt_hci_transport_setup and  bt_hci_vendor_init_sequence functions.

Could you possibly share your considerations on the solution? There may exist another approach to the execution of vendor-specific commands for initializing the controller, before hci_core starts its own initialization.

Thanks and Regards,
Nazar


Cancelled Event: Zephyr Project: APIs - Tuesday, December 28, 2021 #cal-cancelled

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

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, December 28, 2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

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
 
 
________________________________________________________________________________


Cancelled Event: Zephyr Project: APIs - Tuesday, December 21, 2021 #cal-cancelled

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

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, December 21, 2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

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
 
 
________________________________________________________________________________


Cancelled Event: Zephyr Project: APIs - Tuesday, December 14, 2021 #cal-cancelled

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

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, December 14, 2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

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
 
 
________________________________________________________________________________


Re: Execute vendor-specific commands to initialize BT Controller

Chettimada, Vinayak Kariappa
 

Hi Nazar,

 

Correct me, the requirement is

  1. to be able to use Vendor HCI command/Response on `bt_enable()` after a HCI device is open but before the `bt_init()`.
  2. to be able to handle asynchronous Vendor HCI Events, if need be.
  3. to be able to perform Device Firmware Update (DFU) or settings update, this would involve synchronization thereafter (similar to CONFIG_BT_WAIT_NOP).
  4. to be able to use the feature conditionally, build-time and/or runtime.
  5. to consider enhancements to Zephyr HCI Extensions

 

Agree that a discussion in an enhancement request will keep information collected. Do post the issue link and I can add my thoughts there.

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Nazar.Palamar via lists.zephyrproject.org
Sent: 13 December 2021 20:52
To: johan.hedberg@...; devel@...
Cc: Ian.Fyall@...
Subject: Re: [Zephyr-devel] Execute vendor-specific commands to initialize BT Controller

 

Hi Johan,
Thank you for your quick response. I will open a new enhancement request for this.

Regards,
Nazar

 

From: Hedberg, Johan <johan.hedberg@...>
Sent: 13 грудня 2021 р. 19:41
To: Palamar Nazar (CSUKR CSS ICW SW CC ML 2) <Nazar.Palamar@...>; devel@...
Cc: Fyall Ian (CYSC CSS ICW SW T 1) <Ian.Fyall@...>
Subject: Re: Execute vendor-specific commands to initialize BT Controller

 

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

 

Hi Nazar,

 

Adding such a feature to the Bluetooth stack sounds like a good idea, but I suspect we need to discuss a bit whether it should be a host extension using a __weak function, an extension to the HCI driver API or something else. Could you open a new enhancement request on github, providing initially the same information as in your email, and we’ll then continue the discussion there: https://github.com/zephyrproject-rtos/zephyr/issues/new/choose

 

Thanks!

 

Johan

 

From: devel@... <devel@...> on behalf of Nazar.Palamar@... <Nazar.Palamar@...>
Date: Monday, 13. December 2021 at 17.42
To: devel@... <devel@...>
Cc: Ian.Fyall@... <Ian.Fyall@...>
Subject: [Zephyr-devel] Execute vendor-specific commands to initialize BT Controller

Hello Devel team,

My name is Nazar. I am working for Infineon in the SW integration team. Currently, I am working on the integration of our CYW43xxx connectivity device into Zephyr (PSoC 6 family).

At the moment, I am working on the integration of the BT part. Wi-Fi will be the next step and I am going to use the HCI H4 driver. HCI H4 driver provides to the user _weak bt_hci_transport_setup to reset the Bluetooth IC. I will use it to power the CYW43xxx device.


The CYW43xxx device requires downloading the controller firmware (via vendor HCI commands) after a power-on. Unfortunately, I cannot do this from bt_hci_transport_setup because the bt hci interface does not start on time when bt_hci_transport_setup is called.


I see the solution as update of the Zephyr common_init() function in hci_core.c, where the add hook to execute the vendor-specific init sequence is:

int __weak  bt_hci_vendor_init_sequence(void)

{

    return 0;

}


static
int common_init(void)

{

    struct net_buf *rsp;

    int err;

  

    /* Execute vendor-specific commands to initialize the controller */

    err = bt_hci_vendor_init_sequence();

    if (err) {

        return err;

    }

...

}

My integration part will implement bt_hci_transport_setup and  bt_hci_vendor_init_sequence functions.

Could you possibly share your considerations on the solution? There may exist another approach to the execution of vendor-specific commands for initializing the controller, before hci_core starts its own initialization.

Thanks and Regards,
Nazar


Re: MISRA

Benjamin Lindqvist
 

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't believe that's true. This is 100% politics if you ask me.

Also before declaring the virtues of Misra, you'll be sure to clarify any vested financial interest you might have in the matter, right? You know, just to make sure you're not shilling. 

On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...> wrote:
Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.

I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.

What matter is *only* the quality of code and MISRA is a tool to achieve
this purpose.

Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:

> Hopefully most people in the community agree that many, if not most,
 > Misra rules are outdated or even slightly harmful. But you optimize
 > with the constraint being the way the world works, not how it should
 > ideally work. If this is what it takes to get zephyr backed by Daimler
 > and Volvo, I for one can't blame the steering committee for thinking
 > the tradeoff is justified. I'd do the same thing probably, despite
 > loathing Misra with all my heart.

In my experience this is a consequence of a misunderstanding of what
MISRA really is.

MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
safety/readability/understanding/analyzability.

Please forget every other idea of it as an enemy to beat or to surrender to.

As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.

I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.

--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara@...

381 - 400 of 8628