date:20200327

---
 user/start/app.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/start/app.rst b/user/start/app.rst
index 98fb284..a0c4a04 100644
--- a/user/start/app.rst
+++ b/user/start/app.rst
@@ -64,14 +64,14 @@ settings:
 /*
  * Simple RTEMS configuration
  */
-#include 
 
-#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
-#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
+
+#define CONFIGURE_UNLIMITED_OBJECTS
+#define CONFIGURE_UNIFIED_WORK_AREAS
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
-#define CONFIGURE_MAXIMUM_TASKS 1
 
 #define CONFIGURE_INIT
 
-- 
2.16.4

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

[PATCH 2/2] user: Use consitent Hello World spelling

---
 user/exe/initialization.rst | 2 +-
 user/start/app.rst  | 4 ++--
 user/tools/boot-image.rst   | 2 +-
 user/tools/tester.rst   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/user/exe/initialization.rst b/user/exe/initialization.rst
index cfe39d6..6c9d657 100644
--- a/user/exe/initialization.rst
+++ b/user/exe/initialization.rst
@@ -82,7 +82,7 @@ system is based on the `FreeBSD SYSINT Framework
 initialization is performed before multitasking is started.
 
 The RTEMS Tool ``rtems-exeinfo`` can provide some detail about the registered
-handlers. The following shows the initialization handlers for the *hello world*
+handlers. The following shows the initialization handlers for the Hello World
 sample application in the RTEMS kernel's testsuite::
 
 .. code-block:: none
diff --git a/user/start/app.rst b/user/start/app.rst
index a0c4a04..ac3c064 100644
--- a/user/start/app.rst
+++ b/user/start/app.rst
@@ -10,7 +10,7 @@ Build Your Application
 You tested a BSP in the previous section.  We built the ``erc32`` BSP
 and it is installed under :file:`$HOME/quick-start/rtems/5`.
 
-We will now create a simple hello world application with a Git
+We will now create a simple Hello World application with a Git
 repository and using the `Waf `_ build system.
 
 The application is be created in :file:`$HOME/quick-start/app/hello`.
@@ -77,7 +77,7 @@ settings:
 
 #include 
 
-Create the *hello world* application source file. Using an editor
+Create the Hello World application source file. Using an editor
 create :file:`hello.c` and copy the follow code:
 
 .. code-block:: c
diff --git a/user/tools/boot-image.rst b/user/tools/boot-image.rst
index 8e8f63d..2d6cad9 100644
--- a/user/tools/boot-image.rst
+++ b/user/tools/boot-image.rst
@@ -315,7 +315,7 @@ Create a disk image from a built U-Boot sandbox:
   Finished
   Cleaning up
 
-Create a 32M byte SD card image with the testsuite's hello world
+Create a 32M byte SD card image with the testsuite's Hello World
 executable (``hello.exe``):
 
 .. code-block:: none
diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index c3c3fe2..e3a21c9 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -95,7 +95,7 @@ perform a pre-test command to covert the executable to a 
suitable format for
 your target.
 
 Before running all the tests it is a good idea to run the ``hello`` test. The
-``hello`` test is an RTEMS version of the classic "Hello World" example and
+``hello`` test is an RTEMS version of the classic Hello World example and
 running it shows you have a working tool chain and build of RTEMS ready to run
 the tests. Using the run with the ERC32 BSP the command is:
 
-- 
2.16.4

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

Discussion regarding high-level interface for GSoC memory protection project.

2020-03-27 Thread Utkarsh Rai

Hi,
My GSoC project proposal

intended for
providing thread-stack protection involves implementation on two levels,
providing low-level hardware support for the target architecture and
high-level architecture-independent APIs. As @Peter Dufault
 pointed to me in my draft the POSIX  compliant way of
doing it would be through mmap, I would request your feedback on the
details of the high-level implementation of thread-stack protection.
My idea is to obtain the stack attributes of the thread that is to be
mapped by pthread_attr_getstack() and then get a file descriptor of the
memory using posix_typed_mem_open() and finally mmap that to the stack of
the required thread(With the specified permissions).
  Is this is a valid approach? If yes, I believe I would have to add the
implementation of   posix_typed_mem_open() to my work plan as RTEMS
does not support it as of now.

Regards,
Utkarsh Rai.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Chapter-on-need-for-RTEMS-specific-cross-compiler

2020-03-27 Thread utkarsh.ra...@gmail.com

---
 user/start/tools.rst | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index c3f039b..8ea1f64 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -3,6 +3,7 @@
 .. Copyright (C) 2019 embedded brains GmbH
 .. Copyright (C) 2019 Sebastian Huber
 .. Copyright (C) 2020 Chris Johns
+.. Copyright (C) 2020 Utkarsh Rai
 
 .. _QuickStartTools:
 
@@ -76,3 +77,36 @@ source code used.
 
 
 Add ``--verbose`` to the GCC command for the the verbose version details.
+
+ 
+Need for RTEMS-Specific Cross-Compiler
+
+
+New users are often confused as to why they cannot use their distribution's
+cross-compiler for their target on rtems, e.g., the riscv64-linux-gnu or the
+arm-none-eabi-gcc on RTEMS. Below mentioned are some of the reasons for using
+the RTEMS cross-compiler.
+
+ ``Correct configuration of Newlib -`` 
+ Newlib is a C standard library implementation intended for use on embedded
+ systems. Most of the POSIX and libc support for RTEMS is derived from
+ Newlib. The RTEMS cross-compiler configures Newlib correctly for RTEMS.
+
+ ``Threading in GCC support libraries -`` 
+ Several threading packages in GCC such as Go threads (libgo), OpenMP
+ (libgomp), and OpenACC need to be customized according to RTEMS. This is
+ done by the RTEMS specific cross-compiler.
+  
+ ``Provide preprocessor define __rtems__ -`` 
+ The  ``__rtems__``  preprocessor define is used to provide conditional 
code
+ compilation in source files that are shared with other projects e.g. in
+ Newlib or imported code from FreeBSD.
+
+ ``Multilib variants to match the BSP -`` 
+ RTEMS configures GCC to create separate runtime libraries for each
+ supported instruction set, floating point unit, vector unit, word size
+ (e.g. 32-bit and 64-bit), endianness, ABI, processor errata workarounds,
+ and so on in the architecture. These libraries are termed multilib 
variants
+ 
(https://docs.rtems.org/branches/master/user/hardware/architectures.html?highlight=multilib).
+ Multilibs variants to match the BSP are set by selecting a specific set of
+ machine options using the RTEMS cross-compiler.
-- 
2.17.1

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

Problem about porting TCP/IP Stack

2020-03-27 Thread jameszxj

Hi all,
        Since rtems-libbsd is too heavy for our project, so 
I tried to port Lightweight TCP/IP stacks.  First I tried lwip, it 
worked but crashed now and then.
The PC pointed at function _Heap_Block_split()??I could not figure it out. 
So I tried cycloneTCP . It is more simple than lwip.  But I encountered 
the same problem.
System still crashed at _Heap_Block_split() sometimes 
(random),  It made me crazy :(
       I tried on diffrent CPUs (zynq7020, sunxi-t3), the 
problem was still there.  _Heap_Block_split() is a core function, It 
seems to have nothing to do with the stack.
Attachments are error messages and disassembly code. Any advices?
       Thanks.

crash_messages
Description: Binary data


disassembly_code.txt
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Covid Code-In Update (27 March 2020)

Hi

I hope this email finds you and your loved ones all well.  Thanks to
everyone who has submitted patches or helped potential GSoC students the
past couple of weeks. Here are some updates on potential small tasks to
pass time. Although I must admit that Tiger King on Netflix has been
entertaining so far as well. :)

First, I have added some more small tasks. You can view them at
https://devel.rtems.org/wiki/SmallTasks. If you think of more, please let
me know or file them yourself with the tag "small, tasks"

Second, I have generated a new warnings report and placed it at
https://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-5-20200326/.
Below my signature is the summary from the run. When I work warnings, I
tend to take one of two approaches. I call one vertical and one horizontal.

The vertical approach is to address as many as possible in a single BSP
family. This has the advantage that you only need one target toolset and
can just do "make >/dev/null" to see if you fixed a warning when you edit a
file. The disadvantage is that you may end up analyzing the same class of
warning again when you switch BSPs.

The horizontal approach is to look at the warnings per class and pick a
class of warnings and start to sweep across BSPs with them. They tend to
need the same type of fix so there is less repeated analysis of individual
cases required. The file warnings-all-5-20200326.txt lists the entire set
of warnings and which BSP they were found in.

Which approach I take depends on my mood. If I have time, I will tend to
focus on a single BSP and then overnight do a build of all BSPs to get a
broader report. If I am doing a "drive by", I might fix a few warnings that
are common across a lot of BSPs and then start an overnight build sweep.

It is probably easier for most users to take a vertical focus on a single
BSP family and let me generate new reports when the patches are merged.

Follow medical expert advice and stay healthy.

Thanks.

--joel


Unique Warnings :  355
BSPs:  134
BSPs with Zero  :  0
BSPs with only in shared:  73


 Warnings by Class

  1 address-of-packed-member
  1 array-bounds
  4 char-subscripts
  1 cpp
 96 format=
 56 implicit-function-declaration
 60 incompatible-pointer-types
  4 int-conversion
  4 int-to-pointer-cast
  3 maybe-uninitialized
  1 misleading-indentation
  3 missing-prototypes
  1 nested-externs
  1 register
  1 restrict
  1 shift-count-overflow
  4 strict-aliasing
  2 strict-prototypes
  1 stringop-truncation
  1 unused-const-variable=
  4 unused-function
 14 unused-variable


 Top Ten BSPs with Warnings

42 powerpc-qemuprep-altivec  (inBSP=17 inLibCPU=0)
42 powerpc-qemuprep  (inBSP=17 inLibCPU=0)
37 powerpc-beatnik  (inBSP=18 inLibCPU=0)
42 powerpc-mvme5500  (inBSP=19 inLibCPU=0)
154 i386-pc386  (inBSP=26 inLibCPU=0)
154 i386-pc486  (inBSP=26 inLibCPU=0)
154 i386-pc586  (inBSP=26 inLibCPU=0)
154 i386-pc586-sse  (inBSP=26 inLibCPU=0)
154 i386-pc686  (inBSP=26 inLibCPU=0)
154 i386-pcp4  (inBSP=26 inLibCPU=0)

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

Re: Problem about porting TCP/IP Stack

2020-03-27 Thread Christian Mauderer

On 27/03/2020 15:58, jameszxj wrote:
> Hi all,
> ?0?2 ?0?2 ?0?2 ?0?2 Since rtems-libbsd is too heavy for our project, so I 
> tried to
> port?0?2Lightweight TCP/IP stacks.?0?2 First I tried lwip, it worked but
> crashed now and then.
> The PC pointed at function?0?2_Heap_Block_split()??I could not figure it
> out. So I tried cycloneTCP . It is more simple than lwip.?0?2 But I
> encountered the same problem.
> System still crashed at?0?2_Heap_Block_split()?0?2sometimes 
> (random),?0?2?0?2It made
> me crazy :(
> ?0?2 ?0?2 ?0?2 ?0?2I tried on diffrent CPUs (zynq7020, sunxi-t3), the problem 
> was
> still there.?0?2?0?2_Heap_Block_split() is a core function, It seems to have
> nothing to do with the stack.
> Attachments are error messages and?0?2disassembly code.?0?2Any advices?
> ?0?2 ?0?2 ?0?2 ?0?2Thanks.
> 
> 
> 

Hello,

I'm quite sure that I've seen some mails regarding lwIP. So there should
be already users for that.

Without having a detailed look at the crash message: If there are
problems with the heap you might want to use

--enable-rtems-debug

during RTEMS configure and maybe add

#define CONFIGURE_STACK_CHECKER_ENABLED

to your configuration. Problems with the heap can be from some part of
the application writing over the end of a buffer or similar. If that
destroys heap structures, you might get problems as soon as RTEMS want's
to do something with the heap. The rtems_debug enables quite a lot of
run time checks like a heap protection. That can help finding the bug.

Note that you have to re-build all libraries after you enable or disable
rtems-debug because some data structures change with that.

Best regards

Christian
-- 

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?0?1ftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] user: Provide a user fiendly configuration

That's good it should reduce startup problems.

On Fri, Mar 27, 2020 at 2:03 AM Sebastian Huber
 wrote:
>
> ---
>  user/start/app.rst | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/user/start/app.rst b/user/start/app.rst
> index 98fb284..a0c4a04 100644
> --- a/user/start/app.rst
> +++ b/user/start/app.rst
> @@ -64,14 +64,14 @@ settings:
>  /*
>   * Simple RTEMS configuration
>   */
> -#include 
>
> -#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
> +#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>  #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> -#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
> +
> +#define CONFIGURE_UNLIMITED_OBJECTS
> +#define CONFIGURE_UNIFIED_WORK_AREAS
>
>  #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> -#define CONFIGURE_MAXIMUM_TASKS 1
>
>  #define CONFIGURE_INIT
>
> --
> 2.16.4
>
> ___
> 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] user: Use consitent Hello World spelling

ok, maybe we also want to have a Hello World glossary item?

On Fri, Mar 27, 2020 at 2:03 AM Sebastian Huber
 wrote:
>
> ---
>  user/exe/initialization.rst | 2 +-
>  user/start/app.rst  | 4 ++--
>  user/tools/boot-image.rst   | 2 +-
>  user/tools/tester.rst   | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/user/exe/initialization.rst b/user/exe/initialization.rst
> index cfe39d6..6c9d657 100644
> --- a/user/exe/initialization.rst
> +++ b/user/exe/initialization.rst
> @@ -82,7 +82,7 @@ system is based on the `FreeBSD SYSINT Framework
>  initialization is performed before multitasking is started.
>
>  The RTEMS Tool ``rtems-exeinfo`` can provide some detail about the registered
> -handlers. The following shows the initialization handlers for the *hello 
> world*
> +handlers. The following shows the initialization handlers for the Hello World
>  sample application in the RTEMS kernel's testsuite::
>
>  .. code-block:: none
> diff --git a/user/start/app.rst b/user/start/app.rst
> index a0c4a04..ac3c064 100644
> --- a/user/start/app.rst
> +++ b/user/start/app.rst
> @@ -10,7 +10,7 @@ Build Your Application
>  You tested a BSP in the previous section.  We built the ``erc32`` BSP
>  and it is installed under :file:`$HOME/quick-start/rtems/5`.
>
> -We will now create a simple hello world application with a Git
> +We will now create a simple Hello World application with a Git
>  repository and using the `Waf `_ build system.
>
>  The application is be created in :file:`$HOME/quick-start/app/hello`.
> @@ -77,7 +77,7 @@ settings:
>
>  #include 
>
> -Create the *hello world* application source file. Using an editor
> +Create the Hello World application source file. Using an editor
>  create :file:`hello.c` and copy the follow code:
>
>  .. code-block:: c
> diff --git a/user/tools/boot-image.rst b/user/tools/boot-image.rst
> index 8e8f63d..2d6cad9 100644
> --- a/user/tools/boot-image.rst
> +++ b/user/tools/boot-image.rst
> @@ -315,7 +315,7 @@ Create a disk image from a built U-Boot sandbox:
>Finished
>Cleaning up
>
> -Create a 32M byte SD card image with the testsuite's hello world
> +Create a 32M byte SD card image with the testsuite's Hello World
>  executable (``hello.exe``):
>
>  .. code-block:: none
> diff --git a/user/tools/tester.rst b/user/tools/tester.rst
> index c3c3fe2..e3a21c9 100644
> --- a/user/tools/tester.rst
> +++ b/user/tools/tester.rst
> @@ -95,7 +95,7 @@ perform a pre-test command to covert the executable to a 
> suitable format for
>  your target.
>
>  Before running all the tests it is a good idea to run the ``hello`` test. The
> -``hello`` test is an RTEMS version of the classic "Hello World" example and
> +``hello`` test is an RTEMS version of the classic Hello World example and
>  running it shows you have a working tool chain and build of RTEMS ready to 
> run
>  the tests. Using the run with the ERC32 BSP the command is:
>
> --
> 2.16.4
>
> ___
> 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: Discussion regarding high-level interface for GSoC memory protection project.

Hi Utkarsh,

You can remove "Discussion regarding" from your subject lines. We know
your emails are discussions regarding the subject.

On Fri, Mar 27, 2020 at 5:26 AM Utkarsh Rai  wrote:
>
> Hi,
> My GSoC project proposal intended for providing thread-stack protection 
> involves implementation on two levels, providing low-level hardware support 
> for the target architecture and high-level architecture-independent APIs. As 
> @Peter Dufault pointed to me in my draft the POSIX  compliant way of doing it 
> would be through mmap, I would request your feedback on the details of the 
> high-level implementation of thread-stack protection.
> My idea is to obtain the stack attributes of the thread that is to be mapped 
> by pthread_attr_getstack() and then get a file descriptor of the memory using 
> posix_typed_mem_open() and finally mmap that to the stack of the required 
> thread(With the specified permissions).
>   Is this is a valid approach? If yes, I believe I would have to add the 
> implementation of   posix_typed_mem_open() to my work plan as RTEMS does 
> not support it as of now.
>

That's an interesting proposition. I guess you are suggesting to make
thread stacks be "typed memory objects"? I don't know the
ramifications of that, but it sounds like a really deep design and
implementation challenge. It's not clear to me that "typed_mem_open"
is proper to call on an existing typed object, but I'm not that
familiar with the TYM interface. It could be something worth fleshing
out though as a summer implementation project if there is plenty of
work to do. It could be something for extension activities.

I think however you could instead use shared memory objects, which
already have some (limited) support, to accomplish the same ideas. You
could give each thread's stack a "named" object in some filesystem,
and other threads could shm_open() and mmap() the stack. I think that
is the right way to go at least based on where we are in RTEMS now.

You should also know and understand that the mmap() interface in RTEMS
is quite shallow and restricted in its support. For file objects it
basically only works to provide a copy of the file, because it works
by copying the memory from the file to the destination. For shared
memory objects it can provide rw access between two threads, but can't
restrict access since we lack general protection mechanisms. If two
threads want to share writeable stack regions then the current support
could work, perhaps by using shared memory objects to set up the
thread stacks. But two threads can't share read-only stack regions
with the current implementation. That would be part of your work to
figure out, in addition to perhaps improving and fixing up the
existing mmap/shm support.

Step back a minute and think about the requirements before you.
Threads have stacks already. Sometimes they share them with each
other. Now you want to isolate each thread's stack from other threads.
But if they still want to share, then you should allow it. How?

The suggestion is to allow threads to use mmap() to map other threads'
stacks. Some questions for you to ponder: Since those stacks exist and
have an address already, can you just fiddle with the protection
regions and return a pointer directly to the stack to allow r/w access
with sharing? What are the limitations on the solution (based on the
number of protection regions supported in hardware)?

Gedare

> Regards,
> Utkarsh Rai.
> ___
> 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

AW: AW: [PATCH v3 3/3] i386: Port to RTEMS

