Re: Large compressed patch: posix-compliance: Update to include POSIX 1003.1-2017 (Issue 7).
Thanks Joel. Is this patch 2/2? Go ahead. On Wed, May 5, 2021 at 3:36 PM Joel Sherrill wrote: > > Hi > > This was too large to send through uncompressed so I am attaching it. > Gedare's idea of not renaming the CSV to bump the version was good. But this > change adds a new column for POSIX 1003.1-2017 (Issue 7). That's the worst > case for patch size. > > bzip dropped it from 300+k to 16k so that's acceptable. > > --joel > ___ > 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] Removed references to legacy network config options in user/bld/index.rst as those options are no longer valid
On Wed, May 5, 2021 at 7:12 PM Vijay Kumar Banerjee wrote: > > Hi Harrison, > > The patch looks good, just a little change is required. You'll notice > that we follow a pattern in our commit messages. First, write the name > of the file changed, then a short description of the change and then, > if applicable, a longer description in the commit message. > This message could be written as "user/bld/index.rst: short description here". > > Thanks for working on updating the documentation. > See also: https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch and it links to https://devel.rtems.org/wiki/Developer/Git#GitCommits > > Best regards, > Vijay > > On Wed, May 5, 2021 at 3:23 PM Harrison Gerber wrote: > > > > From: Harrison > > Make sure your git.username is a complete/legal name, this is for attribution purposes. > > --- > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC - Code Formatting and Style Checking for RTEMS score
hi Ida, On Wed, May 5, 2021 at 3:21 PM Ida Delphine wrote: > > Hello everyone, > > Regarding this project (https://devel.rtems.org/ticket/3860) I went with > clang-format as we all agreed. I have tested it on some "score" files and it > made some changes which I don't think are very much in line with the RTEMS > coding style. However, it wasn't really clear if we will chage the RTEMS > coding style or try to make changes to clang-format to fit the style. > Please will love to know the best option. > We will likely need to consider our choices carefully. If we can find a suitably close style that is already well-supported by clang, and get consensus from the maintainers on a change, then that might be the best route forward. I think the first thing to do is take the examples that have been shown by Sebastian that are "close" but not quite perfect, and identify the cases where they differ with RTEMS style in order to present for discussion here. If consensus can't be reached to change the style, then we would need to have a plan for how to improve the existing tools for what we have. However, I think there is interest in doing less work on the tool side, and more work on how to integrate it into our workflows better. > Cheers, > Ida. > ___ > 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] rtemstoolkit/mailer.py: Fix option ordering for add_arguments
On 6/5/21 4:49 am, Gedare Bloom wrote: > On Wed, May 5, 2021 at 9:16 AM Alex White wrote: >> >> On Wed, May 5, 2021 at 9:47 AM Gedare Bloom wrote: >>> >>> Why? >> >> To prevent the '--mail' and '--use-gitconfig' options from being added more >> than once to the ArgumentParser in add_arguments. >> > How does that happen? > > I'm not trying to be frustrating (just annoying). I want to be sure > we're using the right solution for the right problem, and not just > putting a bandaid over something so it works while we hide some > underlying concerns. Gedare, I am agree. I think there maybe another simpler solution. Why not make the list() be something like ... no_add = ['--mail', '--use-gitconfig'] for o in [opt for opt in list(_options) if not in no_add]: .. ... or something like that? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects
Hi all,
On Wed, May 5, 2021 at 8:42 AM Gedare Bloom wrote:
>
> alright looks good. Vijay or Christian please confirm and push if
> you're good with it too.
>
ofw01.exe breaks after this patch. This probably needs some more debugging.
If it helps, I'm pasting the error:
```
*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
R0 = 0x8001e68c R8 = 0x8001e68c
R1 = 0x80104641 R9 = 0x8005b90c
R2 = 0x0030 R10 = 0x80104640
R3 = 0x80104648 R11 = 0x0002
R4 = 0x0008 R12 = 0x8001e68b
R5 = 0x2ebc SP = 0x801045b8
R6 = 0x80104640 LR = 0x8000d720
R7 = 0x80101e28 PC = 0x80011ba8
CPSR = 0x8193 VEC = 0x0004
RTEMS version: 6.0.0.cfabe5d6e9d8b428110732fffb7ff6ee8211de04
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e256fc4cb0d91a098d2f3d88c3d302fc0426d56, Newlib 436e475)
executing thread ID: 0x089010001
executing thread name: IDLE
U-Boot SPL 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **
```
Best regards,
Vijay
> On Wed, May 5, 2021 at 12:52 AM Niteesh G. S. wrote:
> >
> >
> >
> > On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote:
> >>
> >> Hi Niteesh,
> >>
> >> This looks good to me. What/how did you test it?
> >
> > I tested it using the ofw01 test
> > https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c
> > and read EEPROM using i2c.
> >
> >>
> >> Gedare
> >>
> >> On Sat, May 1, 2021 at 6:31 AM G S Niteesh Babu
> >> wrote:
> >> >
> >> > This patch adds asserts to fix coverity defects
> >> > 1) CID 1474437 (Out-of-bounds access)
> >> > 2) CID 1474436 (Out-of-bounds access)
> >> >
> >> > From manual inspection, out of bounds access cannot occur due to
> >> > bounds checking but coverity fails to detect the checks.
> >> > We are adding asserts as a secondary check.
> >> > ---
> >> > bsps/shared/ofw/ofw.c | 12 +++-
> >> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> >> > index f4b8b63931..0e0a7033ab 100644
> >> > --- a/bsps/shared/ofw/ofw.c
> >> > +++ b/bsps/shared/ofw/ofw.c
> >> > @@ -42,6 +42,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> >
> >> > static void *fdtp = NULL;
> >> >
> >> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >> >const void *prop;
> >> >int offset;
> >> >int len;
> >> > + int copy_len;
> >> >uint32_t cpuid;
> >> >
> >> >offset = rtems_fdt_phandle_to_offset(node);
> >> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> >> > return -1;
> >> >}
> >> >
> >> > - bcopy(prop, buf, MIN(len, bufsize));
> >> > + copy_len = MIN(len, bufsize);
> >> > + _Assert(copy_len <= bufsize);
> >> > + memmove(prop, buf, copy_len);
> >> >
> >> >return len;
> >> > }
> >> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> >> > range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> >> > range.size = fdt32_to_cpu(ptr[j].size);
> >> >
> >> > +/**
> >> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> >> > + * address for buf[i]. If buf[i] points to any address larger
> >> > + * than this, it will be an out of bound access
> >> > + */
> >> > +_Assert([i] < (buf + size - (sizeof(buf[0]) - 1)));
> >> > if (buf[i].start >= range.child_bus &&
> >> > buf[i].start < range.child_bus + range.size) {
> >> >offset = range.parent_bus - range.child_bus;
> >> > --
> >> > 2.17.1
> >> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Removed references to legacy network config options in user/bld/index.rst as those options are no longer valid
Hi Harrison, The patch looks good, just a little change is required. You'll notice that we follow a pattern in our commit messages. First, write the name of the file changed, then a short description of the change and then, if applicable, a longer description in the commit message. This message could be written as "user/bld/index.rst: short description here". Thanks for working on updating the documentation. Best regards, Vijay On Wed, May 5, 2021 at 3:23 PM Harrison Gerber wrote: > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Large compressed patch: posix-compliance: Update to include POSIX 1003.1-2017 (Issue 7).
Hi This was too large to send through uncompressed so I am attaching it. Gedare's idea of not renaming the CSV to bump the version was good. But this change adds a new column for POSIX 1003.1-2017 (Issue 7). That's the worst case for patch size. bzip dropped it from 300+k to 16k so that's acceptable. --joel 0002-posix-compliance-Update-to-include-POSIX-1003.1-2017.patch.bz2 Description: application/bzip ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] posix-compliance/posix_rst.py: Use proper names of standards in headings
---
posix-compliance/posix_rst.py | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/posix-compliance/posix_rst.py b/posix-compliance/posix_rst.py
index 6e3b41c..c50fd4a 100755
--- a/posix-compliance/posix_rst.py
+++ b/posix-compliance/posix_rst.py
@@ -40,30 +40,30 @@ standards = [
standard_names = {
'RTEMS' : 'RTEMS Complete Profile',
-'POSIX-2008' : 'POSIX-2008',
-'POSIX-2003' : 'POSIX-2003',
+'POSIX-2008' : 'POSIX-2008 (Issue 7)',
+'POSIX-2003' : 'POSIX-2003 (Issue 6)',
'PSE51' : 'POSIX PSE51 - Minimal',
'PSE52' : 'POSIX PSE52 - Real-Time Controller',
'PSE53' : 'POSIX PSE53 - Dedicated',
'PSE54' : 'POSIX PSE54 - Multipurpose',
'C99' : 'C99 Standard Library',
'C11' : 'C11 Standard Library',
-'FACE 2.1 Security' : 'FACE 2.1 Security',
-'FACE 2.1 Safety Base': 'FACE 2.1 Safety Base',
-'FACE 2.1 Safety Extended': 'FACE 2.1 Safety Extended',
-'FACE 2.1 General Purpose': 'FACE 2.1 General Purpose',
-'FACE 3.0 Security' : 'FACE 3.0 Security',
-'FACE 3.0 Safety Base': 'FACE 3.0 Safety Base',
-'FACE 3.0 Safety Extended': 'FACE 3.0 Safety Extended',
-'FACE 3.0 General Purpose': 'FACE 3.0 General Purpose',
-'FACE 3.1 Security' : 'FACE 3.1 Security',
-'FACE 3.1 Safety Base': 'FACE 3.1 Safety Base',
-'FACE 3.1 Safety Extended': 'FACE 3.1 Safety Extended',
-'FACE 3.1 General Purpose': 'FACE 3.1 General Purpose',
-'SCA 2.2.2 AEP' : 'SCA 2.2.2 AEP',
-'SCA 4.1 Ultra Lightweight AEP' : 'SCA 4.1 Ultra Lightweight AEP',
-'SCA 4.1 Lightweight AEP' : 'SCA 4.1 Lightweight AEP',
-'SCA 4.1 [Full] AEP' : 'SCA 4.1 [Full] AEP'
+'FACE 2.1 Security' : 'FACE Technical Standard, Edition 2.1
Security',
+'FACE 2.1 Safety Base': 'FACE Technical Standard, Edition 2.1 Safety
Base',
+'FACE 2.1 Safety Extended': 'FACE Technical Standard, Edition 2.1 Safety
Extended',
+'FACE 2.1 General Purpose': 'FACE Technical Standard, Edition 2.1 General
Purpose',
+'FACE 3.0 Security' : 'FACE Technical Standard, Edition 3.0
Security',
+'FACE 3.0 Safety Base': 'FACE Technical Standard, Edition 3.0 Safety
Base',
+'FACE 3.0 Safety Extended': 'FACE Technical Standard, Edition 3.0 Safety
Extended',
+'FACE 3.0 General Purpose': 'FACE Technical Standard, Edition 3.0 General
Purpose',
+'FACE 3.1 Security' : 'FACE Technical Standard, Edition 3.1
Security',
+'FACE 3.1 Safety Base': 'FACE Technical Standard, Edition 3.1 Safety
Base',
+'FACE 3.1 Safety Extended': 'FACE Technical Standard, Edition 3.1 Safety
Extended',
+'FACE 3.1 General Purpose': 'FACE Technical Standard, Edition 3.1 General
Purpose',
+'SCA 2.2.2 AEP' : 'Software Communications Architecture 2.2.2
AEP',
+'SCA 4.1 Ultra Lightweight AEP' : 'Software Communications Architecture
4.1 Ultra Lightweight Appliation Environment Profile',
+'SCA 4.1 Lightweight AEP' : 'Software Communications Architecture 4.1
Lightweight Appliation Environment Profile',
+'SCA 4.1 [Full] AEP' : 'Software Communications Architecture 4.1
[Full] Appliation Environment Profile'
}
col_names = {
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Removed references to legacy network config options in user/bld/index.rst as those options are no longer valid
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
GSoC - Code Formatting and Style Checking for RTEMS score
Hello everyone, Regarding this project (https://devel.rtems.org/ticket/3860) I went with clang-format as we all agreed. I have tested it on some "score" files and it made some changes which I don't think are very much in line with the RTEMS coding style. However, it wasn't really clear if we will chage the RTEMS coding style or try to make changes to clang-format to fit the style. Please will love to know the best option. Cheers, Ida. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat()
On Wed, May 5, 2021 at 11:03 AM Ryan Long wrote: > > Reply is below. > > -Original Message- > From: Gedare Bloom > Sent: Tuesday, May 4, 2021 11:27 AM > To: Ryan Long > Cc: Sebastian Huber ; devel@rtems.org > Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat() > > On Tue, May 4, 2021 at 10:04 AM Ryan Long wrote: > > > > > > > > -Original Message- > > From: Sebastian Huber > > Sent: Tuesday, May 4, 2021 12:04 AM > > To: Ryan Long ; devel@rtems.org > > Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and > > utimensat() > > > > On 03/05/2021 15:40, Ryan Long wrote: > > > > > Created futimens.c and utimensat.c to add support for the POSIX > > > methods futimens() and utimensat(). > > > > > > utime() and utimes() are considered obsolote by POSIX, but RTEMS > > > will continue to support them. > > > > > > Closes #4396 > > > --- > > > cpukit/Makefile.am | 2 + > > > cpukit/include/rtems/libio_.h | 61 +- > > > cpukit/libcsupport/src/futimens.c | 91 +++ > > > cpukit/libcsupport/src/utimensat.c | 229 > > > + > > > spec/build/cpukit/librtemscpu.yml | 2 + > > > 5 files changed, 384 insertions(+), 1 deletion(-) > > > create mode 100644 cpukit/libcsupport/src/futimens.c > > > create mode 100644 cpukit/libcsupport/src/utimensat.c > > > > > > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am index > > > b0df610..29b4207 100644 > > > --- a/cpukit/Makefile.am > > > +++ b/cpukit/Makefile.am > > > @@ -262,6 +262,8 @@ librtemscpu_a_SOURCES += libcsupport/src/unmount.c > > > librtemscpu_a_SOURCES += libcsupport/src/__usrenv.c > > > librtemscpu_a_SOURCES += libcsupport/src/utime.c > > > librtemscpu_a_SOURCES += libcsupport/src/utimes.c > > > +librtemscpu_a_SOURCES += libcsupport/src/futimens.c > > > +librtemscpu_a_SOURCES += libcsupport/src/utimensat.c > > > librtemscpu_a_SOURCES += libcsupport/src/utsname.c > > > librtemscpu_a_SOURCES += libcsupport/src/vprintk.c > > > librtemscpu_a_SOURCES += libcsupport/src/write.c diff --git > > > a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h > > > index > > > e9eb462..fc7a1e4 100644 > > > --- a/cpukit/include/rtems/libio_.h > > > +++ b/cpukit/include/rtems/libio_.h > > > @@ -7,7 +7,7 @@ > > >*/ > > > > > > /* > > > - * COPYRIGHT (c) 1989-2011. > > > + * COPYRIGHT (c) 1989-2011, 2021. > > >* On-Line Applications Research Corporation (OAR). > > >* > > >* Modifications to support reference counting in the file system > > > are @@ -357,6 +357,65 @@ static inline void > > > rtems_filesystem_instance_unlock( > > > (*mt_entry->ops->unlock_h)( mt_entry ); > > > } > > > > > > +/* Prototypes for functions used between utimensat() and futimens() > > > +*/ > > > + > > > +/** > > > + * @brief Checks the tv_sec member of a timespec struct > > > + * > > > + * @param[in] time The timespec struct to be validated > > > + * > > > + * Ensures that the value in the tv_sec member is non-negative. > > > + * > > > + * @retval true If the tv_sec member is a valid value > > > + * @retval false If the tv_sec member is not a valid value */ bool > > > +rtems_filesystem_utime_tv_sec_valid( struct timespec time ); > > > + > > > +/** > > > + * @brief Checks the tv_nsec member of a timespec struct > > > + * > > > + * Ensures that the value in the tv_nsec member is equal to either > > > + * UTIME_NOW, UTIME_OMIT, or a value greater-than or equal to zero > > > + * and less than a billion. > > > + * > > > + * @param[in] time The timespec struct to be validated > > > + * > > > + * @retval true If the tv_nsec member is a valid value > > > + * @retval false If the tv_nsec member is not a valid value */ > > > +bool rtems_filesystem_utime_tv_nsec_valid( struct timespec time ); > > > > Are these two functions ever used individually? Do they modify the time? > > Maybe we should add a standard phase for boolean type returns: > > > > @return Returns true, if the X is valid, otherwise false. > > > > [Ryan Long] These functions are only used in > > rtems_filesystem_utime_check_times(). They don't modify the time, they just > > ensure that the members of the timespec struct are valid values. Should the > > arguments for those functions be changed to be a const since they're not > > being modified? And sure, I can consolidate the @retval statements like > > that. > > > > > + > > > +/** > > > + * @brief Determines if the process has write permissions to a file > > > + * > > > + * Checks that the process has the same userID as the file and > > > +whether the > > > + * file has write permissions. > > > + * > > > + * @param[in] currentloc The current location to a file > > > + * @param[in] fstat_h The file handler of @currentloc > > Why is this an extra parameter? > > [Ryan Long] This was Joel's suggestion, but I didn't think about just using > > the currentloc argument. I'll change that in V2. > > > + * > > > + * @retval
Re: [PATCH] rtemstoolkit/mailer.py: Fix option ordering for add_arguments
On Wed, May 5, 2021 at 9:16 AM Alex White wrote:
>
> On Wed, May 5, 2021 at 9:47 AM Gedare Bloom wrote:
> >
> > Why?
>
> To prevent the '--mail' and '--use-gitconfig' options from being added more
> than once to the ArgumentParser in add_arguments.
>
How does that happen?
I'm not trying to be frustrating (just annoying). I want to be sure
we're using the right solution for the right problem, and not just
putting a bandaid over something so it works while we hide some
underlying concerns.
Gedare
> Alex
>
> >
> > On Wed, May 5, 2021 at 8:08 AM Alex White wrote:
> > >
> > > The ordering of keys cannot be guaranteed in a dictionary. This changes
> > > the options dictionary to an OrderedDict to preserve key order. This
> > > also fixes the iteration start point in add_arguments.
> > >
> > > Closes #4402
> > > ---
> > > rtemstoolkit/mailer.py | 24 +---
> > > 1 file changed, 13 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
> > > index ae51d78..ad832d5 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'.
> > > @@ -33,6 +34,7 @@
> > > #
> > >
> > > from __future__ import print_function
> > > +from collections import OrderedDict
> > >
> > > import os
> > > import smtplib
> > > @@ -43,16 +45,16 @@ from rtemstoolkit import execute
> > > from rtemstoolkit import options
> > > from rtemstoolkit import path
> > >
> > > -_options = {
> > > -'--mail' : 'Send email report or results.',
> > > -'--use-gitconfig': 'Use mail configuration from git config.',
> > > -'--mail-to' : 'Email address to send the email to.',
> > > -'--mail-from': 'Email address the report is from.',
> > > -'--smtp-host': 'SMTP host to send via.',
> > > -'--smtp-port': 'SMTP port to send via.',
> > > -'--smtp-user': 'User for SMTP authentication.',
> > > -'--smtp-password': 'Password for SMTP authentication.'
> > > -}
> > > +_options = OrderedDict([
> > > +('--mail' , 'Send email report or results.'),
> > > +('--use-gitconfig', 'Use mail configuration from git config.'),
> > > +('--mail-to' , 'Email address to send the email to.'),
> > > +('--mail-from', 'Email address the report is from.'),
> > > +('--smtp-host', 'SMTP host to send via.'),
> > > +('--smtp-port', 'SMTP port to send via.'),
> > > +('--smtp-user', 'User for SMTP authentication.'),
> > > +('--smtp-password', 'Password for SMTP authentication.')
> > > +])
> > >
> > > def append_options(opts):
> > > for o in _options:
> > > @@ -61,7 +63,7 @@ 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:]:
> > > +for o in list(_options)[2:]:
> > > 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
> > ___
> > 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] riscv/console: console-config.c update
- Parsing the sub-node should be available generic not specific to Freedom Arty310 board. If we remove the Freedom Arty macro now, it will lose backward compatibility.The proposed change will retain the backward compatibility and also adds the necessary fix for parsing sub-node. --- bsps/riscv/riscv/console/console-config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/riscv/riscv/console/console-config.c b/bsps/riscv/riscv/console/console-config.c index d962a5a418..797506a31b 100644 --- a/bsps/riscv/riscv/console/console-config.c +++ b/bsps/riscv/riscv/console/console-config.c @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt) stdout_path = ""; } -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0 +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0)) int root; int soc; root = fdt_path_offset(fdt, "/"); -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat()
Reply is below. -Original Message- From: Gedare Bloom Sent: Tuesday, May 4, 2021 11:27 AM To: Ryan Long Cc: Sebastian Huber ; devel@rtems.org Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and utimensat() On Tue, May 4, 2021 at 10:04 AM Ryan Long wrote: > > > > -Original Message- > From: Sebastian Huber > Sent: Tuesday, May 4, 2021 12:04 AM > To: Ryan Long ; devel@rtems.org > Subject: Re: [PATCH v1 1/5] libcsupport: Added futimens() and > utimensat() > > On 03/05/2021 15:40, Ryan Long wrote: > > > Created futimens.c and utimensat.c to add support for the POSIX > > methods futimens() and utimensat(). > > > > utime() and utimes() are considered obsolote by POSIX, but RTEMS > > will continue to support them. > > > > Closes #4396 > > --- > > cpukit/Makefile.am | 2 + > > cpukit/include/rtems/libio_.h | 61 +- > > cpukit/libcsupport/src/futimens.c | 91 +++ > > cpukit/libcsupport/src/utimensat.c | 229 > > + > > spec/build/cpukit/librtemscpu.yml | 2 + > > 5 files changed, 384 insertions(+), 1 deletion(-) > > create mode 100644 cpukit/libcsupport/src/futimens.c > > create mode 100644 cpukit/libcsupport/src/utimensat.c > > > > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am index > > b0df610..29b4207 100644 > > --- a/cpukit/Makefile.am > > +++ b/cpukit/Makefile.am > > @@ -262,6 +262,8 @@ librtemscpu_a_SOURCES += libcsupport/src/unmount.c > > librtemscpu_a_SOURCES += libcsupport/src/__usrenv.c > > librtemscpu_a_SOURCES += libcsupport/src/utime.c > > librtemscpu_a_SOURCES += libcsupport/src/utimes.c > > +librtemscpu_a_SOURCES += libcsupport/src/futimens.c > > +librtemscpu_a_SOURCES += libcsupport/src/utimensat.c > > librtemscpu_a_SOURCES += libcsupport/src/utsname.c > > librtemscpu_a_SOURCES += libcsupport/src/vprintk.c > > librtemscpu_a_SOURCES += libcsupport/src/write.c diff --git > > a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h > > index > > e9eb462..fc7a1e4 100644 > > --- a/cpukit/include/rtems/libio_.h > > +++ b/cpukit/include/rtems/libio_.h > > @@ -7,7 +7,7 @@ > >*/ > > > > /* > > - * COPYRIGHT (c) 1989-2011. > > + * COPYRIGHT (c) 1989-2011, 2021. > >* On-Line Applications Research Corporation (OAR). > >* > >* Modifications to support reference counting in the file system > > are @@ -357,6 +357,65 @@ static inline void > > rtems_filesystem_instance_unlock( > > (*mt_entry->ops->unlock_h)( mt_entry ); > > } > > > > +/* Prototypes for functions used between utimensat() and futimens() > > +*/ > > + > > +/** > > + * @brief Checks the tv_sec member of a timespec struct > > + * > > + * @param[in] time The timespec struct to be validated > > + * > > + * Ensures that the value in the tv_sec member is non-negative. > > + * > > + * @retval true If the tv_sec member is a valid value > > + * @retval false If the tv_sec member is not a valid value */ bool > > +rtems_filesystem_utime_tv_sec_valid( struct timespec time ); > > + > > +/** > > + * @brief Checks the tv_nsec member of a timespec struct > > + * > > + * Ensures that the value in the tv_nsec member is equal to either > > + * UTIME_NOW, UTIME_OMIT, or a value greater-than or equal to zero > > + * and less than a billion. > > + * > > + * @param[in] time The timespec struct to be validated > > + * > > + * @retval true If the tv_nsec member is a valid value > > + * @retval false If the tv_nsec member is not a valid value */ > > +bool rtems_filesystem_utime_tv_nsec_valid( struct timespec time ); > > Are these two functions ever used individually? Do they modify the time? > Maybe we should add a standard phase for boolean type returns: > > @return Returns true, if the X is valid, otherwise false. > > [Ryan Long] These functions are only used in > rtems_filesystem_utime_check_times(). They don't modify the time, they just > ensure that the members of the timespec struct are valid values. Should the > arguments for those functions be changed to be a const since they're not > being modified? And sure, I can consolidate the @retval statements like that. > > > + > > +/** > > + * @brief Determines if the process has write permissions to a file > > + * > > + * Checks that the process has the same userID as the file and > > +whether the > > + * file has write permissions. > > + * > > + * @param[in] currentloc The current location to a file > > + * @param[in] fstat_h The file handler of @currentloc > Why is this an extra parameter? > [Ryan Long] This was Joel's suggestion, but I didn't think about just using > the currentloc argument. I'll change that in V2. > > + * > > + * @retval 0 If the process has write permissions > > + * @retval -1 If the process does not have write permissions > Why 0 and -1, what about errno? Is it set by the function or not? > [Ryan Long] It's 0 and -1 because it uses the > rtems_set_errno_and_return_minus_one() macro. > > + */ > > +int
Re: [PATCH] rtemstoolkit/mailer.py: Fix option ordering for add_arguments
On Wed, May 5, 2021 at 9:47 AM Gedare Bloom wrote:
>
> Why?
To prevent the '--mail' and '--use-gitconfig' options from being added more
than once to the ArgumentParser in add_arguments.
Alex
>
> On Wed, May 5, 2021 at 8:08 AM Alex White wrote:
> >
> > The ordering of keys cannot be guaranteed in a dictionary. This changes
> > the options dictionary to an OrderedDict to preserve key order. This
> > also fixes the iteration start point in add_arguments.
> >
> > Closes #4402
> > ---
> > rtemstoolkit/mailer.py | 24 +---
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
> > index ae51d78..ad832d5 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'.
> > @@ -33,6 +34,7 @@
> > #
> >
> > from __future__ import print_function
> > +from collections import OrderedDict
> >
> > import os
> > import smtplib
> > @@ -43,16 +45,16 @@ from rtemstoolkit import execute
> > from rtemstoolkit import options
> > from rtemstoolkit import path
> >
> > -_options = {
> > -'--mail' : 'Send email report or results.',
> > -'--use-gitconfig': 'Use mail configuration from git config.',
> > -'--mail-to' : 'Email address to send the email to.',
> > -'--mail-from': 'Email address the report is from.',
> > -'--smtp-host': 'SMTP host to send via.',
> > -'--smtp-port': 'SMTP port to send via.',
> > -'--smtp-user': 'User for SMTP authentication.',
> > -'--smtp-password': 'Password for SMTP authentication.'
> > -}
> > +_options = OrderedDict([
> > +('--mail' , 'Send email report or results.'),
> > +('--use-gitconfig', 'Use mail configuration from git config.'),
> > +('--mail-to' , 'Email address to send the email to.'),
> > +('--mail-from', 'Email address the report is from.'),
> > +('--smtp-host', 'SMTP host to send via.'),
> > +('--smtp-port', 'SMTP port to send via.'),
> > +('--smtp-user', 'User for SMTP authentication.'),
> > +('--smtp-password', 'Password for SMTP authentication.')
> > +])
> >
> > def append_options(opts):
> > for o in _options:
> > @@ -61,7 +63,7 @@ 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:]:
> > +for o in list(_options)[2:]:
> > 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
> ___
> 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] Return NULL for zero size allocations
On Wed, May 5, 2021 at 9:48 AM Gedare Bloom wrote: > On Wed, May 5, 2021 at 1:19 AM Sebastian Huber > wrote: > > > > On 05/05/2021 09:00, Chris Johns wrote: > > > On 5/5/21 4:58 pm, Chris Johns wrote: > > >> On 5/5/21 4:52 pm, Sebastian Huber wrote: > > >>> In POSIX, zero size memory allocations are implementation-defined > > >>> behaviour. The implementation has two options: > > >>> > > >>> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html > > >>> > > >>> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > > >>> > > >>> Linux and FreeBSD return a unique pointer for zero size memory > > >>> allocations. Return NULL on RTEMS to more likely catch the use of a > > >>> zero size memory area by erroneous applications. > > >>> > > >>> Update #4390. > > >> > > >> Huh? Are we going in circles here [1]? > > > Ah I have not read the related thread. Sorry. > > > > I hoped that you break the circle ;-) > > > > Fine with me. Joel? > As long as we return NULL. :) FYI I ran into a Linux application last year that did a malloc(0) after not properly fetching a configuration parameter or it had a bogus value. Turned out it didn't manifest until well it had clobbered some memory. I've wondered if a callback for these type of errors like std::new_handler in C++ would be a good thing to help users who make a mistake or run out of memory. --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 > ___ > 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: rtems_scheduler_ident_by_processor_set()
ok
On Wed, May 5, 2021 at 5:28 AM Sebastian Huber
wrote:
>
> Check for a NULL processor set pointer.
> ---
> cpukit/rtems/src/scheduleridentbyprocessorset.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/cpukit/rtems/src/scheduleridentbyprocessorset.c
> b/cpukit/rtems/src/scheduleridentbyprocessorset.c
> index 3d48bfba3e..8d55d470f5 100644
> --- a/cpukit/rtems/src/scheduleridentbyprocessorset.c
> +++ b/cpukit/rtems/src/scheduleridentbyprocessorset.c
> @@ -44,6 +44,10 @@ rtems_status_code rtems_scheduler_ident_by_processor_set(
> return RTEMS_INVALID_ADDRESS;
>}
>
> + if ( cpuset == NULL ) {
> +return RTEMS_INVALID_ADDRESS;
> + }
> +
>status = _Processor_mask_From_cpu_set_t( , cpusetsize, cpuset );
>if ( status == PROCESSOR_MASK_COPY_INVALID_SIZE ) {
> return RTEMS_INVALID_SIZE;
> --
> 2.26.2
>
> ___
> 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: rtems_scheduler_get_processor_set() status
ok, this is also consistent with rtems_scheduler_ident_by_processor_set()
On Wed, May 5, 2021 at 6:27 AM Sebastian Huber
wrote:
>
> In case the processor set is not large enough to contain the processor
> set owned by the scheduler return RTEMS_INVALID_SIZE instead of
> RTEMS_INVALID_NUMBER. This is more in line with other directives since
> the issue is related to the size of an object.
>
> Close #4401.
> ---
> cpukit/rtems/src/schedulergetprocessorset.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/rtems/src/schedulergetprocessorset.c
> b/cpukit/rtems/src/schedulergetprocessorset.c
> index 6027ab31a2..71a351528a 100644
> --- a/cpukit/rtems/src/schedulergetprocessorset.c
> +++ b/cpukit/rtems/src/schedulergetprocessorset.c
> @@ -50,7 +50,7 @@ rtems_status_code rtems_scheduler_get_processor_set(
>processor_set = _Scheduler_Get_processors( scheduler );
>status = _Processor_mask_To_cpu_set_t( processor_set, cpusetsize, cpuset );
>if ( status != PROCESSOR_MASK_COPY_LOSSLESS ) {
> -return RTEMS_INVALID_NUMBER;
> +return RTEMS_INVALID_SIZE;
>}
>
>return RTEMS_SUCCESSFUL;
> --
> 2.26.2
>
> ___
> 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] Return NULL for zero size allocations
On Wed, May 5, 2021 at 1:19 AM Sebastian Huber wrote: > > On 05/05/2021 09:00, Chris Johns wrote: > > On 5/5/21 4:58 pm, Chris Johns wrote: > >> On 5/5/21 4:52 pm, Sebastian Huber wrote: > >>> In POSIX, zero size memory allocations are implementation-defined > >>> behaviour. The implementation has two options: > >>> > >>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html > >>> > >>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > >>> > >>> Linux and FreeBSD return a unique pointer for zero size memory > >>> allocations. Return NULL on RTEMS to more likely catch the use of a > >>> zero size memory area by erroneous applications. > >>> > >>> Update #4390. > >> > >> Huh? Are we going in circles here [1]? > > Ah I have not read the related thread. Sorry. > > I hoped that you break the circle ;-) > Fine with me. 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] rtemstoolkit/mailer.py: Fix option ordering for add_arguments
Why?
On Wed, May 5, 2021 at 8:08 AM Alex White wrote:
>
> The ordering of keys cannot be guaranteed in a dictionary. This changes
> the options dictionary to an OrderedDict to preserve key order. This
> also fixes the iteration start point in add_arguments.
>
> Closes #4402
> ---
> rtemstoolkit/mailer.py | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
> index ae51d78..ad832d5 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'.
> @@ -33,6 +34,7 @@
> #
>
> from __future__ import print_function
> +from collections import OrderedDict
>
> import os
> import smtplib
> @@ -43,16 +45,16 @@ from rtemstoolkit import execute
> from rtemstoolkit import options
> from rtemstoolkit import path
>
> -_options = {
> -'--mail' : 'Send email report or results.',
> -'--use-gitconfig': 'Use mail configuration from git config.',
> -'--mail-to' : 'Email address to send the email to.',
> -'--mail-from': 'Email address the report is from.',
> -'--smtp-host': 'SMTP host to send via.',
> -'--smtp-port': 'SMTP port to send via.',
> -'--smtp-user': 'User for SMTP authentication.',
> -'--smtp-password': 'Password for SMTP authentication.'
> -}
> +_options = OrderedDict([
> +('--mail' , 'Send email report or results.'),
> +('--use-gitconfig', 'Use mail configuration from git config.'),
> +('--mail-to' , 'Email address to send the email to.'),
> +('--mail-from', 'Email address the report is from.'),
> +('--smtp-host', 'SMTP host to send via.'),
> +('--smtp-port', 'SMTP port to send via.'),
> +('--smtp-user', 'User for SMTP authentication.'),
> +('--smtp-password', 'Password for SMTP authentication.')
> +])
>
> def append_options(opts):
> for o in _options:
> @@ -61,7 +63,7 @@ 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:]:
> +for o in list(_options)[2:]:
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects
alright looks good. Vijay or Christian please confirm and push if
you're good with it too.
On Wed, May 5, 2021 at 12:52 AM Niteesh G. S. wrote:
>
>
>
> On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote:
>>
>> Hi Niteesh,
>>
>> This looks good to me. What/how did you test it?
>
> I tested it using the ofw01 test
> https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c
> and read EEPROM using i2c.
>
>>
>> Gedare
>>
>> On Sat, May 1, 2021 at 6:31 AM G S Niteesh Babu wrote:
>> >
>> > This patch adds asserts to fix coverity defects
>> > 1) CID 1474437 (Out-of-bounds access)
>> > 2) CID 1474436 (Out-of-bounds access)
>> >
>> > From manual inspection, out of bounds access cannot occur due to
>> > bounds checking but coverity fails to detect the checks.
>> > We are adding asserts as a secondary check.
>> > ---
>> > bsps/shared/ofw/ofw.c | 12 +++-
>> > 1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
>> > index f4b8b63931..0e0a7033ab 100644
>> > --- a/bsps/shared/ofw/ofw.c
>> > +++ b/bsps/shared/ofw/ofw.c
>> > @@ -42,6 +42,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > static void *fdtp = NULL;
>> >
>> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
>> >const void *prop;
>> >int offset;
>> >int len;
>> > + int copy_len;
>> >uint32_t cpuid;
>> >
>> >offset = rtems_fdt_phandle_to_offset(node);
>> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
>> > return -1;
>> >}
>> >
>> > - bcopy(prop, buf, MIN(len, bufsize));
>> > + copy_len = MIN(len, bufsize);
>> > + _Assert(copy_len <= bufsize);
>> > + memmove(prop, buf, copy_len);
>> >
>> >return len;
>> > }
>> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
>> > range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
>> > range.size = fdt32_to_cpu(ptr[j].size);
>> >
>> > +/**
>> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
>> > + * address for buf[i]. If buf[i] points to any address larger
>> > + * than this, it will be an out of bound access
>> > + */
>> > +_Assert([i] < (buf + size - (sizeof(buf[0]) - 1)));
>> > if (buf[i].start >= range.child_bus &&
>> > buf[i].start < range.child_bus + range.size) {
>> >offset = range.parent_bus - range.child_bus;
>> > --
>> > 2.17.1
>> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] rtemstoolkit/mailer.py: Fix option ordering for add_arguments
The ordering of keys cannot be guaranteed in a dictionary. This changes
the options dictionary to an OrderedDict to preserve key order. This
also fixes the iteration start point in add_arguments.
Closes #4402
---
rtemstoolkit/mailer.py | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index ae51d78..ad832d5 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'.
@@ -33,6 +34,7 @@
#
from __future__ import print_function
+from collections import OrderedDict
import os
import smtplib
@@ -43,16 +45,16 @@ from rtemstoolkit import execute
from rtemstoolkit import options
from rtemstoolkit import path
-_options = {
-'--mail' : 'Send email report or results.',
-'--use-gitconfig': 'Use mail configuration from git config.',
-'--mail-to' : 'Email address to send the email to.',
-'--mail-from': 'Email address the report is from.',
-'--smtp-host': 'SMTP host to send via.',
-'--smtp-port': 'SMTP port to send via.',
-'--smtp-user': 'User for SMTP authentication.',
-'--smtp-password': 'Password for SMTP authentication.'
-}
+_options = OrderedDict([
+('--mail' , 'Send email report or results.'),
+('--use-gitconfig', 'Use mail configuration from git config.'),
+('--mail-to' , 'Email address to send the email to.'),
+('--mail-from', 'Email address the report is from.'),
+('--smtp-host', 'SMTP host to send via.'),
+('--smtp-port', 'SMTP port to send via.'),
+('--smtp-user', 'User for SMTP authentication.'),
+('--smtp-password', 'Password for SMTP authentication.')
+])
def append_options(opts):
for o in _options:
@@ -61,7 +63,7 @@ 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:]:
+for o in list(_options)[2:]:
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
[PATCH] rtems: rtems_scheduler_get_processor_set() status
In case the processor set is not large enough to contain the processor
set owned by the scheduler return RTEMS_INVALID_SIZE instead of
RTEMS_INVALID_NUMBER. This is more in line with other directives since
the issue is related to the size of an object.
Close #4401.
---
cpukit/rtems/src/schedulergetprocessorset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/rtems/src/schedulergetprocessorset.c
b/cpukit/rtems/src/schedulergetprocessorset.c
index 6027ab31a2..71a351528a 100644
--- a/cpukit/rtems/src/schedulergetprocessorset.c
+++ b/cpukit/rtems/src/schedulergetprocessorset.c
@@ -50,7 +50,7 @@ rtems_status_code rtems_scheduler_get_processor_set(
processor_set = _Scheduler_Get_processors( scheduler );
status = _Processor_mask_To_cpu_set_t( processor_set, cpusetsize, cpuset );
if ( status != PROCESSOR_MASK_COPY_LOSSLESS ) {
-return RTEMS_INVALID_NUMBER;
+return RTEMS_INVALID_SIZE;
}
return RTEMS_SUCCESSFUL;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] rtems: rtems_scheduler_ident_by_processor_set()
Check for a NULL processor set pointer.
---
cpukit/rtems/src/scheduleridentbyprocessorset.c | 4
1 file changed, 4 insertions(+)
diff --git a/cpukit/rtems/src/scheduleridentbyprocessorset.c
b/cpukit/rtems/src/scheduleridentbyprocessorset.c
index 3d48bfba3e..8d55d470f5 100644
--- a/cpukit/rtems/src/scheduleridentbyprocessorset.c
+++ b/cpukit/rtems/src/scheduleridentbyprocessorset.c
@@ -44,6 +44,10 @@ rtems_status_code rtems_scheduler_ident_by_processor_set(
return RTEMS_INVALID_ADDRESS;
}
+ if ( cpuset == NULL ) {
+return RTEMS_INVALID_ADDRESS;
+ }
+
status = _Processor_mask_From_cpu_set_t( , cpusetsize, cpuset );
if ( status == PROCESSOR_MASK_COPY_INVALID_SIZE ) {
return RTEMS_INVALID_SIZE;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Return NULL for zero size allocations
On 05/05/2021 09:00, Chris Johns wrote: On 5/5/21 4:58 pm, Chris Johns wrote: On 5/5/21 4:52 pm, Sebastian Huber wrote: In POSIX, zero size memory allocations are implementation-defined behaviour. The implementation has two options: https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html Linux and FreeBSD return a unique pointer for zero size memory allocations. Return NULL on RTEMS to more likely catch the use of a zero size memory area by erroneous applications. Update #4390. Huh? Are we going in circles here [1]? Ah I have not read the related thread. Sorry. I hoped that you break the circle ;-) -- 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: [PATCH] Return NULL for zero size allocations
On 5/5/21 4:58 pm, Chris Johns wrote: > On 5/5/21 4:52 pm, Sebastian Huber wrote: >> In POSIX, zero size memory allocations are implementation-defined >> behaviour. The implementation has two options: >> >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html >> >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html >> >> Linux and FreeBSD return a unique pointer for zero size memory >> allocations. Return NULL on RTEMS to more likely catch the use of a >> zero size memory area by erroneous applications. >> >> Update #4390. > > > Huh? Are we going in circles here [1]? Ah I have not read the related thread. Sorry. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Return NULL for zero size allocations
On 5/5/21 4:52 pm, Sebastian Huber wrote: > In POSIX, zero size memory allocations are implementation-defined > behaviour. The implementation has two options: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > > Linux and FreeBSD return a unique pointer for zero size memory > allocations. Return NULL on RTEMS to more likely catch the use of a > zero size memory area by erroneous applications. > > Update #4390. Huh? Are we going in circles here [1]? Chris [1] https://git.rtems.org/rtems/commit/?id=d692c62dfbf834c16ef7f171ea3161b3f3fac06b ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Return NULL for zero size allocations
In POSIX, zero size memory allocations are implementation-defined
behaviour. The implementation has two options:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html
Linux and FreeBSD return a unique pointer for zero size memory
allocations. Return NULL on RTEMS to more likely catch the use of a
zero size memory area by erroneous applications.
Update #4390.
---
cpukit/libcsupport/src/alignedalloc.c| 4 ++
cpukit/libcsupport/src/calloc.c | 9 +--
cpukit/libcsupport/src/malloc.c | 4 ++
cpukit/libcsupport/src/malloc_deferred.c | 4 ++
cpukit/libcsupport/src/posix_memalign.c | 4 ++
cpukit/libcsupport/src/rtems_memalign.c | 4 ++
cpukit/libcsupport/src/rtemscalloc.c | 9 +--
testsuites/libtests/malloctest/init.c| 81
8 files changed, 56 insertions(+), 63 deletions(-)
diff --git a/cpukit/libcsupport/src/alignedalloc.c
b/cpukit/libcsupport/src/alignedalloc.c
index b552fc2a0f..9c9ea83bd8 100644
--- a/cpukit/libcsupport/src/alignedalloc.c
+++ b/cpukit/libcsupport/src/alignedalloc.c
@@ -35,6 +35,10 @@
void *aligned_alloc( size_t alignment, size_t size )
{
+ if ( size == 0 ) {
+return NULL;
+ }
+
return rtems_heap_allocate_aligned_with_boundary( size, alignment, 0 );
}
diff --git a/cpukit/libcsupport/src/calloc.c b/cpukit/libcsupport/src/calloc.c
index 693aa21453..d5cefb382a 100644
--- a/cpukit/libcsupport/src/calloc.c
+++ b/cpukit/libcsupport/src/calloc.c
@@ -35,14 +35,15 @@ void *calloc(
size_t length;
if ( nelem == 0 ) {
-length = 0;
- } else if ( elsize > SIZE_MAX / nelem ) {
+return NULL;
+ }
+
+ if ( elsize > SIZE_MAX / nelem ) {
errno = ENOMEM;
return NULL;
- } else {
-length = nelem * elsize;
}
+ length = nelem * elsize;
cptr = malloc( length );
RTEMS_OBFUSCATE_VARIABLE( cptr );
if ( RTEMS_PREDICT_FALSE( cptr == NULL ) ) {
diff --git a/cpukit/libcsupport/src/malloc.c b/cpukit/libcsupport/src/malloc.c
index 795254fbab..3e55a94c83 100644
--- a/cpukit/libcsupport/src/malloc.c
+++ b/cpukit/libcsupport/src/malloc.c
@@ -30,6 +30,10 @@ void *malloc(
{
void*return_this;
+ if ( size == 0 ) {
+return NULL;
+ }
+
return_this = rtems_heap_allocate_aligned_with_boundary( size, 0, 0 );
if ( !return_this ) {
errno = ENOMEM;
diff --git a/cpukit/libcsupport/src/malloc_deferred.c
b/cpukit/libcsupport/src/malloc_deferred.c
index aab76406c7..b319d1213e 100644
--- a/cpukit/libcsupport/src/malloc_deferred.c
+++ b/cpukit/libcsupport/src/malloc_deferred.c
@@ -106,6 +106,10 @@ void *rtems_heap_allocate_aligned_with_boundary(
void *rtems_malloc( size_t size )
{
+ if ( size == 0 ) {
+return NULL;
+ }
+
return rtems_heap_allocate_aligned_with_boundary( size, 0, 0 );
}
#endif
diff --git a/cpukit/libcsupport/src/posix_memalign.c
b/cpukit/libcsupport/src/posix_memalign.c
index 316ed7315c..4e89413c24 100644
--- a/cpukit/libcsupport/src/posix_memalign.c
+++ b/cpukit/libcsupport/src/posix_memalign.c
@@ -37,6 +37,10 @@ int posix_memalign(
*memptr = NULL;
+ if ( size == 0 ) {
+return 0;
+ }
+
if ( alignment < sizeof( void * ) ) {
return EINVAL;
}
diff --git a/cpukit/libcsupport/src/rtems_memalign.c
b/cpukit/libcsupport/src/rtems_memalign.c
index aa938ac66f..aa67c74a29 100644
--- a/cpukit/libcsupport/src/rtems_memalign.c
+++ b/cpukit/libcsupport/src/rtems_memalign.c
@@ -40,6 +40,10 @@ int rtems_memalign(
*pointer = NULL;
+ if ( size == 0 ) {
+return 0;
+ }
+
/*
* Perform the aligned allocation requested
*/
diff --git a/cpukit/libcsupport/src/rtemscalloc.c
b/cpukit/libcsupport/src/rtemscalloc.c
index 836f1da64d..7e05a14bb1 100644
--- a/cpukit/libcsupport/src/rtemscalloc.c
+++ b/cpukit/libcsupport/src/rtemscalloc.c
@@ -47,13 +47,14 @@ void *rtems_calloc( size_t nelem, size_t elsize )
void *p;
if ( nelem == 0 ) {
-length = 0;
- } else if ( elsize > SIZE_MAX / nelem ) {
return NULL;
- } else {
-length = nelem * elsize;
}
+ if ( elsize > SIZE_MAX / nelem ) {
+return NULL;
+ }
+
+ length = nelem * elsize;
p = rtems_malloc( length );
RTEMS_OBFUSCATE_VARIABLE( p );
if ( RTEMS_PREDICT_FALSE( p == NULL ) ) {
diff --git a/testsuites/libtests/malloctest/init.c
b/testsuites/libtests/malloctest/init.c
index c9dcb63b2c..a33764177d 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1153,10 +1153,7 @@ static void test_rtems_malloc(void)
void *p;
p = rtems_malloc(0);
- rtems_test_assert(p != NULL);
-
- RTEMS_OBFUSCATE_VARIABLE(p);
- free(p);
+ rtems_test_assert(p == NULL);
errno = 0;
p = rtems_malloc(SIZE_MAX / 2);
@@ -1176,22 +1173,13 @@ static void test_rtems_calloc(void)
int *i;
p = rtems_calloc(0, 0);
- rtems_test_assert(p != NULL);
-
- RTEMS_OBFUSCATE_VARIABLE(p);
- free(p);
+ rtems_test_assert(p ==
Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects
On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote:
> Hi Niteesh,
>
> This looks good to me. What/how did you test it?
>
I tested it using the ofw01 test
https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c
and read EEPROM using i2c.
> Gedare
>
> On Sat, May 1, 2021 at 6:31 AM G S Niteesh Babu
> wrote:
> >
> > This patch adds asserts to fix coverity defects
> > 1) CID 1474437 (Out-of-bounds access)
> > 2) CID 1474436 (Out-of-bounds access)
> >
> > From manual inspection, out of bounds access cannot occur due to
> > bounds checking but coverity fails to detect the checks.
> > We are adding asserts as a secondary check.
> > ---
> > bsps/shared/ofw/ofw.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index f4b8b63931..0e0a7033ab 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static void *fdtp = NULL;
> >
> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >const void *prop;
> >int offset;
> >int len;
> > + int copy_len;
> >uint32_t cpuid;
> >
> >offset = rtems_fdt_phandle_to_offset(node);
> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> > return -1;
> >}
> >
> > - bcopy(prop, buf, MIN(len, bufsize));
> > + copy_len = MIN(len, bufsize);
> > + _Assert(copy_len <= bufsize);
> > + memmove(prop, buf, copy_len);
> >
> >return len;
> > }
> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> > range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> > range.size = fdt32_to_cpu(ptr[j].size);
> >
> > +/**
> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> > + * address for buf[i]. If buf[i] points to any address larger
> > + * than this, it will be an out of bound access
> > + */
> > +_Assert([i] < (buf + size - (sizeof(buf[0]) - 1)));
> > if (buf[i].start >= range.child_bus &&
> > buf[i].start < range.child_bus + range.size) {
> >offset = range.parent_bus - range.child_bus;
> > --
> > 2.17.1
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
