[PATCH v3] eng: Add Python development guidelines

[Sebastian Huber]

---
v3:

* Use "preferred" instead of "main" language.

v2:

* Fix grammar
* Recommend pytest instead of unittest

 eng/management.rst   |   1 +
 eng/python-devel.rst | 163 +++
 2 files changed, 164 insertions(+)
 create mode 100644 eng/python-devel.rst

diff --git a/eng/management.rst b/eng/management.rst
index 064559c..6eb4217 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -16,5 +16,6 @@ Software Development Management
 vc-users
 vc-authors
 coding
+python-devel
 change-management
 issue-tracking
diff --git a/eng/python-devel.rst b/eng/python-devel.rst
new file mode 100644
index 000..b1e0fa6
--- /dev/null
+++ b/eng/python-devel.rst
@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _PythonDevelGuide:
+
+Python Development Guidelines
+*
+
+Python is the preferred programming language for the RTEMS Tools.  The RTEMS
+Tools run on the host computer of an RTEMS user or maintainer.  These
+guidelines cover the Python language version, the source code formatting, use
+of static analysis tools, type annotations, testing, code coverage, and
+documentation.  There are exceptions for existing code and third-party code.
+It is recommended to read the
+`PEP 8 - Style Guide for Python Code 
`_
+and the
+`Google Python Style Guide `_.
+
+Python Language Versions
+
+
+Although the official end-of-life of Python 2.7 was on January 1, 2020, the
+RTEMS Project still cares about Python 2.7 compatibility for some tools.  Every
+tool provided by the RTEMS Project which an RTEMS user may use to develop
+applications with RTEMS should be Python 2.7 compatible.  Examples are the
+build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale is
+that there are still some maintained Linux distributions in the wild which ship
+only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
+updates until June 2024.  Everything an RTEMS maintainer uses should be written
+in Python 3.6.
+
+Python Code Formatting
+==
+
+Good looking code is important.  Unfortunately, what looks good is a bit
+subjective and varies from developer to developer.  Arguing about the code
+format is not productive.  Code reviews should focus on more important topics,
+for example functionality, testability, and performance.  Fortunately, for
+Python there are some good automatic code formatters available.  All new code
+specifically developed for the RTEMS Tools should be piped through the
+`yapf `_ Python code formatter before it is
+committed or sent for review.  Use the default settings of the tool
+(`PEP 8 `_ coding style).
+
+You can disable the automatic formatting by the tool in a region starting with
+the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, for
+example
+
+.. code-block:: python
+
+# yapf: disable
+FOO = {
+# ... some very large, complex data literal.
+}
+
+BAR = [
+# ... another large data literal.
+]
+# yapf: enable
+
+For a single literal, you can disable the formatting like this:
+
+.. code-block:: python
+
+BAZ = {
+(1, 2, 3, 4),
+(5, 6, 7, 8),
+(9, 10, 11, 12),
+}  # yapf: disable
+
+Static Analysis Tools
+=
+
+Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
+commit your code or send it for review if the tools find some rule
+violations.  Run the tools with the default configuration.  If you have
+problems to silence the tools, then please ask for help on the :r:list:`devel`.
+Consult the tool documentation to silence false positives.
+
+Type Annotations
+
+
+For Python 3.6 or later code use type annotations.  All public functions of
+your modules should have `PEP 484 `_
+type annotations.  Check for type issues with the
+`mypy `_ static type checker.
+
+Testing
+===
+
+Write tests for your code with the
+`pytest `_ framework.  Use the
+`monkeypatch `_ mocking
+module.  Do not use the standard Python ``unittest`` and ``unittest.mock``
+modules.  Use ``coverage run -m pytest`` to run the tests with code coverage
+support.  If you modify existing code or contribute new code to a subproject
+which uses tests and the code coverage metric, then do not make the code
+coverage worse.
+
+Test Organization
+-
+
+Do not use test classes to group tests.  Use separate files instead.  Avoid
+deep test directory hierarchies.  For example, place tests for

Re: [PATCH v2] eng: Add Python development guidelines

[Sebastian Huber]

On 18/03/2020 06:28, Chris Johns wrote:


Build System


Any need to have something about the build system to be used to wrap a project?
There is waf as used in rtems-tools and then are are Python packaging systems.

Should this be covered?
Yes, this should be covered, but I would like to do this in a follow up 
patch. I guess this topic needs a bit more consideration. Python seems 
to have a lot of specialized tools for the module packaging, testing, 
and deployment. I am not really a Python expert. So I don't know what 
works best for us.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What sanitizers preferred?

[suyash singh]

AddressSanitizer is supported on  Android ARM
ThreadSanitizer supported on x86_64
Memory sanitizer and UBsan not on the ones you mentioned but on freeBSD
DataFlowSanitizer is under development for x86_64 Linux

But they use virtual memory.


On Mon, Mar 16, 2020 at 10:25 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 15/03/2020 17:52, suyash singh wrote:
>>
>> Hello,
>> Out of
>> AddressSanitizer ,
>> ThreadSanitizer ,
>> MemorySanitizer , and
>> DataFlowSanitizer .
>>
>> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
>> suggested?
>>
>> Asking as part of my proposed gsoc project,
>>
>> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>>
>> I am not sure of these sanitizers can be used in RTEMS at all. We don't
>> have virtual memory. Firstly, it would be necessary to check for each
>> sanitizer if it uses virtual memory. If yes, then is this absolutely
>> necessary or just convenient? Also the sanitizers are not available on all
>> LLVM architectures. We have to evaluate if the architectures-specific
>> adoptions can be used in RTEMS.
>>
>
> +1
>
> Another area is the compiler stack protection techniques. I have no idea
> if those are applicable to RTEMS but they would be useful if they can work.
>
> Ignoring other constraints from embedded systems, any possible technique
> to use with RTEMS must be evaluated against the constraints imposed by
> having a single address space, no VM, and single process model.
>
> You need to check if any of these will work before this project has a
> chance.
>
> I would be willing to entertain a project for an appropriate solution that
> is limited to say ARM, x86, and RISC-V.
>
> --joel
>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Add support for building with Clang/LLVM

[Sebastian Huber]

On 18/03/2020 06:10, Chris Johns wrote:


On 17/3/20 4:50 pm, Sebastian Huber wrote:

On 17/03/2020 03:09, Chris Johns wrote:


That follows the rtems/waf (new build system) convention by default.

Do you mean the work Sebastian is doing? If you are, it currently might but that
work is not finished and it may change, partially to make it consistent with
this package. This has not been discussed.

We discussed the way to find tools during the waf configure phase. See bottom of
this email:

https://lists.rtems.org/pipermail/devel/2019-December/056291.html


Oh we did, I am sorry.


Maybe I misinterpreted your steps 1. to 3.

I am not sure if you have, I have not tested it.


In the waf configure output you see
the absolute paths of the tools. So you can check if they are the right ones.

The way rtems_waf works is due to the paths passed to the tool check? My reading
of Hesham's change is only the env path is checked for clang and this is what I
am questioning, i.e. does the --prefix, --rtems-tools etc work with clang just
like gcc?


In the new build system, the path list is created like this:

def get_path_list(conf):
    path_list = []
    tools = conf.options.rtems_tools
    if tools is not None:
    for t in tools.split(","):
    path_list.extend([t + "/bin", t])
    path_list.append(conf.env.PREFIX + "/bin")
    path_list.extend(os.environ.get("PATH", "").split(os.pathsep))
    return path_list



I think we should be consistent what ever the specifics are and this should
before across different packages and for tools within a package.
Yes, we should have a copy and paste routine which is used across the 
waf based build systems.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2020 memory protection project initial draft.

[Utkarsh Rai]

Hi, I have prepared my initial draft for the project and look forward to
your feedback on the same.
I have also added this to the GSoC tracking page.
 GSOC2020_ Rai_Memory_Protection

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What sanitizers preferred?

[suyash singh]

Yes it uses virtual memory. I confirmed from a LLVM sanitizer contributor.



On Mon, Mar 16, 2020 at 9:35 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/03/2020 17:52, suyash singh wrote:
>
> Hello,
> Out of
> AddressSanitizer ,
> ThreadSanitizer ,
> MemorySanitizer , and
> DataFlowSanitizer .
>
> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
> suggested?
>
> Asking as part of my proposed gsoc project,
>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>
> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] eng: Add Python development guidelines

[Chris Johns]

On 18/3/20 7:50 am, Sebastian Huber wrote:
> ---
> v2:
> 
> * Fix grammar
> * Recommend pytest instead of unittest
> 
>  eng/management.rst   |   1 +
>  eng/python-devel.rst | 163 
> +++
>  2 files changed, 164 insertions(+)
>  create mode 100644 eng/python-devel.rst
> 
> diff --git a/eng/management.rst b/eng/management.rst
> index 064559c..6eb4217 100644
> --- a/eng/management.rst
> +++ b/eng/management.rst
> @@ -16,5 +16,6 @@ Software Development Management
>  vc-users
>  vc-authors
>  coding
> +python-devel
>  change-management
>  issue-tracking
> diff --git a/eng/python-devel.rst b/eng/python-devel.rst
> new file mode 100644
> index 000..a36d95e
> --- /dev/null
> +++ b/eng/python-devel.rst
> @@ -0,0 +1,163 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +
> +.. _PythonDevelGuide:
> +
> +Python Development Guidelines
> +*
> +
> +Python is the main programming language for the RTEMS Tools.  The RTEMS Tools

Preferred rather than main? We also have a C++ toolkit.

> +run on the host computer of an RTEMS user or maintainer.  These guidelines
> +cover the Python language version, the source code formatting, use of static
> +analysis tools, type annotations, testing, code coverage, and documentation.
> +There are exceptions for existing code and third-party code.  It is 
> recommended
> +to read the
> +`PEP 8 - Style Guide for Python Code 
> `_
> +and the
> +`Google Python Style Guide 
> `_.
> +
> +Python Language Versions
> +
> +
> +Although the official end-of-life of Python 2.7 was on January 1, 2020, the
> +RTEMS Project still cares about Python 2.7 compatibility for some tools.  
> Every
> +tool provided by the RTEMS Project which an RTEMS user may use to develop
> +applications with RTEMS should be Python 2.7 compatible.  Examples are the
> +build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale 
> is
> +that there are still some maintained Linux distributions in the wild which 
> ship
> +only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
> +updates until June 2024.  Everything an RTEMS maintainer uses should be 
> written
> +in Python 3.6.
> +
> +Python Code Formatting
> +==
> +
> +Good looking code is important.  Unfortunately, what looks good is a bit
> +subjective and varies from developer to developer.  Arguing about the code
> +format is not productive.  Code reviews should focus on more important 
> topics,
> +for example functionality, testability, and performance.  Fortunately, for
> +Python there are some good automatic code formatters available.  All new code
> +specifically developed for the RTEMS Tools should be piped through the
> +`yapf `_ Python code formatter before it is
> +committed or sent for review.  Use the default settings of the tool
> +(`PEP 8 `_ coding style).
> +
> +You can disable the automatic formatting by the tool in a region starting 
> with
> +the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, for
> +example
> +
> +.. code-block:: python
> +
> +# yapf: disable
> +FOO = {
> +# ... some very large, complex data literal.
> +}
> +
> +BAR = [
> +# ... another large data literal.
> +]
> +# yapf: enable
> +
> +For a single literal, you can disable the formatting like this:
> +
> +.. code-block:: python
> +
> +BAZ = {
> +(1, 2, 3, 4),
> +(5, 6, 7, 8),
> +(9, 10, 11, 12),
> +}  # yapf: disable
> +
> +Static Analysis Tools
> +=
> +
> +Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
> +commit your code or send it for review if the tools find some rule
> +violations.  Run the tools with the default configuration.  If you have
> +problems to silence the tools, then please ask for help on the 
> :r:list:`devel`.
> +Consult the tool documentation to silence false positives.

Would these be wrapped in a build environment so you can say ...

 ./waf lint

Even ...

 ./waf format

?

> +
> +Type Annotations
> +
> +
> +For Python 3.6 or later code use type annotations.  All public functions of
> +your modules should have `PEP 484 
> `_
> +type annotations.  Check for type issues with the
> +`mypy `_ static type checker.
> +
> +Testing
> +===
> +
> +Write tests for your code with the
> +`pytest `_ framework.  Use 
> the
> +`monkeypatch `_ mocking
> +module.  Do not use the standard Python ``unittest`` and ``unittest.mock``
> 

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Chris Johns]

On 18/3/20 4:59 am, Amar Takhar wrote:
> On 2020-03-17 15:21 +0100, Sebastian Huber wrote:
>>
>> It seems that pytest recommends monkeypatch:
>>
>> https://docs.pytest.org/en/latest/monkeypatch.html
>>
> 
> Yes, also I use this:
> 
>   https://github.com/pytest-dev/pytest-mock
> 
> Plugins are extremely easy to use in pytest and are usually comprised of a 
> single file we can include in our test suite.

Are these plugins extra dependencies or are they part of our test code?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Chris Johns]

On 17/3/20 5:23 pm, Sebastian Huber wrote:
> On 17/03/2020 01:05, Amar Takhar wrote:
> 
>> On 2020-03-17 10:55 +1100, Chris Johns wrote:
>>> On 17/3/20 7:21 am, Sebastian Huber wrote:
 Chris, what do you think about using pytest in favour of the standard 
 Python
 unitttest?
>>> I am fine with pytest. Testing is a development feature and so we can have a
>>> different criteria for the needed dependencies.
>> If we're choosing pytest I'd like to see explicit documentation of what 
>> pattern 
>> to use for which situations.
>>
>> It's really easy to fall into traditional patterns for non Python languages 
>> which means we lose advantages of going to pytest.
> This sounds like a great addition to the Testing section in the new Python
> Development Guidelines chapter of the engineering manual.

+1

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Add support for building with Clang/LLVM

[Chris Johns]

On 17/3/20 4:50 pm, Sebastian Huber wrote:
> On 17/03/2020 03:09, Chris Johns wrote:
> 
>>> That follows the rtems/waf (new build system) convention by default.
>> Do you mean the work Sebastian is doing? If you are, it currently might but 
>> that
>> work is not finished and it may change, partially to make it consistent with
>> this package. This has not been discussed.
> 
> We discussed the way to find tools during the waf configure phase. See bottom 
> of
> this email:
> 
> https://lists.rtems.org/pipermail/devel/2019-December/056291.html
> 

Oh we did, I am sorry.

> Maybe I misinterpreted your steps 1. to 3. 

I am not sure if you have, I have not tested it.

> In the waf configure output you see
> the absolute paths of the tools. So you can check if they are the right ones.

The way rtems_waf works is due to the paths passed to the tool check? My reading
of Hesham's change is only the env path is checked for clang and this is what I
am questioning, i.e. does the --prefix, --rtems-tools etc work with clang just
like gcc?

I think we should be consistent what ever the specifics are and this should
before across different packages and for tools within a package.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Chris Johns]

On 18/3/20 12:06 am, Joel Sherrill wrote:
> I should have said that I am OK with this patch and if the examples build with
> the the waf patch to the examples build system, I'm OK with that also.

The patch needs to have an updated rtems_waf to pull in the env var check I just
pushed.

> I am not comfortable reviewing the patch to the rtems waf infrastructure. 

I am OK with this change.

> Sebastian, if you can push these, it would be appreciated. I'm about to head
> into meetings and won't possibly get to it before this afternoon.

I think we wait for a v2 patch.

Chris

> 
> --joel
> 
> On Tue, Mar 17, 2020 at 8:03 AM Joel Sherrill  > wrote:
> 
> The examples are released with each RTEMS version. The examples master
> should track RTEMS master.
> 
> https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003/  includes a
> mated rtems-examples.
> 
>  --joel
> 
> On Tue, Mar 17, 2020 at 5:11 AM Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> 
> 
> On Tue, Mar 17, 2020 at 3:25 PM Sebastian Huber
>  > wrote:
> 
> Should the examples also work with RTEMS 4.10 or 4.11?
> 
> That's a good point. Should we sort out the examples that are not 
> expected
> to work on 4.10 and 4.11 (like lvgl example) and do this change only 
> on
> those
> files?  
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems_waf PATCH] rtems: Allow checking multiple environment variable

[Chris Johns]

Hi,

Nice change, I have pushed this.

Chris