2020-03-27 Thread Jan.Sommer

Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Gesendet: Montag, 23. März 2020 14:20
An: Sommer, Jan; devel@rtems.org
Betreff: Re: AW: [PATCH v3 3/3] i386: Port to RTEMS
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von
> > jan.som...@dlr.de
> > Gesendet: Montag, 23. März 2020 13:50
> > An: sebastian.hu...@embedded-brains.de; devel@rtems.org
> > Betreff: AW: [PATCH v3 3/3] i386: Port to RTEMS
> > 
> > 
> > 
> > > -Ursprüngliche Nachricht-
> > > Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> > > Gesendet: Montag, 23. März 2020 10:59
> > > An: Sommer, Jan; devel@rtems.org
> > > Betreff: Re: [PATCH v3 3/3] i386: Port to RTEMS
> > >
> > > On 23/03/2020 09:06, Jan Sommer wrote:
> > >
> > > > @@ -4597,7 +4599,12 @@ iflib_device_register(device_t dev, void *sc,
> > > if_shared_ctx_t sctx, if_ctx_t *ct
> > > > /* Set up cpu set.  If it fails, use the set of all CPUs. */
> > > > if (bus_get_cpus(dev, INTR_CPUS, sizeof(ctx->ifc_cpus), &ctx-
> > > >ifc_cpus) != 0) {
> > > > device_printf(dev, "Unable to fetch CPU list\n");
> > > > +#ifndef __rtems__
> > > > CPU_COPY(&all_cpus, &ctx->ifc_cpus);
> > > > +#else /* __rtems__ */
> > > > +   cpuset_t cpus = {all_cpus};
> > > > +   CPU_COPY(&cpus, &ctx->ifc_cpus);
> > > > +#endif /* __rtems__ */
> > > > }
> > > > MPASS(CPU_COUNT(&ctx->ifc_cpus) > 0);
> > >
> > > What is the reason for this change?
> > >
> > 
> > For RTEMS the all_cpus variable has been replaced in freebsd/sys/sys/smp.h
> > to " #define all_cpus 1U".
> > The additional variable is there because CPU_COPY requires an address.
> > 
> > > Could you please move the changes in non-x86 specific files to a
> > > separate commit. Especially the  is an important header
> > > file used across all architectures.
> > 
> Ok, problems like this are an indication that you try to use a feature which 
> is 
> not really supported. I would first try to understand what the purpose of the
> ifc_cpus is. Maybe this stuff could be disabled completely.

Ok, I investigated the issue further. 
If I understand the RTEMS specific settings in sys/smp.h correctly, 
rtems-libbsd always assumes to run on a single core?

ifc_cpus is the map of active CPUs, i.e. for RTEMS it should be 1, and is used 
to determine the queue sizes.
It is only initialized once from all_cpus, but with CPU_COPY, which requires an 
address as source.
In FreeBSD all_cpus is a variable, for RTEMS it is only a define producing a 
compile error.

As far as I see it, we could either use a temporary variable as above or maybe 
an int for the all_cpus in sys/smp.h instead of the define.
However the latter would move the assignment to a c-file, thus making it harder 
to find. Do you have any other idea?

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

Re: [PATCH 2/2] user: Use consitent Hello World spelling

Good idea Gedare.

And consitent should be consistent.

On Fri, Mar 27, 2020 at 10:41 AM Gedare Bloom  wrote:

> ok, maybe we also want to have a Hello World glossary item?
>
> On Fri, Mar 27, 2020 at 2:03 AM Sebastian Huber
>  wrote:
> >
> > ---
> >  user/exe/initialization.rst | 2 +-
> >  user/start/app.rst  | 4 ++--
> >  user/tools/boot-image.rst   | 2 +-
> >  user/tools/tester.rst   | 2 +-
> >  4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/user/exe/initialization.rst b/user/exe/initialization.rst
> > index cfe39d6..6c9d657 100644
> > --- a/user/exe/initialization.rst
> > +++ b/user/exe/initialization.rst
> > @@ -82,7 +82,7 @@ system is based on the `FreeBSD SYSINT Framework
> >  initialization is performed before multitasking is started.
> >
> >  The RTEMS Tool ``rtems-exeinfo`` can provide some detail about the
> registered
> > -handlers. The following shows the initialization handlers for the
> *hello world*
> > +handlers. The following shows the initialization handlers for the Hello
> World
> >  sample application in the RTEMS kernel's testsuite::
> >
> >  .. code-block:: none
> > diff --git a/user/start/app.rst b/user/start/app.rst
> > index a0c4a04..ac3c064 100644
> > --- a/user/start/app.rst
> > +++ b/user/start/app.rst
> > @@ -10,7 +10,7 @@ Build Your Application
> >  You tested a BSP in the previous section.  We built the ``erc32`` BSP
> >  and it is installed under :file:`$HOME/quick-start/rtems/5`.
> >
> > -We will now create a simple hello world application with a Git
> > +We will now create a simple Hello World application with a Git
> >  repository and using the `Waf `_ build system.
> >
> >  The application is be created in :file:`$HOME/quick-start/app/hello`.
> > @@ -77,7 +77,7 @@ settings:
> >
> >  #include 
> >
> > -Create the *hello world* application source file. Using an editor
> > +Create the Hello World application source file. Using an editor
> >  create :file:`hello.c` and copy the follow code:
> >
> >  .. code-block:: c
> > diff --git a/user/tools/boot-image.rst b/user/tools/boot-image.rst
> > index 8e8f63d..2d6cad9 100644
> > --- a/user/tools/boot-image.rst
> > +++ b/user/tools/boot-image.rst
> > @@ -315,7 +315,7 @@ Create a disk image from a built U-Boot sandbox:
> >Finished
> >Cleaning up
> >
> > -Create a 32M byte SD card image with the testsuite's hello world
> > +Create a 32M byte SD card image with the testsuite's Hello World
> >  executable (``hello.exe``):
> >
> >  .. code-block:: none
> > diff --git a/user/tools/tester.rst b/user/tools/tester.rst
> > index c3c3fe2..e3a21c9 100644
> > --- a/user/tools/tester.rst
> > +++ b/user/tools/tester.rst
> > @@ -95,7 +95,7 @@ perform a pre-test command to covert the executable to
> a suitable format for
> >  your target.
> >
> >  Before running all the tests it is a good idea to run the ``hello``
> test. The
> > -``hello`` test is an RTEMS version of the classic "Hello World" example
> and
> > +``hello`` test is an RTEMS version of the classic Hello World example
> and
> >  running it shows you have a working tool chain and build of RTEMS ready
> to run
> >  the tests. Using the run with the ERC32 BSP the command is:
> >
> > --
> > 2.16.4
> >
> > ___
> > 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: [PATCH 2/2] user: Use consitent Hello World spelling

On Fri, Mar 27, 2020 at 10:59 AM Joel Sherrill  wrote:
>
> Good idea Gedare.
>
> And consitent should be consistent.
>
I wasn't going to complain about typos in the commit message :)

There's another typo in the other one too.

> On Fri, Mar 27, 2020 at 10:41 AM Gedare Bloom  wrote:
>>
>> ok, maybe we also want to have a Hello World glossary item?
>>
>> On Fri, Mar 27, 2020 at 2:03 AM Sebastian Huber
>>  wrote:
>> >
>> > ---
>> >  user/exe/initialization.rst | 2 +-
>> >  user/start/app.rst  | 4 ++--
>> >  user/tools/boot-image.rst   | 2 +-
>> >  user/tools/tester.rst   | 2 +-
>> >  4 files changed, 5 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/user/exe/initialization.rst b/user/exe/initialization.rst
>> > index cfe39d6..6c9d657 100644
>> > --- a/user/exe/initialization.rst
>> > +++ b/user/exe/initialization.rst
>> > @@ -82,7 +82,7 @@ system is based on the `FreeBSD SYSINT Framework
>> >  initialization is performed before multitasking is started.
>> >
>> >  The RTEMS Tool ``rtems-exeinfo`` can provide some detail about the 
>> > registered
>> > -handlers. The following shows the initialization handlers for the *hello 
>> > world*
>> > +handlers. The following shows the initialization handlers for the Hello 
>> > World
>> >  sample application in the RTEMS kernel's testsuite::
>> >
>> >  .. code-block:: none
>> > diff --git a/user/start/app.rst b/user/start/app.rst
>> > index a0c4a04..ac3c064 100644
>> > --- a/user/start/app.rst
>> > +++ b/user/start/app.rst
>> > @@ -10,7 +10,7 @@ Build Your Application
>> >  You tested a BSP in the previous section.  We built the ``erc32`` BSP
>> >  and it is installed under :file:`$HOME/quick-start/rtems/5`.
>> >
>> > -We will now create a simple hello world application with a Git
>> > +We will now create a simple Hello World application with a Git
>> >  repository and using the `Waf `_ build system.
>> >
>> >  The application is be created in :file:`$HOME/quick-start/app/hello`.
>> > @@ -77,7 +77,7 @@ settings:
>> >
>> >  #include 
>> >
>> > -Create the *hello world* application source file. Using an editor
>> > +Create the Hello World application source file. Using an editor
>> >  create :file:`hello.c` and copy the follow code:
>> >
>> >  .. code-block:: c
>> > diff --git a/user/tools/boot-image.rst b/user/tools/boot-image.rst
>> > index 8e8f63d..2d6cad9 100644
>> > --- a/user/tools/boot-image.rst
>> > +++ b/user/tools/boot-image.rst
>> > @@ -315,7 +315,7 @@ Create a disk image from a built U-Boot sandbox:
>> >Finished
>> >Cleaning up
>> >
>> > -Create a 32M byte SD card image with the testsuite's hello world
>> > +Create a 32M byte SD card image with the testsuite's Hello World
>> >  executable (``hello.exe``):
>> >
>> >  .. code-block:: none
>> > diff --git a/user/tools/tester.rst b/user/tools/tester.rst
>> > index c3c3fe2..e3a21c9 100644
>> > --- a/user/tools/tester.rst
>> > +++ b/user/tools/tester.rst
>> > @@ -95,7 +95,7 @@ perform a pre-test command to covert the executable to a 
>> > suitable format for
>> >  your target.
>> >
>> >  Before running all the tests it is a good idea to run the ``hello`` test. 
>> > The
>> > -``hello`` test is an RTEMS version of the classic "Hello World" example 
>> > and
>> > +``hello`` test is an RTEMS version of the classic Hello World example and
>> >  running it shows you have a working tool chain and build of RTEMS ready 
>> > to run
>> >  the tests. Using the run with the ERC32 BSP the command is:
>> >
>> > --
>> > 2.16.4
>> >
>> > ___
>> > 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 v11] tests for fenv.h functions

2020-03-27 Thread Eshan dhawan

---
 testsuites/psxtests/psxfenv01/init.c| 88 -
 testsuites/psxtests/psxfenv01/psxfenv01.doc |  9 ++-
 testsuites/psxtests/psxfenv01/psxfenv01.scn |  4 -
 3 files changed, 76 insertions(+), 25 deletions(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index cdb0fa596e..cfa31d6a16 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -6,6 +6,7 @@
 /*
  * SPDX-License-Identifier: BSD-2-Clause
  *
+ * Copyright (C) 2020 Eshan Dhawan 
  * Copyright (C) 2019 Vaibhav Gupta
  *
  * Redistribution and use in source and binary forms, with or without
@@ -46,11 +47,12 @@
 #include 
 #include 
 #include 
+#include 
 
 const char rtems_test_name[] = "PSXFENV 01";
 
 /* forward declarations to avoid warnings */
-rtems_task Init(rtems_task_argument ignored);
+rtems_task Init( rtems_task_argument ignored );
 
 /* Test Function Begins */
 rtems_task Init(rtems_task_argument ignored)
@@ -62,40 +64,90 @@ rtems_task Init(rtems_task_argument ignored)
 
   /*
* 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
-   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
-   * 'fetestexcept()' functions are supported by the architecture.
+   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
+   * fetestexcept() functions are supported by the architecture.
* Hence their testcases can be wrapped under #ifdef and #endif.
*/
   #ifdef FE_ALL_EXCEPT /* floating-point exceptions */
-puts( "fesetenv(FE_DFL_ENV)." );
-r = fesetenv(FE_DFL_ENV);
-if (r)
-  printf("fesetenv ==> %d\n", r);
+r = fesetenv( FE_DFL_ENV );
+if ( r ) {
+  printf( "fesetenv ==> %d\n", r);
+}
 rtems_test_assert( r == 0 );
 
-/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
-puts( "feclearexcept(FE_ALL_EXCEPT)." );
-r = feclearexcept(FE_ALL_EXCEPT);
-if (r)
-  printf("feclearexcept ==> 0x%x\n", r);
+/* Test feclearexcept() and fetestexcept() in one go. */
+r = feclearexcept( FE_ALL_EXCEPT );
+if ( r ) {
+  printf( "feclearexcept ==> 0x%x\n", r );
+}
 rtems_test_assert( r == 0 );
 
 r = fetestexcept( FE_ALL_EXCEPT );
-if (r)
-  printf("fetestexcept ==> 0x%x\n", r);
+if ( r ) {
+  printf( "fetestexcept ==> 0x%x\n", r );
+}
 rtems_test_assert( r == 0 );
 
-/* Test 'FE_DIVBYZERO' */
-puts( "Divide by zero and confirm fetestexcept()" );
+/* Test 'FE_DIVBYZERO' 
+ *Divide by zero and confirm fetestexcept() */
 a = 0.0;
 b = 1.0;
 c = b/a;
 (void) c;
+/* Test fegetexceptflag() and fesetexceptflag() */
+r = fegetexceptflag( &excepts, FE_ALL_EXCEPT );
+if ( r ) {
+  printf( "fegetexceptflag ==> 0x%x\n", r );
+}
+rtems_test_assert( r == 0 );
 
-fegetexceptflag(&excepts,FE_ALL_EXCEPT);
+r = fesetexceptflag( &excepts, FE_ALL_EXCEPT );
+if ( r ) {
+  printf( "fesetexceptflag ==> 0x%x\n", r );
+}
+rtems_test_assert( r == 0 );
 
+/* Test for fegetround() and fesetround() 
+ * They have four main macros to be tested separated by ifdef
+ * Since not all architectures support them 
+ * The test case gets and sets the rounding directions */
+#ifdef FE_TONEAREST
+rtems_test_assert( fegetround() == FE_TONEAREST );   
+#endif
+#ifdef FE_TOWARDZERO
+  r = fesetround( FE_TOWARDZERO );
+  if ( r ) {
+  printf( "fesetround ==> 0x%x\n", r ); 
+} 
+  rtems_test_assert( r == 0 );
+  rtems_test_assert( fegetround() == FE_TOWARDZERO );
+#endif
+#ifdef FE_DOWNWARD
+  r = fesetround( FE_DOWNWARD );
+  if ( r ) {
+  printf( "fesetround ==> 0x%x\n", r ); 
+} 
+  rtems_test_assert( r == 0 );
+  rtems_test_assert( fegetround() == FE_DOWNWARD );
+#endif
+#ifdef FE_UPWARD
+  r = fesetround( FE_UPWARD );
+  if ( r ) {
+  printf( "fesetround ==> 0x%x\n", r ); 
+}   
+  rtems_test_assert( r == 0 );
+  rtems_test_assert( fegetround() == FE_UPWARD );
+#endif
+#ifdef FE_TONEAREST
+  r = fesetround( FE_TONEAREST );
+  if ( r ) {
+  printf( "fesetround ==> 0x%x\n", r );
+} 
+  rtems_test_assert( r == 0 );
+#endif
+  
 #ifdef FE_DIVBYZERO
-r = feraiseexcept(FE_DIVBYZERO);
+r = feraiseexcept( FE_DIVBYZERO ) ;
 rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
 #endif
 
diff --git a/testsuites/psxtests/psxfenv01/psxfenv01.doc 
b/testsuites/psxtests/psxfenv01/psxfenv01.doc
index 3aa7757496..52d9fd19c7 100644
--- a/testsuites/psxtests/psxfenv01/psxfenv01.doc
+++ b/testsuites/psxtests/psxfenv01/psxfenv01.doc
@@ -1,4 +1,4 @@
-#  COPYRIGHT (c) 2019
+#  COPYRIGHT (c) 2019
 #  On-Line Applications Research Corporation (OAR).
 #
 # SPDX-License-Identifier: BSD-2-Clause
@@ -12,9 +12,12 @@ Directives:
   fesetenv
   feclearexcept
   fetestexcept
-  texceptflag
   feraiseexcept
-
+  fesetexeptflag
+  fegetexeptflag
+  fegetround
+  fesetround
+  
 Concepts:
 
 + This test exercises the

Re: discussion related to implementation of File descriptor functions in RTEMS

2020-03-27 Thread Eshan Dhawan

On Thu, Mar 26, 2020 at 11:18 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25/03/2020 20:33, Joel Sherrill wrote:
>
>
>
> On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
>>> wrote:
>>>
 Hello everyone,
 As @Vaibhav Gupta  suggested I have also
 added adding file descriptor functions to my GSOC project.
 I went through the mailing list archives for more information.
 RTEMS as its own file descriptor so the functions need to be
 implemented from scratch.
 I wanted to get more information related to it.

>>>
>>> What's the set of functions you are proposing for those not tracking
>>> your draft proposal?
>>>
>> Link:
>> https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
>> I haven't searched about the functions in the list yet. The list was made
>> by Vaibhav, last year and he told me that it could be added to proposal
>> this year as well.
>> I read the archives that these need to be written from scratch.
>>
>
>
> Maybe not. I found at least this implementation of renameat() which was
> implemented on top of existing calls:
>
>
> https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>
> It should be in a C file but that shows it can be done. That directory has
> a lot of these methods.
>
> Adding the *at() functions with an RTEMS-specific implementation would be
> nice (and not difficult). The generic renameat() implementation for example
> changes the current directory. One of the goals of this API is to avoid
> exactly this. In glibc/Linux for example a system call is used:
>
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/renameat.c;h=901d61f37e10d0c2df245c01bb2ef980d00e8f52;hb=HEAD
>
> https://github.com/torvalds/linux/blob/master/fs/namei.c#L4590
>
Can you tell where to find details related to these function as well as how
to implement them?
:)

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

Re: Ran clang

2020-03-27 Thread suyash singh

On Fri, Mar 27, 2020 at 9:36 PM Joel Sherrill  wrote:

>
>
> On Fri, Mar 27, 2020 at 10:39 AM Gedare Bloom  wrote:
>
>> This appears to be a pretty standard llvm/clang build for a host system.
>>
>> There are two parts to consider:
>> * Using the host tools over RTEMS
>> * Using cross-compiler tools over RTEMS
>>
>> For analyzer I don't think the cross-target is a problem but I'm not
>> really sure. That should be understood before pushing further. My
>> understanding though is that most of the analyzers run on the LLVM IR, so
>> the backend is irrelevant.
>>
>
By cross compiler tools do you mean the Clang Static Analyzer should work
on all hosts after building only once?

>
> I think the RISC-V and SPARC  have BSPs that can be built with clang.
> clang/llvm has a package in the RSB. I would recommend building llvm using
> the RSB and then building the supported BSPs.
>
> That is a more solid base to use for analysis. Building RTEMS with the
> native compiler is hopeless (tilting at windmills).
>
> Also gcc 10 has improved analysis (
> https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/).
> I would like to see support for using either for static analysis.
>
> Supporting >1 open source/free tool for static analysis before fixing
> anything is important (to me). This is already built by the rtems6 RSB
> toolchain. When that builds anyway -- it tracks the tools head. :)
>
> Your project should include any additions to the RSB (if needed) and
> documenting use of the analyzers. If there is a technique to annotate
> source to avoid false positives or deliberate violations, your project
> should document that also
>

 Do you mean the RSB can already build Clang Static Analyzer and
UBSan?

 So build clang/llvm and then build BSPs for analysis?

Also gcc 10 has improved analysis (
> https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/).
> I would like to see support for using either for static analysis.
> Supporting >1 open source/free tool for static analysis before fixing
> anything is important (to me). This is already built by the rtems6 RSB
> toolchain. When that builds anyway -- it tracks the tools head. :)


 Do you mean adding both gcc 10 and clang static analyzer in RTEMS?
What is already built by rtems6 RSB toolchain?


UBSan needs code to be compiled. Will it be a problem?

Also I am quoting from clang mailing list

As of now we only analyze code that compiles without errors to begin
> with. This does force us to have some amount of interaction with the
> build system.


What are your problems with scan-build though? Is it somehow not working
> for your build system? RTEMS looks like it has a plain old Makefile; as
> long as it respects environment variables CC and CXX, "scan-build make"
> should work just fine
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] user: Use consitent Hello World spelling


On 2020-03-27 18:00, Gedare Bloom wrote:


On Fri, Mar 27, 2020 at 10:59 AM Joel Sherrill  wrote:

Good idea Gedare.

And consitent should be consistent.


I wasn't going to complain about typos in the commit message :)

There's another typo in the other one too.

Ok, time for the week end.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] c-user: Use new template for integer config opts

Try to bring all descriptions up to date.  Add cross-references to
several options.  Clarify configuration value constraints.

Close #3901.
---
 c-user/config/bdbuf.rst | 192 -
 c-user/config/classic-api.rst   | 306 +++-
 c-user/config/classic-init-task.rst | 109 ++--
 c-user/config/device-driver.rst |  25 ++-
 c-user/config/event-record.rst  |  31 ++--
 c-user/config/filesystem.rst|  37 ++--
 c-user/config/general.rst   | 335 +---
 c-user/config/idle-task.rst |  26 ++-
 c-user/config/mpci.rst  |  62 +++
 c-user/config/posix-api.rst | 242 ++
 c-user/config/posix-init-thread.rst |  29 ++--
 c-user/config/scheduler-general.rst |  44 +++--
 12 files changed, 912 insertions(+), 526 deletions(-)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index 84b1d33..56a47e0 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -44,17 +44,23 @@ CONFIGURE_BDBUF_BUFFER_MAX_SIZE
 CONSTANT:
 ``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
 
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-It must be positive and an integral multiple of the buffer minimum size.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
-The default value is 4096 bytes.
+The default value is 4096.
+
+VALUE CONSTRAINTS:
+The value of this configuration option must satisfy all of the following
+constraints:
+
+* It must be greater than or equal to 0.
+
+* It must be an integral multiple of 
:ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
 
 DESCRIPTION:
-Defines the maximum size of a buffer in bytes.
+The value of this configuration option defines the maximum size of a buffer
+in bytes.
 
 NOTES:
 None.
@@ -69,17 +75,19 @@ CONFIGURE_BDBUF_BUFFER_MIN_SIZE
 CONSTANT:
 ``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
 
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
-The default value is 512 bytes.
+The default value is 512.
+
+VALUE CONSTRAINTS:
+The value of this configuration option must be greater than or equal to 0
+and less than or equal to ``UINT32_MAX``.
 
 DESCRIPTION:
-Defines the minimum size of a buffer in bytes.
+The value of this configuration option defines the minimum size of a buffer
+in bytes.
 
 NOTES:
 None.
@@ -94,17 +102,19 @@ CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
 CONSTANT:
 ``CONFIGURE_BDBUF_CACHE_MEMORY_SIZE``
 
-DATA TYPE:
-Unsigned integer (``size_t``).
-
-RANGE:
-Positive.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
-The default value is 32768 bytes.
+The default value is 32768.
+
+VALUE CONSTRAINTS:
+The value of this configuration option must be greater than or equal to 0
+and less than or equal to ``SIZE_MAX``.
 
 DESCRIPTION:
-Size of the cache memory in bytes.
+The value of this configuration option defines the size of the cache memory
+in bytes.
 
 NOTES:
 None.
@@ -119,17 +129,19 @@ CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
 CONSTANT:
 ``CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS``
 
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
 The default value is 0.
 
+VALUE CONSTRAINTS:
+The value of this configuration option must be greater than or equal to 0
+and less than or equal to ``UINT32_MAX``.
+
 DESCRIPTION:
-Defines the maximum blocks per read-ahead request.
+The value of this configuration option defines the maximum blocks per
+read-ahead request.
 
 NOTES:
 A value of 0 disables the read-ahead task (default).  The read-ahead task
@@ -146,17 +158,19 @@ CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
 CONSTANT:
 ``CONFIGURE_BDBUF_MAX_WRITE_BLOCKS``
 
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
 The default value is 16.
 
+VALUE CONSTRAINTS:
+The value of this configuration option must be greater than or equal to 0
+and less than or equal to ``UINT32_MAX``.
+
 DESCRIPTION:
-Defines the maximum blocks per write request.
+The value of this configuration option defines the maximum blocks per write
+request.
 
 NOTES:
 None.
@@ -171,17 +185,18 @@ CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
 CONSTANT:
 ``CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY``
 
-DATA TYPE:
-Task priority (``rtems_task_priority``).
-
-RANGE:
-Valid task priority.
+OPTION TYPE:
+This configuration option is an integer define.
 
 DEFAULT VALUE:
 The default value is 15.
 
+VALUE CONSTRAINTS:
+The value of this configuration option must be a valid task priority of the
+configu

Re: discussion related to implementation of File descriptor functions in RTEMS

On Fri, Mar 27, 2020 at 12:12 PM Eshan Dhawan 
wrote:

>
>
> On Thu, Mar 26, 2020 at 11:18 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 25/03/2020 20:33, Joel Sherrill wrote:
>>
>>
>>
>> On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:
>>>


 On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
 wrote:

> Hello everyone,
> As @Vaibhav Gupta  suggested I have also
> added adding file descriptor functions to my GSOC project.
> I went through the mailing list archives for more information.
> RTEMS as its own file descriptor so the functions need to be
> implemented from scratch.
> I wanted to get more information related to it.
>

 What's the set of functions you are proposing for those not tracking
 your draft proposal?

>>> Link:
>>> https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
>>> I haven't searched about the functions in the list yet. The list was
>>> made by Vaibhav, last year and he told me that it could be added to
>>> proposal this year as well.
>>> I read the archives that these need to be written from scratch.
>>>
>>
>>
>> Maybe not. I found at least this implementation of renameat() which was
>> implemented on top of existing calls:
>>
>>
>> https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>>
>> It should be in a C file but that shows it can be done. That directory
>> has a lot of these methods.
>>
>> Adding the *at() functions with an RTEMS-specific implementation would be
>> nice (and not difficult). The generic renameat() implementation for example
>> changes the current directory. One of the goals of this API is to avoid
>> exactly this. In glibc/Linux for example a system call is used:
>>
>>
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/renameat.c;h=901d61f37e10d0c2df245c01bb2ef980d00e8f52;hb=HEAD
>>
>> https://github.com/torvalds/linux/blob/master/fs/namei.c#L4590
>>
>
I'm not disagreeing that a generic implementation is undesirable long-term
but these methods have not been present for 30 years and no one has
complained about their absence. I would propose generic implementations be
added and a ticket filed to add RTEMS specific implementations if someone
complains about the performance.

I see adding them now as a higher effort task that brings little value.
These are for standards compliance and not performance critical.

Unless as Eshan says, you have a simple pattern in your head to add them as
system calls. But that still requires a fair amount of implementation
versus just porting these.

>
>> Can you tell where to find details related to these function as well as
> how to implement them?
> :)
>
> thanks
> -Eshan
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Use new template for integer config opts


The documentation was generated by updated application configuration items

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

and the following generator:

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

The next step is to add new option types for the following options:

spec/acfg/opt/RTEMS-ACFG-OPT-APPLEXTRADRIVERS.yml
spec/acfg/opt/RTEMS-ACFG-OPT-APPLPREREQUISITEDRIVERS.yml
spec/acfg/opt/RTEMS-ACFG-OPT-IDLETASKBODY.yml
spec/acfg/opt/RTEMS-ACFG-OPT-INITIALEXTENSIONS.yml
spec/acfg/opt/RTEMS-ACFG-OPT-INITTASKENTRYPOINT.yml
spec/acfg/opt/RTEMS-ACFG-OPT-MPMPCITABLEPOINTER.yml
spec/acfg/opt/RTEMS-ACFG-OPT-POSIXINITTHREADENTRYPOINT.yml
spec/acfg/opt/RTEMS-ACFG-OPT-TASKSTACKALLOCATOR.yml
spec/acfg/opt/RTEMS-ACFG-OPT-TASKSTACKALLOCATORINIT.yml
spec/acfg/opt/RTEMS-ACFG-OPT-TASKSTACKDEALLOCATOR.yml

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

RISC-V BSP Test Results

Hi

I wanted to pass along that Spike appears to be working now from the RSB.
Test results are in the build archive show that 5 or 7 fail on sis but the
other BSPs tend to have 20-24 failures with some timeouts and invalids. No
idea why. It would be appreciated if anyone who knows the RISC-V
could see if these are reasonable.


   - [rtems-test] riscv/griscv: RTEMS_POSIX_API: Passed:577 Failed:5
   Timeout:0 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv/griscv: RTEMS_DEBUG, RTEMS_POSIX_API: Passed:575
   Failed:7 Timeout:0 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32iac: RTEMS_POSIX_API: Passed:545 Failed:20
   Timeout:17 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32imac: RTEMS_POSIX_API: Passed:546 Failed:23
   Timeout:13 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32imafc: RTEMS_POSIX_API: Passed:545 Failed:23
   Timeout:14 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32imafdc: RTEMS_POSIX_API: Passed:544 Failed:24
   Timeout:14 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32imafd: RTEMS_POSIX_API: Passed:542 Failed:22
   Timeout:18 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32im: RTEMS_POSIX_API: Passed:544 Failed:21
   Timeout:17 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv32/rv32i: RTEMS_POSIX_API: Passed:543 Failed:20
   Timeout:17 Invalid:2 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imac: RTEMS_POSIX_API: Passed:548 Failed:22
   Timeout:12 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imac: RTEMS_POSIX_API: Passed:549 Failed:22
   Timeout:11 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imafdc_medany: RTEMS_POSIX_API: Passed:549
   Failed:21 Timeout:12 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imafdc: RTEMS_POSIX_API: Passed:549 Failed:21
   Timeout:12 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imafd: RTEMS_POSIX_API: Passed:552 Failed:20
   Timeout:10 Invalid:0 Wrong:0
     *joel
   at rtems.org *
   - [rtems-test] riscv64/rv64imafd: RTEMS_POSIX_API: Passed:552 Failed:19
   Timeout:11 Invalid:0 Wrong:0
     *joel
   at rtems.org *

If anyone reads this far, I want to point out that there are ~1450 posts to
the build@ mailing list this month!!!

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

Re: RISC-V BSP Test Results


On 2020-03-27 18:49, Joel Sherrill wrote:


I wanted to pass along that Spike appears to be working now from the RSB.
Test results are in the build archive show that 5 or 7 fail on sis but 
the

other BSPs tend to have 20-24 failures with some timeouts and invalids. No
idea why. It would be appreciated if anyone who knows the RISC-V
could see if these are reasonable.
libdl is not supported as well as fenv. The other are simulator 
problems, e.g. timing for the spintrcritical* or performance for 
crypt01. One or two should be looked after. I don't have time for this.

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

Re: Discussion regarding high-level interface for GSoC memory protection project.

2020-03-27 Thread Utkarsh Rai

On Fri, Mar 27, 2020 at 9:31 PM Gedare Bloom  wrote:

> Hi Utkarsh,
>
> You can remove "Discussion regarding" from your subject lines. We know
> your emails are discussions regarding the subject.
>
> On Fri, Mar 27, 2020 at 5:26 AM Utkarsh Rai 
> wrote:
> >
> > Hi,
> > My GSoC project proposal intended for providing thread-stack protection
> involves implementation on two levels, providing low-level hardware support
> for the target architecture and high-level architecture-independent APIs.
> As @Peter Dufault pointed to me in my draft the POSIX  compliant way of
> doing it would be through mmap, I would request your feedback on the
> details of the high-level implementation of thread-stack protection.
> > My idea is to obtain the stack attributes of the thread that is to be
> mapped by pthread_attr_getstack() and then get a file descriptor of the
> memory using posix_typed_mem_open() and finally mmap that to the stack of
> the required thread(With the specified permissions).
> >   Is this is a valid approach? If yes, I believe I would have to add the
> implementation of   posix_typed_mem_open() to my work plan as RTEMS
> does not support it as of now.
> >
>
> That's an interesting proposition. I guess you are suggesting to make
> thread stacks be "typed memory objects"? I don't know the
> ramifications of that, but it sounds like a really deep design and
> implementation challenge. It's not clear to me that "typed_mem_open"
> is proper to call on an existing typed object, but I'm not that
> familiar with the TYM interface. It could be something worth fleshing
> out though as a summer implementation project if there is plenty of
> work to do. It could be something for extension activities.
>
> I think however you could instead use shared memory objects, which
> already have some (limited) support, to accomplish the same ideas. You
> could give each thread's stack a "named" object in some filesystem,
> and other threads could shm_open() and mmap() the stack. I think that
> is the right way to go at least based on where we are in RTEMS now.
>
> You should also know and understand that the mmap() interface in RTEMS
> is quite shallow and restricted in its support. For file objects it
> basically only works to provide a copy of the file, because it works
> by copying the memory from the file to the destination. For shared
> memory objects it can provide rw access between two threads, but can't
> restrict access since we lack general protection mechanisms. If two
> threads want to share writeable stack regions then the current support
> could work, perhaps by using shared memory objects to set up the
> thread stacks. But two threads can't share read-only stack regions
> with the current implementation. That would be part of your work to
> figure out, in addition to perhaps improving and fixing up the
> existing mmap/shm support.
>
>   I had looked into that and therefore initially proposed a separate
'mem_share()' interface, but as was pointed out, it was not POSIX compliant.
 So I guess, adding on to the existing mmap/shm support is the best way to
move forward.

Step back a minute and think about the requirements before you.
> Threads have stacks already. Sometimes they share them with each
> other. Now you want to isolate each thread's stack from other threads.
> But if they still want to share, then you should allow it. How?
>
> The suggestion is to allow threads to use mmap() to map other threads'
> stacks. Some questions for you to ponder: Since those stacks exist and
> have an address already, can you just fiddle with the protection
> regions and return a pointer directly to the stack to allow r/w access
> with sharing?

I guess if a thread makes explicit calls to mmap for stack sharing and the
access to other stacks is not granted, this can be implemented(At the
hardware level it would mean that the page table attributes would be
updated for the thread-stack that is to be mapped).

> What are the limitations on the solution (based on the
> number of protection regions supported in hardware)?
>
As was mentioned in a separate thread we would have to go with the common
minimum hardware support to support maximum targets.

> Gedare
>
> > Regards,
> > Utkarsh Rai.
> > ___
> > 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: discussion related to implementation of File descriptor functions in RTEMS

On 2020-03-27 18:41, Joel Sherrill wrote:

On Fri, Mar 27, 2020 at 12:12 PM Eshan Dhawan > wrote:

On Thu, Mar 26, 2020 at 11:18 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

On 25/03/2020 20:33, Joel Sherrill wrote:

On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan
mailto:eshandhawa...@gmail.com>> wrote:

On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill
mailto:j...@rtems.org>> wrote:

On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan
mailto:eshandhawa...@gmail.com>> wrote:

Hello everyone,
As @Vaibhav Gupta
suggested I
have also added adding file descriptor functions
to my GSOC project.
I went through the mailing list archives for more
information.
RTEMS as its own file descriptor so the functions
need to be implemented from scratch.
I wanted to get more information related to it.

What's the set of functions you are proposing for
those not tracking your draft proposal?

Link:

https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
I haven't searched about the functions in the list yet.
The list was made by Vaibhav, last year and he told me
that it could be added to proposal this year as well.
I read the archives that these need to be written from
scratch.

Maybe not. I found at least this implementation of renameat()
which was implemented on top of existing calls:

https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h

It should be in a C file but that shows it can be done. That
directory has a lot of these methods.

Adding the *at() functions with an RTEMS-specific
implementation would be nice (and not difficult). The generic
renameat() implementation for example changes the current
directory. One of the goals of this API is to avoid exactly
this. In glibc/Linux for example a system call is used:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/renameat.c;h=901d61f37e10d0c2df245c01bb2ef980d00e8f52;hb=HEAD

https://github.com/torvalds/linux/blob/master/fs/namei.c#L4590

I'm not disagreeing that a generic implementation is undesirable
long-term but these methods have not been present for 30 years and no
one has complained about their absence. I would propose generic
implementations be added and a ticket filed to add RTEMS specific
implementations if someone complains about the performance.

I see adding them now as a higher effort task that brings little
value. These are for standards compliance and not performance critical.

I would prefer to have real implementations and not just a Potemkin
village. Changing the current working directory (there is only on in
RTEMS by default) can lead to hard to find bugs.

All these functions are probably easy to implement. With LIBIO_GET_IOP()
and LIBIO_GET_IOP_WITH_ACCESS() you get the iop from the file
descriptor. Then we have to add a variant of
rtems_filesystem_eval_path_start_with_root_and_current() which uses the
location of the iop as the initial currentloc. The root and current
global locations can be set to rtems_filesystem_global_location_null.

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

Re: AW: AW: [PATCH v3 3/3] i386: Port to RTEMS