Re: GSOC: Call for Mentors

2020-02-17 Thread Amaan Cheval 
Hey! I'd like to co-mentor a project too. Thanks!

On Tue, Feb 18, 2020 at 8:56 AM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Hi Gedare,
>
> Please add me to the list of co-mentors.
> Looking forward to a great experience. :)
>
> Best regards,
> Vijay
>
>
> On Tue, Feb 18, 2020, 1:28 AM Gedare Bloom  wrote:
>
>> Assuming we get accepted on 2/20, I will be able to start adding mentors
>> shortly after. Please let me know if you're interested to mentor this
>> summer, either in a primary or co-mentor capacity. As usual, I will provide
>> "backup" mentoring and high-level organization of all projects with weekly
>> contact to each student. Primary mentors are responsible for multiple
>> interactions per week (daily is best) with their student and providing
>> strong technical guidance. Co-mentors should stay in the loop, and possibly
>> step in if the primary mentor needs a break or other emergency comes up.
>>
>> Gedare
>> ___
>> 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: GSOC: Call for Mentors

2020-02-17 Thread Vijay Kumar Banerjee 
Hi Gedare,

Please add me to the list of co-mentors.
Looking forward to a great experience. :)

Best regards,
Vijay


On Tue, Feb 18, 2020, 1:28 AM Gedare Bloom  wrote:

> Assuming we get accepted on 2/20, I will be able to start adding mentors
> shortly after. Please let me know if you're interested to mentor this
> summer, either in a primary or co-mentor capacity. As usual, I will provide
> "backup" mentoring and high-level organization of all projects with weekly
> contact to each student. Primary mentors are responsible for multiple
> interactions per week (daily is best) with their student and providing
> strong technical guidance. Co-mentors should stay in the loop, and possibly
> step in if the primary mentor needs a break or other emergency comes up.
>
> Gedare
> ___
> 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] libmisc/shell: Fix the handling of joel scripts in telnet

2020-02-17 Thread Chris Johns 
On 17/2/20 8:47 pm, Chris Johns wrote:
> 
>> On 17 Feb 2020, at 5:51 pm, Sebastian Huber 
>>  wrote:
>>
>> On 17/02/2020 07:05, chr...@rtems.org wrote:
>>> From: Chris Johns
>>> - Fix the passing of std[in/out] to child threads
>>> - Fix deleting of managed memory in the key destructor
>>> - Only set the key in the main loop thread
>>> - Only allocate a shell env outside of the main loop
>>> - Work around #3970
>>> - Fix memory leak if the task start fails
>>> - Remove error level from shell env, it cannot be returned this way. Add
>>>   exit_code but the API is broken so it cannot be returned.
>>> Closes #3859
>>
>> Any changes required in existing Telnet application code after this patch?
> 
> No. The intention is to not break telnet.

Actually this may not be true, it depends on how the user has implemented their
telnet command. If it is similar to the libbsd telnet test it will build but
fail at runtime. The call `rtems_shell_dup_current_env` needs to be made. I am
going enforce this by checking the magic number in the struct in the shell main
loop call.

The libbsd telnet test needs to be ...

static void
telnet_shell(char *name, void *arg)
{
rtems_shell_env_t env;

rtems_shell_dup_current_env();

env.devname = name;
env.taskname = "TLNT";
env.login_check = NULL;
env.forever = false;

rtems_shell_main_loop();
}

The env dup call is present in 4.11.

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

[4.11 PATCH] libmisc/shell: Fix the handling of joel scripts in telnet

2020-02-17 Thread chrisj 
From: Chris Johns 

- Fix the passing of std[in/out] to child threads
- Fix deleting of managed memory in the key destructor
- Only set the key in the main loop thread
- Only allocate a shell env outside of the main loop
- Fix memory leak if the task start fails
- Remove error level from shell env, it cannot be returned this way. Add
  exit_code but the API is broken so it cannot be returned.

Closes #3877
---
 cpukit/libmisc/shell/shell.c   | 205 +++--
 cpukit/libmisc/shell/shell.h   |   9 +-
 testsuites/libtests/shell01/init.c | 123 -
 3 files changed, 265 insertions(+), 72 deletions(-)

diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index 5f042f5855..fd2148acfd 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -40,20 +40,35 @@
 #include 
 #include 
 
+#define SHELL_STD_DEBUG 0
+
+#if SHELL_STD_DEBUG
+static FILE* default_stdout;
+#define shell_std_debug(...) fprintf(default_stdout, __VA_ARGS__)
+#else
+#define shell_std_debug(...)
+#endif
+
 const rtems_shell_env_t rtems_global_shell_env = {
   .magic = rtems_build_name('S', 'E', 'N', 'V'),
+  .managed   = false,
   .devname   = CONSOLE_DEVICE_NAME,
   .taskname  = "SHGL",
   .exit_shell= false,
   .forever   = true,
-  .errorlevel= -1,
   .echo  = false,
   .cwd   = "/",
   .input = NULL,
   .output= NULL,
   .output_append = false,
+  .parent_stdin  = NULL,
+  .parent_stdout = NULL,
+  .parent_stderr = NULL,
   .wake_on_end   = RTEMS_ID_NONE,
-  .login_check   = NULL
+  .exit_code = NULL,
+  .login_check   = NULL,
+  .uid   = 0,
+  .gid   = 0
 };
 
 static pthread_once_t rtems_shell_once = PTHREAD_ONCE_INIT;
@@ -64,7 +79,7 @@ static pthread_key_t rtems_shell_current_env_key;
  *  Initialize the shell user/process environment information
  */
 static rtems_shell_env_t *rtems_shell_init_env(
-  rtems_shell_env_t *shell_env_p
+  rtems_shell_env_t *shell_env_parent
 )
 {
   rtems_shell_env_t *shell_env;
@@ -72,11 +87,16 @@ static rtems_shell_env_t *rtems_shell_init_env(
   shell_env = malloc(sizeof(rtems_shell_env_t));
   if ( !shell_env )
 return NULL;
-  if ( !shell_env_p ) {
+
+  if ( shell_env_parent == NULL ) {
+shell_env_parent = rtems_shell_get_current_env();
+  }
+  if ( shell_env_parent == NULL ) {
 *shell_env = rtems_global_shell_env;
   } else {
-*shell_env = *shell_env_p;
+*shell_env = *shell_env_parent;
   }
+  shell_env->managed = true;
   shell_env->taskname = NULL;
 
   return shell_env;
@@ -92,14 +112,16 @@ static void rtems_shell_env_free(
   rtems_shell_env_t *shell_env;
   shell_env = (rtems_shell_env_t *) ptr;
 
-  if ( !ptr )
+  if ( ptr == NULL )
 return;
 
-  if ( shell_env->input )
-free((void *)shell_env->input);
-  if ( shell_env->output )
-free((void *)shell_env->output);
-  free( ptr );
+  if ( shell_env->managed ) {
+if ( shell_env->input )
+  free((void *)shell_env->input);
+if ( shell_env->output )
+  free((void *)shell_env->output);
+free( ptr );
+  }
 }
 
 static void rtems_shell_create_file(const char *name, const char *content)
@@ -131,6 +153,10 @@ static void rtems_shell_init_once(void)
   struct passwd pwd;
   struct passwd *pwd_res;
 
+#if SHELL_STD_DEBUG
+  default_stdout = stdout;
+#endif
+
   pthread_key_create(_shell_current_env_key, rtems_shell_env_free);
 
   /* dummy call to init /etc dir */
@@ -170,15 +196,22 @@ rtems_shell_env_t *rtems_shell_get_current_env(void)
 void rtems_shell_dup_current_env(rtems_shell_env_t *copy)
 {
   rtems_shell_env_t *env = rtems_shell_get_current_env();
-  if (env) {
+  if (env != NULL) {
 *copy = *env;
   }
   else {
-memset(copy, 0, sizeof(rtems_shell_env_t));
-copy->magic= rtems_build_name('S', 'E', 'N', 'V');
-copy->devname  = CONSOLE_DEVICE_NAME;
-copy->taskname = "RTSH";
+*copy = rtems_global_shell_env;
+copy->magic = rtems_build_name('S', 'E', 'N', 'V');
+copy->devname   = CONSOLE_DEVICE_NAME;
+copy->taskname  = "RTSH";
+copy->parent_stdout = stdout;
+copy->parent_stdin  = stdin;
+copy->parent_stderr = stderr;
   }
+  /*
+   * Duplicated environments are not managed.
+   */
+  copy->managed = false;
 }
 
 /*
@@ -707,10 +740,9 @@ static bool rtems_shell_init_user_env(void)
 #define RTEMS_SHELL_PROMPT_SIZE   (128)
 
 bool rtems_shell_main_loop(
-  rtems_shell_env_t *shell_env_arg
+  rtems_shell_env_t *shell_env
 )
 {
-  rtems_shell_env_t *shell_env;
   inteno;
   struct termios term;
   struct termios previous_term;
@@ -729,9 +761,8 @@ bool rtems_shell_main_loop(
 
   rtems_shell_init_environment();
 
-  shell_env = rtems_shell_init_env(shell_env_arg);
-  if (shell_env == NULL) {
-rtems_error(0, "rtems_shell_init_env");
+  if (shell_env->magic != rtems_build_name('S', 'E', 'N', 'V')) {
+rtems_error(0, "invalid shell environment passed

[4.11 PATCH] libcsupport/newlib: Call newlib's __sinit to force reent initialisation

2020-02-17 Thread chrisj 
From: Chris Johns 

- Newlib overtites any FILE pointers set in stdin, stdout or stderr.

Closes #3870
---
 cpukit/libcsupport/src/newlibc_reent.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/newlibc_reent.c 
b/cpukit/libcsupport/src/newlibc_reent.c
index 430157cf0f..6dc0b1eeaa 100644
--- a/cpukit/libcsupport/src/newlibc_reent.c
+++ b/cpukit/libcsupport/src/newlibc_reent.c
@@ -44,7 +44,10 @@ bool newlib_create_hook(
   }
 #endif
 
-  _REENT_INIT_PTR((creating_task->libc_reent)); /* GCC extension: structure 
constants */
+  extern void __sinit (struct _reent *s);
+  struct _reent *reent = (struct _reent *) creating_task->libc_reent;
+  _REENT_INIT_PTR((reent)); /* GCC extension: structure constants */
+  __sinit( reent );
 
   return true;
 }
-- 
2.23.0

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

[PATCH] user/tools: Add RTEMS TFTP Proxy command documentation

2020-02-17 Thread chrisj 
From: Chris Johns 

---
 images/user/tftp-proxy-1.png  | Bin 0 -> 15339 bytes
 images/user/tftp-proxy-1.puml |  34 +++
 user/testing/tftp.rst |   2 +
 user/tools/boot-image.rst |   2 +-
 user/tools/index.rst  |   1 +
 user/tools/tftp-proxy.rst | 166 ++
 6 files changed, 204 insertions(+), 1 deletion(-)
 create mode 100644 images/user/tftp-proxy-1.png
 create mode 100644 images/user/tftp-proxy-1.puml
 create mode 100644 user/tools/tftp-proxy.rst

diff --git a/images/user/tftp-proxy-1.png b/images/user/tftp-proxy-1.png
new file mode 100644
index 
..e6f4b5535e409b585e0e9ed1ff379278ef76ea94
GIT binary patch
literal 15339
zcmZv@1z40(*DkCef~7m4Ty9osdNcQ4&9B2q(e)JG)T9k(nyS?lysMLclW;s
z-}gJ`Kj(09!OSyz_OoN{b>Hh=>-nT8FNF#3-|RaaphaL&|ciSbz2n+4O|gZ
zC$INg#mwlQ|lcQQ75Xz<~onUj+pKRdgfmA;MBJ8LU8LtAS?
z7#}6*q1jwj!|A`*Z`}snxP0~aA{U+rBkBt;2>9JX-xBiJq=$IQC03}by`S`Zg!=u(D)UKa%ocBy
zW=byMoV_B+XR4QfYh>`lI6~raOprt2tvq6O^ot5CB-Z$;SaO*D1aaAtQH03;qw^z*
zg;Ay`DRHWBTXB=CnCGl1n~~j9ueWfLFZokO?g`>v4wQ2V
zZ`#D?aYv-S?jmepU(6`EBwI)y28F_XU$`)SzXuDH_6~|W!U)Pu*zldR{P|_B
zXRnj`J1>!CuQSz={CuzLwMZ(DmO$poTUO0?8Cw`qL|AR*vQ8WQWjFEJ#+OGUUZ
zxQdZ2tGTv4ycEqj7Nbc{9xqo!YW==b`0#EFn##_eep1@PW-jEN7xN`}kIj#~LmR
zh9u%rvHVYKQGU0K!4JVCorXWVXpR$B4t8Zz4CjN?8jujQ^E8VzMiEbU@Af?>A)faC
z>+=kxRq<(FABCfXLr`!qGc)u0+FG1k5ux>aqBvJ{8H5s?IBxT~i2WEQdFb8fhJu2E
znwo^M1@b;;9z-5b2{9B5VoZ1cy+on>t5>gNWCkqC`IEx_j|S!WOWTvx&-nPr>P9*`
zq)j3%#V2qvvip(B@S6@e#&7;9!L5|z<*ZDZV4~o@sMo|$Fa*Mi5MpRXx27a|l
zR_7QrI$~*}aom>-(@iBMI8{^*=x6B+ZU6J%)zheynI6;b1P!f3F$9ww
zJg{qL79Dpv9J(vRVdfl?9B_{jmRPEgs*;m(awaU|byfEBeFJ9=@jJWOMjmRx6HRtk
zK0YnUF!!;}_0>N~Ufj02aZZk4MIH4JuV>WMP1E*pD27weR8o<;uB&>%LC!L!F;N?v
zGYvV0-WBiG!(~wqwgzYtR#+DhF~fDRf+q3QR6e2nh)rMkbo7>>K`c1X)_1
zGY^uG@zDxiyuVonGIQt1xx+0gH82wm#aJ5Uowu~}M*NRfcF}|hi$_bH^6T6(F!8s7
zC3qi~;q}jR9KQWVG>Sl97ZpXzdbaC4Q-94(GW*i!?BT+$
zZlZeplmV5!W39p2-(UEC5}!UY-zg!q7Y+V2%uAIWc+
z{_H)1^Q^KN{N-g)&?y3)!)WGZxbbQBKrYhA+44Q2-91Jc!~Z3eocHnW!nZy)(Q}NW
zzrRN2TQ4=!}kTOtRO&
z`CrIM8_HL@7^1bRIrO5FYICxXH>E6=~oHNu8-|9%~OSoGG;EHg-G%~bBr9@
zh`Gn4Y_?*XW$JS%Pn!_*bT2rEfVFz6(sE=OXFED}2F78}+Q^LehY<$Wbiel}ub{Q&
zXBQt^`9BXt8d7L@OYknuGQGVwiRdpRH3loU8?bl^SDjMusVCJZ!>6BLOxK~~pez)^
zWB*mKT47R~(sW~rVk)BzyYW%&-8)WAl%;5qr!0q%uE9qcJoehvUrvX$(j?zMBI^IJ
z-`M<{f<8VMg7IRK!FCQ7?J+ysKxBJf_SmtH^@1T*4PFXX-u`=$3h9~8?be5nIf#OLT`m{dgN1}rI193}fnh44{7_m+(XHY+>-@isez>~US_^v;M*w&>GqF_ZY*tIO3GFu@>Qau~yXtBJOFaN-uPWfd3hUG{Tr_Vb}B=amF&^v
zAf8)VxcQN%-i?Jq0oX96TRfpJYRT;c9+O%~S23xM5mr%33{697l#ga|CNjbRn9*60

Re: GSOC: Call for Mentors

2020-02-17 Thread Christian Mauderer 
Hello Gedare,

it was a really nice experience in the last years. So I would be happy
to participate as a mentor again. Please add me using my work mail
address (added it as CC) because there is a connected google account for it.

Best regards

Christian

On 17/02/2020 20:58, Gedare Bloom wrote:
> Assuming we get accepted on 2/20, I will be able to start adding mentors
> shortly after. Please let me know if you're interested to mentor this
> summer, either in a primary or co-mentor capacity. As usual, I will
> provide "backup" mentoring and high-level organization of all projects
> with weekly contact to each student. Primary mentors are responsible for
> multiple interactions per week (daily is best) with their student and
> providing strong technical guidance. Co-mentors should stay in the loop,
> and possibly step in if the primary mentor needs a break or other
> emergency comes up.
> 
> Gedare
> 
> ___
> 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: gdb for RTEMS 5

2020-02-17 Thread Joel Sherrill 
On Mon, Feb 17, 2020 at 12:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/02/2020 23:05, Chris Johns wrote:
> > Hi,
> >
> > The builders have exposed a couple of regressions with gdb-9.1 ...
> >
> >   - FreeBSD
> >  - bfin
>
> On my FreeBSD 12.1 it worked:
>
> https://lists.rtems.org/pipermail/build/2020-February/010245.html


rtems 6 appears to have bumped to gdb 9.1 since the last time I built:

https://lists.rtems.org/pipermail/build/2020-January/009786.html

I will crank up a sweep on 6 now.

>
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Loading RTEMS applications from u-boot on Raspberry Pi 2

2020-02-17 Thread Cláudio Maia 
I am currently experimenting with RTEMS and Raspberry Pi 2 with the goal of 
exploring RTEMS-SMP properties (mainly scheduling and memory behaviour).

Currently, I am able to load an .img file when the default kernel.img file that 
comes with Raspbian is replaced by the RTEMS aplication .img file in the boot 
partition (let's call this approach #1).

However, I cannot execute any RTEMS application directly from u-boot (let's 
call this approach #2). The result is that when an .img is loaded using u-boot 
there is no output afterwards.
Can someone help me in detecting what is the issue?

---
I use the following settings to build the samples for the target:

$ $RTEMS/rtems/configure --prefix=$RTEMS/rtems/5 --target=arm-rtems5 
--enable-rtemsbsp=raspberrypi2 --enable-tests=samples
$ make install


---
For approach #1, the .img file is generated using the following command:

$ arm-rtems5-objcopy -O binary ticker.exe kernel.img

Then, I replace kernel.img in the boot partition and add the following lines to 
the config.txt file:

kernel_address=0x20
kernel=kernel.img

The code executes without issues.

---
For approach #2, I do the following:

$ arm-rtems5-objcopy -R -S -O binary hello.exe hello.bin
$ mkimage -A arm -O rtems -T kernel -C none -a 0x20 -e 0x200080 -d 
hello.bin hello-rtems.img

Image Name:   
Created:  Mon Feb 17 13:59:50 2020
Image Type:   ARM RTEMS Kernel Image (uncompressed)
Data Size:1055340 Bytes = 1030.61 kB = 1.01 MB
Load Address: 0020
Entry Point:  00200080

Then, after u-boot loads on the target, I do the following:

U-Boot> fatload mmc 0:1 0x20 hello-rtems.img 
reading hello-rtems.img 
1055404 bytes read in 103 ms (9.8 MiB/s)
 
U-Boot> iminfo

## Checking Image at 0020 ...
   Legacy image found
   Image Name:
   Image Type:   ARM RTEMS Kernel Image (uncompressed)
   Data Size:1055340 Bytes = 1 MiB
   Load Address: 0020
   Entry Point:  00200080
   Verifying Checksum ... OK
   
U-Boot> bootm 0x20
## Booting kernel from Legacy Image at 0020 ...
   Image Name:
   Image Type:   ARM RTEMS Kernel Image (uncompressed)
   Data Size:1055340 Bytes = 1 MiB
   Load Address: 0020
   Entry Point:  00200080
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
## Transferring control to RTEMS (at address 00200080) ...

After this point, nothing happens on the board.
---

Thank you in advance. Regards
Cláudio Maia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC: Call for Mentors

2020-02-17 Thread Gedare Bloom 
Assuming we get accepted on 2/20, I will be able to start adding mentors
shortly after. Please let me know if you're interested to mentor this
summer, either in a primary or co-mentor capacity. As usual, I will provide
"backup" mentoring and high-level organization of all projects with weekly
contact to each student. Primary mentors are responsible for multiple
interactions per week (daily is best) with their student and providing
strong technical guidance. Co-mentors should stay in the loop, and possibly
step in if the primary mentor needs a break or other emergency comes up.

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

Re: Project for GSoC 2020

2020-02-17 Thread Gedare Bloom 
On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai  wrote:

> Hello everyone,
>
Hello Utkarsh Rai,


> I would like to contribute to the Beagleboard BSP project, in particular
> towards the improvement of the peripheral support. I have a few questions
> pertaining to the same:-
>
> 1. Is adding support for Ethernet and USB a reasonable goal for the
> duration of the GSOC?
>
> 2. FreeBSD has support for Ethernet and USB  can we port that to libbsd?
>
> 3. What are the deliverables for this project, for instance, would I be
> required to add shell support for these peripherals or maybe an example app?
>
> I have also attached a screenshot of the changed  'hello world' program
> along with this email
>
Thanks. It is nice to see that you already ran it successfully on the BBB.

As of now, the BBB has quite mature support including Ethernet and USB.
There is another student actively working on a proposal to expand our BBB
support a bit further. I'm not certain if there is sufficient
work/interest/mentoring available to support multiple BBB projects. You
might consider what specific projects would interest you though. You should
take a look at past years' GSoC projects documented on our wiki, they are
linked from our main 'GSoC' page.

There are also lots of interesting projects that can be done in a
BSP-agnostic way, but still could be valuable to test with the BBB. The
most important aspect about doing development with a BBB is that you can
use the JTAG, which requires some soldering and additional effort to work
with a standalone JTAG debugger.  If you don't have that, and want to work
with the BBB, it is highly recommended.



> ___
> 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] Changed 'hello world' as a proof of concept(GSoC 2020).

2020-02-17 Thread Gedare Bloom 
Thank you. Please set your git-config user.name to your full/legal name for
copyright purposes.

On Mon, Feb 17, 2020 at 9:07 AM Utkarsh  wrote:

> From: ur10 
>
> ---
>  testsuites/samples/hello/init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/testsuites/samples/hello/init.c
> b/testsuites/samples/hello/init.c
> index 34ded37c55..e2a4f30cd1 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>
> -const char rtems_test_name[] = "HELLO WORLD";
> +const char rtems_test_name[] = "Proof of concept";
>
>  static rtems_task Init(
>rtems_task_argument ignored
> @@ -22,7 +22,7 @@ static rtems_task Init(
>  {
>rtems_print_printer_fprintf_putc(_test_printer);
>TEST_BEGIN();
> -  printf( "Hello World\n" );
> +  printf( "**Hello RTEMS Community
> *** \n" );
>TEST_END();
>rtems_test_exit( 0 );
>  }
> --
> 2.17.1
>
> ___
> 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: GSoC 2020 Proposal | Beagle BSP: Add a flattened device tree based initialization

2020-02-17 Thread Vijay Kumar Banerjee 
On Mon, Feb 17, 2020 at 1:32 PM G. S. Niteesh  wrote:

> Hi everyone,
> I have completed my proposal for GSoC 2020 for the project
> https://devel.rtems.org/ticket/3784. I would like to get suggestions
> from the community regarding the proposal. Below is the link to my
> proposal please have a look.
>
> https://docs.google.com/document/d/1V2RitYJOvWOvfow99hPUFB034iw4gb4eSfH8MixHnrk/edit?ts=5e498c23#
>
> Hi Niteesh,

It's great that you already got the proposal ready!
I saw a few comments from the mentors and I'm sure you're working
on them, meanwhile please also add your name to the GSoC tracking
page here:
https://devel.rtems.org/wiki/GSoC/2020

Best regards,
Vijay

>
> Thank you,
> 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: Status of fenv.h header and floating point environment support in newlib

2020-02-17 Thread Joel Sherrill 
Please stay on devel@. You get more help that way. I moved this back.

On Mon, Feb 17, 2020 at 10:31 AM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> Thank you Joel.
> I will add my name to the page you pointed out and start building my
> proposal as well. I think my first priority should be researching in depth
> about the floating point support (the registers and the FPU support) for
> the processors based on ARM. I think collecting the various BSD
> implementations sources for fenv is needed first. I found this FreeBSD
> implementation for the ARM architecture:
> https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
> Thanks a lot for sharing the NetBSD implementation it's thorough :)
>

It may turn out they are the same code or close for a given architecture.
FreeBSD is #1 choice. NetBSD likely has more architectures.

Another place I remembered is https://musl.libc.org/. They appear to have
a lot of architectures.

I spot checked a few other projects that I could think of but they either
also
used the FreeBSD code or only supported x86 and arm.


> About proposal should I be building it starting today? Also can I send
> patches if I happen to implement anything irrespective of the fact that
> POSIX Compliance is a GSoC open project of RTEMS(as in contributing patches
> independently would they be taken in consideration for a review?)
>

Working on your proposal should be a top priority. If we don't get accepted
as a project or you don't finish your proposal, then we can accept you. :)

With that said, there are things to do as you work on the proposal.

Being able to build newlib independently is critical on this project.
Vaibhav
and I have scripts to ease that.

Eventually you will have to have a toolchain for each architecture you want
to address.

You should also consider that after the first couple of these, they will
get easier so
pick some other POSIX Compliance tickets that are interesting. This is
AFAIK the
only one that is per architecture though. The rest will be port/implement
some code
and write tests.


> I will start looking into PowerPC and MIPS implementations later on. If
> you have more implementations links and resources please share them with me
> if possible.
>

Look as you work on your proposal.

--joel


>
> Regards,
> Ayush Dwivedi
>
>
> On Mon 17 Feb, 2020, 9:06 PM Joel Sherrill,  wrote:
>
>> Ayush please add yourself to  https://devel.rtems.org/wiki/GSoC/2020.
>>
>> Vaibhav.. we haven't asked others to add themselves to the table.
>> Please ping anyone we missed.
>>
>> On the fenv.h side, there are some basic guidelines on how to provide
>> the fenv functionality and subtleties from the POSIX requirements.
>>
>> First, the preferred origin of the implementation is another open source
>> project with FreeBSD and NetBSD being at the top of the list. For example,
>> here is the NetBSD implementation for the m68k:
>>
>> https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h
>>
>> But there are differences between vanilla m68k and coldfire so that may
>> not support all CPU variations. Would have to be determined.
>>
>> I have not found a SPARC implementation with an appropriate license.
>> Jiri may have a better source.
>>
>> I would put ARM, PowerPC, and MIPS at the top of the desired list that we
>> should be able to find BSD implementations for. We don't have an aarch64
>> port yet but I wouldn't stop a GSoC student from adding it to newlib.
>> Just can't
>> be tested with RTEMS yet. Beyond that, architectures like the m68k where
>> it
>> is porting, not writing from scratch are priorities. Covering as many
>> architectures
>> that are popular with RTEMS is the goal. SPARC64 would be down the list
>> based on that.
>>
>> Next POSIX allows an implementation to not support much if it isn't there
>> in hardware.
>>
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12
>>
>>
>> The fact that an architecture may not support a feature is challenging to
>> testing.
>>
>> --joel
>>
>> On Mon, Feb 17, 2020 at 5:54 AM Jiri Gaisler  wrote:
>>
>>>
>>> On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>>>
>>>
>>>
>>> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
>>> wrote:
>>>
 Hello Joel,
 This is regarding the open project #2966 POSIX-Compliance #2971( Add
 fenv.h to newlib). The task is about adding the floating point environment
 header to the newlib library but the source code of the library already has
 the header with the listed function declarations and data struct as needed.
 The implementations for the following architectures are available in the
 newlib-cygwin repository:
 >RISCV
 >i386
 >x86_64
 As pointed out in the POSIX Compliance project sub-task page the
 implementations for following architectures are yet to be added:
 >ARM(software float implementation for this exists but no fenv
 implementation)
 >AArch64(software float

Re: Status of fenv.h header and floating point environment support in newlib

2020-02-17 Thread Vaibhav Gupta 
On Mon, 17 Feb 2020 at 21:06, Joel Sherrill  wrote:

> Ayush please add yourself to  https://devel.rtems.org/wiki/GSoC/2020.
>
> Vaibhav.. we haven't asked others to add themselves to the table.
> Please ping anyone we missed.
>
Sure, I will inform them.

>
> On the fenv.h side, there are some basic guidelines on how to provide
> the fenv functionality and subtleties from the POSIX requirements.
>
And Dr Joel have already re-structured fenv implementation of RISCV
last summer. I would recommend everyone to study that structure for
once, those who are planning to work on fenv.
Porting fenv for other architectures under same structure will make
thing simple.
Also, check the weekly updates of
last year https://devel.rtems.org/wiki/GSoC/2019#VaibhavGupta
and go through the discussions done on mailing list. Check archives.
They will be of lot help to get to know the work done till now.

--Vaibhav Gupta

>
> First, the preferred origin of the implementation is another open source
> project with FreeBSD and NetBSD being at the top of the list. For example,
> here is the NetBSD implementation for the m68k:
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h
>
> But there are differences between vanilla m68k and coldfire so that may
> not support all CPU variations. Would have to be determined.
>
> I have not found a SPARC implementation with an appropriate license.
> Jiri may have a better source.
>
> I would put ARM, PowerPC, and MIPS at the top of the desired list that we
> should be able to find BSD implementations for. We don't have an aarch64
> port yet but I wouldn't stop a GSoC student from adding it to newlib. Just
> can't
> be tested with RTEMS yet. Beyond that, architectures like the m68k where it
> is porting, not writing from scratch are priorities. Covering as many
> architectures
> that are popular with RTEMS is the goal. SPARC64 would be down the list
> based on that.
>
> Next POSIX allows an implementation to not support much if it isn't there
> in hardware.
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12
>
>
> The fact that an architecture may not support a feature is challenging to
> testing.
>
> --joel
>
> On Mon, Feb 17, 2020 at 5:54 AM Jiri Gaisler  wrote:
>
>>
>> On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>>
>>
>>
>> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
>> wrote:
>>
>>> Hello Joel,
>>> This is regarding the open project #2966 POSIX-Compliance #2971( Add
>>> fenv.h to newlib). The task is about adding the floating point environment
>>> header to the newlib library but the source code of the library already has
>>> the header with the listed function declarations and data struct as needed.
>>> The implementations for the following architectures are available in the
>>> newlib-cygwin repository:
>>> >RISCV
>>> >i386
>>> >x86_64
>>> As pointed out in the POSIX Compliance project sub-task page the
>>> implementations for following architectures are yet to be added:
>>> >ARM(software float implementation for this exists but no fenv
>>> implementation)
>>> >AArch64(software float implementation for this exists but no fenv
>>> implementation)
>>> >SPARC and SPARC64(directories for these architectures are missing from
>>> libm/machine/ so no implementation of any sort)
>>>
>>> I would like to try and implement the functions declared in the header
>>> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>>>
>>> Following is the output after running test for posix fenv
>>> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and
>>> sparc-rtems5-gdb.(The Test failed)
>>>
>> Yes because testsuite needs modifications and moreover fenv on SPARC is
>> not yet supported. Since the support for RISCV and x86_64 is present, you
>> can make a testsuite for them. You can use qemu for running riscv files.
>>
>> Note that sis (riscv-rtems5-sis) also supports RISCV32 using the griscv
>> BSP in RTEMS.
>>
>> Jiri.
>>
>> ___
>> 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] Changed 'hello world' as a proof of concept(GSoC 2020).

2020-02-17 Thread Utkarsh 
From: ur10 

---
 testsuites/samples/hello/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 34ded37c55..e2a4f30cd1 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 
-const char rtems_test_name[] = "HELLO WORLD";
+const char rtems_test_name[] = "Proof of concept";
 
 static rtems_task Init(
   rtems_task_argument ignored
@@ -22,7 +22,7 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "**Hello RTEMS Community *** \n" 
);
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.17.1

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

Re: Status of fenv.h header and floating point environment support in newlib

2020-02-17 Thread Joel Sherrill 
Ayush please add yourself to  https://devel.rtems.org/wiki/GSoC/2020.

Vaibhav.. we haven't asked others to add themselves to the table.
Please ping anyone we missed.

On the fenv.h side, there are some basic guidelines on how to provide
the fenv functionality and subtleties from the POSIX requirements.

First, the preferred origin of the implementation is another open source
project with FreeBSD and NetBSD being at the top of the list. For example,
here is the NetBSD implementation for the m68k:

https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h

But there are differences between vanilla m68k and coldfire so that may
not support all CPU variations. Would have to be determined.

I have not found a SPARC implementation with an appropriate license.
Jiri may have a better source.

I would put ARM, PowerPC, and MIPS at the top of the desired list that we
should be able to find BSD implementations for. We don't have an aarch64
port yet but I wouldn't stop a GSoC student from adding it to newlib. Just
can't
be tested with RTEMS yet. Beyond that, architectures like the m68k where it
is porting, not writing from scratch are priorities. Covering as many
architectures
that are popular with RTEMS is the goal. SPARC64 would be down the list
based on that.

Next POSIX allows an implementation to not support much if it isn't there
in hardware.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12


The fact that an architecture may not support a feature is challenging to
testing.

--joel

On Mon, Feb 17, 2020 at 5:54 AM Jiri Gaisler  wrote:

>
> On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>
>
>
> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
> wrote:
>
>> Hello Joel,
>> This is regarding the open project #2966 POSIX-Compliance #2971( Add
>> fenv.h to newlib). The task is about adding the floating point environment
>> header to the newlib library but the source code of the library already has
>> the header with the listed function declarations and data struct as needed.
>> The implementations for the following architectures are available in the
>> newlib-cygwin repository:
>> >RISCV
>> >i386
>> >x86_64
>> As pointed out in the POSIX Compliance project sub-task page the
>> implementations for following architectures are yet to be added:
>> >ARM(software float implementation for this exists but no fenv
>> implementation)
>> >AArch64(software float implementation for this exists but no fenv
>> implementation)
>> >SPARC and SPARC64(directories for these architectures are missing from
>> libm/machine/ so no implementation of any sort)
>>
>> I would like to try and implement the functions declared in the header
>> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>>
>> Following is the output after running test for posix fenv
>> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and
>> sparc-rtems5-gdb.(The Test failed)
>>
> Yes because testsuite needs modifications and moreover fenv on SPARC is
> not yet supported. Since the support for RISCV and x86_64 is present, you
> can make a testsuite for them. You can use qemu for running riscv files.
>
> Note that sis (riscv-rtems5-sis) also supports RISCV32 using the griscv
> BSP in RTEMS.
>
> Jiri.
>
> ___
> 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

Fwd: libc coordination list

2020-02-17 Thread Joel Sherrill 
I assume some folks on the devel@ list will want to track this

-- Forwarded message -
From: Florian Weimer 
Date: Mon, Feb 17, 2020, 7:49 AM
Subject: libc coordination list
To: , , 


There's a new mailing list for cross-libc coordination issues, hosted at
Openwall:

  

I'm including the test of the announcement below.

Thanks,
Florian

Welcome to the libc-coord list!

This list is intended to coordinate work on run-time libraries for the C
programming language and its extensions.  Expected topics include:

- Proposals for portable library extensions
- Discussion and clarification of the behavior of already established
  interfaces
- Public review of proposals for the C standard or POSIX
- ABI-level changes that impact C implementations
- Coordination of the design and implementation of interfaces between
  compilers and libraries
- Other toolchain integration topics, such as debugger performance tools
  support

Posts to the list should be self-contained and include the material
relevant to the discussion, rather than relying solely on external
references.  Posting links to relevant external resources as well is
acceptable, but posting only links is discouraged.  Your message
should remain valuable even with all of the external resources gone.

Please be respectful of other people's work.  There is value in having
different implementations exploring various design choices.  But there
is also value in providing source code portability to programmers.
This list aims to help balancing these two goals.

To subscribe to the list, send mail to:

  

The list posting address is:

  

You can also manage your subscription at .

This list is lightly moderated (to deal with automated email
submissions), with Rich Felker and Florian Weimer as the initial
moderators, and the expectation that regular posters will be
white-listed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Status of fenv.h header and floating point environment support in newlib

2020-02-17 Thread Jiri Gaisler 

On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>
>
> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com 
> > wrote:
>
> Hello Joel,
> This is regarding the open project #2966 POSIX-Compliance #2971( Add 
> fenv.h to newlib). The task is about adding the floating point environment 
> header to the newlib library but the source code of the library already has 
> the header with the listed function declarations and data struct as needed. 
> The implementations for the following architectures are available in the 
> newlib-cygwin repository:
> >RISCV
> >i386
> >x86_64
> As pointed out in the POSIX Compliance project sub-task page the 
> implementations for following architectures are yet to be added:
> >ARM(software float implementation for this exists but no fenv 
> implementation)
> >AArch64(software float implementation for this exists but no fenv 
> implementation)
> >SPARC and SPARC64(directories for these architectures are missing from 
> libm/machine/ so no implementation of any sort)
>
> I would like to try and implement the functions declared in the header 
> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>
> Following is the output after running test for posix fenv 
> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and 
> sparc-rtems5-gdb.(The Test failed)
>
> Yes because testsuite needs modifications and moreover fenv on SPARC is not 
> yet supported. Since the support for RISCV and x86_64 is present, you can 
> make a testsuite for them. You can use qemu for running riscv files.

Note that sis (riscv-rtems5-sis) also supports RISCV32 using the griscv BSP in 
RTEMS.

Jiri.


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

Re: Status of fenv.h header and floating point environment support in newlib

2020-02-17 Thread Vaibhav Gupta 
On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> Hello Joel,
> This is regarding the open project #2966 POSIX-Compliance #2971( Add
> fenv.h to newlib). The task is about adding the floating point environment
> header to the newlib library but the source code of the library already has
> the header with the listed function declarations and data struct as needed.
> The implementations for the following architectures are available in the
> newlib-cygwin repository:
> >RISCV
> >i386
> >x86_64
> As pointed out in the POSIX Compliance project sub-task page the
> implementations for following architectures are yet to be added:
> >ARM(software float implementation for this exists but no fenv
> implementation)
> >AArch64(software float implementation for this exists but no fenv
> implementation)
> >SPARC and SPARC64(directories for these architectures are missing from
> libm/machine/ so no implementation of any sort)
>
> I would like to try and implement the functions declared in the header
> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>
> Following is the output after running test for posix fenv
> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and
> sparc-rtems5-gdb.(The Test failed)
>
Yes because testsuite needs modifications and moreover fenv on SPARC is not
yet supported. Since the support for RISCV and x86_64 is present, you can
make a testsuite for them. You can use qemu for running riscv files.

--Vaibhav

>
> Regards,
> Ayush Dwivedi
> ___
> 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] libmisc/shell: Fix the handling of joel scripts in telnet

2020-02-17 Thread Chris Johns 

> On 17 Feb 2020, at 5:51 pm, Sebastian Huber 
>  wrote:
> 
> On 17/02/2020 07:05, chr...@rtems.org wrote:
>> From: Chris Johns
>> - Fix the passing of std[in/out] to child threads
>> - Fix deleting of managed memory in the key destructor
>> - Only set the key in the main loop thread
>> - Only allocate a shell env outside of the main loop
>> - Work around #3970
>> - Fix memory leak if the task start fails
>> - Remove error level from shell env, it cannot be returned this way. Add
>>   exit_code but the API is broken so it cannot be returned.
>> Closes #3859
> 
> Any changes required in existing Telnet application code after this patch?

No. The intention is to not break telnet. 

Chris

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

[PATCH] c-user: Obsolete CONFIGURE_HAS_OWN_INIT_TASK_TABLE

2020-02-17 Thread Sebastian Huber 
The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and
CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_*
configuration options.  These two options are probably unused, see also:

* https://lists.rtems.org/pipermail/users/2019-April/033129.html

* https://lists.rtems.org/pipermail/users/2019-April/033130.html

Removing them simplifies the configuration. If there is a real user need
which shows up after the removal, we can resurrect them on demand.

Using CONFIGURE_HAS_OWN_INIT_TASK_TABLE would have required the use of
the undocumented CONFIGURE_INIT_TASK_TABLE and
CONFIGURE_INIT_TASK_TABLE_SIZE configuration options.

Close #3873.
---
 c-user/configuring_a_system.rst | 40 
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index bc2b37a..fbcfbfc 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -1563,34 +1563,6 @@ DESCRIPTION:
 NOTES:
 None.
 
-.. index:: CONFIGURE_HAS_OWN_INIT_TASK_TABLE
-
-.. _CONFIGURE_HAS_OWN_INIT_TASK_TABLE:
-
-CONFIGURE_HAS_OWN_INIT_TASK_TABLE
--
-
-CONSTANT:
-``CONFIGURE_HAS_OWN_INIT_TASK_TABLE``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-``CONFIGURE_HAS_OWN_INIT_TASK_TABLE`` is defined if the user wishes to
-define their own Classic API Initialization Tasks Table.  This table should
-be named ``Initialization_tasks``.
-
-NOTES:
-This is a seldom used configuration parameter. The most likely use case is
-when an application desires to have more than one initialization task.
-
 POSIX API Configuration
 ===
 
@@ -4813,6 +4785,18 @@ CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
 This configuration option was present in all RTEMS versions since at least 1995
 and is obsolete since RTEMS 5.1.
 
+.. index:: CONFIGURE_HAS_OWN_INIT_TASK_TABLE
+
+.. _CONFIGURE_HAS_OWN_INIT_TASK_TABLE:
+
+CONFIGURE_HAS_OWN_INIT_TASK_TABLE
+-
+
+This configuration option was present in all RTEMS versions since at least 1995
+and is obsolete since RTEMS 5.1.  If you used this configuration option or you
+think that there should be a way to configure more than one Classic API
+initialization task, then please ask on the :r:list:`users`.
+
 .. index:: CONFIGURE_HAS_OWN_MOUNT_TABLE
 
 CONFIGURE_HAS_OWN_MOUNT_TABLE
-- 
2.16.4

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

[PATCH] c-user: Obsolete CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE

2020-02-17 Thread Sebastian Huber 
The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and
CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_*
configuration options.  These two options are probably unused, see also:

* https://lists.rtems.org/pipermail/users/2019-April/033129.html

* https://lists.rtems.org/pipermail/users/2019-April/033130.html

Removing them simplifies the configuration. If there is a real user need
which shows up after the removal, we can resurrect them on demand.

Using CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE would have required the
use of the undocumented CONFIGURE_POSIX_INIT_THREAD_TABLE_NAME and
CONFIGURE_POSIX_INIT_THREAD_TABLE_SIZE configuration options.

Close #3874.
---
 c-user/configuring_a_system.rst | 48 ++---
 1 file changed, 16 insertions(+), 32 deletions(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index fbcfbfc..d6d9411 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -1913,34 +1913,6 @@ NOTES:
 Task/Thread Stack Memory Above Minimum` for more information about
 ``CONFIGURE_EXTRA_TASK_STACKS``.
 
-.. index:: CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE
-
-.. _CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE:
-
-CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE
--
-
-CONSTANT:
-``CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-``CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE`` is defined if the user wishes
-to define their own POSIX API Initialization Threads Table.  This table
-should be named ``POSIX_Initialization_threads``.
-
-NOTES:
-This is a seldom used configuration parameter. The most likely use case is
-when an application desires to have more than one initialization task.
-
 Configuring Custom Task Stack Allocation
 
 
@@ -4906,12 +4878,17 @@ CONFIGURE_MAXIMUM_POSIX_SPINLOCKS
 
 This configuration option is obsolete since RTEMS 5.1.
 
-.. index:: CONFIGURE_TERMIOS_DISABLED
+.. index:: CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE
 
-CONFIGURE_TERMIOS_DISABLED
---
+.. _CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE:
 
-This configuration option is obsolete since RTEMS 5.1.
+CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE
+-
+
+This configuration option was present in all RTEMS versions since at least 1995
+and is obsolete since RTEMS 5.1.  If you used this configuration option or you
+think that there should be a way to configure more than one POSIX 
initialization
+thread, then please ask on the  :r:list:`users`.
 
 .. index:: CONFIGURE_SMP_APPLICATION
 
@@ -4928,3 +4905,10 @@ CONFIGURE_SMP_MAXIMUM_PROCESSORS
 
 This configuration option was introduced in RTEMS 4.11.0 and is obsolete since
 RTEMS 5.1.  See also :ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
+
+.. index:: CONFIGURE_TERMIOS_DISABLED
+
+CONFIGURE_TERMIOS_DISABLED
+--
+
+This configuration option is obsolete since RTEMS 5.1.
-- 
2.16.4

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

Re: [PATCH v3] testsuite/newlib: Check newlib does not touch an assigned std FILE pointer

2020-02-17 Thread Chris Johns 


> On 17 Feb 2020, at 5:54 pm, Sebastian Huber 
>  wrote:
> 
> On 16/02/2020 23:29, chr...@rtems.org wrote:
>> From: Chris Johns
>> Update #3870
> 
> Looks good. If you have time, please remove the #include  
> before the push.

Will do. Saw that after I post the patch. 

Chris

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

GSoC 2020 Proposal | Beagle BSP: Add a flattened device tree based initialization

2020-02-17 Thread G. S. Niteesh 
Hi everyone,
I have completed my proposal for GSoC 2020 for the project
https://devel.rtems.org/ticket/3784. I would like to get suggestions
from the community regarding the proposal. Below is the link to my
proposal please have a look.
https://docs.google.com/document/d/1V2RitYJOvWOvfow99hPUFB034iw4gb4eSfH8MixHnrk/edit?ts=5e498c23#


Thank you,
Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel