Re: [PATCH] user/bld/index.rst: removed references to legacy network config options

[Vijay Kumar Banerjee]

Hi Harrison,

It's very close, just one little change

On Fri, May 7, 2021 at 5:02 PM Harrison Gerber  wrote:
>
> From: Harrison 
>
As it was mentioned in your last review. Please use your full legal
name in the patches for attribution purposes.

Thank you for the patch.

Best regards,
Vijay

> ---
>  user/bld/index.rst | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/user/bld/index.rst b/user/bld/index.rst
> index ebedf5a..411b3a2 100644
> --- a/user/bld/index.rst
> +++ b/user/bld/index.rst
> @@ -309,10 +309,6 @@ in the configuration file.
>  Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP
>  section of the configuration file.
>
> -``--enable-networking`` | ``--disable-networking``
> -Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP section 
> of
> -the configuration file.
> -
>  ``--enable-paravirt`` | ``--disable-paravirt``
>  Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section of
>  the configuration file.
> @@ -354,9 +350,6 @@ Please have a look at the following example configuration 
> file.
>  # --enable-multiprocessing
>  RTEMS_MULTIPROCESSING = False
>
> -# --enable-networking
> -RTEMS_NETWORKING = True
> -
>  # --disable-paravirt
>  RTEMS_PARAVIRT = False
>
> --
> 2.25.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

[PATCH] user/bld/index.rst: removed references to legacy network config options

[Harrison Gerber]

From: Harrison 

---
 user/bld/index.rst | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/user/bld/index.rst b/user/bld/index.rst
index ebedf5a..411b3a2 100644
--- a/user/bld/index.rst
+++ b/user/bld/index.rst
@@ -309,10 +309,6 @@ in the configuration file.
 Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP
 section of the configuration file.
 
-``--enable-networking`` | ``--disable-networking``
-Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP section of
-the configuration file.
-
 ``--enable-paravirt`` | ``--disable-paravirt``
 Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section of
 the configuration file.
@@ -354,9 +350,6 @@ Please have a look at the following example configuration 
file.
 # --enable-multiprocessing
 RTEMS_MULTIPROCESSING = False
 
-# --enable-networking
-RTEMS_NETWORKING = True
-
 # --disable-paravirt
 RTEMS_PARAVIRT = False
 
-- 
2.25.1

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

code review: help implementing clock_montonic

[zack_on_the_speed_chanel]

hello,

Currenttly i'm trying to implement the clock_monotonic which was part of ticket 
#3889. So far these are the changes are as follows

ptimer->clock_type= _id;
in the timer create i added a field for the timer id and saved it when the 
timer was made. Then in getttime I used the appropriate timers to get the time.

for example.

if (ptimer->clock_type ==CLOCK_REALTIME) {
Per_CPU_Control *cpu;
struct timespec spec;
struct timespec expire;

cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
_TOD_Get(spec);
_Timespec_From_ticks( expire, >Timer.expire);

if (spec->tv.nsec+spec->tv.sec > expire->tv.nsec+expire->tv.sec ) {

remaining = (uint32_t) (expire->tv.nsec+expire->tv.sec - 
spec->tv.nsec+spec->tv.sec);
} else {
remaining = 0;
}

_Timespec_From_ticks( remaining, >it_value );
value->it_interval = ptimer->timer_data.it_interval;

_POSIX_Timer_Release( cpu, _context );
return 0;
}
Here i made two separate cases for getting the time. Also joel told me to I 
feel that it is a bit redundant to call everything using timespec to 
calculating remaining time and then just use timespec_From_ticks to get the 
time. It was a recommendation from Joel. Did I make the correct change. Also I 
assume that Delete does not need any changes because It does not require any 
measuring of time. Is there anything i need to change for timer_settime?

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

[PATCH v5] rtems-debugger: Fixed 32bit pointers

[Stephen Clark]

Using 32bit types like uint32_t for pointers creates issues on 64 bit
architectures like AArch64. Replaced occurrences of these with uintptr_t,
which will work for both 32 and 64 bit architectures. Added hex_decode_addr
function to rtems-debugger. Changed rtems_debugger_target_swbreak_control()
parameter to DB_ADDR.
---
 .../rtems/debugger/rtems-debugger-server.h|  5 
 cpukit/libdebugger/rtems-debugger-server.c| 30 +++
 cpukit/libdebugger/rtems-debugger-target.c|  2 +-
 cpukit/libdebugger/rtems-debugger-target.h|  2 +-
 4 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/cpukit/include/rtems/debugger/rtems-debugger-server.h 
b/cpukit/include/rtems/debugger/rtems-debugger-server.h
index 2189aac873..beff302641 100644
--- a/cpukit/include/rtems/debugger/rtems-debugger-server.h
+++ b/cpukit/include/rtems/debugger/rtems-debugger-server.h
@@ -50,6 +50,11 @@ extern "C" {
  */
 #define DB_UINT uint32_t
 
+/**
+ * Data type for addresses. Here for 64bit support.
+ */
+#define DB_ADDR uintptr_t
+
 /*
  * Debugger signals.
  */
diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
b/cpukit/libdebugger/rtems-debugger-server.c
index 975ec23a30..2ada418a79 100644
--- a/cpukit/libdebugger/rtems-debugger-server.c
+++ b/cpukit/libdebugger/rtems-debugger-server.c
@@ -154,6 +154,26 @@ hex_encode(int val)
   return "0123456789abcdef"[val & 0xf];
 }
 
+static inline DB_ADDR
+hex_decode_addr(const uint8_t* data)
+{
+  DB_ADDR ui = 0;
+  size_t  i;
+  if (data[0] == '-') {
+if (data[1] == '1')
+  ui = (DB_ADDR) -1;
+  }
+  else {
+for (i = 0; i < (sizeof(ui) * 2); ++i) {
+  int v = hex_decode(data[i]);
+  if (v < 0)
+break;
+  ui = (ui << 4) | v;
+}
+  }
+  return ui;
+}
+
 static inline DB_UINT
 hex_decode_uint(const uint8_t* data)
 {
@@ -1438,10 +1458,10 @@ remote_read_memory(uint8_t* buffer, int size)
   if (comma == NULL)
 remote_packet_out_str(r_E01);
   else {
-DB_UINT addr;
+uintptr_t addr;
 DB_UINT length;
 int r;
-addr = hex_decode_uint([1]);
+addr = hex_decode_addr([1]);
 length = hex_decode_uint((const uint8_t*) comma + 1);
 remote_packet_out_reset();
 r = rtems_debugger_target_start_memory_access();
@@ -1468,10 +1488,10 @@ remote_write_memory(uint8_t* buffer, int size)
   comma = strchr((const char*) buffer, ',');
   colon = strchr((const char*) buffer, ':');
   if (comma != NULL && colon != NULL) {
-DB_UINT addr;
+uintptr_t addr;
 DB_UINT length;
 int r;
-addr = hex_decode_uint([1]);
+addr = hex_decode_addr([1]);
 length = hex_decode_uint((const uint8_t*) comma + 1);
 r = rtems_debugger_target_start_memory_access();
 if (r == 0) {
@@ -1521,7 +1541,7 @@ remote_breakpoints(bool insert, uint8_t* buffer, int size)
   uint32_t capabilities;
   DB_UINT  addr;
   DB_UINT  kind;
-  addr = hex_decode_uint((const uint8_t*) comma1 + 1);
+  addr = hex_decode_addr((const uint8_t*) comma1 + 1);
   kind = hex_decode_uint((const uint8_t*)comma2 + 1);
   capabilities = rtems_debugger_target_capabilities();
   switch (buffer[1]) {
diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index bf7579700d..99da21921b 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -168,7 +168,7 @@ rtems_debugger_target_reg_table_size(void)
 }
 
 int
-rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT kind)
+rtems_debugger_target_swbreak_control(bool insert, DB_ADDR addr, DB_UINT kind)
 {
   rtems_debugger_target* target = rtems_debugger->target;
   rtems_debugger_target_swbreak* swbreaks;
diff --git a/cpukit/libdebugger/rtems-debugger-target.h 
b/cpukit/libdebugger/rtems-debugger-target.h
index f2abbe5fd3..db356e1f07 100644
--- a/cpukit/libdebugger/rtems-debugger-target.h
+++ b/cpukit/libdebugger/rtems-debugger-target.h
@@ -200,7 +200,7 @@ extern void 
rtems_debugger_target_exception_print(CPU_Exception_frame* frame);
  * Software breakpoints. These are also referred to as memory breakpoints.
  */
 extern int rtems_debugger_target_swbreak_control(boolinsert,
- DB_UINT addr,
+ uintptr_t addr,
  DB_UINT kind);
 
 /**
-- 
2.27.0

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

Re: FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Joel Sherrill]

On Fri, May 7, 2021 at 12:12 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 07/05/2021 19:07, Joel Sherrill wrote:
> >
> >
> > On Fri, May 7, 2021 at 11:42 AM Sebastian Huber
> >  > > wrote:
> >
> >
> > On 07/05/2021 17:12, Đức Anh wrote:
> >  > Dear all,
> >  >
> >  > I built arm/fvp_cortex_r52 on the master branch,
> commit a1679af3805.
> >  > When I run rtems-test for this BSP, the program report
> >  > that FVP_BaseR_Cortex-R52x1 does not exist. So that all the tests
> > failed.
> >
> > It works for me:
> >
> > [4329/4329] Linking
> >
>  /tmp/sh/b-rtems/arm/fvp_cortex_r52/testsuites/validation/ts-validation-1.exe
> > Waf: Leaving directory `/tmp/sh/b-rtems/arm/fvp_cortex_r52'
> > 'build_arm/fvp_cortex_r52' finished successfully (12.065s)
> > ~/src/rtems (master) > rtems-test --rtems-bsp=fvp_cortex_r52x4
> > build/arm/fvp_cortex_r52
> >
> >
> > Not sure why I missed the ini file but thanks for posting.
> >
> > What simulator does this run on? How do you get it? I would like to add
> > it to my build sweeps.
>
> This BSP is still work in progress. I had to switch to other projects.
> The simulator needs a license from Arm:
>
>
> https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
>
>
Thanks for the info. Guess it will get a readme and short section in the
users guide eventually. At least until then, this email thread should show
up.

--joel

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] rtemstoolkit/mailer.py: Fix option ordering for add_arguments

[Alex White]

The ordering of keys cannot be guaranteed in a dictionary. This changes
the options iteration to no longer rely on key ordering.

Closes #4402
---
 rtemstoolkit/mailer.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index ae51d78..085a2ce 100644
--- a/rtemstoolkit/mailer.py
+++ b/rtemstoolkit/mailer.py
@@ -1,6 +1,7 @@
 #
 # RTEMS Tools Project (http://www.rtems.org/)
 # Copyright 2013-2016 Chris Johns (chr...@rtems.org)
+# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
 # All rights reserved.
 #
 # This file is part of the RTEMS Tools package in 'rtems-tools'.
@@ -61,7 +62,8 @@ def append_options(opts):
 def add_arguments(argsp):
 argsp.add_argument('--mail', help = _options['--mail'], action = 
'store_true')
 argsp.add_argument('--use-gitconfig', help = _options['--use-gitconfig'], 
action = 'store_true')
-for o in list(_options)[1:]:
+no_add = ['--mail', '--use-gitconfig']
+for o in [opt for opt in list(_options) if opt not in no_add]:
 argsp.add_argument(o, help = _options[o], type = str)
 
 class mail:
-- 
2.27.0

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

OAR RTEMS Automated Build Sweep Update

[Joel Sherrill]

Hi

I wanted to pass along that I turned on rtems7 tools to be built once a
week and test the same BSPs and configurations done for rtems6.  Results
should be showing up on build@. Currently the following is done:

+ If RTEMS Tools has changed, Coverity is run at  12:15 PM every day
(CentOS)

+ If RTEMS or RSB has changed, Coverity is run at at 15 after midnight
every day (CentOS)

+ RTEMS 6 Sweep of Tools and BSPs at 4:45pm every Friday (CentOS, FreeBSD,
Ubuntu)

+ RTEMS 7 Sweep of Tools and BSPs at 4:45pm every Friday (CentOS, FreeBSD,
Ubuntu)

The size of the sweep varies based on what has changed. If needed, it will
build all tools, run tests with debug on and off, SMP on and off as
appropriate for BSPs with simulators, and runs the rtems bsp builder.

Note: The rtems-bsp-builder has not been converted to waf and a high number
of failures are reported.

The CentOS computer is pretty beefy and takes about 30 hours if
everything has to be built and all BSPs build and test completely. The
FreeBSD and Ubuntu computers are older and it takes 2.5 - 3 days.

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

Re: FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Sebastian Huber]

On 07/05/2021 19:07, Joel Sherrill wrote:



On Fri, May 7, 2021 at 11:42 AM Sebastian Huber 
> wrote:



On 07/05/2021 17:12, Đức Anh wrote:
 > Dear all,
 >
 > I built arm/fvp_cortex_r52 on the master branch, commit a1679af3805.
 > When I run rtems-test for this BSP, the program report
 > that FVP_BaseR_Cortex-R52x1 does not exist. So that all the tests
failed.

It works for me:

[4329/4329] Linking
/tmp/sh/b-rtems/arm/fvp_cortex_r52/testsuites/validation/ts-validation-1.exe
Waf: Leaving directory `/tmp/sh/b-rtems/arm/fvp_cortex_r52'
'build_arm/fvp_cortex_r52' finished successfully (12.065s)
~/src/rtems (master) > rtems-test --rtems-bsp=fvp_cortex_r52x4
build/arm/fvp_cortex_r52


Not sure why I missed the ini file but thanks for posting.

What simulator does this run on? How do you get it? I would like to add
it to my build sweeps.


This BSP is still work in progress. I had to switch to other projects. 
The simulator needs a license from Arm:


https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Joel Sherrill]

On Fri, May 7, 2021 at 11:42 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 07/05/2021 17:12, Đức Anh wrote:
> > Dear all,
> >
> > I built arm/fvp_cortex_r52 on the master branch, commit a1679af3805.
> > When I run rtems-test for this BSP, the program report
> > that FVP_BaseR_Cortex-R52x1 does not exist. So that all the tests failed.
>
> It works for me:
>
> [4329/4329] Linking
>
> /tmp/sh/b-rtems/arm/fvp_cortex_r52/testsuites/validation/ts-validation-1.exe
> Waf: Leaving directory `/tmp/sh/b-rtems/arm/fvp_cortex_r52'
> 'build_arm/fvp_cortex_r52' finished successfully (12.065s)
> ~/src/rtems (master) > rtems-test --rtems-bsp=fvp_cortex_r52x4
> build/arm/fvp_cortex_r52
>

Not sure why I missed the ini file but thanks for posting.

What simulator does this run on? How do you get it? I would like to add
it to my build sweeps.

Thanks.

--joel

>
> [...]
>
> 657/657] p:596 f:6   u:6   e:0   I:0   B:3   t:0   L:0   i:0   W:0   |
> arm/fvp_cortex_r52: ts-validation-1.exe
>
> Passed:641
> Failed:  6
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 0
> Test too long:   1
> Invalid: 0
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 657
> Failures:
>   dl06.exe
>   dl09.exe
>   ttest02.exe
>   minimum.exe
>   smpmutex02.exe
>   sptimecounter02.exe
> User Input:
>   dl10.exe
>   monitor.exe
>   termios.exe
>   top.exe
>   fileio.exe
>   capture.exe
> Benchmark:
>   dhrystone.exe
>   whetstone.exe
>   linpack.exe
> Test too long:
>   smplock01.exe
> Average test time: 0:00:00.547722
> Testing time : 0:05:59.853078
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Sebastian Huber]

On 07/05/2021 17:12, Đức Anh wrote:

Dear all,

I built arm/fvp_cortex_r52 on the master branch, commit a1679af3805. 
When I run rtems-test for this BSP, the program report 
that FVP_BaseR_Cortex-R52x1 does not exist. So that all the tests failed.


It works for me:

[4329/4329] Linking 
/tmp/sh/b-rtems/arm/fvp_cortex_r52/testsuites/validation/ts-validation-1.exe

Waf: Leaving directory `/tmp/sh/b-rtems/arm/fvp_cortex_r52'
'build_arm/fvp_cortex_r52' finished successfully (12.065s)
~/src/rtems (master) > rtems-test --rtems-bsp=fvp_cortex_r52x4 
build/arm/fvp_cortex_r52


[...]

657/657] p:596 f:6   u:6   e:0   I:0   B:3   t:0   L:0   i:0   W:0   | 
arm/fvp_cortex_r52: ts-validation-1.exe


Passed:641
Failed:  6
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 0
Test too long:   1
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 657
Failures:
 dl06.exe
 dl09.exe
 ttest02.exe
 minimum.exe
 smpmutex02.exe
 sptimecounter02.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 fileio.exe
 capture.exe
Benchmark:
 dhrystone.exe
 whetstone.exe
 linpack.exe
Test too long:
 smplock01.exe
Average test time: 0:00:00.547722
Testing time : 0:05:59.853078

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Joel Sherrill]

On Fri, May 7, 2021, 10:13 AM Đức Anh  wrote:

> Dear all,
>
> I built arm/fvp_cortex_r52 on the master branch, commit a1679af3805. When
> I run rtems-test for this BSP, the program report
> that FVP_BaseR_Cortex-R52x1 does not exist. So that all the tests failed.
>

I don't see a configuration file (ini) for this bsp and RTEMS tester in
rtems-tools so that explains the tester error.



> How can I fix this problem? I followed all the build step (./waf
> configure, build, install)
>

I also don't see a readme or entry in the users guide for this bsp. That
should give some indication of how to run them.

Hopefully someone else will pop up it is more about this BSP.

> Best Regards,
> Duc Anh
> ___
> 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

FVP_BaseR_Cortex-R52x1 not exist when testing arm/fvp_cortex_r52

[Đức Anh]

Dear all,

I built arm/fvp_cortex_r52 on the master branch, commit a1679af3805. When I
run rtems-test for this BSP, the program report that FVP_BaseR_Cortex-R52x1
does not exist. So that all the tests failed.

How can I fix this problem? I followed all the build step (./waf configure,
build, install)

Best Regards,
Duc Anh
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Christian MAUDERER]

Hello Joel,

Am 07.05.21 um 16:45 schrieb Joel Sherrill:



On Fri, May 7, 2021 at 9:04 AM Christian MAUDERER 
> wrote:


It is a bit hard to see: The setkey programm uses the functions from
this library. In pfkey_open, a socket is opened and returned to setkey.
But setkey never closes it.


This much I assumed from the words "socket" and "leak" :)


We already have wrappers around all of the "dangerous" functions that
allocated resources. The wrappers register the resource allocation. If
an application called with
rtems_bsd_program_call_main_with_data_restore
exits, it will close or free the resources.


This makes sense. Is this documented?


Like a lot of libbsd: Not really. A rough description of the user-space 
utility porting process is here:


https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n189

But that is basically a "do it exactly like it is written there" guide 
than an explanation. The part that the rtems-bsd-program.h does all of 
the magic with the wrappers and registering ressources is clearly 
missing. If you know a good location where I should add a bit of 
description for this, please let me know.





There are some other functions in the pfkey that don't work well with
that mechanism. Therefore I only added the one function that is
responsible for the socket leak.


How about add some more to the commit message along the lines of
what you explained here. It just isn't obvious how a change to a macro
without words like free or deallocate in it fixes anything.



I'll do that (most likely) on Monday.

Best regards

Christian



Note that it is a bit of a hack but it works. I have planned to replace
the ipsec-tools with the tools from racoon2 soon to support newer
encryption protocols. So I think it's a reasonable intermediate
solution.


OK.  One thing we have gotten better at is migrating to pick up better
things.

--joel


Best regards

Christian

Am 07.05.21 um 15:56 schrieb Joel Sherrill:
 > How does this fix a leak?
 >
 > On Fri, May 7, 2021 at 7:09 AM Christian MAUDERER
 > mailto:christian.maude...@embedded-brains.de>
 > >> wrote:
 >
 >     Note that I would like to push this patch on 5-freebsd-12 as
well as on
 >     master.
 >
 >     Best regards
 >
 >     Christian
 >
 >
 >     Am 07.05.21 um 14:08 schrieb Christian Mauderer:
 >      > Fixes #4404
 >      > ---
 >      >   ipsec-tools/src/libipsec/pfkey.c | 7 +++
 >      >   1 file changed, 7 insertions(+)
 >      >
 >      > diff --git a/ipsec-tools/src/libipsec/pfkey.c
 >     b/ipsec-tools/src/libipsec/pfkey.c
 >      > index a621be12..385a21a9 100644
 >      > --- a/ipsec-tools/src/libipsec/pfkey.c
 >      > +++ b/ipsec-tools/src/libipsec/pfkey.c
 >      > @@ -1,5 +1,12 @@
 >      >   #include 
 >      >
 >      > +#ifdef __rtems__
 >      > +/* Only need socket from rtems-bsd-program wrappers! */
 >      > +int
 >      > +rtems_bsd_program_socket(int domain, int type, int protocol);
 >      > +#define socket(domain, type, protocol) \
 >      > +    rtems_bsd_program_socket(domain, type, protocol)
 >      > +#endif /* __rtems__ */
 >      >   /*  $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06
tteras Exp
 >     $    */
 >      >
 >      >   /*  $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp
$  */
 >      >
 >
 >     --
 >     
 >     embedded brains GmbH
 >     Herr Christian MAUDERER
 >     Dornierstr. 4
 >     82178 Puchheim
 >     Germany
 >     email: christian.maude...@embedded-brains.de

 >     >
 >     phone: +49-89-18 94 741 - 18
 >     fax:   +49-89-18 94 741 - 08
 >
 >     Registergericht: Amtsgericht München
 >     Registernummer: HRB 157899
 >     Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
Thomas Dörfler
 >     Unsere Datenschutzerklärung finden Sie hier:
 > https://embedded-brains.de/datenschutzerklaerung/

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

 >     

Re: [PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Joel Sherrill]

On Fri, May 7, 2021 at 9:04 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> It is a bit hard to see: The setkey programm uses the functions from
> this library. In pfkey_open, a socket is opened and returned to setkey.
> But setkey never closes it.
>

This much I assumed from the words "socket" and "leak" :)

>
> We already have wrappers around all of the "dangerous" functions that
> allocated resources. The wrappers register the resource allocation. If
> an application called with rtems_bsd_program_call_main_with_data_restore
> exits, it will close or free the resources.
>

This makes sense. Is this documented?


>
> There are some other functions in the pfkey that don't work well with
> that mechanism. Therefore I only added the one function that is
> responsible for the socket leak.
>

How about add some more to the commit message along the lines of
what you explained here. It just isn't obvious how a change to a macro
without words like free or deallocate in it fixes anything.


>
> Note that it is a bit of a hack but it works. I have planned to replace
> the ipsec-tools with the tools from racoon2 soon to support newer
> encryption protocols. So I think it's a reasonable intermediate solution.
>

OK.  One thing we have gotten better at is migrating to pick up better
things.

--joel

>
> Best regards
>
> Christian
>
> Am 07.05.21 um 15:56 schrieb Joel Sherrill:
> > How does this fix a leak?
> >
> > On Fri, May 7, 2021 at 7:09 AM Christian MAUDERER
> >  > > wrote:
> >
> > Note that I would like to push this patch on 5-freebsd-12 as well as
> on
> > master.
> >
> > Best regards
> >
> > Christian
> >
> >
> > Am 07.05.21 um 14:08 schrieb Christian Mauderer:
> >  > Fixes #4404
> >  > ---
> >  >   ipsec-tools/src/libipsec/pfkey.c | 7 +++
> >  >   1 file changed, 7 insertions(+)
> >  >
> >  > diff --git a/ipsec-tools/src/libipsec/pfkey.c
> > b/ipsec-tools/src/libipsec/pfkey.c
> >  > index a621be12..385a21a9 100644
> >  > --- a/ipsec-tools/src/libipsec/pfkey.c
> >  > +++ b/ipsec-tools/src/libipsec/pfkey.c
> >  > @@ -1,5 +1,12 @@
> >  >   #include 
> >  >
> >  > +#ifdef __rtems__
> >  > +/* Only need socket from rtems-bsd-program wrappers! */
> >  > +int
> >  > +rtems_bsd_program_socket(int domain, int type, int protocol);
> >  > +#define socket(domain, type, protocol) \
> >  > +rtems_bsd_program_socket(domain, type, protocol)
> >  > +#endif /* __rtems__ */
> >  >   /*  $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp
> > $*/
> >  >
> >  >   /*  $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
> >  >
> >
> > --
> > 
> > embedded brains GmbH
> > Herr Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> > 
> > phone: +49-89-18 94 741 - 18
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
> Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > 
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Christian MAUDERER]

It is a bit hard to see: The setkey programm uses the functions from 
this library. In pfkey_open, a socket is opened and returned to setkey. 
But setkey never closes it.


We already have wrappers around all of the "dangerous" functions that 
allocated resources. The wrappers register the resource allocation. If 
an application called with rtems_bsd_program_call_main_with_data_restore 
exits, it will close or free the resources.


There are some other functions in the pfkey that don't work well with 
that mechanism. Therefore I only added the one function that is 
responsible for the socket leak.


Note that it is a bit of a hack but it works. I have planned to replace 
the ipsec-tools with the tools from racoon2 soon to support newer 
encryption protocols. So I think it's a reasonable intermediate solution.


Best regards

Christian

Am 07.05.21 um 15:56 schrieb Joel Sherrill:

How does this fix a leak?

On Fri, May 7, 2021 at 7:09 AM Christian MAUDERER 
> wrote:


Note that I would like to push this patch on 5-freebsd-12 as well as on
master.

Best regards

Christian


Am 07.05.21 um 14:08 schrieb Christian Mauderer:
 > Fixes #4404
 > ---
 >   ipsec-tools/src/libipsec/pfkey.c | 7 +++
 >   1 file changed, 7 insertions(+)
 >
 > diff --git a/ipsec-tools/src/libipsec/pfkey.c
b/ipsec-tools/src/libipsec/pfkey.c
 > index a621be12..385a21a9 100644
 > --- a/ipsec-tools/src/libipsec/pfkey.c
 > +++ b/ipsec-tools/src/libipsec/pfkey.c
 > @@ -1,5 +1,12 @@
 >   #include 
 >
 > +#ifdef __rtems__
 > +/* Only need socket from rtems-bsd-program wrappers! */
 > +int
 > +rtems_bsd_program_socket(int domain, int type, int protocol);
 > +#define socket(domain, type, protocol) \
 > +    rtems_bsd_program_socket(domain, type, protocol)
 > +#endif /* __rtems__ */
 >   /*  $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp
$    */
 >
 >   /*  $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
 >

-- 


embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de

phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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




--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Joel Sherrill]

How does this fix a leak?

On Fri, May 7, 2021 at 7:09 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Note that I would like to push this patch on 5-freebsd-12 as well as on
> master.
>
> Best regards
>
> Christian
>
>
> Am 07.05.21 um 14:08 schrieb Christian Mauderer:
> > Fixes #4404
> > ---
> >   ipsec-tools/src/libipsec/pfkey.c | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/ipsec-tools/src/libipsec/pfkey.c
> b/ipsec-tools/src/libipsec/pfkey.c
> > index a621be12..385a21a9 100644
> > --- a/ipsec-tools/src/libipsec/pfkey.c
> > +++ b/ipsec-tools/src/libipsec/pfkey.c
> > @@ -1,5 +1,12 @@
> >   #include 
> >
> > +#ifdef __rtems__
> > +/* Only need socket from rtems-bsd-program wrappers! */
> > +int
> > +rtems_bsd_program_socket(int domain, int type, int protocol);
> > +#define socket(domain, type, protocol) \
> > +rtems_bsd_program_socket(domain, type, protocol)
> > +#endif /* __rtems__ */
> >   /*  $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
> >
> >   /*  $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Christian MAUDERER]

Note that I would like to push this patch on 5-freebsd-12 as well as on 
master.


Best regards

Christian


Am 07.05.21 um 14:08 schrieb Christian Mauderer:

Fixes #4404
---
  ipsec-tools/src/libipsec/pfkey.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index a621be12..385a21a9 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1,5 +1,12 @@
  #include 
  
+#ifdef __rtems__

+/* Only need socket from rtems-bsd-program wrappers! */
+int
+rtems_bsd_program_socket(int domain, int type, int protocol);
+#define socket(domain, type, protocol) \
+rtems_bsd_program_socket(domain, type, protocol)
+#endif /* __rtems__ */
  /*$NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
  
  /*	$KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $	*/




--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak

[Christian Mauderer]

Fixes #4404
---
 ipsec-tools/src/libipsec/pfkey.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index a621be12..385a21a9 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1,5 +1,12 @@
 #include 
 
+#ifdef __rtems__
+/* Only need socket from rtems-bsd-program wrappers! */
+int
+rtems_bsd_program_socket(int domain, int type, int protocol);
+#define socket(domain, type, protocol) \
+rtems_bsd_program_socket(domain, type, protocol)
+#endif /* __rtems__ */
 /* $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
 
 /* $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
-- 
2.26.2

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

Re: qemu version for source builder

[Karel Gardas]

On 5/7/21 8:15 AM, Richi Dubey wrote:
>  So, does this qemu not support e6500 cores (for the t2080rdb platform)?

IIRC e500/e5500/e6500 are supported by ppce500.

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

qemu version for source builder

[Richi Dubey]

Hi,

rdubey@hpc1:~/quick-start/src/rsb$
~/quick-start/rtems/6/bin/qemu-system-ppc64  -machine help
Supported machines are:
40p  IBM RS/6000 7020 (40p)
bamboo   bamboo
g3beige  Heathrow based PowerMAC
mac99Mac99 based PowerMAC
mpc8544dsmpc8544ds
none empty machine
powernv10IBM PowerNV (Non-Virtualized) POWER10
powernv8 IBM PowerNV (Non-Virtualized) POWER8
powernv  IBM PowerNV (Non-Virtualized) POWER9 (alias of
powernv9)
powernv9 IBM PowerNV (Non-Virtualized) POWER9
ppce500  generic paravirt e500 platform
pseries-2.1  pSeries Logical Partition (PAPR compliant)
pseries-2.10 pSeries Logical Partition (PAPR compliant)
pseries-2.11 pSeries Logical Partition (PAPR compliant)
pseries-2.12 pSeries Logical Partition (PAPR compliant)
pseries-2.12-sxxmpSeries Logical Partition (PAPR compliant)
pseries-2.2  pSeries Logical Partition (PAPR compliant)
pseries-2.3  pSeries Logical Partition (PAPR compliant)
pseries-2.4  pSeries Logical Partition (PAPR compliant)
pseries-2.5  pSeries Logical Partition (PAPR compliant)
pseries-2.6  pSeries Logical Partition (PAPR compliant)
pseries-2.7  pSeries Logical Partition (PAPR compliant)
pseries-2.8  pSeries Logical Partition (PAPR compliant)
pseries-2.9  pSeries Logical Partition (PAPR compliant)
pseries-3.0  pSeries Logical Partition (PAPR compliant)
pseries-3.1  pSeries Logical Partition (PAPR compliant)
pseries-4.0  pSeries Logical Partition (PAPR compliant)
pseries-4.1  pSeries Logical Partition (PAPR compliant)
pseries-4.2  pSeries Logical Partition (PAPR compliant)
pseries-5.0  pSeries Logical Partition (PAPR compliant)
pseries-5.1  pSeries Logical Partition (PAPR compliant)
pseries  pSeries Logical Partition (PAPR compliant) (alias of
pseries-5.2)
pseries-5.2  pSeries Logical Partition (PAPR compliant) (default)
ref405ep ref405ep
sam460ex aCube Sam460ex
taihutaihu
virtex-ml507 Xilinx Virtex ML507 reference design

I got this qemu by using the source builder with this command: "
./source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
devel/qemu.bset"
 So, does this qemu not support e6500 cores (for the t2080rdb platform)?

I read in a recent discussion about choosing qemu version:
https://lists.rtems.org/pipermail/devel/2020-May/059645.html. I can't seem
to get any version of qemu except the no-version named one:

rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu4.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu4.bset
error: no build set file found: devel/qemu4.bset
Build Set: Time 0:00:00.000433
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu6.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu6.bset
error: no build set file found: devel/qemu6.bset
Build Set: Time 0:00:00.000442
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu5.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu5.bset
error: no build set file found: devel/qemu5.bset
Build Set: Time 0:00:00.000493
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu.bset
Build Set: devel/autotools-internal.bset
config: devel/autoconf-2.69-1.cfg
///
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel