[PATCH v2] rtems-fdt / shell - Fix string truncation warning

[Frank Kuehndel]

From: Frank Kühndel 

The compiler warning was:

../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:
'strncpy' specified bound depends on the length of the source argument
  267 | strncpy(path, name, namelen);
  | ^~~~

It turns out that the `strncpy()` nor the buffer `path` is needed when
one uses `strncmp()` instead of `strcmp()`. This needs some change to
the algorithm but has the advantage that `name` is never truncated
to the size of the buffer `path`.
---
 cpukit/libmisc/rtems-fdt/rtems-fdt.c | 40 +---
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
index 39e70bffec..0ea365314f 100644
--- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
+++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
@@ -248,48 +248,46 @@ rtems_fdt_index_find_by_name(rtems_fdt_index* index,
 {
   int min = 0;
   int max = index->num_entries;
-  charpath[256];
-  const char* cmp_name = name;
-
   /*
* Handle trailing slash case.
*/
-  int namelen = strlen(name);
+  size_t namelen = strlen(name);
   if (namelen > 0 && name[namelen-1] == '/')
   {
 namelen--;
-
-if (namelen >= (int)sizeof(path) - 1)
-{
-  namelen = sizeof(path) - 1;
-}
-
-strncpy(path, name, namelen);
-path[namelen] = 0;
-cmp_name = path;
   }
 
   /* Binary search for the name. */
   while (min < max)
   {
 int middle = (min + max) / 2;
-int cmp = strcmp(cmp_name, index->entries[middle].name);
+int cmp = strncmp(name, index->entries[middle].name, namelen);
+if (cmp == 0)
+{
+  /* 'namelen' characters are equal but 'index->entries[middle].name' */
+  /* could have additional characters. */
+  if (index->entries[middle].name[namelen] == '\0')
+  {
+/* Found it. */
+return index->entries[middle].offset;
+  }
+  else
+  {
+ /* 'index->entries[middle].name' is longer than 'name'. */
+ cmp = -1;
+  }
+}
 if (cmp < 0)
 {
   /* Look lower than here. */
   max = middle;
 }
-else if (cmp > 0)
+else
 {
   /* Look higher than here. */
   min = middle + 1;
 }
-else
-{
-  /* Found it. */
-  return index->entries[middle].offset;
-}
-  }
+ }
 
   /* Didn't find it. */
   return -FDT_ERR_NOTFOUND;
-- 
2.26.2

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

Re: [PATCH v2] User Manual languages section

[Gedare Bloom]

Thanks for this. Someone should at least add TBD stubs for a few
languages. If we say nothing, the assumption is there is nothing to
say. You can open a ticket, assign it to me if you like. It will take
some research to find the set of languages.

On Sun, Oct 18, 2020 at 4:01 PM  wrote:
>
> Hello,
>
> Thank you for the reviews and comments of the v1 patch. I believe I have
> addressed the items raised in the review comments.
>
> I have not added sections for languages I do not know about or use. I think
> it is best those who know the language and support it should add a section.
> I understand this patch maybe feel unbalanced but I would rather attempt
> a start at a section with what I know thana having to wait for me to learn
> and research and test Ada and Fortran.
>
> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Joel Sherrill]

This was reported against 4.11 which means it needs to be committed to
4.11, 5, and master.

--joel

On Mon, Oct 19, 2020 at 10:33 AM Sebastian Huber  wrote:

> Module:rtems
> Branch:master
> Commit:2b9fb3141cb10b8bbfa1a18a6aab42474988a636
> Changeset:
> http://git.rtems.org/rtems/commit/?id=2b9fb3141cb10b8bbfa1a18a6aab42474988a636
>
> Author:Sebastian Huber 
> Date:  Mon Oct 19 16:31:51 2020 +0200
>
> posix: Fix pthread_spin_unlock()
>
> Prevent a call to _SMP_lock_Stats_register_or_max_section_time().  This
> fixes a
> thread stack corruption in case RTEMS_PROFILING and RTEMS_SMP is enabled.
>
> Close #4157.
>
> ---
>
>  cpukit/posix/src/pspinunlock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/posix/src/pspinunlock.c
> b/cpukit/posix/src/pspinunlock.c
> index ca36a5f..5c02012 100644
> --- a/cpukit/posix/src/pspinunlock.c
> +++ b/cpukit/posix/src/pspinunlock.c
> @@ -40,7 +40,7 @@ int pthread_spin_unlock( pthread_spinlock_t *lock )
>  #if defined(RTEMS_PROFILING)
>/* This is a hack to get around the lock profiling statistics */
>unused_stats.total_section_time = 0;
> -  unused_stats.max_section_time = 0;
> +  unused_stats.max_section_time = UINT32_MAX;
>unused_context.stats = &unused_stats;
>unused_context.acquire_instant = 0;
>  #endif
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] User Manual languages section