On 17/3/20 8:52 pm, Vijay Kumar Banerjee wrote:
> ---
>  rtems.py | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/rtems.py b/rtems.py
> index 6dd71b1..ceabcd9 100644
> --- a/rtems.py
> +++ b/rtems.py
> @@ -479,10 +479,11 @@ def check_options(ctx, prefix, rtems_tools, rtems_path, 
> rtems_version, rtems_arc
>  
>  return rtems_version, rtems_path, tools, archs, arch_bsps
>  
> -def check_env(ctx, var):
> -if var in ctx.env and len(ctx.env[var]) != 0:
> -return True
> -return False
> +def check_env(ctx, *env_vars):
> +for v in env_vars:
> +if v not in ctx.env or len(ctx.env[v]) == 0:
> +return False
> +return True
>  
>  def check(ctx, option, setting = 'Yes'):
>  if option in ctx.env:
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve the Raspberry Pi BSP

[Joel Sherrill]

On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:

> Hi,
>I would like to know whether the projects shown in this
> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the
> ideas are yet to implement I could work on it.
>

I think there is plenty left. I am not authoritative on this though.

I think getting Pi3/4 support still has work.

I think USB plus Ethernet.

I recall the graphics work was done on the Beagle.

I am not even sure that Pi2 qemu support has been worked through completely.



It will more interesting to work those projects rather than my currently
> selected project which is Release Note Generator.
> Meanwhile I have uploaded my draft proposal which is ongoing self revision.
>
> Thank you
> Denil C Verghese
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Regarding my proposal.

[Denil Verghese]

Hi,
 I have been closely watching the mailing list as well as my proposal
for any suggestions of any kind but, so far I received none.
  Is there anything that I can do to improve my proposal so that it
benefits the community.
   As  mentioned in the RTEMS GSoC page repeated review gives more chance
of acceptance. Hence I request Interested mentors to look into it and
provide valuable suggestions.

Since I felt the project will be too short I would also like to add a code
formatter/checker ticket to it. Will it suffice?

Is there anything I can do to be a successful member of this community as
well as a GSoC student.

Thank you.
Denil C Verghese
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Too Build Failures on Various Hosts

[Joel Sherrill]

Hi

I haven't made a master list but it seems as though a number of
target architectures seem to have issues on different hosts. Do
we have a master list to attempt to burn down?

I know Chris mentioned moving some targets back a bit on gdb
(I think) to move past this quickly.

What's the set is host/target/failure reason?

Thanks.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Improve Python 3 compatibility misc directory

[Anmol Mishra]

Refer https://docs.python.org/3.1/whatsnew/3.0.html

On Wed, 18 Mar, 2020, 02:22 Anmol mishra,  wrote:

> From: Anmol Mishra 
>
> ---
>  misc/tools/boot.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/misc/tools/boot.py b/misc/tools/boot.py
> index 265d1b3..78e43bc 100644
> --- a/misc/tools/boot.py
> +++ b/misc/tools/boot.py
> @@ -147,7 +147,7 @@ class bootloader(object):
>  self.clean = True
>
>  def __getitem__(self, key):
> -if self.macros.has_key(key) and self.macros[key] != 'None':
> +if key in self.macros and self.macros[key] != 'None':
>  r = self.macros.expand('%%{%s}' % (key))
>  if r == '1':
>  return True
> @@ -171,7 +171,7 @@ class bootloader(object):
>
>  def check_mandatory_configs(self):
>  for c in self.get_mandatory_configs():
> -if not self.macros.has_key(c):
> +if c not in self.macros:
>  raise error.general('boot config missing: %s' % (c))
>
>  def load_config(self, bootloader, config):
> --
> 2.21.0 (Apple Git-122.2)
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Improve Python 3 compatibility misc directory

[Anmol mishra]

From: Anmol Mishra 

---
 misc/tools/boot.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/misc/tools/boot.py b/misc/tools/boot.py
index 265d1b3..78e43bc 100644
--- a/misc/tools/boot.py
+++ b/misc/tools/boot.py
@@ -147,7 +147,7 @@ class bootloader(object):
 self.clean = True
 
 def __getitem__(self, key):
-if self.macros.has_key(key) and self.macros[key] != 'None':
+if key in self.macros and self.macros[key] != 'None':
 r = self.macros.expand('%%{%s}' % (key))
 if r == '1':
 return True
@@ -171,7 +171,7 @@ class bootloader(object):
 
 def check_mandatory_configs(self):
 for c in self.get_mandatory_configs():
-if not self.macros.has_key(c):
+if c not in self.macros:
 raise error.general('boot config missing: %s' % (c))
 
 def load_config(self, bootloader, config):
-- 
2.21.0 (Apple Git-122.2)

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] eng: Add Python development guidelines

[Sebastian Huber]

---
v2:

* Fix grammar
* Recommend pytest instead of unittest

 eng/management.rst   |   1 +
 eng/python-devel.rst | 163 +++
 2 files changed, 164 insertions(+)
 create mode 100644 eng/python-devel.rst

diff --git a/eng/management.rst b/eng/management.rst
index 064559c..6eb4217 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -16,5 +16,6 @@ Software Development Management
 vc-users
 vc-authors
 coding
+python-devel
 change-management
 issue-tracking
diff --git a/eng/python-devel.rst b/eng/python-devel.rst
new file mode 100644
index 000..a36d95e
--- /dev/null
+++ b/eng/python-devel.rst
@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _PythonDevelGuide:
+
+Python Development Guidelines
+*
+
+Python is the main programming language for the RTEMS Tools.  The RTEMS Tools
+run on the host computer of an RTEMS user or maintainer.  These guidelines
+cover the Python language version, the source code formatting, use of static
+analysis tools, type annotations, testing, code coverage, and documentation.
+There are exceptions for existing code and third-party code.  It is recommended
+to read the
+`PEP 8 - Style Guide for Python Code 
`_
+and the
+`Google Python Style Guide `_.
+
+Python Language Versions
+
+
+Although the official end-of-life of Python 2.7 was on January 1, 2020, the
+RTEMS Project still cares about Python 2.7 compatibility for some tools.  Every
+tool provided by the RTEMS Project which an RTEMS user may use to develop
+applications with RTEMS should be Python 2.7 compatible.  Examples are the
+build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale is
+that there are still some maintained Linux distributions in the wild which ship
+only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
+updates until June 2024.  Everything an RTEMS maintainer uses should be written
+in Python 3.6.
+
+Python Code Formatting
+==
+
+Good looking code is important.  Unfortunately, what looks good is a bit
+subjective and varies from developer to developer.  Arguing about the code
+format is not productive.  Code reviews should focus on more important topics,
+for example functionality, testability, and performance.  Fortunately, for
+Python there are some good automatic code formatters available.  All new code
+specifically developed for the RTEMS Tools should be piped through the
+`yapf `_ Python code formatter before it is
+committed or sent for review.  Use the default settings of the tool
+(`PEP 8 `_ coding style).
+
+You can disable the automatic formatting by the tool in a region starting with
+the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, for
+example
+
+.. code-block:: python
+
+# yapf: disable
+FOO = {
+# ... some very large, complex data literal.
+}
+
+BAR = [
+# ... another large data literal.
+]
+# yapf: enable
+
+For a single literal, you can disable the formatting like this:
+
+.. code-block:: python
+
+BAZ = {
+(1, 2, 3, 4),
+(5, 6, 7, 8),
+(9, 10, 11, 12),
+}  # yapf: disable
+
+Static Analysis Tools
+=
+
+Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
+commit your code or send it for review if the tools find some rule
+violations.  Run the tools with the default configuration.  If you have
+problems to silence the tools, then please ask for help on the :r:list:`devel`.
+Consult the tool documentation to silence false positives.
+
+Type Annotations
+
+
+For Python 3.6 or later code use type annotations.  All public functions of
+your modules should have `PEP 484 `_
+type annotations.  Check for type issues with the
+`mypy `_ static type checker.
+
+Testing
+===
+
+Write tests for your code with the
+`pytest `_ framework.  Use the
+`monkeypatch `_ mocking
+module.  Do not use the standard Python ``unittest`` and ``unittest.mock``
+modules.  Use ``coverage run -m pytest`` to run the tests with code coverage
+support.  If you modify existing code or contribute new code to a subproject
+which uses tests and the code coverage metric, then do not make the code
+coverage worse.
+
+Test Organization
+-
+
+Do not use test classes to group tests.  Use separate files instead.  Avoid
+deep test directory hierarchies.  For example, place tests for
+:file:`mymodule.py` in :file:`tests/test_mymodule.py`.  For 

[PATCH] user/gsoc: GSoC Getting Started Instructions

[G S Niteesh Babu]

---
 user/index.rst   |   1 +
 user/start/gsoc.rst  | 453 +++
 user/start/index.rst |   1 +
 3 files changed, 455 insertions(+)
 create mode 100644 user/start/gsoc.rst

diff --git a/user/index.rst b/user/index.rst
index 0e644c9..f253ea6 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
 
 .. topic:: Copyrights and License
 
+| |copy| 2020 Niteesh Babu
 | |copy| 2019 Vijay Kumar Banerjee
 | |copy| 2018 Amaan Cheval
 | |copy| 2018 Marçal Comajoan Cara
diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
new file mode 100644
index 000..071c1cc
--- /dev/null
+++ b/user/start/gsoc.rst
@@ -0,0 +1,453 @@
+.. comment: SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (C) 2020 Niteesh Babu 
+.. comment: All rights reserved.
+
+
+.. _QuickStartGSoC:
+
+GSoC Getting Started
+
+
+The goal of this page is to help you get RTEMS compiled and running so you can
+start with the real work.
+
+Please join the :r:list:`users` and :r:list:`devel` mailing lists and ask 
questions.
+Help correct any deficiencies in the code or documentation you spot, including
+those on the wiki. The ultimate goal of GSoC is to help you become part of the
+open source community.
+
+.. _QuickStartConfigureComputer:
+
+Configure a Development Computer
+
+
+You will be best served by using a GNU/Linux environment, which could be in a
+virtual machine, for example that uses `​Virtualbox 
`_
+and should run on most modern desktop systems. You should also be able to work
+with a MacOS or Windows system, but might encounter more difficulty than a *nix
+environment.
+
+Feel free to ask questions on the rtems-users mailing list in case you face
+trouble with the steps. If you want tools for another architecture, replace
+sparc in the RSB directions with another architecture, such as arm or mips. You
+can also use the RSB to build RTEMS directly, but we recommend that you learn
+how to build RTEMS by itself with the compiler tools generated by RSB.
+
+As you will be compiling a lot of code, it is recommended to have a reasonably
+fast development machine.
+
+The instructions in this chapter will help you in quickly setting up a
+development environment. For a detailed set of instruction please refer to the
+:ref:`QuickStart` chapter.
+
+You need tools for your host’s operating system to build the RTEMS tool suite
+from source. Please have a look at the :ref:`host-computer` chapter for the
+instructions to install the tools.
+
+Choosing an Installation Prefix
+---
+
+The term ``prefix`` refers to the path on your computer where the software is 
to
+be installed.
+In this case, we choose the home directory ``$HOME/rtems`` as our prefix.
+
+.. code-block:: none
+
+  mkdir $HOME/rtems
+
+Getting Sources
+---
+
+We obtain the source code for the :ref:`RTEMS Source Builder (RSB) ` and
+RTEMS from the RTEMS :r:url:`git`.
+
+The :ref:`RTEMS Source Builder (RSB) ` is the tool used to build RTEMS
+packages from source. We will be using the RSB to build RTEMS the source.
+Please have a look at the :ref:`RTEMS Source Builder (RSB) ` for more
+information.
+
+We'll clone to the repositories to ``$HOME/rtems/src``.
+
+.. code-block:: none
+
+  mkdir -p $HOME/rtems/src
+  cd $HOME/rtems/src
+  git clone git://git.rtems.org/rtems-source-builder.git rsb
+  git clone git://git.rtems.org/rtems.git
+
+Building the Tool suite
+---
+
+Once you have cloned the repositories and installed the required tools for
+your host operating system. You can start building the tools suite for your 
BSP.
+The tools suite is the collection of compiler, debugger, Assembler and other
+tools required for developing the software.
+
+You can check if your host is set up correctly using ``sb-check`` tool provided
+in the RSB repository.
+
+.. code-block:: none
+
+  cd $HOME/rtems/src/rsb/source-builder
+  ./sb-check
+
+If you installed all the required tools you should have the following output.
+
+.. code-block:: none
+
+  RTEMS Source Builder - Check, 5 (0b7e87143b76)
+  Environment is ok
+
+.. note:: The numbers may vary depending on the RSB release.
+
+The tool suite for RTEMS and the RTEMS sources are tightly coupled. For 
example,
+do not use a RTEMS version 5 tool suite with RTEMS version 4.11 sources and 
vice
+versa. In simple words, make sure you clone both the repositories at the same
+time.
+
+The tools suite is architecture specific. In this guide we will be building the
+tools suite for the SPARC architecture. So the tool suite name is sparc-rtems5.
+You can build the tools suite for other architectures like ARM, RISCV by
+replacing the architecture name. For example, for ARM the tools suite name 
would
+be arm-rtems5.
+
+The following command builds and installs the tools suite in the path mentioned
+in the prefix 

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Amar Takhar]

On 2020-03-17 15:20 +0100, Sebastian Huber wrote:
> 
> Ok, what would be a recommendation for the guidelines? Something like this:
> 
> Place tests for a module in a directory. Use individual test files for tests
> related to a particular class or functionality, e.g. module/test_xyz.py.
> 
> OR
> 
> Use individual test files for tests related to a particular class or
> functionality. Include the module name in the test file names, e.g.
> test_module_xyz.py.

The last one .. however the first does apply if we're going to have 1,000 test 
files.  I'd only use subdirs if it will be difficult to manage which is fairly 
rare.

It's nice to be able to 'ls -1' and get an overview of your entire module / 
class / support list in the file names.  It also makes it easy to relate back 
to 
the actual python file that is being tested.

For example:

mymodule.py -> tests/test_mymodule.py

mymodule.py:class First -> tests/test_mymodule_first.py
mymodule.py:class Second -> tests/test_mymodule_second.py
mymodule.py:class Third -> tests/test_mymodule_third.py

You can also do:

file_handler.py -> tests/test_file_handler_input.py
file_handler.py -> tests/test_file_handler_output.py

The 2nd is an example of grouping similar tests but doesn't necessarily reflect 
any classes in file_handler.py

When you really need to change your testing methodology it should really go 
into 
a different file.


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Amar Takhar]

On 2020-03-17 15:21 +0100, Sebastian Huber wrote:
> 
> It seems that pytest recommends monkeypatch:
> 
> https://docs.pytest.org/en/latest/monkeypatch.html
> 

Yes, also I use this:

  https://github.com/pytest-dev/pytest-mock

Plugins are extremely easy to use in pytest and are usually comprised of a 
single file we can include in our test suite.


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: GSoC Announcement: GSoC 2020 Student applications are now open (until March 31 at 1800 UTC)

[Joel Sherrill]

Hi

This should be passed along to any students interested.

Also they need to do our hello world task and work on their application.

--joel

-- Forwarded message -
From: Google Summer of Code Announce <
google-summer-of-code-annou...@googlegroups.com>
Date: Mon, Mar 16, 2020 at 1:14 PM
Subject: GSoC Announcement: GSoC 2020 Student applications are now open
(until March 31 at 1800 UTC)
To: Google Summer of Code Announce <
google-summer-of-code-annou...@googlegroups.com>


Interested university students can now apply to be a part of Google Summer
of Code 2020!


Visit the program site, g.co/gsoc, to register and start submitting your
project proposals for the organizations that interest you. Be sure to read
the Ideas Lists the 200 organizations
 mentoring students
this year have created, and reach out to the organizations early to get
feedback on your proposal so that you have the opportunity to edit it
before the final deadline of March 31 at 1800 UTC.


Read the Student Guide  for
important tips and information about the program. The guide was written by
Mentors, Org Administrators, former students and Google administrators.


Applications close Tuesday, March 31 at 18:00 UTC.  All final proposals
must be submitted before the deadline to be considered by the mentor
organizations.


Good luck!

- Google Open Source Programs Office

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Announce" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-announce/d516bb31-378f-429b-9e95-6f7adda3ae11%40googlegroups.com

.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Documentation of the Configuration Options

[Sebastian Huber]

Hello,

I added the configuration groups and options as specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt

I can generate the latest documentation sources one-to-one from the 
specification with this module:


https://git.rtems.org/sebh/rtems-qual.git/tree/rtemsqual/applconfig.py

My next step is to introduce the new templates:

https://devel.rtems.org/ticket/3900

https://devel.rtems.org/ticket/3901

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Docs: Adding GSoC Getting Started Instructions

[Gedare Bloom]

On Tue, Mar 17, 2020 at 2:12 AM Niteesh G. S.  wrote:
>
> On Tue, Mar 17, 2020 at 2:28 AM Gedare Bloom  wrote:
>>
>> On Mon, Mar 16, 2020 at 12:56 PM Niteesh G. S.  wrote:
>> >
>> > I am interested in taking up #3907. I'll mostly be copying and updating 
>> > the contents from the old wiki site.
>> >
>> > I have the following plan in mind. I'll start working on it if you are 
>> > happy with it.
>> >
>> > Add a new gsoc section in the user manual with contents
>> > from https://devel.rtems.org/wiki/GSoC (index.rst)
>> > Under this section, we'll have the following
>> > 1) GSoC getting started instructions 
>> > (https://devel.rtems.org/wiki/GSoC/GettingStarted)
>> > 2) Mentors list (https://devel.rtems.org/wiki/GSoC/Mentors)
>> > 3) Previous year GSoC information under separate pages.
>> >
>>
>> I think it should be separated somewhat. This GSoC stuff is not right
>> to put in the User Manual, except for the Getting Started guide. There
>> is the full "Quick Start"
>> https://docs.rtems.org/branches/master/user/start/index.html#  that
>> may be too complicated for new users, but that area of the user manual
>> is probably where the simplified "GSoC" guide should live.
>
>
> I'll start with adding the getting started instructions in the quick start 
> section and later start working on the
> Learning with RTEMS section.
> Regarding the getting started instructions, should we ask the user to refer 
> to the quick start section for
> build instructions or should we repeat them? The old wiki tells to refer the 
> quick start guide for build
> instructions but IMHO having all the instructions in one place will make it 
> easy for the newcomers.
>

I agree with you that having a simplified build instructions for
newcomers is good. And provide the pointer to the full instructions.

>
>>
>> That said, I'd be OK with introducing a new "Learning with RTEMS"
>> Manual that covers both SoC, GCI, and maybe can be expanded over time.
>> As a kind of "beginner friendly / student-oriented" guide?
>>
>> > Niteesh
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Sebastian Huber]

On 17/03/2020 06:54, Sebastian Huber wrote:

On 16/03/2020 20:26, Amar Takhar wrote:

I should have also added some of my own reasons why pytest is better 
for writing

tests in Python:

   - Fantastic exception handling makes it far easier to debug test 
and code.

 PDB works seamlessly.
   - Far less overhead in creating initial tests.
   - Trivial fixture support
   - Paramaterised tests -- this is incredibly essential / useful.

Another feature that's not often mentioned is pytest discovers tests 
all on its
own.  You can put a test anywhere labled test_*.py and it will work.  
You can

run pytest anywhere in the source as well.

The above are starkly different from unittest where these features 
don't exist

or are difficult / have a large overhead to implement.
What is your recommendation with respect to the use of unittest.mock? 


It seems that pytest recommends monkeypatch:

https://docs.pytest.org/en/latest/monkeypatch.html

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Sebastian Huber]

On 17/03/2020 13:55, Amar Takhar wrote:


On 2020-03-17 06:52 +0100, Sebastian Huber wrote:

So you would not use test classes to group tests for a specific class?

No I would not typically grouping tests involves keeping them in separate files.
You gain no advantage to keeping them all in one large file.  You can also use
directory structures to do this as well.


Ok, what would be a recommendation for the guidelines? Something like this:

Place tests for a module in a directory. Use individual test files for 
tests related to a particular class or functionality, e.g. 
module/test_xyz.py.


OR

Use individual test files for tests related to a particular class or 
functionality. Include the module name in the test file names, e.g. 
test_module_xyz.py.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Description of rtems-libbsd testsuite applications

[Gabriel.Moyano]

Hello Sebastian,

I followed your recommendations regarding rtems_test_begin(), rtems_test_end() 
and RTEMS_TEST_STATE_USER_INPUT. Now I'm working on getting running the 
rtems-libbsd testsuit with RTEMS Tester.

I would like to ask you 2 questions:


1.   About arphole: In the arp_processor() function there is an "if" 
statement which verify 3 conditions. One of them is that spa (source protocol 
address) should be equal to INADDR_ANY which is 0.0.0.0 and this never happens. 
From my understanding, if the spa could be any address there is no need to test 
this condition. Is this right?



2.   About dhcpcd01 and dhcpcd02: RTEMS Tester gives a timeout error as a 
result. I think this is because no exit() call happens. Dhcpcd creates a file 
under /var/db/dhcpcd_.lease after obtaining a lease. Maybe this could 
be used as exit condition in test_main() in case of dhcpcd02. A similar 
solutions could be implemented for the dhcp hook in dhcpcd01 but instead of 
printing out the environment variables, writing them into a file and checking 
whether this file exists in test_main(). What do you think?

Please let me know if you have any suggestion.

Thanks for your help,
Gabriel

--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
Simulation and Software Technology | Lilienthalplatz 7 | 38108 Braunschweig  | 
Germany

Dipl.-Ing Gabriel Moyano | Research Scientist in Onboard Software Systems group
DLR.de

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Joel Sherrill]

I should have said that I am OK with this patch and if the examples build
with the the waf patch to the examples build system, I'm OK with that also.

I am not comfortable reviewing the patch to the rtems waf infrastructure.

Sebastian, if you can push these, it would be appreciated. I'm about to
head into meetings and won't possibly get to it before this afternoon.

--joel

On Tue, Mar 17, 2020 at 8:03 AM Joel Sherrill  wrote:

> The examples are released with each RTEMS version. The examples master
> should track RTEMS master.
>
> https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003/  includes a
> mated rtems-examples.
>
>  --joel
>
> On Tue, Mar 17, 2020 at 5:11 AM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 17, 2020 at 3:25 PM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Should the examples also work with RTEMS 4.10 or 4.11?
>>>
>>> That's a good point. Should we sort out the examples that are not
>> expected
>> to work on 4.10 and 4.11 (like lvgl example) and do this change only on
>> those
>> files?
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Joel Sherrill]

The examples are released with each RTEMS version. The examples master
should track RTEMS master.

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003/  includes a
mated rtems-examples.

 --joel

On Tue, Mar 17, 2020 at 5:11 AM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
> On Tue, Mar 17, 2020 at 3:25 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Should the examples also work with RTEMS 4.10 or 4.11?
>>
>> That's a good point. Should we sort out the examples that are not expected
> to work on 4.10 and 4.11 (like lvgl example) and do this change only on
> those
> files?
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Amar Takhar]

On 2020-03-17 06:52 +0100, Sebastian Huber wrote:
> So you would not use test classes to group tests for a specific class?

No I would not typically grouping tests involves keeping them in separate 
files.  
You gain no advantage to keeping them all in one large file.  You can also use 
directory structures to do this as well.

Test classes are useful if you need to do setup and tear down.  For instance 
instantiating a class that all the tests run on or starting / stopping hardware 
you are testing.

Otherwise keep them as plain functions.


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Improve Python 3 compatibility

[Chris Johns]

Thanks, please push.

On 17/3/20 6:34 pm, Sebastian Huber wrote:
> ---
>  tester/rt/check.py | 2 +-
>  wscript| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/rt/check.py b/tester/rt/check.py
> index c7f6c23..2a38d99 100755
> --- a/tester/rt/check.py
> +++ b/tester/rt/check.py
> @@ -284,7 +284,7 @@ class warnings_errors:
>  common = warnings['common']
>  for build in builds:
>  build_warnings = warnings[build]
> -if build is not 'common':
> +if build != 'common':
>  build_warnings = [w for w in build_warnings if w not in 
> common]
>  s += textbox.row(cols_1,
>   [' %s : %d warning(s)' % (build,
> diff --git a/wscript b/wscript
> index bd7c54d..1f5bbea 100644
> --- a/wscript
> +++ b/wscript
> @@ -135,7 +135,7 @@ def check_options(ctx, host):
>  ctx.env.CXX = '%s-g++' % (host)
>  ctx.env.AR = '%s-ar' % (host)
>  ctx.env.PYTHON = 'python'
> -elif host is not 'native':
> +elif host != 'native':
>  ctx.fatal('unknown host: %s' % (host));
>  
>  #
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Vijay Kumar Banerjee]

On Tue, Mar 17, 2020 at 3:25 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Should the examples also work with RTEMS 4.10 or 4.11?
>
> That's a good point. Should we sort out the examples that are not expected
to work on 4.10 and 4.11 (like lvgl example) and do this change only on
those
files?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Sebastian Huber]

Should the examples also work with RTEMS 4.10 or 4.11?

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[rtems-examples PATCH 2/2] Replace deprecated CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

[Vijay Kumar Banerjee]

---
 benchmarks/nbench/main.c| 2 +-
 c11/c11_cndvar01/rtems_config.c | 2 +-
 c11/c11_key01/rtems_config.c| 2 +-
 c11/c11_mutex01/rtems_config.c  | 2 +-
 c11/c11_thread01/rtems_config.c | 2 +-
 file_io/crc/init.c  | 2 +-
 file_io/fdopen/README   | 2 +-
 file_io/fdopen/test.c   | 2 +-
 file_io/filerdback/test.c   | 2 +-
 file_io/repeated_opens/test.c   | 2 +-
 filesystem/fat_ramdisk/init.c   | 2 +-
 led/complex1/main.cc| 2 +-
 lvgl/hello/test.c   | 2 +-
 micromonitor/umon/test.c| 2 +-
 misc/adamain/rtems_init.c   | 2 +-
 misc/minimum/test.c | 2 +-
 misc/qemu_vfat/system.h | 2 +-
 ticker/low_ticker/init.c| 2 +-
 ticker/low_ticker1/init.c   | 2 +-
 ticker/low_ticker2/init.c   | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/benchmarks/nbench/main.c b/benchmarks/nbench/main.c
index f330255..68f799e 100644
--- a/benchmarks/nbench/main.c
+++ b/benchmarks/nbench/main.c
@@ -20,7 +20,7 @@
 #define CONFIGURE_MICROSECONDS_PER_TICK 1000
 #define CONFIGURE_TICKS_PER_TIMESLICE 5
 
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 50
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 50
 #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
 
 #define CONFIGURE_SWAPOUT_TASK_PRIORITY 220
diff --git a/c11/c11_cndvar01/rtems_config.c b/c11/c11_cndvar01/rtems_config.c
index a596695..218bfe9 100644
--- a/c11/c11_cndvar01/rtems_config.c
+++ b/c11/c11_cndvar01/rtems_config.c
@@ -45,7 +45,7 @@ static void *POSIX_Init(void *arg)
 
 #define CONFIGURE_UNLIMITED_OBJECTS
 #define CONFIGURE_UNIFIED_WORK_AREAS
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
 
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE (64 * 1024)
 
diff --git a/c11/c11_key01/rtems_config.c b/c11/c11_key01/rtems_config.c
index b8fd346..b33ebbc 100644
--- a/c11/c11_key01/rtems_config.c
+++ b/c11/c11_key01/rtems_config.c
@@ -45,7 +45,7 @@ static void *POSIX_Init(void *arg)
 
 #define CONFIGURE_UNLIMITED_OBJECTS
 #define CONFIGURE_UNIFIED_WORK_AREAS
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
 
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE (64 * 1024)
 
diff --git a/c11/c11_mutex01/rtems_config.c b/c11/c11_mutex01/rtems_config.c
index b72f679..3d9f8d3 100644
--- a/c11/c11_mutex01/rtems_config.c
+++ b/c11/c11_mutex01/rtems_config.c
@@ -45,7 +45,7 @@ static void *POSIX_Init(void *arg)
 
 #define CONFIGURE_UNLIMITED_OBJECTS
 #define CONFIGURE_UNIFIED_WORK_AREAS
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
 
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE (64 * 1024)
 
diff --git a/c11/c11_thread01/rtems_config.c b/c11/c11_thread01/rtems_config.c
index 43c8e07..4bfded6 100644
--- a/c11/c11_thread01/rtems_config.c
+++ b/c11/c11_thread01/rtems_config.c
@@ -45,7 +45,7 @@ static void *POSIX_Init(void *arg)
 
 #define CONFIGURE_UNLIMITED_OBJECTS
 #define CONFIGURE_UNIFIED_WORK_AREAS
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
 
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE (64 * 1024)
 
diff --git a/file_io/crc/init.c b/file_io/crc/init.c
index 4888e70..f05ab24 100644
--- a/file_io/crc/init.c
+++ b/file_io/crc/init.c
@@ -54,7 +54,7 @@ rtems_task Init(
 
 /* filesystem */
 #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 40
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 40
 #define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK 512
 
 /* tasks */
diff --git a/file_io/fdopen/README b/file_io/fdopen/README
index dee115d..6584480 100644
--- a/file_io/fdopen/README
+++ b/file_io/fdopen/README
@@ -57,7 +57,7 @@ into 0302), I would appreciate it.
 #define CONFIGURE_MAXIMUM_TASKS   20
 #define CONFIGURE_MAXIMUM_TIMERS  20
 #define CONFIGURE_MAXIMUM_PERIODS 1
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS  10
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS  10
 #define CONFIGURE_INIT_TASK_STACK_SIZE(32*1024)
 #define CONFIGURE_INIT_TASK_PRIORITY  90
 #define CONFIGURE_INIT_TASK_INITIAL_MODES (RTEMS_PREEMPT | \
diff --git a/file_io/fdopen/test.c b/file_io/fdopen/test.c
index 5ab50a5..388624f 100644
--- a/file_io/fdopen/test.c
+++ b/file_io/fdopen/test.c
@@ -74,7 +74,7 @@ rtems_task Init(
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
 
 #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
-#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 6
+#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 6
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 #define CONFIGURE_MAXIMUM_TASKS 1
diff --git a/file_io/filerdback/test.c b/file_io/filerdback/test.c
index ef0a4cc..96d983f 100644
--- a/file_io/filerdback/test.c
+++ b/file_io/filerdback/test.c
@@ -56,7 +56,7 @@ rtems_task Init(
 
 #define CONFIGURE_MAXIMUM_TASKS 1
 #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
-#define 

[rtems-examples PATCH 1/2] filesystem: Add checks for rtems-bin2c

[Vijay Kumar Banerjee]

---
 file_io/crc/wscript| 23 ---
 filesystem/fat_ramdisk/wscript | 18 +-
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/file_io/crc/wscript b/file_io/crc/wscript
index 531da20..45384a9 100644
--- a/file_io/crc/wscript
+++ b/file_io/crc/wscript
@@ -26,14 +26,15 @@ def build(bld):
 #
 # Package the root file system as a C file.
 #
-rootfs.build_from_src_root(bld,
-   name = 'fs-root',
-   root = 'rootfs')
-
-bld(features = 'c cprogram',
-target = 'crc.exe',
-includes = bld.includes,
-defines = bld.defines,
-source = ['init.c',
-  'fs-root-tar.c',
-  'crc_32.c'])
+if rtems.check_env(bld, 'RTEMS_BIN2C'):
+rootfs.build_from_src_root(bld,
+   name = 'fs-root',
+   root = 'rootfs')
+
+bld(features = 'c cprogram',
+target = 'crc.exe',
+includes = bld.includes,
+defines = bld.defines,
+source = ['init.c',
+  'fs-root-tar.c',
+  'crc_32.c'])
diff --git a/filesystem/fat_ramdisk/wscript b/filesystem/fat_ramdisk/wscript
index a980187..ecf216f 100644
--- a/filesystem/fat_ramdisk/wscript
+++ b/filesystem/fat_ramdisk/wscript
@@ -26,17 +26,17 @@ def build(bld):
 #
 # Package the root file system as a C file.
 #
-rootfs.build_from_src_root(bld,
-   name = 'fs-root',
-   root = 'rootfs')
+if rtems.check_env(bld, 'RTEMS_BIN2C', 'RTEMS_TLD'):
+rootfs.build_from_src_root(bld,
+   name = 'fs-root',
+   root = 'rootfs')
 
-bld(features = 'c cprogram',
-target = 'fat_ramdisk.exe',
-includes = bld.includes,
-defines = bld.defines,
-source = ['init.c', 'fs-root-tar.c'])
+bld(features = 'c cprogram',
+target = 'fat_ramdisk.exe',
+includes = bld.includes,
+defines = bld.defines,
+source = ['init.c', 'fs-root-tar.c'])
 
-if rtems.check_env(bld, 'RTEMS_TLD'):
 bld(features = 'c rtrace',
 target = 'fat_ramdisk.texe',
 includes = bld.includes,
-- 
2.21.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[rtems_waf PATCH] rtems: Allow checking multiple environment variable

[Vijay Kumar Banerjee]

---
 rtems.py | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/rtems.py b/rtems.py
index 6dd71b1..ceabcd9 100644
--- a/rtems.py
+++ b/rtems.py
@@ -479,10 +479,11 @@ def check_options(ctx, prefix, rtems_tools, rtems_path, 
rtems_version, rtems_arc
 
 return rtems_version, rtems_path, tools, archs, arch_bsps
 
-def check_env(ctx, var):
-if var in ctx.env and len(ctx.env[var]) != 0:
-return True
-return False
+def check_env(ctx, *env_vars):
+for v in env_vars:
+if v not in ctx.env or len(ctx.env[v]) == 0:
+return False
+return True
 
 def check(ctx, option, setting = 'Yes'):
 if option in ctx.env:
-- 
2.21.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What sanitizers preferred?

[suyash singh]

I have asked about the constraints on LLVM sanitizers github. Waiting for
their response.

If sanitizers is not possible, is only adding clang-analyzer too small a
project for GSOC?

If its too small there are several clang tools like thread safety analysis,
clang format and clang check which could be added. I don't know about their
usefulness in RTEMS.

On Mon, Mar 16, 2020 at 11:59 PM Gedare Bloom  wrote:

> On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 15/03/2020 17:52, suyash singh wrote:
> >>
> >> Hello,
> >> Out of
> >> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and
> DataFlowSanitizer.
> >>
> >> Are all of them useful as RTEMS-tools to integrate? Any other
> sanitizers suggested?
> >>
> >> Asking as part of my proposed gsoc project,
> >>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
> >>
> >> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
> >
> >
> > +1
> >
> > Another area is the compiler stack protection techniques. I have no idea
> if those are applicable to RTEMS but they would be useful if they can work.
> >
> > Ignoring other constraints from embedded systems, any possible technique
> to use with RTEMS must be evaluated against the constraints imposed by
> having a single address space, no VM, and single process model.
> >
> > You need to check if any of these will work before this project has a
> chance.
> >
> > I would be willing to entertain a project for an appropriate solution
> that is limited to say ARM, x86, and RISC-V.
> >
> +1
>
> UBSan is a good candidate.
>
> > --joel
> >
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] c-user: Canonicalize configuration option groups

[Sebastian Huber]

Update #3836.
---
 c-user/config/bdbuf.rst   |  4 ++--
 c-user/config/classic-api.rst |  3 +--
 c-user/config/classic-init-task.rst   |  5 ++---
 c-user/config/device-driver.rst   |  8 ++--
 c-user/config/event-record.rst|  2 ++
 c-user/config/filesystem.rst  |  1 +
 c-user/config/general.rst |  3 +--
 c-user/config/idle-task.rst   |  3 +--
 c-user/config/mpci.rst| 13 ++---
 c-user/config/posix-api.rst   |  8 
 c-user/config/posix-init-thread.rst   |  5 ++---
 c-user/config/scheduler-clustered.rst |  1 +
 c-user/config/scheduler-general.rst   | 14 --
 c-user/config/task-stack-alloc.rst|  7 ---
 14 files changed, 37 insertions(+), 40 deletions(-)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index 011d4ee..7c4ba52 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -5,8 +5,8 @@
 Block Device Cache Configuration
 
 
-This section defines Block Device Cache (bdbuf) related configuration
-parameters.
+This section describes configuration options related to the Block Device Cache
+(bdbuf).
 
 .. index:: CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
index 6c8f6ca..3647d05 100644
--- a/c-user/config/classic-api.rst
+++ b/c-user/config/classic-api.rst
@@ -5,8 +5,7 @@
 Classic API Configuration
 =
 
-This section defines the Classic API related system configuration parameters
-supported by .
+This section describes configuration options related to the Classic API.
 
 .. index:: CONFIGURE_MAXIMUM_BARRIERS
 
diff --git a/c-user/config/classic-init-task.rst 
b/c-user/config/classic-init-task.rst
index cbbec9a..8eaafca 100644
--- a/c-user/config/classic-init-task.rst
+++ b/c-user/config/classic-init-task.rst
@@ -5,9 +5,8 @@
 Classic API Initialization Task Configuration
 =
 
-The  configuration system can automatically generate an
-Initialization Tasks Table named ``Initialization_tasks`` with a single entry.
-The following parameters control the generation of that table.
+This section describes configuration options related to the Classic API
+initialization task.
 
 .. index:: CONFIGURE_INIT_TASK_ARGUMENTS
 
diff --git a/c-user/config/device-driver.rst b/c-user/config/device-driver.rst
index 38638ce..7a1196d 100644
--- a/c-user/config/device-driver.rst
+++ b/c-user/config/device-driver.rst
@@ -5,12 +5,8 @@
 Device Driver Configuration
 ===
 
-This section defines the configuration parameters related to the automatic
-generation of a Device Driver Table.  As  only is aware
-of a small set of standard device drivers, the generated Device Driver Table is
-suitable for simple applications with no custom device drivers.
-
-Note that network device drivers are not configured in the Device Driver Table.
+This section describes configuration options related to the device drivers.
+Note that network device drivers are not covered by the following options.
 
 .. index:: CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
 
diff --git a/c-user/config/event-record.rst b/c-user/config/event-record.rst
index 6ac0db0..01e9af2 100644
--- a/c-user/config/event-record.rst
+++ b/c-user/config/event-record.rst
@@ -5,6 +5,8 @@
 Event Recording Configuration
 =
 
+This section describes configuration options related to the event recording.
+
 .. index:: CONFIGURE_RECORD_EXTENSIONS_ENABLED
 
 .. _CONFIGURE_RECORD_EXTENSIONS_ENABLED:
diff --git a/c-user/config/filesystem.rst b/c-user/config/filesystem.rst
index 43b0db0..2936e1a 100644
--- a/c-user/config/filesystem.rst
+++ b/c-user/config/filesystem.rst
@@ -5,6 +5,7 @@
 Filesystem Configuration
 
 
+This section describes configuration options related to filesytems.
 By default, the In-Memory Filesystem (IMFS) is used as the base filesystem 
(also
 known as root filesystem).  In order to save some memory for your application,
 you can disable the filesystem support with the
diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index f5f44d3..52d2743 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -5,8 +5,7 @@
 General System Configuration
 
 
-This section defines the general system configuration options supported by
-.
+This section describes general system configuration options.
 
 .. index:: CONFIGURE_DIRTY_MEMORY
 
diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
index ef8b192..a39aaa1 100644
--- a/c-user/config/idle-task.rst
+++ b/c-user/config/idle-task.rst
@@ -5,8 +5,7 @@
 Idle Task Configuration
 ===
 
-This section defines the IDLE task related configuration parameters supported
-by .
+This section describes configuration options related to the idle tasks.
 
 

Re: RTEMS Docs: Adding GSoC Getting Started Instructions

[Niteesh G. S.]

On Tue, Mar 17, 2020 at 2:28 AM Gedare Bloom  wrote:

> On Mon, Mar 16, 2020 at 12:56 PM Niteesh G. S. 
> wrote:
> >
> > I am interested in taking up #3907. I'll mostly be copying and updating
> the contents from the old wiki site.
> >
> > I have the following plan in mind. I'll start working on it if you are
> happy with it.
> >
> > Add a new gsoc section in the user manual with contents
> > from https://devel.rtems.org/wiki/GSoC (index.rst)
> > Under this section, we'll have the following
> > 1) GSoC getting started instructions (
> https://devel.rtems.org/wiki/GSoC/GettingStarted)
> > 2) Mentors list (https://devel.rtems.org/wiki/GSoC/Mentors)
> > 3) Previous year GSoC information under separate pages.
> >
>
> I think it should be separated somewhat. This GSoC stuff is not right
> to put in the User Manual, except for the Getting Started guide. There
> is the full "Quick Start"
> https://docs.rtems.org/branches/master/user/start/index.html#  that
> may be too complicated for new users, but that area of the user manual
> is probably where the simplified "GSoC" guide should live.
>

I'll start with adding the getting started instructions in the quick start
section and later start working on the
Learning with RTEMS section.
Regarding the getting started instructions, should we ask the user to refer
to the quick start section for
build instructions or should we repeat them? The old wiki tells to refer
the quick start guide for build
instructions but IMHO having all the instructions in one place will make it
easy for the newcomers.



> That said, I'd be OK with introducing a new "Learning with RTEMS"
> Manual that covers both SoC, GCI, and maybe can be expanded over time.
> As a kind of "beginner friendly / student-oriented" guide?
>
> > Niteesh
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Improve Python 3 compatibility

[Sebastian Huber]

---
 tester/rt/check.py | 2 +-
 wscript| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rt/check.py b/tester/rt/check.py
index c7f6c23..2a38d99 100755
--- a/tester/rt/check.py
+++ b/tester/rt/check.py
@@ -284,7 +284,7 @@ class warnings_errors:
 common = warnings['common']
 for build in builds:
 build_warnings = warnings[build]
-if build is not 'common':
+if build != 'common':
 build_warnings = [w for w in build_warnings if w not in common]
 s += textbox.row(cols_1,
  [' %s : %d warning(s)' % (build,
diff --git a/wscript b/wscript
index bd7c54d..1f5bbea 100644
--- a/wscript
+++ b/wscript
@@ -135,7 +135,7 @@ def check_options(ctx, host):
 ctx.env.CXX = '%s-g++' % (host)
 ctx.env.AR = '%s-ar' % (host)
 ctx.env.PYTHON = 'python'
-elif host is not 'native':
+elif host != 'native':
 ctx.fatal('unknown host: %s' % (host));
 
 #
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems_littlevgl 1/2] waf: Remove unnecessary code.

[Christian Mauderer]

Hello Vijay,

thanks for the hint and the review. I removed the objects too. Beneath
that I added another patch to use a release version of lvgl.

Best regards

Christian

On 16/03/2020 21:50, Vijay Kumar Banerjee wrote:
> Hi!
> 
> On Wed, Mar 11, 2020 at 7:59 PM Christian Mauderer
>  > wrote:
> 
> ---
>  lvgl.py | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..d6584f7 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -77,12 +77,6 @@ def build(bld):
>          if source_dir not in include_paths:
>              include_paths.append(source_dir)
> 
> -    bld.objects(target = objects,
> -                features = 'c',
> -                cflags = '-O2',
> -                includes = includes,
> -                source = source)
> -
>      bld.stlib(target = 'lvgl',
>                features = 'c',
>                includes = includes,
> 
> 
> I think `use=objects` isn't required either in the next line. This
> builds fine.
> 
> Best regards,
> Vijay
> 
> -- 
> 2.16.4
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 rtems_littlevgl 2/3] waf: Enable optimization and debug symbols.

[Christian Mauderer]

---
 lvgl.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lvgl.py b/lvgl.py
index f275287..b91a265 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -77,6 +77,7 @@ def build(bld):
 
 bld.stlib(target = 'lvgl',
   features = 'c',
+  cflags = ['-O2', '-g'],
   includes = includes,
   source = sources)
 
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

---
 lvgl.py | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/lvgl.py b/lvgl.py
index 5452ed0..f275287 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -68,26 +68,17 @@ def build(bld):
 
 sources, includes = source_list(bld)
 includes.append('.')
-objects = []
 include_paths = []
 
 for source in sources:
-objects.append(source[:-1] + 'o')
 source_dir = os.path.dirname(source)
 if source_dir not in include_paths:
 include_paths.append(source_dir)
 
-bld.objects(target = objects,
-features = 'c',
-cflags = '-O2',
-includes = includes,
-source = source)
-
 bld.stlib(target = 'lvgl',
   features = 'c',
   includes = includes,
-  source = sources,
-  use = objects)
+  source = sources)
 
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 rtems_littlevgl 3/3] Update to lvgl v6.1.2

[Christian Mauderer]

---
 lv_drivers | 2 +-
 lvgl   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lv_drivers b/lv_drivers
index 117812e..24cedaa 16
--- a/lv_drivers
+++ b/lv_drivers
@@ -1 +1 @@
-Subproject commit 117812eec9a5b82fe879f53ee0d1bf39cb9027c8
+Subproject commit 24cedaa756b83c50c36f4aa0c625fcdfba89431b
diff --git a/lvgl b/lvgl
index 94c95bc..2ead495 16
--- a/lvgl
+++ b/lvgl
@@ -1 +1 @@
-Subproject commit 94c95bc9e461847a734a5bde9818fa837d343425
+Subproject commit 2ead4959038fcfd01eaee0f124b98a8ae3efec21
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello world and query about a project availability

[Richi Dubey]

Thanks for telling me about the copyright and licensing issue. I would
submit a new patch before the end of the day.


On Sat, Mar 14, 2020 at 4:52 AM Gedare Bloom  wrote:
>
> On Fri, Mar 13, 2020 at 2:04 PM Richi Dubey  wrote:
> >
> > Dear Dr. Bloom,
> >
> > Please find my patch given below :-
> >
> > From 296fa828fec7c3f99231b377c57ca20411564703 Mon Sep 17 00:00:00 2001
> > From: Richi Dubey 
> > Date: Sat, 14 Mar 2020 01:33:02 +0530
> > Subject: [PATCH 2/2] Changed the hello world file
> >
> > ---
> >  testsuites/samples/hello/init.c | 43 +++--
> >  1 file changed, 14 insertions(+), 29 deletions(-)
> >
> > diff --git a/testsuites/samples/hello/init.c 
> > b/testsuites/samples/hello/init.c
> > index 34ded37c55..e29306e7c9 100644
> > --- a/testsuites/samples/hello/init.c
> > +++ b/testsuites/samples/hello/init.c
> > @@ -1,44 +1,29 @@
> > -/*
> > - *  COPYRIGHT (c) 1989-2012.
> > - *  On-Line Applications Research Corporation (OAR).
> > - *
> > - *  The license and distribution terms for this file may be
> > - *  found in the file LICENSE in this distribution or at
> > - *  http://www.rtems.org/license/LICENSE.
> > - */
> > -
> It is incorrect to remove someone else's copyright and licensing information.
>
> > -#ifdef HAVE_CONFIG_H
> > -#include "config.h"
> > -#endif
> > -
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> >
> > -const char rtems_test_name[] = "HELLO WORLD";
> > -
> > -static rtems_task Init(
> > +rtems_task Init(
> >rtems_task_argument ignored
> >  )
> >  {
> > -  rtems_print_printer_fprintf_putc(_test_printer);
> > -  TEST_BEGIN();
> > -  printf( "Hello World\n" );
> > -  TEST_END();
> > -  rtems_test_exit( 0 );
> > +  printf( "\n\n*** Hello RTEMS 2020! Let's do something new :) ***\n" );
> > +  printf( "Hello Everyone\n" );
> > +  printf( "*** Bubyee ***\n" );
> > +  exit( 0 );
>
> Although you were successful, this patch includes a lot of unnecessary
> changes. When you work on code and do submit patches, you should
> minimize non-relevant changes.
>
> >  }
> >
> > +/* configuration information */
> > +
> > +#include 
> >
> >  /* NOTICE: the clock driver is explicitly disabled */
> >  #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
> > -#define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
> > -
> > -#define CONFIGURE_MAXIMUM_TASKS1
> > +#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> > +#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
> >
> >  #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> > -
> > -#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
> > -
> > -#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
> > +#define CONFIGURE_MAXIMUM_TASKS 1
> >
> >  #define CONFIGURE_INIT
> >  #include 
> > +/* end of file */
> > --
> > 2.17.1
> >
> > On Fri, Mar 13, 2020 at 12:54 AM Gedare Bloom  wrote:
> > >
> > > On Thu, Mar 12, 2020 at 1:23 PM Gedare Bloom  wrote:
> > > >
> > > > Hi Richi,
> > > >
> > > > Welcome. The "Improve the SMP Scheduler" will require strong C
> > > > programming skills before the summer. You will be expected to
> > > > demonstrate that during the proposal period. I'm the only likely
> > > > mentor for that project this year, and I haven't decided if I will
> > > > mentor any projects, or which project I might mentor if I do. So it
> > > > can be a bit risky to pursue that project, but if you are passionate
> > > > about it and have the required capabilities, then you should start to
> > > > prepare a proposal and convince me that I should mentor you :).
> > > >
> > > > The project itself is a straightforward implementation from the
> > > > current skeleton of the scheduler. So you will want to also include
> > > > some "extension" activities in case you complete the scheduler
> > > > quickly.
> > > >
> > > > You should add yourself to https://devel.rtems.org/wiki/GSoC/2020
> > > >
> > > PS: thanks for the screenshot, please send your patch as well.
> > >
> > > > Gedare
> > > >
> > > > On Thu, Mar 12, 2020 at 1:04 PM Richi Dubey  
> > > > wrote:
> > > > >
> > > > > Hey everyone,
> > > > >
> > > > > Could someone please tell me if this project
> > > > > (https://devel.rtems.org/ticket/2510) titled
> > > > > "Improve the SMP scheduler with arbitrary processor affinity support"
> > > > > still open? I went through the mpi-sws paper and I found the concept
> > > > > of implementing
> > > > > task's affinity to a processor to increase its efficiency really
> > > > > interesting. Can someone please help me with this?
> > > > >
> > > > > Thanks,
> > > > > Richi.
> > > > > ___
> > > > > devel mailing list
> > > > > devel@rtems.org
> > > > > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello world and query about a project availability

[Richi Dubey]

Dear Dr. Bloom,

I have added my name on the GSoC Tracking list and have shared a draft
proposal with you. Please suggest changes in my proposal:
https://docs.google.com/document/d/1bth9sh3qH2vMTks1yiGpZVskUcD-g5jED4a3zJx1Klc/edit?usp=sharing

Also, currently the extension ideas I have in my mind are following:

1) Add support for multiple criticalilty level for tasks, and work on
another scheduler which would takes into account criticality level and
the multicore system. For example: EDF-VD by Dr. Baruah as it is 100%
schedulable.
2) Add priority ordering for asynchronous task according to Audsley's
optimal priority ordering
(https://www.sciencedirect.com/science/article/pii/S002001901654)

Please let me know your thoughts.

Thanks,
Richi.

On Fri, Mar 13, 2020 at 12:53 AM Gedare Bloom  wrote:
>
> Hi Richi,
>
> Welcome. The "Improve the SMP Scheduler" will require strong C
> programming skills before the summer. You will be expected to
> demonstrate that during the proposal period. I'm the only likely
> mentor for that project this year, and I haven't decided if I will
> mentor any projects, or which project I might mentor if I do. So it
> can be a bit risky to pursue that project, but if you are passionate
> about it and have the required capabilities, then you should start to
> prepare a proposal and convince me that I should mentor you :).
>
> The project itself is a straightforward implementation from the
> current skeleton of the scheduler. So you will want to also include
> some "extension" activities in case you complete the scheduler
> quickly.
>
> You should add yourself to https://devel.rtems.org/wiki/GSoC/2020
>
> Gedare
>
> On Thu, Mar 12, 2020 at 1:04 PM Richi Dubey  wrote:
> >
> > Hey everyone,
> >
> > Could someone please tell me if this project
> > (https://devel.rtems.org/ticket/2510) titled
> > "Improve the SMP scheduler with arbitrary processor affinity support"
> > still open? I went through the mpi-sws paper and I found the concept
> > of implementing
> > task's affinity to a processor to increase its efficiency really
> > interesting. Can someone please help me with this?
> >
> > Thanks,
> > Richi.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

[Sebastian Huber]

On 17/03/2020 01:05, Amar Takhar wrote:


On 2020-03-17 10:55 +1100, Chris Johns wrote:

On 17/3/20 7:21 am, Sebastian Huber wrote:

Chris, what do you think about using pytest in favour of the standard Python
unitttest?

I am fine with pytest. Testing is a development feature and so we can have a
different criteria for the needed dependencies.

If we're choosing pytest I'd like to see explicit documentation of what pattern
to use for which situations.

It's really easy to fall into traditional patterns for non Python languages
which means we lose advantages of going to pytest.
This sounds like a great addition to the Testing section in the new 
Python Development Guidelines chapter of the engineering manual.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel