Re: We are loosing patches

On 09/09/2020 17:52, Gedare Bloom wrote: > On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer > wrote: >> >> Hello Jan and Joel, >> >> On 09/09/2020 15:19, Joel Sherrill wrote: >>> >>> >>> On Wed, Sep 9, 2020 at 3:43 AM >> > wrote: >>> >>> I would like this idea. >>>

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

Hello Gedare, I'll have to rework some parts (the ones where I checked for the BSP) but I'll try. Best regards Christian On 09/09/2020 17:58, Gedare Bloom wrote: > Can this be pushed upstream in a non-RTEMS specific way? > > On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer > wrote: >> >> Som

[PATCH 2/3] ifmcstat: Port to RTEMS

--- Makefile.todo | 1 + freebsd/usr.sbin/ifmcstat/ifmcstat.c | 49 ++- freebsd/usr.sbin/ifmcstat/printb.c| 5 ++ .../ifmcstat/rtems-bsd-ifmcstat-data.h| 4 ++ .../rtems-bsd-ifmcstat-ifmcstat-data.h| 7 +++ ..

[PATCH 3/3] mcast01: Add test program

--- libbsd.py | 1 + testsuite/mcast01/test_main.c | 285 ++ 2 files changed, 286 insertions(+) create mode 100644 testsuite/mcast01/test_main.c diff --git a/libbsd.py b/libbsd.py index 6a471873..c251fba4 100644 --- a/libbsd.py +++ b/libbsd.p

[PATCH 0/3] libbsd: Add multicast test program

Sebastian Huber (3): ifmcstat: Import from FreeBSD ifmcstat: Port to RTEMS mcast01: Add test program Makefile.todo |1 + freebsd/usr.sbin/ifmcstat/ifmcstat.c | 1295 + freebsd/usr.sbin/ifmcstat/printb.c| 75 + .../if

[PATCH 1/3] ifmcstat: Import from FreeBSD

--- freebsd/usr.sbin/ifmcstat/ifmcstat.c | 1250 ++ freebsd/usr.sbin/ifmcstat/printb.c | 70 ++ 2 files changed, 1320 insertions(+) create mode 100644 freebsd/usr.sbin/ifmcstat/ifmcstat.c create mode 100644 freebsd/usr.sbin/ifmcstat/printb.c diff --git a/freebsd/usr.

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 09/09/2020 17:28, Gedare Bloom wrote: I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it should be made from the 5-freebsd-12 branch? I feel it is currently confusing but either way it has issues. Maybe, we can continue to discuss that outside of this patch set? R

Re: [PATCH 0/3] libbsd: Add multicast test program

On 10/09/2020 09:51, Sebastian Huber wrote: Sebastian Huber (3): ifmcstat: Import from FreeBSD ifmcstat: Port to RTEMS mcast01: Add test program I would like to back port this also to the 5-freebsd-12 branch. The ifmcstat command is a helpful diagnostics command. _

Re: [PATCH 0/3] libbsd: Add multicast test program

On 10/9/20 8:17 pm, Sebastian Huber wrote: > On 10/09/2020 09:51, Sebastian Huber wrote: > >> Sebastian Huber (3): >>    ifmcstat: Import from FreeBSD >>    ifmcstat: Port to RTEMS >>    mcast01: Add test program > I would like to back port this also to the 5-freebsd-12 branch. The ifmcstat > comm

Re: [PATCH 0/3] libbsd: Add multicast test program

On 10/09/2020 12:38, Chris Johns wrote: On 10/9/20 8:17 pm, Sebastian Huber wrote: On 10/09/2020 09:51, Sebastian Huber wrote: Sebastian Huber (3):    ifmcstat: Import from FreeBSD    ifmcstat: Port to RTEMS    mcast01: Add test program I would like to back port this also to the 5-freebsd

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 10/09/2020 12:13, Sebastian Huber wrote: On 09/09/2020 17:28, Gedare Bloom wrote: I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it should be made from the 5-freebsd-12 branch? I feel it is currently confusing but either way it has issues. Maybe, we can contin

Re: [PATCH 0/3] libbsd: Add multicast test program

FWIW I have an mcast-writer and mcast-listener example that I got off the net. I cleaned the warnings and changed it so it plugs in to the shell as a user provided mains in the shell. I didn't know where it might belong to even be a candidate to add. Here are the main files. Not sure what to do wi

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

Hello Gedare, I created a ticket for this in FreeBSD (I really hope I picked the right way for this). I'll wait whether it needs some adaption and then re-send an adapted patch for libbsd as soon as I have a version that is accepted in FreeBSD. Best regards Christian On 10/09/2020 09:05, Christ

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

Hello, I added a ticket for this: https://devel.rtems.org/ticket/4074 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

Document this application configuration option. Update #4074. --- c-user/config/classic-api.rst | 35 +++ 1 file changed, 35 insertions(+) diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst index f0fbe6f..d7002ad 100644 --- a/c-user/config/

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

How is the user/system integrator supposed to figure out the size of the TLS? It is not known until the application is linked and thus varies based on the total set of code linked. As far as I can tell, this makes this type of task creation unsuitable for use in libraries where the end system is u

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

Thanks, good luck :) On Thu, Sep 10, 2020 at 7:19 AM Christian Mauderer wrote: > > Hello Gedare, > > I created a ticket for this in FreeBSD (I really hope I picked the right > way for this). I'll wait whether it needs some adaption and then re-send > an adapted patch for libbsd as soon as I have

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

Hello Joel, this configuration option is a by product of the discussions related to the proposed rtems_task_create_from_config() directive. I addresses an issue with thread-local storage in dynamically linked objects. Since I work currently in the same code area, it is easier if I try to imple

Re: New coding style for new files?

On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber wrote: > > Hello, > > I think we waste too much time to address coding style issues on newly > contributed code, for example GSoC. I don't know a source code > formatting tool which supports the RTEMS coding style and I think it is > not worth the ti

Re: [PATCH] user: Add xilinx-zynq BSP details

Thanks for the doco. Just a few comments. On Mon, Sep 7, 2020 at 9:30 PM wrote: > > From: Chris Johns > > --- > user/bsps/arm/xilinx-zynq.rst | 114 +- > 1 file changed, 112 insertions(+), 2 deletions(-) > > diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/

Re: Introducing the Strong APA Scheduler

On Mon, Sep 7, 2020 at 8:55 AM Richi Dubey wrote: > > Invalid directory. Sorry for the doubt. > Did you get it working? You'll want to run a "clean" version also for comparison, to isolate problems you might introduce. > On Mon, Sep 7, 2020 at 8:18 PM Richi Dubey wrote: >>> >>> You should run

Re: New coding style for new files?

On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom wrote: > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber > wrote: > > > > Hello, > > > > I think we waste too much time to address coding style issues on newly > > contributed code, for example GSoC. I don't know a source code > > formatting tool whi

Re: [PATCH] user: Add xilinx-zynq BSP details

Looks good to me other than Gedare's comments. Glad to see it. I don't think it goes in the Zynq section but when using networking with qemu, you tend to need to forward ports. Is there a logical location for general BSP independent information on using Qemu with RTEMS? On Thu, Sep 10, 2020 at

Re: Determining Linux Distribution

On 10/09/2020 00:25, Chris Johns wrote: > On 10/9/20 8:15 am, Joel Sherrill wrote: >> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas > > wrote: >> >> On 9/9/20 11:03 PM, Karel Gardas wrote: >> > so Debian, Kali and OpenSuSE at least are not well handled by this

Re: Determining Linux Distribution

On Thu, Sep 10, 2020 at 11:09 AM Christian Mauderer wrote: > On 10/09/2020 00:25, Chris Johns wrote: > > On 10/9/20 8:15 am, Joel Sherrill wrote: > >> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas >> > wrote: > >> > >> On 9/9/20 11:03 PM, Karel Gardas wrote: > >

Re: Determining Linux Distribution

On 10/09/2020 18:31, Joel Sherrill wrote: > > > On Thu, Sep 10, 2020 at 11:09 AM Christian Mauderer > wrote: > > On 10/09/2020 00:25, Chris Johns wrote: > > On 10/9/20 8:15 am, Joel Sherrill wrote: > >> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas > mai

[PATCH] Remove tmoverhd which existed to produce the obsolete coverhd.h

Closes #4040. --- bsps/m68k/mvme147/README |5 +- bsps/m68k/mvme147s/README |5 +- testsuites/ada/configure.ac |1 - testsuites/ada/tmtests/Makefile.am|1 - testsuites/ada/tmtests/tmoverhd/Makefile.am | 13 -

Re: Introducing the Strong APA Scheduler

Yes. You'll want to run a "clean" version also for comparison, to isolate > problems you might introduce. Shouldn't the clean version give no errors and timeouts? Cause mine does give failures. On Thu, Sep 10, 2020 at 9:02 PM Gedare Bloom wrote: > On Mon, Sep 7, 2020 at 8:55 AM Richi Dubey wr

[PATCH] tester: Correct path

--- user/tools/tester.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index 5452856..1d10462 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@ -258,8 +258,7 @@ the directories under that path are searched for a

[PATCH] Confstr Patches

Adds Confstr file To RTEMS with test Signed-off-by: Eshan dhawan --- cpukit/Makefile.am| 1 + cpukit/posix/src/confstr.c| 105 +++ testsuites/psxtests/Makefile.am | 9 ++ testsuites/psxtests/configure.ac |

Re: Introducing the Strong APA Scheduler

On Thu, Sep 10, 2020 at 12:56 PM Richi Dubey wrote: > > Yes. > >> You'll want to run a "clean" version also for comparison, to isolate >> problems you might introduce. > > Shouldn't the clean version give no errors and timeouts? Cause mine does give > failures. > There are sometimes bugs or thin

Re: Strong APA scheduler testing

Start at the end and work your way back. The clean version reports: Passed:636 Failed: 1 User Input: 6 Expected Fail: 1 Indeterminate: 0 Benchmark: 3 Timeout: 3 Invalid: 5 Wrong Version: 1 Wrong Build: 0 Wrong Tools: 0 -- To

Re: [PATCH] tester: Correct path

On Thu, Sep 10, 2020 at 12:59 PM Richi Dubey wrote: > > --- > user/tools/tester.rst | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/user/tools/tester.rst b/user/tools/tester.rst > index 5452856..1d10462 100644 > --- a/user/tools/tester.rst > +++ b/user/tools/tester.rst

Re: New coding style for new files?

On 11/9/20 1:32 am, Joel Sherrill wrote: > I also think when doing this we should consider things that we do that > we have since learned safety standards don't like such as single statement > if's without braces. I think we should have braces now. Are there open tools available that check for the

Re: [PATCH 0/3] libbsd: Add multicast test program

On 10/9/20 9:33 pm, Sebastian Huber wrote: > On 10/09/2020 12:38, Chris Johns wrote: > >> On 10/9/20 8:17 pm, Sebastian Huber wrote: >>> On 10/09/2020 09:51, Sebastian Huber wrote: >>> Sebastian Huber (3):     ifmcstat: Import from FreeBSD     ifmcstat: Port to RTEMS     mcast0

Re: New coding style for new files?

On Thu, Sep 10, 2020, 5:22 PM Chris Johns wrote: > On 11/9/20 1:32 am, Joel Sherrill wrote: > > I also think when doing this we should consider things that we do that > > we have since learned safety standards don't like such as single > statement > > if's without braces. I think we should have b

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 10/9/20 9:34 pm, Sebastian Huber wrote: > On 10/09/2020 12:13, Sebastian Huber wrote: >> On 09/09/2020 17:28, Gedare Bloom wrote: >> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and >> if it >> should be made from the 5-freebsd-12 branch? I feel it is currentl

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 11/09/2020 07:38, Chris Johns wrote: On 10/9/20 9:34 pm, Sebastian Huber wrote: On 10/09/2020 12:13, Sebastian Huber wrote: On 09/09/2020 17:28, Gedare Bloom wrote: I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it should be made from the 5-freebsd-12 branch? I

Virus Warning

Hello, I assume that most of you are careful anyway. But nonetheless a virus warning: I received a message that pretends to be an answer to a RTEMS mailing list post. The mail has a .doc file attached that contains a virus. Text of the mail is: -- Good afternoon! It is regarding o