[Joel Sherrill]

On Mon, Oct 19, 2020 at 10:20 AM Gedare Bloom  wrote:

> Thanks for this. Someone should at least add TBD stubs for a few
> languages. If we say nothing, the assumption is there is nothing to
> say. You can open a ticket, assign it to me if you like. It will take
> some research to find the set of languages.
>

+1 Please add a TBD section for at least C and Ada along with a comment
that points to a ticket for it.

This will get lost otherwise.

--joel

>
> On Sun, Oct 18, 2020 at 4:01 PM  wrote:
> >
> > Hello,
> >
> > Thank you for the reviews and comments of the v1 patch. I believe I have
> > addressed the items raised in the review comments.
> >
> > I have not added sections for languages I do not know about or use. I
> think
> > it is best those who know the language and support it should add a
> section.
> > I understand this patch maybe feel unbalanced but I would rather attempt
> > a start at a section with what I know thana having to wait for me to
> learn
> > and research and test Ada and Fortran.
> >
> > Chris
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Sebastian Huber]

On 19/10/2020 17:42, Joel Sherrill wrote:

This was reported against 4.11 which means it needs to be committed to 
4.11, 5, and master.
It depends on the severity of the bug if I create tickets and back ports 
for this right now.

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

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Gedare Bloom]

On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
 wrote:
>
> On 19/10/2020 17:42, Joel Sherrill wrote:
>
> > This was reported against 4.11 which means it needs to be committed to
> > 4.11, 5, and master.
> It depends on the severity of the bug if I create tickets and back ports
> for this right now.

If we know the bug exists we should at least create tickets on the
open, affected branch(es).

When we know how to fix it, we should also at least reference that as
well. This way someone else can make the fix easier if they need it.

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

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Sebastian Huber]

On 19/10/2020 18:53, Gedare Bloom wrote:


On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
  wrote:

On 19/10/2020 17:42, Joel Sherrill wrote:


This was reported against 4.11 which means it needs to be committed to
4.11, 5, and master.

It depends on the severity of the bug if I create tickets and back ports
for this right now.

If we know the bug exists we should at least create tickets on the
open, affected branch(es).

When we know how to fix it, we should also at least reference that as
well. This way someone else can make the fix easier if they need it.


I thought this is the purpose of the "version" field?

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

Re: [PATCH 0/1] Confstr patch

[Joel Sherrill]

I think grep is your friend. :)

spec/build/testsuites/psxtests/ has all the test descriptions. Hopefully
nothing else is required beyond adding another file.

On Fri, Oct 16, 2020 at 2:38 AM Eshan dhawan 
wrote:

> Apologies for sending this patch so late.
> This patch got struck between my exams and a project deadline.
>
> Also Can someone tell me the extra changes that are required
> to be made to make this patch compatible with the new build system.
>
> Eshan dhawan (1):
>   Confstr Patches
>
>  cpukit/Makefile.am|   1 +
>  cpukit/posix/src/confstr.c| 105 +
>  testsuites/psxtests/Makefile.am   |   9 ++
>  testsuites/psxtests/configure.ac  |   1 +
>  testsuites/psxtests/psxconfstr/init.c | 143 ++
>  testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 +++
>  testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
>  7 files changed, 280 insertions(+)
>  create mode 100644 cpukit/posix/src/confstr.c
>  create mode 100644 testsuites/psxtests/psxconfstr/init.c
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn
>
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] Confstr Patches

[Joel Sherrill]

Does anyone have any comments other than adding support for waf?

--joel

On Fri, Oct 16, 2020 at 2:38 AM Eshan dhawan 
wrote:

> Signed-off-by: Eshan dhawan 
> ---
>  cpukit/Makefile.am|   1 +
>  cpukit/posix/src/confstr.c| 105 +
>  testsuites/psxtests/Makefile.am   |   9 ++
>  testsuites/psxtests/configure.ac  |   1 +
>  testsuites/psxtests/psxconfstr/init.c | 143 ++
>  testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 +++
>  testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
>  7 files changed, 280 insertions(+)
>  create mode 100644 cpukit/posix/src/confstr.c
>  create mode 100644 testsuites/psxtests/psxconfstr/init.c
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index bdd8ebef33..337e8f8df1 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -510,6 +510,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
>  librtemscpu_a_SOURCES += posix/src/condtimedwait.c
>  librtemscpu_a_SOURCES += posix/src/condwait.c
>  librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
> +librtemscpu_a_SOURCES += posix/src/confstr.c
>  librtemscpu_a_SOURCES += posix/src/_execve.c
>  librtemscpu_a_SOURCES += posix/src/fork.c
>  librtemscpu_a_SOURCES += posix/src/key.c
> diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
> new file mode 100644
> index 00..828aa22a4e
> --- /dev/null
> +++ b/cpukit/posix/src/confstr.c
> @@ -0,0 +1,105 @@
> +/*-
> + * SPDX-License-Identifier: BSD-3-Clause
> + *
> + * Copyright (c) 1993
> + * The Regents of the University of California.  All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of the University nor the names of its contributors
> + *may be used to endorse or promote products derived from this
> software
> + *without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
> LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
> WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include 
> +/* Reduced to make sense in RTEMS */
> +__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
> +__FBSDID("$FreeBSD$");
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +
> +size_t
> +confstr(int name, char *buf, size_t len)
> +{
> +  const char *p;
> +  const char UPE[] = "unsupported programming environment";
> +
> +  switch (name) {
> +
> +case _CS_PATH:
> +  errno = EINVAL;
> +  return (0);
> +
> +/*
> + * POSIX/SUS ``Programming Environments'' stuff
> + *
> + * We don't support more than one programming environment
> + * on any platform (yet), so we just return the empty
> + * string for the environment we are compiled for,
> + * and the string "unsupported programming environment"
> + * for anything else.  (The Standard says that if these
> + * values are used on a system which does not support
> + * this environment -- determined via sysconf() -- then
> + * the value we return is unspecified.  So, we return
> + * something which will cause obvious breakage.)
> + */
> +
> +case _CS_POSIX_V6_ILP32_OFF32_CFLAGS:
> +case _CS_POSIX_V6_ILP32_OFF32_LDFLAGS:
> +case _CS_POSIX_V6_ILP32_OFF32_LIBS:
> +case _CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS:
> +case _CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS:
> +case _CS_POSIX_V6_LPBIG_OFFBIG_LIBS:
> +case _CS_POSIX_V6_ILP32_OFFBIG_CFLAGS:
> +case _CS_POSIX_V6_ILP32_OFFBIG_LDFLAGS:
> +case _CS_POSIX_V6_ILP32_OFFBIG_LIBS:
> +case _CS_POSIX_V6_LP64_OFF64_CFLAGS:
> +case _CS_POSIX_V6_LP64_OFF64_LDFLAGS:
> +case _CS_POSIX_V6_LP64_OFF64_LIBS:
> +case _CS_POSIX_V7_ILP32_OFF32_CFL

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Gedare Bloom]

On Mon, Oct 19, 2020 at 11:11 AM Sebastian Huber
 wrote:
>
> On 19/10/2020 18:53, Gedare Bloom wrote:
>
> > On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
> >   wrote:
> >> On 19/10/2020 17:42, Joel Sherrill wrote:
> >>
> >>> This was reported against 4.11 which means it needs to be committed to
> >>> 4.11, 5, and master.
> >> It depends on the severity of the bug if I create tickets and back ports
> >> for this right now.
> > If we know the bug exists we should at least create tickets on the
> > open, affected branch(es).
> >
> > When we know how to fix it, we should also at least reference that as
> > well. This way someone else can make the fix easier if they need it.
>
> I thought this is the purpose of the "version" field?
>
https://lists.rtems.org/pipermail/devel/2018-August/050685.html

The problem is that for example this ticket #4157 is closed. So how
does someone know the bug isn't fixed in 4.11 and 5?

It is a problem we face and why we end up duplicating all these
tickets in the first place. I don't know (if there is) a right answer.

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

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Chris Johns]

On 20/10/20 5:06 am, Gedare Bloom wrote:
> On Mon, Oct 19, 2020 at 11:11 AM Sebastian Huber
>  wrote:
>>
>> On 19/10/2020 18:53, Gedare Bloom wrote:
>>
>>> On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
>>>   wrote:
 On 19/10/2020 17:42, Joel Sherrill wrote:

> This was reported against 4.11 which means it needs to be committed to
> 4.11, 5, and master.
 It depends on the severity of the bug if I create tickets and back ports
 for this right now.
>>> If we know the bug exists we should at least create tickets on the
>>> open, affected branch(es).
>>>
>>> When we know how to fix it, we should also at least reference that as
>>> well. This way someone else can make the fix easier if they need it.
>>
>> I thought this is the purpose of the "version" field?
>>
> https://lists.rtems.org/pipermail/devel/2018-August/050685.html
> 
> The problem is that for example this ticket #4157 is closed. So how
> does someone know the bug isn't fixed in 4.11 and 5?
> 
> It is a problem we face and why we end up duplicating all these
> tickets in the first place. I don't know (if there is) a right answer.

I think cloning tickets is the best solution we have. I cannot see a better 
path.

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

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Chris Johns]

On 20/10/20 2:46 am, Sebastian Huber wrote:
> On 19/10/2020 17:42, Joel Sherrill wrote:
> 
>> This was reported against 4.11 which means it needs to be committed to 4.11,
>> 5, and master.
> It depends on the severity of the bug if I create tickets and back ports for
> this right now.

If it is needed on 4.11 doing this now would be helpful as I am looking to make
a 4.11 release for other reasons.

SMP is experimental on 4.11 so I suspect this would be the least of someone
problems and moving to 5's SMP would be the best (only?) path forward.

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

Re: [PATCH v2] User Manual languages section

[Chris Johns]

On 20/10/20 2:43 am, Joel Sherrill wrote:
> On Mon, Oct 19, 2020 at 10:20 AM Gedare Bloom  > wrote:
> 
> Thanks for this. Someone should at least add TBD stubs for a few
> languages. If we say nothing, the assumption is there is nothing to
> say. You can open a ticket, assign it to me if you like. It will take
> some research to find the set of languages.
> 
> +1 Please add a TBD section for at least C and Ada along with a comment
> that points to a ticket for it.
> 
> This will get lost otherwise.
> 

I am happy to add TBD sections and tickets for languages if there is a list to
create.

I removed Ada because Joel suggested Fortran if the RSB can build it. I then
started to think, I do not build Ada ot Fortran so maybe I should not add things
I am not sure about.

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

[PATCH] powerpc/nexus: Add legacy PCI support to PowerPC Motorola Shared BSP family

[chrisj]

From: Chris Johns 

---
 libbsd.py | 2 +-
 rtemsbsd/include/bsp/nexus-devices.h  | 6 +-
 rtemsbsd/powerpc/include/machine/legacyvar.h  | 2 ++
 rtemsbsd/powerpc/include/machine/pci_cfgreg.h | 2 ++
 4 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 rtemsbsd/powerpc/include/machine/legacyvar.h
 create mode 100644 rtemsbsd/powerpc/include/machine/pci_cfgreg.h

diff --git a/libbsd.py b/libbsd.py
index 7c9743cb..2dc0d0db 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -2787,7 +2787,7 @@ class pci(builder.Module):
 ]
 )
 self.addCPUDependentFreeBSDSourceFiles(
-[ 'i386' ],
+[ 'i386', "powerpc" ],
 [
 'sys/x86/x86/legacy.c',
 'sys/x86/pci/pci_bus.c',
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 94013564..125ac0c3 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -196,6 +196,10 @@ SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(fec, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
-#endif
+#elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H)
+
+RTEMS_BSD_DRIVER_PC_LEGACY;
+
+#endif /* LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H */
 
 #endif
diff --git a/rtemsbsd/powerpc/include/machine/legacyvar.h 
b/rtemsbsd/powerpc/include/machine/legacyvar.h
new file mode 100644
index ..8683a0e5
--- /dev/null
+++ b/rtemsbsd/powerpc/include/machine/legacyvar.h
@@ -0,0 +1,2 @@
+/* See freebsd/sys/x86/include/machine/legacyvar.h */
+#include 
diff --git a/rtemsbsd/powerpc/include/machine/pci_cfgreg.h 
b/rtemsbsd/powerpc/include/machine/pci_cfgreg.h
new file mode 100644
index ..1bfa468e
--- /dev/null
+++ b/rtemsbsd/powerpc/include/machine/pci_cfgreg.h
@@ -0,0 +1,2 @@
+/* See freebsd/sys/x86/include/machine/pci_cfgreg.h */
+#include 
-- 
2.24.1

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

LibBSD PowerPC motorola_shared BSP PCI Support

[chrisj]

Hello,

This patch for libbsd adds PCI support to the motorola_shared BSP family.

Tested on a MVME2700 (mvme2307) BSP:

nexus0: 
pcib0 pcibus 0 on motherboard
pci0:  on pcib0
pci0:  at device 0.0 (no driver attached)
pci0:  at device 11.0 (no driver attached)
pci0:  at device 11.1 (no driver attached)
pci0:  at device 12.0 (no driver attached)
pci0:  at device 13.0 (no driver attached)
pci0:  at device 14.0 (no driver attached)

Chris


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

BSP maintenance (was Re: set_vector() on SPARC)

[Chris Johns]

On 19/10/20 4:51 pm, Sebastian Huber wrote:
> On 16/10/2020 19:48, Joel Sherrill wrote:
>> On Thu, Oct 15, 2020 at 11:40 PM Chris Johns > > wrote:
>>
>>     On 16/10/20 3:30 pm, Sebastian Huber wrote:
>>     > On 16/10/2020 03:09, Chris Johns wrote:
>>     >> On 16/10/20 4:57 am, Sebastian Huber wrote:
>>     >>> I suggest to remove this function and replace it with
>>     rtems_interrupt_catch()
>>     >>> and add the interrupt enable to rtems_interrupt_catch().
>>     >> Which BSPs will this effect?
>>     >
>>     > All SPARC BSPs.
>>
>>     OK.
>>
>> Unless you make that all BSPs which have set_vector, I am not in favor of 
>> this.
>>
>> set_vector() was intended many many years ago as a central place for a BSP
>> to touch an interrupt mask register if it had one. This was sometimes present
>> on architectures which we now call simple vectored. This was universally
>> present across all simple vectored architectures.
>>
>> If you want to eliminate it, do so. Don't leave it partially present.
> My intention was to change this only on SPARC. The other architectures that 
> use
> set_vector() are not really maintained.

BSP maintenance is hard and in this context the term "maintained" is subjective.
I feel there exists a grey area that is not defined in a way that makes it 
clear.

The following questions are an attempt to scope the problem and not a specific
set of questions directly related to the set_vector changes. As a result I have
changed the subject. I will leave you and Joel to debate that subject.

If these architectures are not being maintained as you suggest where do we
document this and how do we inform the users?

If you did update the architectures to remove set_vector are they now 
maintained?

Is updating the code without being able to test the changes maintaining an
architecture or BSP or do we require some level of testing?

Other factors effect how far you go such as the size of the change. Is being
able to change an architecture or BSP better than not being able to post a
change because changing all architectures or BSPs is too large a task?

>>     >> What testing on real hardware will there be?
>>     >
>>     > I will test on GR712RC and GR740. I hope Gaisler tests the RTEMS
>>     master from
>>     > time to time on their hardware.
>>
>>     Yes. Testing as we are working on changes is much more helpful
>>     than finding out long after the focus has shifted.
>>
>> +1
> Testing this change on everything except SPARC would be difficult.

Yes and this is an important point to discuss. Is a change that is not tested
better than not having the change made? This becomes hard because it leaves a
liability in the code if it is not changed. If a BSP breaks and you open it up
to fix and you find it is behind the "current" interfaces do you fix the bug or
do you update the interface(s) and fix the bug? I have this situation with the
mvme2307 BSP at the moment.

I do not have answers for these questions but I feel we need to discuss the
topic and attempt to frame a context.

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

Re: [PATCH v2] rtems-fdt / shell - Fix string truncation warning

[Chris Johns]

OK to push.

Thanks
Chris

On 20/10/20 12:16 am, Frank Kuehndel wrote:
> From: Frank Kühndel 
> 
> The compiler warning was:
> 
> ../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:
> 'strncpy' specified bound depends on the length of the source argument
>   267 | strncpy(path, name, namelen);
>   | ^~~~
> 
> It turns out that the `strncpy()` nor the buffer `path` is needed when
> one uses `strncmp()` instead of `strcmp()`. This needs some change to
> the algorithm but has the advantage that `name` is never truncated
> to the size of the buffer `path`.
> ---
>  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 40 +---
>  1 file changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 39e70bffec..0ea365314f 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -248,48 +248,46 @@ rtems_fdt_index_find_by_name(rtems_fdt_index* index,
>  {
>int min = 0;
>int max = index->num_entries;
> -  charpath[256];
> -  const char* cmp_name = name;
> -
>/*
> * Handle trailing slash case.
> */
> -  int namelen = strlen(name);
> +  size_t namelen = strlen(name);
>if (namelen > 0 && name[namelen-1] == '/')
>{
>  namelen--;
> -
> -if (namelen >= (int)sizeof(path) - 1)
> -{
> -  namelen = sizeof(path) - 1;
> -}
> -
> -strncpy(path, name, namelen);
> -path[namelen] = 0;
> -cmp_name = path;
>}
>  
>/* Binary search for the name. */
>while (min < max)
>{
>  int middle = (min + max) / 2;
> -int cmp = strcmp(cmp_name, index->entries[middle].name);
> +int cmp = strncmp(name, index->entries[middle].name, namelen);
> +if (cmp == 0)
> +{
> +  /* 'namelen' characters are equal but 'index->entries[middle].name' */
> +  /* could have additional characters. */
> +  if (index->entries[middle].name[namelen] == '\0')
> +  {
> +/* Found it. */
> +return index->entries[middle].offset;
> +  }
> +  else
> +  {
> + /* 'index->entries[middle].name' is longer than 'name'. */
> + cmp = -1;
> +  }
> +}
>  if (cmp < 0)
>  {
>/* Look lower than here. */
>max = middle;
>  }
> -else if (cmp > 0)
> +else
>  {
>/* Look higher than here. */
>min = middle + 1;
>  }
> -else
> -{
> -  /* Found it. */
> -  return index->entries[middle].offset;
> -}
> -  }
> + }
>  
>/* Didn't find it. */
>return -FDT_ERR_NOTFOUND;
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] posix: Fix pthread_spin_unlock()

[Sebastian Huber]

On 20/10/2020 00:17, Chris Johns wrote:

On 20/10/20 5:06 am, Gedare Bloom wrote:

On Mon, Oct 19, 2020 at 11:11 AM Sebastian Huber
  wrote:

On 19/10/2020 18:53, Gedare Bloom wrote:


On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
   wrote:

On 19/10/2020 17:42, Joel Sherrill wrote:


This was reported against 4.11 which means it needs to be committed to
4.11, 5, and master.

It depends on the severity of the bug if I create tickets and back ports
for this right now.

If we know the bug exists we should at least create tickets on the
open, affected branch(es).

When we know how to fix it, we should also at least reference that as
well. This way someone else can make the fix easier if they need it.

I thought this is the purpose of the "version" field?


https://lists.rtems.org/pipermail/devel/2018-August/050685.html

The problem is that for example this ticket #4157 is closed. So how
does someone know the bug isn't fixed in 4.11 and 5?

It is a problem we face and why we end up duplicating all these
tickets in the first place. I don't know (if there is) a right answer.

I think cloning tickets is the best solution we have. I cannot see a better 
path.


Not everything is equally important.

I did run the test suite in an unusual configuration, identified two 
unexpected test failures, debugged the tests, reported two issues with 
the first affected RTEMS version and a target milestone, and fixed the 
issues on the master. This is enough work for bugs which probably affect 
only one person on this planet.


--
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

Re: BSP maintenance (was Re: set_vector() on SPARC)

[Thomas Doerfler]

Chris,

hm, isn't this something related to our tiering of architectures/BSPs?
Those who have a maintainer/test board should detect any fault due to
the proposed change rather soon/at the next regular test. Those who are
not in constant testing... well they are not tier 1, right?

wkr,

Thomas.

Am 20.10.20 um 04:32 schrieb Chris Johns:
> If these architectures are not being maintained as you suggest where do we
> document this and how do we inform the users?
> 
> If you did update the architectures to remove set_vector are they now 
> maintained?
> 
> Is updating the code without being able to test the changes maintaining an
> architecture or BSP or do we require some level of testing?
> 

-- 

embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.
For our privacy statement, see
https://embedded-brains.de/en/data-privacy-statement/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel