Re: [PATCH] improved error checking in ticks per timeslice

2024-03-18 Thread zack leung
 Do I need to do anything?


On Mon, 18 Mar 2024 at 16:38, Kinsey Moore  wrote:

> Sorry, I didn't realize I had tests turned off in my local build when I
> checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
>
> Kinsey
>
> On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> This patch breaks the build:
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> --
>> embedded brains GmbH & Co. KG
>> 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] improved error checking in ticks per timeslice

2024-03-14 Thread zack leung
Did you check in the code?

Il mar 12 mar 2024, 21:55 Kinsey Moore  ha
scritto:

> Sorry, I missed this in the deluge of emails. Looks good to me.
>
> Kinsey
>
> On Tue, Mar 12, 2024 at 8:17 PM zack leung 
> wrote:
>
>> ping
>>
>> On Fri, 8 Mar 2024 at 22:03,  wrote:
>>
>>> From: Zack leung 
>>>
>>> ---
>>>  cpukit/doxygen/appl-config.h  | 3 +--
>>>  cpukit/include/rtems/confdefs/clock.h | 4 
>>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
>>> index bd7cde628f..f843ebbd39 100644
>>> --- a/cpukit/doxygen/appl-config.h
>>> +++ b/cpukit/doxygen/appl-config.h
>>> @@ -3312,8 +3312,7 @@
>>>   * @parblock
>>>   * The following constraints apply to this configuration option:
>>>   *
>>> - * * The value of the configuration option shall be greater than or
>>> equal to
>>> - *   zero.
>>> + * * The value of the configuration option shall be greater than zero.
>>>   *
>>>   * * The value of the configuration option shall be less than or equal
>>> to >>   *   href="https://en.cppreference.com/w/c/types/integer
>>> ">UINT32_MAX.
>>> diff --git a/cpukit/include/rtems/confdefs/clock.h
>>> b/cpukit/include/rtems/confdefs/clock.h
>>> index 26519cc70b..bb6c7e0b68 100644
>>> --- a/cpukit/include/rtems/confdefs/clock.h
>>> +++ b/cpukit/include/rtems/confdefs/clock.h
>>> @@ -70,6 +70,10 @@
>>>#warning "The clock ticks per second is not an integer"
>>>  #endif
>>>
>>> +#if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
>>> CONFIGURE_TICKS_PER_TIMESLICE <= 0
>>> +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> +#endif
>>> +
>>>  #if CONFIGURE_MICROSECONDS_PER_TICK <= 0
>>>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>>>  #endif
>>> --
>>> 2.43.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] improved error checking in ticks per timeslice

2024-03-12 Thread zack leung
ping

On Fri, 8 Mar 2024 at 22:03,  wrote:

> From: Zack leung 
>
> ---
>  cpukit/doxygen/appl-config.h  | 3 +--
>  cpukit/include/rtems/confdefs/clock.h | 4 
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..f843ebbd39 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,8 +3312,7 @@
>   * @parblock
>   * The following constraints apply to this configuration option:
>   *
> - * * The value of the configuration option shall be greater than or equal
> to
> - *   zero.
> + * * The value of the configuration option shall be greater than zero.
>   *
>   * * The value of the configuration option shall be less than or equal to
>*   href="https://en.cppreference.com/w/c/types/integer;>UINT32_MAX.
> diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..bb6c7e0b68 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -70,6 +70,10 @@
>#warning "The clock ticks per second is not an integer"
>  #endif
>
> +#if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
> CONFIGURE_TICKS_PER_TIMESLICE <= 0
> +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +#endif
> +
>  #if CONFIGURE_MICROSECONDS_PER_TICK <= 0
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>  #endif
> --
> 2.43.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improved error checking in ticks per timeslice

2024-03-05 Thread zack leung
Hey i've replied with another patch :)

On Tue, 5 Mar 2024 at 10:42, Kinsey Moore  wrote:

> Zack,
> It looks like there's been a little confusion here. Sebastian was
> requesting that you condense the pair of #ifs into a single #if with && and
> the defined check still coming first. It is mostly trivial in this
> instance, but virtually every other example in the related files is of a
> multi-conditional #if versus nested #ifs where possible. Technically, I
> think what you have is fine as the RTEMS coding conventions don't directly
> express a preference on split #ifs versus compound #ifs but it doesn't
> match the style of the surrounding code.
>
> Kinsey
>
> On Mon, Mar 4, 2024 at 7:39 PM zack leung 
> wrote:
>
>> ping
>>
>>
>> On Tue, 27 Feb 2024 at 21:33, zack leung 
>> wrote:
>>
>>>
>>> joel said:
>>>+#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
>>> > defined(CONFIGURE_TICKS_PER_TIMESLICE)
>>> > +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>> > +#endif
>>> > +
>>> >
>>> >
>>> > This is modifying the right file but I think it is safer to check that
>>> > it is defined
>>> > before checking its value.
>>>
>>> Yes, the defined() check should be first. - sebestian
>>>
>>> You said this in relation to joel's comment in my previous thread. You
>>> can check in either one.  The  previous one used the "and" statement.
>>>
>>> Zack
>>>
>>> On Tue, 27 Feb 2024 at 02:08, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
>>>> On 19.02.24 03:13, zakthertems...@gmail.com wrote:
>>>> > +#if defined(CONFIGURE_TICKS_PER_TIMESLICE)
>>>> > +  #if CONFIGURE_TICKS_PER_TIMESLICE <= 0
>>>> > +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>>> > +  #endif
>>>> > +#endif
>>>>
>>>> This should be
>>>>
>>>> #if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
>>>> CONFIGURE_TICKS_PER_TIMESLICE <= 0
>>>>
>>>> from my point of view. Just check the style of the related header files
>>>> for a reference.
>>>>
>>>> --
>>>> embedded brains GmbH & Co. KG
>>>> 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] improved error checking in ticks per timeslice

2024-03-04 Thread zack leung
ping


On Tue, 27 Feb 2024 at 21:33, zack leung  wrote:

>
> joel said:
>+#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> > defined(CONFIGURE_TICKS_PER_TIMESLICE)
> > +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> > +#endif
> > +
> >
> >
> > This is modifying the right file but I think it is safer to check that
> > it is defined
> > before checking its value.
>
> Yes, the defined() check should be first. - sebestian
>
> You said this in relation to joel's comment in my previous thread. You can
> check in either one.  The  previous one used the "and" statement.
>
> Zack
>
> On Tue, 27 Feb 2024 at 02:08, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 19.02.24 03:13, zakthertems...@gmail.com wrote:
>> > +#if defined(CONFIGURE_TICKS_PER_TIMESLICE)
>> > +  #if CONFIGURE_TICKS_PER_TIMESLICE <= 0
>> > +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> > +  #endif
>> > +#endif
>>
>> This should be
>>
>> #if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
>> CONFIGURE_TICKS_PER_TIMESLICE <= 0
>>
>> from my point of view. Just check the style of the related header files
>> for a reference.
>>
>> --
>> embedded brains GmbH & Co. KG
>> 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] improved error checking in ticks per timeslice

2024-02-27 Thread zack leung
joel said:
   +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +#endif
> +
>
>
> This is modifying the right file but I think it is safer to check that
> it is defined
> before checking its value.

Yes, the defined() check should be first. - sebestian

You said this in relation to joel's comment in my previous thread. You can
check in either one.  The  previous one used the "and" statement.

Zack

On Tue, 27 Feb 2024 at 02:08, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19.02.24 03:13, zakthertems...@gmail.com wrote:
> > +#if defined(CONFIGURE_TICKS_PER_TIMESLICE)
> > +  #if CONFIGURE_TICKS_PER_TIMESLICE <= 0
> > +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> > +  #endif
> > +#endif
>
> This should be
>
> #if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
> CONFIGURE_TICKS_PER_TIMESLICE <= 0
>
> from my point of view. Just check the style of the related header files
> for a reference.
>
> --
> embedded brains GmbH & Co. KG
> 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] improved error checking in ticks per timeslice

2024-02-26 Thread zack leung
ping


On Tue, 20 Feb 2024 at 20:25, zack leung  wrote:

> ping
>
> On Sun, 18 Feb 2024 at 21:15,  wrote:
>
>> ---
>>  cpukit/doxygen/appl-config.h  | 2 +-
>>  cpukit/include/rtems/confdefs/clock.h | 6 ++
>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
>> index bd7cde628f..d480eb3971 100644
>> --- a/cpukit/doxygen/appl-config.h
>> +++ b/cpukit/doxygen/appl-config.h
>> @@ -3312,7 +3312,7 @@
>>   * @parblock
>>   * The following constraints apply to this configuration option:
>>   *
>> - * * The value of the configuration option shall be greater than or
>> equal to
>> + * * The value of the configuration option shall be greater than
>>   *   zero.
>>   *
>>   * * The value of the configuration option shall be less than or equal
>> to > diff --git a/cpukit/include/rtems/confdefs/clock.h
>> b/cpukit/include/rtems/confdefs/clock.h
>> index 26519cc70b..f4c4575057 100644
>> --- a/cpukit/include/rtems/confdefs/clock.h
>> +++ b/cpukit/include/rtems/confdefs/clock.h
>> @@ -74,6 +74,12 @@
>>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>>  #endif
>>
>> +#if defined(CONFIGURE_TICKS_PER_TIMESLICE)
>> +  #if CONFIGURE_TICKS_PER_TIMESLICE <= 0
>> +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> +  #endif
>> +#endif
>> +
>>  #ifdef __cplusplus
>>  extern "C" {
>>  #endif
>> --
>> 2.43.0
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improved error checking in ticks per timeslice

2024-02-20 Thread zack leung
ping

On Sun, 18 Feb 2024 at 21:15,  wrote:

> ---
>  cpukit/doxygen/appl-config.h  | 2 +-
>  cpukit/include/rtems/confdefs/clock.h | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..d480eb3971 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,7 +3312,7 @@
>   * @parblock
>   * The following constraints apply to this configuration option:
>   *
> - * * The value of the configuration option shall be greater than or equal
> to
> + * * The value of the configuration option shall be greater than
>   *   zero.
>   *
>   * * The value of the configuration option shall be less than or equal to
>  diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..f4c4575057 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -74,6 +74,12 @@
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>  #endif
>
> +#if defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +  #if CONFIGURE_TICKS_PER_TIMESLICE <= 0
> +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +  #endif
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> --
> 2.43.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improved error checking in ticks per timeslice

2024-02-14 Thread zack leung
 > This file is generated from something in rtems-central. This was at the
> top of the file:
>
>   * This file is part of the RTEMS quality process and was automatically
>   * generated.  If you find something that needs to be fixed or
>   * worded better please post a report or patch to an RTEMS mailing list

No, problem. I can fix this before I check in the patch.

re: this do you need me to change it to something?

On Wed, 14 Feb 2024 at 09:28, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 14.02.24 15:18, Joel Sherrill wrote:
> > I'm cc'ing Sebastian because you edited the text in a generated file. He
> > should be able to point us to the right place to fix it.
> >
> > On Mon, Feb 12, 2024 at 8:26 PM  > <mailto:zakthertems...@gmail.com>> wrote:
> >
> > From: Zack leung mailto:z.liang...@gmail.com
> >>
> >
> > diff --git a/cpukit/doxygen/appl-config.h
> b/cpukit/doxygen/appl-config.h
> > index bd7cde628f..d480eb3971 100644
> > --- a/cpukit/doxygen/appl-config.h
> > +++ b/cpukit/doxygen/appl-config.h
> > @@ -3312,7 +3312,7 @@
> >* @parblock
> >* The following constraints apply to this configuration option:
> >*
> > - * * The value of the configuration option shall be greater than or
> > equal to
> > + * * The value of the configuration option shall be greater than
> >*   zero.
> >
> >
> >
> > This file is generated from something in rtems-central. This was at the
> > top of the file:
> >
> >   * This file is part of the RTEMS quality process and was automatically
> >   * generated.  If you find something that needs to be fixed or
> >   * worded better please post a report or patch to an RTEMS mailing list
>
> No, problem. I can fix this before I check in the patch.
>
> >
> >*
> >* * The value of the configuration option shall be less than or
> > equal to  > diff --git a/cpukit/include/rtems/confdefs/clock.h
> > b/cpukit/include/rtems/confdefs/clock.h
> > index 26519cc70b..d0d7c453bc 100644
> > --- a/cpukit/include/rtems/confdefs/clock.h
> > +++ b/cpukit/include/rtems/confdefs/clock.h
> > @@ -74,6 +74,10 @@
> > #error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
> >   #endif
> >
> > +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> > defined(CONFIGURE_TICKS_PER_TIMESLICE)
> > +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> > +#endif
> > +
> >
> >
> > This is modifying the right file but I think it is safer to check that
> > it is defined
> > before checking its value.
>
> Yes, the defined() check should be first.
>
> --
> embedded brains GmbH & Co. KG
> 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] fixed warning related to spstdc17

2023-11-10 Thread zack leung
ping

On Tue, 31 Oct 2023 at 22:07, zack leung  wrote:

> Sorry either I lack knowledge in C or lack knowledge in working with
> rtems. Do you mean if rtems smp is defined then we make sure that scheduler
> context base type is defined? I don't quite understand why it would be
> !defined? And the changes you're referring to are not in the scheduler.h
> file which is where the struct is defined.
>
> On Mon, 30 Oct 2023 at 03:04, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29.10.23 02:44, zack leung wrote:
>> > ./../../cpukit/include/rtems/score/schedulerpriority.h:87:21: error:
>> > field 'Base' has incomplete type
>> > 87 |   Scheduler_Context Base;
>> >| ^~~~
>> > ../../../cpukit/include/rtems/score/schedulersimple.h:89:21: error:
>> > field 'Base' has incomplete type
>> > 89 |   Scheduler_Context Base;
>> >| ^~~~
>> >
>> > I get this error when using typedefs
>>
>> Yes, the
>>
>> typedef struct Scheduler_Context Scheduler_Context;
>>
>> only creates the typedef and the structure name. This is why I also wrote:
>>
>> Then you have to make sure that #if !defined(RTEMS_SMP) no objects of
>> this type are used.
>>
>> For example:
>>
>> diff --git a/cpukit/include/rtems/score/schedulersimple.h
>> b/cpukit/include/rtems/score/schedulersimple.h
>> index d9acd3dea0..0db72b2a51 100644
>> --- a/cpukit/include/rtems/score/schedulersimple.h
>> +++ b/cpukit/include/rtems/score/schedulersimple.h
>> @@ -83,10 +83,12 @@ extern "C" {
>>* @brief Simple scheduler context.
>>*/
>>   typedef struct {
>> +#if !defined(RTEMS_SMP)
>> /**
>>  * @brief Basic scheduler context.
>>  */
>> Scheduler_Context Base;
>> +#endif
>>
>> /**
>>  * @brief One ready queue for all ready threads.
>>
>> --
>> 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] fixed warning related to spstdc17

2023-10-31 Thread zack leung
Sorry either I lack knowledge in C or lack knowledge in working with rtems.
Do you mean if rtems smp is defined then we make sure that scheduler
context base type is defined? I don't quite understand why it would be
!defined? And the changes you're referring to are not in the scheduler.h
file which is where the struct is defined.

On Mon, 30 Oct 2023 at 03:04, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29.10.23 02:44, zack leung wrote:
> > ./../../cpukit/include/rtems/score/schedulerpriority.h:87:21: error:
> > field 'Base' has incomplete type
> > 87 |   Scheduler_Context Base;
> >| ^~~~
> > ../../../cpukit/include/rtems/score/schedulersimple.h:89:21: error:
> > field 'Base' has incomplete type
> > 89 |   Scheduler_Context Base;
> >| ^~~~
> >
> > I get this error when using typedefs
>
> Yes, the
>
> typedef struct Scheduler_Context Scheduler_Context;
>
> only creates the typedef and the structure name. This is why I also wrote:
>
> Then you have to make sure that #if !defined(RTEMS_SMP) no objects of
> this type are used.
>
> For example:
>
> diff --git a/cpukit/include/rtems/score/schedulersimple.h
> b/cpukit/include/rtems/score/schedulersimple.h
> index d9acd3dea0..0db72b2a51 100644
> --- a/cpukit/include/rtems/score/schedulersimple.h
> +++ b/cpukit/include/rtems/score/schedulersimple.h
> @@ -83,10 +83,12 @@ extern "C" {
>* @brief Simple scheduler context.
>*/
>   typedef struct {
> +#if !defined(RTEMS_SMP)
> /**
>  * @brief Basic scheduler context.
>  */
> Scheduler_Context Base;
> +#endif
>
> /**
>  * @brief One ready queue for all ready threads.
>
> --
> 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] fixed warning related to spstdc17

2023-10-30 Thread zack leung
./../../cpukit/include/rtems/score/schedulerpriority.h:87:21: error: field
'Base' has incomplete type
   87 |   Scheduler_Context Base;
  | ^~~~
../../../cpukit/include/rtems/score/schedulersimple.h:89:21: error: field
'Base' has incomplete type
   89 |   Scheduler_Context Base;
  | ^~~~

I get this error when using typedefs



#if defined(RTEMS_SMP)
typedef struct Scheduler_Context {



/**
 * @brief Lock to protect this scheduler instance.
 */
ISR_lock_Control Lock;

/**
 * @brief The set of processors owned by this scheduler instance.
 */
Processor_mask Processors;

} Scheduler_Context;
#endif
#if !defined(RTEMS_SMP)
 typedef struct Scheduler_Context Scheduler_Context;
#endif
/**

or

#if defined(RTEMS_SMP)
typedef struct Scheduler_Context {



/**
 * @brief Lock to protect this scheduler instance.
 */
ISR_lock_Control Lock;

/**
 * @brief The set of processors owned by this scheduler instance.
 */
Processor_mask Processors;

} Scheduler_Context;
#else
 typedef struct Scheduler_Context Scheduler_Context;
#endif
/**

On Fri, 27 Oct 2023 at 01:40, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 27.10.23 03:43, zack leung wrote:
> > ping
> >
> > On Tue, 24 Oct 2023 at 22:17, zack leung  > <mailto:zakthertems...@gmail.com>> wrote:
> >
> > that didn't work but i'm thinking of defining a char array that is
> > equal to the size of the processor lock and the isr lock?
>
> This is a bit complicated and still leads to a size increase.
>
> > i figured
> > that the processor lock is 64 bits and isr lock is a one bit?
> > I'm confused on how to make an api define do you have a file i can
> > look at?
>
> Maybe you try to fix the Scheduler_Context warning first. It is easier
> to fix. I am pretty sure that this approach works:
>
> Get rid of the empty structures is to just provide typedefs, for example:
>
> #if defined(RTEMS_SMP)
> typedef struct Scheduler_Context {
> ...
> } Scheduler_Context;
> #else
> typedef struct Scheduler_Context Scheduler_Context;
> #endif
>
> Then you have to make sure that #if !defined(RTEMS_SMP) no objects of
> this type are used.
>
> --
> 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] fixed warning related to spstdc17

2023-10-26 Thread zack leung
ping

On Tue, 24 Oct 2023 at 22:17, zack leung  wrote:

> that didn't work but i'm thinking of defining a char array that is  equal
> to the size of the processor lock and the isr lock? i figured  that the
> processor lock is 64 bits and isr lock is a one bit?
> I'm confused on how to make an api define do you have a file i can look
> at?
>
>
>
> On Tue, 24 Oct 2023 at 08:31, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 24.10.23 14:02, zack leung wrote:
>> > hi! sabestian did you mean the size of the structure?
>>
>> Yes, one option to get rid of the empty structures is to just provide
>> typedefs, for example:
>>
>> #if defined(RTEMS_SMP)
>> typedef struct Scheduler_Context {
>> ...
>> } Scheduler_Context;
>> #else
>> typedef struct Scheduler_Context Scheduler_Context;
>> #endif
>>
>> Then you have to make sure that #if !defined(RTEMS_SMP) no objects of
>> this type are used.
>>
>> For the ISR locks we can do something similar. However, in this case
>> this affects also the API, so we probably need an API define for this as
>> well.  Suggestion: RTEMS_HAVE_INTERRUPT_LOCK_OBJECTS.
>>
>> The user can then do something like this:
>>
>> struct app {
>>...
>> #if defined(RTEMS_HAVE_INTERRUPT_LOCK_OBJECTS)
>>rtems_interrupt_lock lock;
>> #endif
>>...
>> }
>>
>> --
>> 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] fixed warning related to spstdc17

2023-10-24 Thread zack leung
that didn't work but i'm thinking of defining a char array that is  equal
to the size of the processor lock and the isr lock? i figured  that the
processor lock is 64 bits and isr lock is a one bit?
I'm confused on how to make an api define do you have a file i can look at?



On Tue, 24 Oct 2023 at 08:31, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 24.10.23 14:02, zack leung wrote:
> > hi! sabestian did you mean the size of the structure?
>
> Yes, one option to get rid of the empty structures is to just provide
> typedefs, for example:
>
> #if defined(RTEMS_SMP)
> typedef struct Scheduler_Context {
> ...
> } Scheduler_Context;
> #else
> typedef struct Scheduler_Context Scheduler_Context;
> #endif
>
> Then you have to make sure that #if !defined(RTEMS_SMP) no objects of
> this type are used.
>
> For the ISR locks we can do something similar. However, in this case
> this affects also the API, so we probably need an API define for this as
> well.  Suggestion: RTEMS_HAVE_INTERRUPT_LOCK_OBJECTS.
>
> The user can then do something like this:
>
> struct app {
>...
> #if defined(RTEMS_HAVE_INTERRUPT_LOCK_OBJECTS)
>rtems_interrupt_lock lock;
> #endif
>...
> }
>
> --
> 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] fixed warning related to spstdc17

2023-10-24 Thread zack leung
hi! sabestian did you mean the size of the structure?

On Mon, 23 Oct 2023 at 10:20, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Zack,
>
> there is a bit more work to do to fix this warning. The warning fix
> should not result in a size increase of the uniprocessor RTEMS
> configuration.
>
> --
> 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] TMS570 console driver, SCI frame error (baudrate calculation error)

2023-07-14 Thread zack leung
hi, so do you want me make this change?

On Wed, 12 Jul 2023 at 10:54, Gedare Bloom  wrote:

> On Wed, Jul 12, 2023 at 8:06 AM Joel Sherrill  wrote:
> >
> >
> > Pavel this was filed as https://devel.rtems.org/ticket/4903. The ticket
> submitter
> > didn't give a patch, just a code change snippet and explanation. Zack
> turned it into
> > a patch. You will need to post that on the ticket to get the submitter's
> feedback.
> >
> > I hope you don't mind copying that to the ticket and seeing what you
> think is
> > really up.
> >
> I posted it over there. Thanks Pavel and Joel.
>
> > Thanks.
> >
> > --joel
> >
> > On Wed, Jul 12, 2023 at 8:49 AM Pavel Pisa 
> wrote:
> >>
> >> Hello Zack and Gedare,
> >>
> >> On Tuesday 11 of July 2023 19:52:27 Gedare Bloom wrote:
> >> > Thanks for the patch. Someone should probably test it, or identify in
> >> > the documentation why this calculation was off-by-1. Pavel, any clues?
> >> > On Sun, Jul 9, 2023 at 10:09 PM zack 
> wrote:
> >> > > Fixes #4903
> >> > > diff --git a/bsps/arm/tms570/console/tms570-sci.c
> >> > > b/bsps/arm/tms570/console/tms570-sci.c index 768770a4c8..59a0b7e6f1
> >> > > 100644
> >> > > --- a/bsps/arm/tms570/console/tms570-sci.c
> >> > > +++ b/bsps/arm/tms570/console/tms570-sci.c
> >> > > @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
> >> > >/* Apply baudrate to the hardware */
> >> > >baudrate *= 2 * 16;
> >> > >bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
> >> > > -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
> >> > > +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
> >>
> >> I think that change is not correct. The actual used values
> >> for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze
> >> the case. The code can result in some rounding error and can
> >> be enhanced if fractional divider is used or even super finegrained
> >> fractional divider. But these options are available only for
> >> for SCI/LIN peripheral case.
> >>
> >> According to
> >>
> >> TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller
> >> Technical Reference Manual
> >> Literature Number: SPNU499B
> >>
> >> 26.2.3 SCI Baud Rate
> >>
> >>   SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)
> >>
> >>   Asynchronous baud value = SCICLK Frequency / 16
> >>
> >> So the substraction of one corresponds to the manual.
> >>
> >> Actual code does not use M part. It would be problem if it is
> >> leftover from some boot/monitor but it is part of BRS 32-bit
> >> register which is overwritten in the whole, so such problem
> >> should not appear either.
> >>
> >> So I vote against the proposed change for now and suggest
> >> to do analysis what happens in the computation and what
> >> are input values and output. Change would/could affect
> >> negatively large number of combinations of the baudrate
> >> and clocks.
> >>
> >> I would consider to discuss if the rounding formula
> >> could/should be updated, but I think that it is the best
> >> which cane be achieved for rations which do not result
> >> in exact ratio.
> >>
> >>   (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
> >>
> >> If there is interrest then code can be enhanced by fraction
> >> dividers for SCI/LIN peripheral case. The field with variant
> >> should be added into tms570_sci_context and in this case
> >> the alternative formula can be used
> >>
> >>   long long bauddiv;
> >>   bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate;
> >>   ctx->regs->BRS = ((bauddiv >> 4) & 0xff) | ((bauddiv & 0xf) <<
> 24);
> >>
> >> which should be rewritten after header for SCI/LIN update to
> >>
> >>   ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) |
> TMS570_LIN_BRS_M(bauddiv & 0xf);
> >
> >
> >
> >>
> >>
> >> Best wishes,
> >>
> >>
> >> Pavel
> >> --
> >> Pavel Pisa
> >> phone:  +420 603531357
> >> e-mail: p...@cmp.felk.cvut.cz
> >> Department of Control Engineering FEE CVUT
> >> Karlovo namesti 13, 121 35, Prague 2
> >> university: http://control.fel.cvut.cz/
> >> personal:   http://cmp.felk.cvut.cz/~pisa
> >> projects:   https://www.openhub.net/accounts/ppisa
> >> CAN related:http://canbus.pages.fel.cvut.cz/
> >> RISC-V education: https://comparch.edu.cvut.cz/
> >> Open Technologies Research Education and Exchange Services
> >> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
> >>
> >> ___
> >> 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

readdir issue 4674

2023-03-04 Thread zack leung
- hi guys i am working on #4674
- currently i'm not able to get it to produce the error
- my code looks like this
-

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const char rtems_test_name[] = "FSREADDIR ";
int test( void );

int test( void )
{
   char *many_files[] = {"a", "b","c"};


  printf( "\nchdir to the root directory\n" );
 int  status = chdir( "/" );
  printf( "chdir() status : %d\n\n", status );
for (int i = 0; i<3; i++) {
printf("Create %s\n", many_files[i]);
int fd = open (many_files[i], O_CREAT, S_IRWXU);
close (fd);
  }
struct dirent* direntp;
 DIR* dirp;
dirp = opendir( "/" );
if( dirp != NULL ) {
for(;;) {
direntp = readdir( dirp );
if( direntp == NULL ) break;

printf( "%s\n", direntp->d_name );
}

closedir( dirp );

}

   status =  unlink("/b");
printf( "removing the second directory  : %d\n\n", status );
   dirp = opendir( "/" );
if( dirp != NULL ) {
for(;;) {
direntp = readdir( dirp );
if( direntp == NULL ) break;

printf( "%s\n", direntp->d_name );
}

closedir( dirp );

}

   return 0;

}

Am i unlinking it correctly?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] fixes 4557

2023-02-13 Thread Zack leung
From: zack 

Closes #4557
---
 cpukit/libmisc/shell/main_edit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index 6e954639e2..8317452b7b 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1713,7 +1713,6 @@ static void copy_selection(struct editor *ed) {
   ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard, 
ed->env->clipsize);
   if (!ed->env->clipboard) return;
   copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
-  select_toggle(ed);
 }
 
 static void cut_selection(struct editor *ed) {
@@ -2132,7 +2131,7 @@ static void edit(struct editor *ed) {
 
 case ctrl('e'): select_toggle(ed); break;
 case ctrl('a'): select_all(ed); break;
-case ctrl('c'): copy_selection(ed); break;
+case ctrl('c'): copy_selection(ed);select_toggle(ed); break;
 case ctrl('f'): find_text(ed, 0); break;
 case ctrl('l'): goto_line(ed); break;
 case ctrl('g'): find_text(ed, 1); break;
-- 
2.39.1

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


[patch] medit issue

2023-02-10 Thread zack leung
libmisc/shell: User can't cut using ctrl e and x in medit

Closes #4557
---
 cpukit/libmisc/shell/main_edit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c
b/cpukit/libmisc/shell/main_edit.c
index 6e954639e2..8317452b7b 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1713,7 +1713,6 @@ static void copy_selection(struct editor *ed) {
   ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard,
ed->env->clipsize);
   if (!ed->env->clipboard) return;
   copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
-  select_toggle(ed);
 }

 static void cut_selection(struct editor *ed) {
@@ -2132,7 +2131,7 @@ static void edit(struct editor *ed) {

 case ctrl('e'): select_toggle(ed); break;
 case ctrl('a'): select_all(ed); break;
-case ctrl('c'): copy_selection(ed); break;
+case ctrl('c'): copy_selection(ed);select_toggle(ed); break;
 case ctrl('f'): find_text(ed, 0); break;
 case ctrl('l'): goto_line(ed); break;
 case ctrl('g'): find_text(ed, 1); break;
-- 
2.39.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[patch] fixes 4557

2023-02-09 Thread zack leung
fixes 4557 user can't cut using ctrl e and x in medit
---
 cpukit/libmisc/shell/main_edit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c
b/cpukit/libmisc/shell/main_edit.c
index 6e954639e2..8317452b7b 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1713,7 +1713,6 @@ static void copy_selection(struct editor *ed) {
   ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard,
ed->env->clipsize);
   if (!ed->env->clipboard) return;
   copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
-  select_toggle(ed);
 }

 static void cut_selection(struct editor *ed) {
@@ -2132,7 +2131,7 @@ static void edit(struct editor *ed) {

 case ctrl('e'): select_toggle(ed); break;
 case ctrl('a'): select_all(ed); break;
-case ctrl('c'): copy_selection(ed); break;
+case ctrl('c'): copy_selection(ed);select_toggle(ed); break;
 case ctrl('f'): find_text(ed, 0); break;
 case ctrl('l'): goto_line(ed); break;
 case ctrl('g'): find_text(ed, 1); break;
-- 
2.39.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[patch] medit problem

2023-02-04 Thread zack leung
fixes #4557
---
 cpukit/libmisc/shell/main_edit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c
b/cpukit/libmisc/shell/main_edit.c
index 191eefa19d..71bb1d931b 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1710,7 +1710,7 @@ static void copy_selection(struct editor *ed) {
   ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard,
ed->env->clipsize);
   if (!ed->env->clipboard) return;
   copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
-  select_toggle(ed);
+
 }

 static void cut_selection(struct editor *ed) {
@@ -2128,7 +2128,7 @@ static void edit(struct editor *ed) {

 case ctrl('e'): select_toggle(ed); break;
 case ctrl('a'): select_all(ed); break;
-case ctrl('c'): copy_selection(ed); break;
+case ctrl('c'): copy_selection(ed); select_toggle(ed); break;
 case ctrl('f'): find_text(ed, 0); break;
 case ctrl('l'): goto_line(ed); break;
 case ctrl('g'): find_text(ed, 1); break;
-- 
2.39.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket 4364

2023-01-03 Thread zack leung
Hello,

I'm currently looking at ticket 4364. It says that there is a difference
between the test results printed by the console and what is emailed to
@devel. I don't see a difference and i'm just wondering if it has been
fixed

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

[PATCH] rtems_shell_main_chmod problem

2022-12-26 Thread zack leung
Closes #4751
---
 cpukit/libmisc/shell/main_chmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_chmod.c
b/cpukit/libmisc/shell/main_chmod.c
index 1f646d92d4..9a42cbd940 100644
--- a/cpukit/libmisc/shell/main_chmod.c
+++ b/cpukit/libmisc/shell/main_chmod.c
@@ -56,7 +56,7 @@ static int rtems_shell_main_chmod(
*  Now change the files modes
*/
   for (n=2 ; n < argc ; n++) {
-sc = chmod(argv[n++], mode);
+sc = chmod(argv[n], mode);
 _Assert_Unused_variable_unequal(sc, -1);
   }

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

[PATCH] rtems_shell_main_chmod problem

2022-12-26 Thread zack leung
Closes #4751
---
 cpukit/libmisc/shell/main_chmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_chmod.c
b/cpukit/libmisc/shell/main_chmod.c
index 1f646d92d4..9a42cbd940 100644
--- a/cpukit/libmisc/shell/main_chmod.c
+++ b/cpukit/libmisc/shell/main_chmod.c
@@ -56,7 +56,7 @@ static int rtems_shell_main_chmod(
*  Now change the files modes
*/
   for (n=2 ; n < argc ; n++) {
-sc = chmod(argv[n++], mode);
+sc = chmod(argv[n], mode);
 _Assert_Unused_variable_unequal(sc, -1);
   }

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

[PATCH] rtems_shell_main_chmod problem

2022-12-26 Thread zack leung
Closes #4751
---
 cpukit/libmisc/shell/main_chmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_chmod.c
b/cpukit/libmisc/shell/main_chmod.c
index 1f646d92d4..9a42cbd940 100644
--- a/cpukit/libmisc/shell/main_chmod.c
+++ b/cpukit/libmisc/shell/main_chmod.c
@@ -56,7 +56,7 @@ static int rtems_shell_main_chmod(
*  Now change the files modes
*/
   for (n=2 ; n < argc ; n++) {
-sc = chmod(argv[n++], mode);
+sc = chmod(argv[n], mode);
 _Assert_Unused_variable_unequal(sc, -1);
   }

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

Re: [PATCH] rtems_shell_main_mmove problem

2022-12-22 Thread zack leung
Bump

On Wed, 14 Dec 2022 at 20:12, zack leung  wrote:

> Closes #4556
> ---
>  cpukit/libmisc/shell/main_mmove.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/shell/main_mmove.c
> b/cpukit/libmisc/shell/main_mmove.c
> index 38731b10a2..0029882d62 100644
> --- a/cpukit/libmisc/shell/main_mmove.c
> +++ b/cpukit/libmisc/shell/main_mmove.c
> @@ -62,7 +62,7 @@ static int rtems_shell_main_mmove(
>/*
> *  Now copy the memory.
> */
> -  memcpy(dst, src, length);
> +  memmove(dst, src, length);
>
>   return 0;
>  }
> --
> 2.38.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems_shell_main_mmove problem

2022-12-14 Thread zack leung
Closes #4556
---
 cpukit/libmisc/shell/main_mmove.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_mmove.c
b/cpukit/libmisc/shell/main_mmove.c
index 38731b10a2..0029882d62 100644
--- a/cpukit/libmisc/shell/main_mmove.c
+++ b/cpukit/libmisc/shell/main_mmove.c
@@ -62,7 +62,7 @@ static int rtems_shell_main_mmove(
   /*
*  Now copy the memory.
*/
-  memcpy(dst, src, length);
+  memmove(dst, src, length);

  return 0;
 }
-- 
2.38.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] added malloc usable size and test

2022-03-10 Thread zack leung
Ping

Il ven 4 mar 2022, 21:58 zack leung  ha scritto:

> closes #4503
> ---
>  cpukit/include/rtems/libcsupport.h|  5 +++
>  cpukit/libcsupport/src/mallocusablesize.c | 48 +++
>  spec/build/cpukit/librtemscpu.yml |  1 +
>  testsuites/libtests/malloctest/init.c | 15 ++-
>  4 files changed, 68 insertions(+), 1 deletion(-)
>  create mode 100644 cpukit/libcsupport/src/mallocusablesize.c
>
> diff --git a/cpukit/include/rtems/libcsupport.h
> b/cpukit/include/rtems/libcsupport.h
> index f4be4cfc9a..5110ab0fbe 100644
> --- a/cpukit/include/rtems/libcsupport.h
> +++ b/cpukit/include/rtems/libcsupport.h
> @@ -74,6 +74,11 @@ extern size_t malloc_free_space(void);
>   */
>  extern int malloc_info(Heap_Information_block *the_info);
>
> +/**
> + * @brief Find the usable size of the block of memory .
> + */
> +extern size_t malloc_usable_size(void *ptr);
> +
>  /*
>   *  Prototypes required to install newlib reentrancy user extension
>   */
> diff --git a/cpukit/libcsupport/src/mallocusablesize.c
> b/cpukit/libcsupport/src/mallocusablesize.c
> new file mode 100644
> index 00..b7e573023a
> --- /dev/null
> +++ b/cpukit/libcsupport/src/mallocusablesize.c
> @@ -0,0 +1,48 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + *  Copyright (C) 2022 zacchaeus leung
> + *
> + * 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.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +size_t malloc_usable_size( void *ptr ) {
> +
> +  Heap_Control *heap_ptr ;
> +  size_t size;
> +  if ( ptr == NULL ) {
> +return 0;
> +  }
> +
> +  heap_ptr = malloc_get_heap_pointer();
> +  _Heap_Size_of_alloc_area( heap_ptr, ptr,  );
> +
> +  return size;
> +}
> diff --git a/spec/build/cpukit/librtemscpu.yml
> b/spec/build/cpukit/librtemscpu.yml
> index c224937348..2ef11e7e2d 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -670,6 +670,7 @@ source:
>  - cpukit/libcsupport/src/lseek.c
>  - cpukit/libcsupport/src/lstat.c
>  - cpukit/libcsupport/src/malloc.c
> +- cpukit/libcsupport/src/mallocusablesize.c
>  - cpukit/libcsupport/src/malloc_deferred.c
>  - cpukit/libcsupport/src/malloc_dirtier.c
>  - cpukit/libcsupport/src/malloc_walk.c
> diff --git a/testsuites/libtests/malloctest/init.c
> b/testsuites/libtests/malloctest/init.c
> index a33764177d..871edb540e 100644
> --- a/testsuites/libtests/malloctest/init.c
> +++ b/testsuites/libtests/malloctest/init.c
> @@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
>rtems_test_assert( p == NULL );
>rtems_test_assert( errno == -1 );
>  }
> +static void test_usablesize(void)
> +{
> +  int * a = malloc(sizeof( int )*100);
> +  int alloc_size=sizeof( int ) *100 ;
> +  rtems_test_assert( malloc_usable_size( a ) <= alloc_size +
> CPU_HEAP_ALIGNMENT );
> +  free(a);
> +
> +  char * b = malloc(sizeof ( char ) 100);
> +  int alloc_size 2= sizeof ( char ) *100 ;
> +  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 +
> CPU_HEAP_ALIGNMENT);
> +  free( b );
> +}
>
>  rtems_task Init(
>rtems_task_argument argument
> @@ -1405,6 +1417,7 @@ rtems_task Init(
>test_protected_heap_info();
>test_rtems_heap_allocate_ali

[PATCH] added malloc usable size and test

2022-03-04 Thread zack leung
closes #4503
---
 cpukit/include/rtems/libcsupport.h|  5 +++
 cpukit/libcsupport/src/mallocusablesize.c | 48 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 testsuites/libtests/malloctest/init.c | 15 ++-
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/libcsupport/src/mallocusablesize.c

diff --git a/cpukit/include/rtems/libcsupport.h
b/cpukit/include/rtems/libcsupport.h
index f4be4cfc9a..5110ab0fbe 100644
--- a/cpukit/include/rtems/libcsupport.h
+++ b/cpukit/include/rtems/libcsupport.h
@@ -74,6 +74,11 @@ extern size_t malloc_free_space(void);
  */
 extern int malloc_info(Heap_Information_block *the_info);

+/**
+ * @brief Find the usable size of the block of memory .
+ */
+extern size_t malloc_usable_size(void *ptr);
+
 /*
  *  Prototypes required to install newlib reentrancy user extension
  */
diff --git a/cpukit/libcsupport/src/mallocusablesize.c
b/cpukit/libcsupport/src/mallocusablesize.c
new file mode 100644
index 00..b7e573023a
--- /dev/null
+++ b/cpukit/libcsupport/src/mallocusablesize.c
@@ -0,0 +1,48 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ *  Copyright (C) 2022 zacchaeus leung
+ *
+ * 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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+size_t malloc_usable_size( void *ptr ) {
+
+  Heap_Control *heap_ptr ;
+  size_t size;
+  if ( ptr == NULL ) {
+return 0;
+  }
+
+  heap_ptr = malloc_get_heap_pointer();
+  _Heap_Size_of_alloc_area( heap_ptr, ptr,  );
+
+  return size;
+}
diff --git a/spec/build/cpukit/librtemscpu.yml
b/spec/build/cpukit/librtemscpu.yml
index c224937348..2ef11e7e2d 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -670,6 +670,7 @@ source:
 - cpukit/libcsupport/src/lseek.c
 - cpukit/libcsupport/src/lstat.c
 - cpukit/libcsupport/src/malloc.c
+- cpukit/libcsupport/src/mallocusablesize.c
 - cpukit/libcsupport/src/malloc_deferred.c
 - cpukit/libcsupport/src/malloc_dirtier.c
 - cpukit/libcsupport/src/malloc_walk.c
diff --git a/testsuites/libtests/malloctest/init.c
b/testsuites/libtests/malloctest/init.c
index a33764177d..871edb540e 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
   rtems_test_assert( p == NULL );
   rtems_test_assert( errno == -1 );
 }
+static void test_usablesize(void)
+{
+  int * a = malloc(sizeof( int )*100);
+  int alloc_size=sizeof( int ) *100 ;
+  rtems_test_assert( malloc_usable_size( a ) <= alloc_size +
CPU_HEAP_ALIGNMENT );
+  free(a);
+
+  char * b = malloc(sizeof ( char ) 100);
+  int alloc_size 2= sizeof ( char ) *100 ;
+  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 +
CPU_HEAP_ALIGNMENT);
+  free( b );
+}

 rtems_task Init(
   rtems_task_argument argument
@@ -1405,6 +1417,7 @@ rtems_task Init(
   test_protected_heap_info();
   test_rtems_heap_allocate_aligned_with_boundary();
   test_rtems_malloc();
+  test_usablesize();
   test_rtems_calloc();
   test_greedy_allocate();
   test_alloc_zero_size();
@@ -1524,4 +1537,4 @@ RTEMS_SYSINIT_ITEM(
   test_early_malloc,
   RTEMS_SYSINIT_INITIAL_EXTENSIONS,
   RTEMS_SYSINIT_ORDER_FIRST
-);
+);
\ No newline at end of file
-- 
2.35.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH] added malloc usable size and test

2022-03-03 Thread zack leung
---
 cpukit/include/rtems/libcsupport.h|  5 +++
 cpukit/libcsupport/src/mallocusablesize.c | 48 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 testsuites/libtests/malloctest/init.c | 15 ++-
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/libcsupport/src/mallocusablesize.c

diff --git a/cpukit/include/rtems/libcsupport.h 
b/cpukit/include/rtems/libcsupport.h
index f4be4cfc9a..5110ab0fbe 100644
--- a/cpukit/include/rtems/libcsupport.h
+++ b/cpukit/include/rtems/libcsupport.h
@@ -74,6 +74,11 @@ extern size_t malloc_free_space(void);
  */
 extern int malloc_info(Heap_Information_block *the_info);
 
+/**
+ * @brief Find the usable size of the block of memory .
+ */
+extern size_t malloc_usable_size(void *ptr);
+
 /*
  *  Prototypes required to install newlib reentrancy user extension
  */
diff --git a/cpukit/libcsupport/src/mallocusablesize.c 
b/cpukit/libcsupport/src/mallocusablesize.c
new file mode 100644
index 00..b7e573023a
--- /dev/null
+++ b/cpukit/libcsupport/src/mallocusablesize.c
@@ -0,0 +1,48 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) ,  
+ *
+ * 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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+ 
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+size_t malloc_usable_size( void *ptr ) {
+  
+  Heap_Control *heap_ptr ;
+  size_t size;
+  if ( ptr == NULL ) {
+return 0;
+  }
+  
+  heap_ptr = malloc_get_heap_pointer();
+  _Heap_Size_of_alloc_area( heap_ptr, ptr,  );
+
+  return size;
+}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index c224937348..2ef11e7e2d 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -670,6 +670,7 @@ source:
 - cpukit/libcsupport/src/lseek.c
 - cpukit/libcsupport/src/lstat.c
 - cpukit/libcsupport/src/malloc.c
+- cpukit/libcsupport/src/mallocusablesize.c 
 - cpukit/libcsupport/src/malloc_deferred.c
 - cpukit/libcsupport/src/malloc_dirtier.c
 - cpukit/libcsupport/src/malloc_walk.c
diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index a33764177d..871edb540e 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
   rtems_test_assert( p == NULL );
   rtems_test_assert( errno == -1 );
 }
+static void test_usablesize(void)
+{
+  int * a = malloc(sizeof( int )*100);
+  int alloc_size=sizeof( int ) *100 ;
+  rtems_test_assert( malloc_usable_size( a ) <= alloc_size + 
CPU_HEAP_ALIGNMENT );
+  free(a);
+
+  char * b = malloc(sizeof ( char ) 100);
+  int alloc_size 2= sizeof ( char ) *100 ; 
+  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 + 
CPU_HEAP_ALIGNMENT);
+  free( b );
+}
 
 rtems_task Init(
   rtems_task_argument argument
@@ -1405,6 +1417,7 @@ rtems_task Init(
   test_protected_heap_info();
   test_rtems_heap_allocate_aligned_with_boundary();
   test_rtems_malloc();
+  test_usablesize();
   test_rtems_calloc();
   test_greedy_allocate();
   test_alloc_zero_size();
@@ -1524,4 +1537,4 @@ RTEMS_SYSINIT_ITEM(
   test_early_malloc,
   RTEMS_SYSINIT_INITIAL_EXTENSIONS,
   RTEMS_SYSINIT_ORDER_FIRST
-);
+);
\ No newline at end of file
-- 
2.35.1

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


Re: [PATCH] added malloc usable size and test

2022-02-25 Thread zack leung
ping


On Sat, 26 Feb 2022 at 02:42, zack leung  wrote:

> ping
> *
>
> On Sun, 20 Feb 2022 at 02:55, zack leung  wrote:
>
>> diff --git a/cpukit/include/rtems/libcsupport.h
>> b/cpukit/include/rtems/libcsupport.h
>> index f4be4cfc9a..ec385bb71a 100644
>> --- a/cpukit/include/rtems/libcsupport.h
>> +++ b/cpukit/include/rtems/libcsupport.h
>> @@ -73,7 +73,10 @@ extern size_t malloc_free_space(void);
>>   * Find amount of free heap remaining.
>>   */
>>  extern int malloc_info(Heap_Information_block *the_info);
>> -
>> +/**
>> + * @brief Find the usable size of the block of memory.
>> + */
>> +extern size_t malloc_usable_size( void *ptr );
>>  /*
>>   *  Prototypes required to install newlib reentrancy user extension
>>   */
>> @@ -185,6 +188,7 @@ bool rtems_resource_snapshot_equal(
>>   */
>>  bool rtems_resource_snapshot_check(const rtems_resource_snapshot
>> *snapshot);
>>
>> +
>>  /** @} */
>>
>>  #ifdef __cplusplus
>> diff --git a/cpukit/libcsupport/src/mallocusablesize.c
>> b/cpukit/libcsupport/src/mallocusablesize.c
>> new file mode 100644
>> index 00..d9211b1390
>> --- /dev/null
>> +++ b/cpukit/libcsupport/src/mallocusablesize.c
>> @@ -0,0 +1,51 @@
>> +/*
>> + * SPDX-License-Identifier: BSD-2-Clause
>> + *
>> + * Copyright (C) 2022 Zacchaeus Leung
>> + *
>> + * 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.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
>> + */
>> +
>> +#ifdef HAVE_CONFIG_H
>> +#include "config.h"
>> +#endif
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +size_t malloc_usable_size(void *ptr) {
>> +  Heap_Control *heap_ptr ;
>> +  size_t size;
>> +  if (ptr == NULL) {
>> +return 0;
>> +  }
>> +
>> +
>> +  heap_ptr = malloc_get_heap_pointer();
>> +  bool rv=_Heap_Size_of_alloc_area(heap_ptr, ptr, );
>> +  if( rv==false ){
>> +return 0;
>> +  }
>> +
>> +  return size;
>> +}
>> \ No newline at end of file
>> diff --git a/spec/build/cpukit/librtemscpu.yml
>> b/spec/build/cpukit/librtemscpu.yml
>> index 7d6dbae0db..5902008c94 100644
>> --- a/spec/build/cpukit/librtemscpu.yml
>> +++ b/spec/build/cpukit/librtemscpu.yml
>> @@ -670,6 +670,7 @@ source:
>>  - cpukit/libcsupport/src/lseek.c
>>  - cpukit/libcsupport/src/lstat.c
>>  - cpukit/libcsupport/src/malloc.c
>> +- cpukit/libcsupport/src/mallocusablesize.c
>>  - cpukit/libcsupport/src/malloc_deferred.c
>>  - cpukit/libcsupport/src/malloc_dirtier.c
>>  - cpukit/libcsupport/src/malloc_walk.c
>> diff --git a/testsuites/libtests/malloctest/init.c
>> b/testsuites/libtests/malloctest/init.c
>> index a33764177d..38f5554440 100644
>> --- a/testsuites/libtests/malloctest/init.c
>> +++ b/testsuites/libtests/malloctest/init.c
>> @@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
>>rtems_test_assert( p == NULL );
>>rtems_test_assert( errno == -1 );
>>  }
>> +static void test_usablesize(void)
>> +{
>> +  int * a = malloc(sizeof( int )*100);
>> +  int alloc_size=sizeof( int ) *

Re: [PATCH] added malloc usable size and test

2022-02-25 Thread zack leung
ping
*

On Sun, 20 Feb 2022 at 02:55, zack leung  wrote:

> diff --git a/cpukit/include/rtems/libcsupport.h
> b/cpukit/include/rtems/libcsupport.h
> index f4be4cfc9a..ec385bb71a 100644
> --- a/cpukit/include/rtems/libcsupport.h
> +++ b/cpukit/include/rtems/libcsupport.h
> @@ -73,7 +73,10 @@ extern size_t malloc_free_space(void);
>   * Find amount of free heap remaining.
>   */
>  extern int malloc_info(Heap_Information_block *the_info);
> -
> +/**
> + * @brief Find the usable size of the block of memory.
> + */
> +extern size_t malloc_usable_size( void *ptr );
>  /*
>   *  Prototypes required to install newlib reentrancy user extension
>   */
> @@ -185,6 +188,7 @@ bool rtems_resource_snapshot_equal(
>   */
>  bool rtems_resource_snapshot_check(const rtems_resource_snapshot
> *snapshot);
>
> +
>  /** @} */
>
>  #ifdef __cplusplus
> diff --git a/cpukit/libcsupport/src/mallocusablesize.c
> b/cpukit/libcsupport/src/mallocusablesize.c
> new file mode 100644
> index 00..d9211b1390
> --- /dev/null
> +++ b/cpukit/libcsupport/src/mallocusablesize.c
> @@ -0,0 +1,51 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2022 Zacchaeus Leung
> + *
> + * 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.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +size_t malloc_usable_size(void *ptr) {
> +  Heap_Control *heap_ptr ;
> +  size_t size;
> +  if (ptr == NULL) {
> +return 0;
> +  }
> +
> +
> +  heap_ptr = malloc_get_heap_pointer();
> +  bool rv=_Heap_Size_of_alloc_area(heap_ptr, ptr, );
> +  if( rv==false ){
> +return 0;
> +  }
> +
> +  return size;
> +}
> \ No newline at end of file
> diff --git a/spec/build/cpukit/librtemscpu.yml
> b/spec/build/cpukit/librtemscpu.yml
> index 7d6dbae0db..5902008c94 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -670,6 +670,7 @@ source:
>  - cpukit/libcsupport/src/lseek.c
>  - cpukit/libcsupport/src/lstat.c
>  - cpukit/libcsupport/src/malloc.c
> +- cpukit/libcsupport/src/mallocusablesize.c
>  - cpukit/libcsupport/src/malloc_deferred.c
>  - cpukit/libcsupport/src/malloc_dirtier.c
>  - cpukit/libcsupport/src/malloc_walk.c
> diff --git a/testsuites/libtests/malloctest/init.c
> b/testsuites/libtests/malloctest/init.c
> index a33764177d..38f5554440 100644
> --- a/testsuites/libtests/malloctest/init.c
> +++ b/testsuites/libtests/malloctest/init.c
> @@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
>rtems_test_assert( p == NULL );
>rtems_test_assert( errno == -1 );
>  }
> +static void test_usablesize(void)
> +{
> +  int * a = malloc(sizeof( int )*100);
> +  int alloc_size=sizeof( int ) *100 ;
> +  rtems_test_assert(  malloc_usable_size(a) <= alloc_size +
> CPU_HEAP_ALIGNMENT);
> +  free(a);
> +
> +  char * b = malloc(sizeof( char )* 100);
> +  int alloc_size2=sizeof( char ) * 100;
> +  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 +
> CPU_HEAP_ALIGNMENT);
> +  free(b);
> +}
>
>  rtems_task Init(
>rtems_task_argument argument
> @@ -1405,6 +1417,7 @@ rtems_task Init(
>test_protected_heap_info();
>test_rtems_heap_allocate_aligned_with_boundary();
>test_rtems_malloc();
> +  test_usablesize();
>test_rtems_calloc();
>test_greedy_allocate();
>test_alloc_zero_size();
> --
> 2.35.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH] added malloc usable size and test

2022-02-19 Thread zack leung
diff --git a/cpukit/include/rtems/libcsupport.h 
b/cpukit/include/rtems/libcsupport.h
index f4be4cfc9a..ec385bb71a 100644
--- a/cpukit/include/rtems/libcsupport.h
+++ b/cpukit/include/rtems/libcsupport.h
@@ -73,7 +73,10 @@ extern size_t malloc_free_space(void);
  * Find amount of free heap remaining.
  */
 extern int malloc_info(Heap_Information_block *the_info);
-
+/**
+ * @brief Find the usable size of the block of memory.
+ */
+extern size_t malloc_usable_size( void *ptr );
 /*
  *  Prototypes required to install newlib reentrancy user extension
  */
@@ -185,6 +188,7 @@ bool rtems_resource_snapshot_equal(
  */
 bool rtems_resource_snapshot_check(const rtems_resource_snapshot *snapshot);
 
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/libcsupport/src/mallocusablesize.c 
b/cpukit/libcsupport/src/mallocusablesize.c
new file mode 100644
index 00..d9211b1390
--- /dev/null
+++ b/cpukit/libcsupport/src/mallocusablesize.c
@@ -0,0 +1,51 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2022 Zacchaeus Leung
+ *
+ * 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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+ 
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+size_t malloc_usable_size(void *ptr) {
+  Heap_Control *heap_ptr ;
+  size_t size;
+  if (ptr == NULL) {
+return 0;
+  }
+
+  
+  heap_ptr = malloc_get_heap_pointer();
+  bool rv=_Heap_Size_of_alloc_area(heap_ptr, ptr, );
+  if( rv==false ){
+return 0;
+  }
+
+  return size;
+}
\ No newline at end of file
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 7d6dbae0db..5902008c94 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -670,6 +670,7 @@ source:
 - cpukit/libcsupport/src/lseek.c
 - cpukit/libcsupport/src/lstat.c
 - cpukit/libcsupport/src/malloc.c
+- cpukit/libcsupport/src/mallocusablesize.c 
 - cpukit/libcsupport/src/malloc_deferred.c
 - cpukit/libcsupport/src/malloc_dirtier.c
 - cpukit/libcsupport/src/malloc_walk.c
diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index a33764177d..38f5554440 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
   rtems_test_assert( p == NULL );
   rtems_test_assert( errno == -1 );
 }
+static void test_usablesize(void)
+{
+  int * a = malloc(sizeof( int )*100);
+  int alloc_size=sizeof( int ) *100 ;
+  rtems_test_assert(  malloc_usable_size(a) <= alloc_size + 
CPU_HEAP_ALIGNMENT);
+  free(a);
+
+  char * b = malloc(sizeof( char )* 100);
+  int alloc_size2=sizeof( char ) * 100; 
+  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 + 
CPU_HEAP_ALIGNMENT);
+  free(b);
+}
 
 rtems_task Init(
   rtems_task_argument argument
@@ -1405,6 +1417,7 @@ rtems_task Init(
   test_protected_heap_info();
   test_rtems_heap_allocate_aligned_with_boundary();
   test_rtems_malloc();
+  test_usablesize();
   test_rtems_calloc();
   test_greedy_allocate();
   test_alloc_zero_size();
-- 
2.35.1

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


[PATCH] added malloc usable size and test

2022-02-17 Thread zack leung
---
 cpukit/include/rtems/libcsupport.h|  5 ++-
 cpukit/libcsupport/src/mallocusablesize.c | 47 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 testsuites/libtests/malloctest/init.c | 13 +++
 4 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/libcsupport/src/mallocusablesize.c

diff --git a/cpukit/include/rtems/libcsupport.h 
b/cpukit/include/rtems/libcsupport.h
index f4be4cfc9a..5609c5bb94 100644
--- a/cpukit/include/rtems/libcsupport.h
+++ b/cpukit/include/rtems/libcsupport.h
@@ -73,7 +73,10 @@ extern size_t malloc_free_space(void);
  * Find amount of free heap remaining.
  */
 extern int malloc_info(Heap_Information_block *the_info);
-
+/**
+ * @brief Find the usable size of the block of memory .
+ */
+extern size_t malloc_usable_size(void *ptr);
 /*
  *  Prototypes required to install newlib reentrancy user extension
  */
diff --git a/cpukit/libcsupport/src/mallocusablesize.c 
b/cpukit/libcsupport/src/mallocusablesize.c
new file mode 100644
index 00..8a8d6467ad
--- /dev/null
+++ b/cpukit/libcsupport/src/mallocusablesize.c
@@ -0,0 +1,47 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) ,  
+ *
+ * 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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+ 
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+size_t malloc_usable_size(void *ptr) {
+  Heap_Control *heap_ptr ;
+  size_t size;
+  if (ptr == NULL) {
+return 0;
+  }
+  
+  heap_ptr = malloc_get_heap_pointer();
+  _Heap_Size_of_alloc_area(heap_ptr, ptr, );
+
+  return size;
+}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 7d6dbae0db..5902008c94 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -670,6 +670,7 @@ source:
 - cpukit/libcsupport/src/lseek.c
 - cpukit/libcsupport/src/lstat.c
 - cpukit/libcsupport/src/malloc.c
+- cpukit/libcsupport/src/mallocusablesize.c 
 - cpukit/libcsupport/src/malloc_deferred.c
 - cpukit/libcsupport/src/malloc_dirtier.c
 - cpukit/libcsupport/src/malloc_walk.c
diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index a33764177d..ee6a670372 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
   rtems_test_assert( p == NULL );
   rtems_test_assert( errno == -1 );
 }
+static void test_usablesize(void)
+{
+  int * a = malloc(sizeof( int )*100);
+  int alloc_size=sizeof( int ) *100 ;
+  rtems_test_assert(  malloc_usable_size(a) <= alloc_size + 
CPU_HEAP_ALIGNMENT);
+  free(a);
+
+  char * b = malloc(sizeof(char)*100);
+  int alloc_size2=sizeof(char) *100 ; 
+  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 + 
CPU_HEAP_ALIGNMENT);
+  free(b);
+}
 
 rtems_task Init(
   rtems_task_argument argument
@@ -1405,6 +1417,7 @@ rtems_task Init(
   test_protected_heap_info();
   test_rtems_heap_allocate_aligned_with_boundary();
   test_rtems_malloc();
+  test_usablesize();
   test_rtems_calloc();
   test_greedy_allocate();
   test_alloc_zero_size();
-- 
2.35.1

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


[PATCH] added malloc usable size and test

2022-02-13 Thread zack leung
---
 cpukit/include/rtems/libcsupport.h|  8 ++-
 cpukit/libcsupport/src/mallocusablesize.c | 28 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 testsuites/libtests/malloctest/init.c | 15 +++-
 4 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 cpukit/libcsupport/src/mallocusablesize.c

diff --git a/cpukit/include/rtems/libcsupport.h 
b/cpukit/include/rtems/libcsupport.h
index f4be4cfc9a..1fe0f6735f 100644
--- a/cpukit/include/rtems/libcsupport.h
+++ b/cpukit/include/rtems/libcsupport.h
@@ -73,7 +73,12 @@ extern size_t malloc_free_space(void);
  * Find amount of free heap remaining.
  */
 extern int malloc_info(Heap_Information_block *the_info);
-
+/**
+ * @brief Get malloc status information.
+ * 
+ * Find the usable size of the block of memory .
+ */
+extern size_t malloc_usable_size(void *ptr);
 /*
  *  Prototypes required to install newlib reentrancy user extension
  */
@@ -185,6 +190,7 @@ bool rtems_resource_snapshot_equal(
  */
 bool rtems_resource_snapshot_check(const rtems_resource_snapshot *snapshot);
 
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/libcsupport/src/mallocusablesize.c 
b/cpukit/libcsupport/src/mallocusablesize.c
new file mode 100644
index 00..10114182a6
--- /dev/null
+++ b/cpukit/libcsupport/src/mallocusablesize.c
@@ -0,0 +1,28 @@
+/*
+ *  COPYRIGHT (c) 1989-2010.
+ *  On-Line Applications Research Corporation (OAR).
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+Heap_Control *heap_ptr;
+size_t malloc_usable_size(void *ptr) {
+  uintptr_t size;
+  if (ptr == NULL) {
+return 0;
+  }
+  
+  heap_ptr = malloc_get_heap_pointer();
+  _Heap_Size_of_alloc_area(heap_ptr, ptr, );
+
+  return size;
+}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 7d6dbae0db..5902008c94 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -670,6 +670,7 @@ source:
 - cpukit/libcsupport/src/lseek.c
 - cpukit/libcsupport/src/lstat.c
 - cpukit/libcsupport/src/malloc.c
+- cpukit/libcsupport/src/mallocusablesize.c 
 - cpukit/libcsupport/src/malloc_deferred.c
 - cpukit/libcsupport/src/malloc_dirtier.c
 - cpukit/libcsupport/src/malloc_walk.c
diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index a33764177d..2202546719 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
   rtems_test_assert( p == NULL );
   rtems_test_assert( errno == -1 );
 }
+static void test_usablesize(void)
+{
+  int * a = malloc(sizeof( int )*100);
+  int alloc_size=sizeof( int ) *100 ;
+  rtems_test_assert(  malloc_usable_size(a) <= alloc_size + 
CPU_HEAP_ALIGNMENT);
+  free(a);
+
+  char * b = malloc(sizeof(char)*100);
+  int alloc_size2=sizeof(char) *100 ; 
+  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 + 
CPU_HEAP_ALIGNMENT);
+  free(b);
+}
 
 rtems_task Init(
   rtems_task_argument argument
@@ -1405,6 +1417,7 @@ rtems_task Init(
   test_protected_heap_info();
   test_rtems_heap_allocate_aligned_with_boundary();
   test_rtems_malloc();
+  test_usablesize();
   test_rtems_calloc();
   test_greedy_allocate();
   test_alloc_zero_size();
@@ -1524,4 +1537,4 @@ RTEMS_SYSINIT_ITEM(
   test_early_malloc,
   RTEMS_SYSINIT_INITIAL_EXTENSIONS,
   RTEMS_SYSINIT_ORDER_FIRST
-);
+);
\ No newline at end of file
-- 
2.35.1

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


Re: Malloc tests

2022-01-13 Thread zack leung
There a way to get the same values used to make the calculation  in malloc
get usable size?
Bump

Il ven 7 gen 2022, 21:25 zack leung  ha scritto:

> I think that the malloc tests is calculated differently than  alloc_size+
> allocsize mod it looks like this
>  *alloc_size = (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
> when i run the comparison  i get 8 (with heap alignment) and the function
> gives me 12.
>  is the heap alloc bonus part of the current block?
>
> On Thu, 6 Jan 2022 at 21:28, Joel Sherrill  wrote:
>
>> On Thu, Jan 6, 2022 at 2:55 PM Gedare Bloom  wrote:
>> >
>> > On Tue, Jan 4, 2022 at 6:10 PM zack leung 
>> wrote:
>> > >
>> > > Helllo  ,
>> > > I'm working on a patch for malloc_get_usable size right now so far i
>> have
>> > > this test case for malloc, I just make sure that the value is null
>> and i
>> > > just malloc an int and then  i make a call to the function
>> malloc_usable
>> > > size and then i compare it like this.
>> > >
>> > > static void test_malloc_usablesize( void ){
>> > >int * a = malloc(sizeof(int));
>> > >rtems_test_assert((int) malloc_usable_size(a) == 12);
>> > >free (a);
>> > >
>> > >int * b = NULL;
>> > >rtems_test_assert( 0 == malloc_usable_size(b));
>> > >free(b);
>> > >
>> > >
>> > > }
>> > > Is there a good amount of storage to allocate? Also I heard someone
>> made a
>> >
>> > I think that this test case is quite brittle. The "usable size" will
>> > depend on the implementation details of malloc, and the conditions of
>> > the heap when the allocation request gets made. I don't have better
>> > ideas however for how to test the correctness of the usable_size
>> > function. Maybe there are certain sequences of malloc/free calls that
>> > can be relied upon to give you deterministic sizes of allocations?
>>
>> My suggestion in private chat was that you can depend on the
>> malloc heap being initialized with CPU_HEAP_ALIGNMENT. That's
>> what that macro is specifically for. It is used in
>> include/rtems/score/wkspaceinit*.h
>> and has been since the dawn of time.
>>
>> Then the size for a valid pointer from malloc() should be between
>> the allocated size and the next number on a CPU_HEAP_ALIGNMENT
>> boundary. I think the exact number is actually something like this:
>>
>> expected = alloc_size;
>> mod = alloc_size % CPU_HEAP_ALIGMENT;
>> expected += mod;
>>
>> Adding a helper function in the test to compute the expected
>> size allocated and validate the return may be wise if multiple
>> size allocations are going to be tested.
>>
>>
>> > > formatter for rtems source files.  Can someone tell me how to use it
>> and if
>> > > it is on the main branch?
>> >
>> > This was part of a gsoc project last year. We haven't quite made the
>> > switch over to it and the associated coding style I think, but you can
>> > find the code via
>> >
>> https://devel.rtems.org/wiki/GSoC/2021#StudentsSummerofCodeTrackingTable
>> > the student was Meh Mbeh Ida Delphine
>> >
>> >
>> > > ___
>> > > 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: Malloc tests

2022-01-07 Thread zack leung
I think that the malloc tests is calculated differently than  alloc_size+
allocsize mod it looks like this
 *alloc_size = (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
when i run the comparison  i get 8 (with heap alignment) and the function
gives me 12.
 is the heap alloc bonus part of the current block?

On Thu, 6 Jan 2022 at 21:28, Joel Sherrill  wrote:

> On Thu, Jan 6, 2022 at 2:55 PM Gedare Bloom  wrote:
> >
> > On Tue, Jan 4, 2022 at 6:10 PM zack leung 
> wrote:
> > >
> > > Helllo  ,
> > > I'm working on a patch for malloc_get_usable size right now so far i
> have
> > > this test case for malloc, I just make sure that the value is null and
> i
> > > just malloc an int and then  i make a call to the function
> malloc_usable
> > > size and then i compare it like this.
> > >
> > > static void test_malloc_usablesize( void ){
> > >int * a = malloc(sizeof(int));
> > >rtems_test_assert((int) malloc_usable_size(a) == 12);
> > >free (a);
> > >
> > >int * b = NULL;
> > >rtems_test_assert( 0 == malloc_usable_size(b));
> > >free(b);
> > >
> > >
> > > }
> > > Is there a good amount of storage to allocate? Also I heard someone
> made a
> >
> > I think that this test case is quite brittle. The "usable size" will
> > depend on the implementation details of malloc, and the conditions of
> > the heap when the allocation request gets made. I don't have better
> > ideas however for how to test the correctness of the usable_size
> > function. Maybe there are certain sequences of malloc/free calls that
> > can be relied upon to give you deterministic sizes of allocations?
>
> My suggestion in private chat was that you can depend on the
> malloc heap being initialized with CPU_HEAP_ALIGNMENT. That's
> what that macro is specifically for. It is used in
> include/rtems/score/wkspaceinit*.h
> and has been since the dawn of time.
>
> Then the size for a valid pointer from malloc() should be between
> the allocated size and the next number on a CPU_HEAP_ALIGNMENT
> boundary. I think the exact number is actually something like this:
>
> expected = alloc_size;
> mod = alloc_size % CPU_HEAP_ALIGMENT;
> expected += mod;
>
> Adding a helper function in the test to compute the expected
> size allocated and validate the return may be wise if multiple
> size allocations are going to be tested.
>
>
> > > formatter for rtems source files.  Can someone tell me how to use it
> and if
> > > it is on the main branch?
> >
> > This was part of a gsoc project last year. We haven't quite made the
> > switch over to it and the associated coding style I think, but you can
> > find the code via
> > https://devel.rtems.org/wiki/GSoC/2021#StudentsSummerofCodeTrackingTable
> > the student was Meh Mbeh Ida Delphine
> >
> >
> > > ___
> > > 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


Malloc tests

2022-01-04 Thread zack leung
Helllo  ,
I'm working on a patch for malloc_get_usable size right now so far i have
this test case for malloc, I just make sure that the value is null and i
just malloc an int and then  i make a call to the function malloc_usable
size and then i compare it like this.

static void test_malloc_usablesize( void ){
   int * a = malloc(sizeof(int));
   rtems_test_assert((int) malloc_usable_size(a) == 12);
   free (a);

   int * b = NULL;
   rtems_test_assert( 0 == malloc_usable_size(b));
   free(b);


}
Is there a good amount of storage to allocate? Also I heard someone made a
formatter for rtems source files.  Can someone tell me how to use it and if
it is on the main branch?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: New validation test suites

2021-12-13 Thread zack leung
What tasks can I do that can help with ECSS compliance?

Zack

On Mon, 13 Dec 2021 at 21:40, Chris Johns  wrote:

> On 14/12/21 1:53 am, Sebastian Huber wrote:
> > Hello,
> >
> > the ESA activity to pre-qualify parts of RTEMS according to ECSS
> requirements is
> > nearly complete. There is a short presentation available here:
> >
> > https://indico.esa.int/event/374/timetable/
>
> Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained?
> > We finished the specification of the pre-qualified RTEMS feature set. The
> > specification is available in an RTEMS Project repository:
> >
> > https://git.rtems.org/rtems-central/tree/spec
>
> I had a quick look. Is there a more user friendly view of this data?
>
> I think the term "specification" is a little bit misleading because the
> data
> files are not easily read by a person. I understand this is the
> specification
> data set however it is not what I am traditionally use to seeing.
>
> > The validation tests are generated from the specification using the
> > "./spec2modules.py" script and end up in the RTEMS sources of a Git
> submodule. I
> > think the specification and the generation tool is now sufficiently
> stable so
> > that the validation test code can be integrated in the RTEMS master
> branch. The
> > patch set is too big for the mailing list, so you can review it here:
> >
> > https://git.rtems.org/sebh/rtems.git/log/?h=validation
>
> The link failed.
>
> > https://github.com/sebhub/rtems/tree/validation
>
> The header in a test says the regeneration instructions are in the
> engineering
> manual but I could not quickly find them?
>
> > The patch set is organized so that general support code for the
> validation tests
> > is added first and then there are commits for each pre-qualified Classic
> API
> > Manager or subsystem.
> >
> > I did build all BSPs with the patch set. The validation tests use only
> > statically allocated resources.
>
> Are the validation tests compatible with rtems-test?
>
> How many test executables does this add to the testsuite?
>
> What hardware have the validation tests been run on? Any tier 1 archs?
>
> Is there anything that interprets the new test output format? It looks
> like lots
> of great info but a little difficult to read.
>
> > Some low memory targets are not able to link all test suites.
>
> Are these excluded in the normal way?
>
> 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: Ticket 4429

2021-11-18 Thread zack leung
bump

On Mon, 18 Oct 2021 at 23:47, zack leung  wrote:

> bump
>
>
> On Wed, 6 Oct 2021 at 00:30, zack leung  wrote:
>
>> For relative times, the clock identifier is not used to select the clock
>> and instead always the CLOCK_MONOTONIC is used. A side-effect is that
>> sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of
>> CLOCK_REALTIME).
>>
>> I don't understand how the monotonic clock is not being used. I know that
>> if it's not a realtime clock then
>> Thread_queue_Context_set_enqueue_timeout_monotonic_timespec is called and i
>> believe that all the appropriate branches are there to make the monotonic
>> clock work.
>>
>> Zack
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Ticket 4503

2021-11-18 Thread zack leung
bump

On Mon, 18 Oct 2021 at 23:58, zack leung  wrote:

> bump
>
>
> On Sat, 25 Sept 2021 at 00:26, zack leung 
> wrote:
>
>> bump
>>
>> On Thu, 9 Sept 2021 at 02:17, zack leung 
>> wrote:
>>
>>> >Thanks! I guess i'm really unsure about how the pointer relates to the
>>> amount of memory that you can use. I assume the Malloc keeps track of the
>>> sections being used in the heap. Does this function Allocate 2 blocks since
>>> the pointer is set to
>>>
>>> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
>>>
>>> >(I know it's a bit naive to assume this given my first question)
>>>
>>> think the method is _Heap_Size_of_alloc_area. It may need a wrapper
>>> added to the protected heap wrapper for safety. I don't know if it has one.
>>> It should be the equivalent functionality.
>>> > How would i implement a wrapper and what safety measures need to be
>>> implemented. So far it's checking if :  the block is not in the heap and if
>>> it's been previously used. Is the usable memory in the heap calculated by:
>>> the size of the block * # of blocks?
>>>
>>> Thanks, Zack
>>>
>>> -- Forwarded message -
>>> From: Joel Sherrill 
>>> Date: Wed, 8 Sept 2021 at 20:30
>>> Subject: Re: Ticket 4503
>>> To: Gedare Bloom 
>>> Cc: zack leung , rtems-de...@rtems.org <
>>> devel@rtems.org>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:
>>>
>>>> Hi Zack,
>>>>
>>>> https://devel.rtems.org/ticket/4503
>>>>
>>>> The malloc implementation exists in the score as the Heap Manager.
>>>> search for "Heap_" within cpukit to get some ideas where to look.
>>>>
>>>
>>> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper
>>> added to the protected heap wrapper for safety. I don't know if it has one.
>>> It should be the equivalent functionality.
>>>
>>> newlib's malloc.h will need looking at to make sure we provide the right
>>> methods.
>>>
>>>
>>>
>>>>
>>>> @Joel are these two tickets duplicates?
>>>> https://devel.rtems.org/ticket/4503
>>>> https://devel.rtems.org/ticket/4271
>>>>
>>>
>>> Yes. Closed #4271 and merged comments.
>>>
>>> --joel
>>>
>>>
>>>>
>>>>
>>>> -Gedare
>>>>
>>>> On Tue, Sep 7, 2021 at 7:14 PM zack leung 
>>>> wrote:
>>>>
>>>>> I was wondering about ticket 4503. I was wondering where The required
>>>>> functionality should be in the underlying score/ capability used can be
>>>>> found to write this function. Also how does this relate  to
>>>>>
>>>>> Add common malloc family extension method malloc_usable_size()
>>>>> <https://devel.rtems.org/ticket/4271>?
>>>>> Thanks
>>>>> Zack
>>>>> ___
>>>>> 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] fix memory leak within calloc.c libtests

2021-11-01 Thread zack leung
bump


On Mon, 18 Oct 2021 at 23:46, zack leung  wrote:

> fix came from github code inspector, flagged by one of the analysis that
> was done
> ---
>  testsuites/libtests/POSIX/calloc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/testsuites/libtests/POSIX/calloc.c
> b/testsuites/libtests/POSIX/calloc.c
> index bd04faa800..a7537c8cc4 100644
> --- a/testsuites/libtests/POSIX/calloc.c
> +++ b/testsuites/libtests/POSIX/calloc.c
> @@ -16,6 +16,8 @@ int
>  main (void)
>  {
>void *foo = calloc (42, 43);
> +  int rc = (foo != NULL);
> +  free(foo);
>
> -  return (foo != NULL);
> +  return rc;
>  }
> --
> 2.33.0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Ticket 4503

2021-10-18 Thread zack leung
bump


On Sat, 25 Sept 2021 at 00:26, zack leung  wrote:

> bump
>
> On Thu, 9 Sept 2021 at 02:17, zack leung  wrote:
>
>> >Thanks! I guess i'm really unsure about how the pointer relates to the
>> amount of memory that you can use. I assume the Malloc keeps track of the
>> sections being used in the heap. Does this function Allocate 2 blocks since
>> the pointer is set to
>>
>> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
>>
>> >(I know it's a bit naive to assume this given my first question)
>>
>> think the method is _Heap_Size_of_alloc_area. It may need a wrapper added
>> to the protected heap wrapper for safety. I don't know if it has one. It
>> should be the equivalent functionality.
>> > How would i implement a wrapper and what safety measures need to be
>> implemented. So far it's checking if :  the block is not in the heap and if
>> it's been previously used. Is the usable memory in the heap calculated by:
>> the size of the block * # of blocks?
>>
>> Thanks, Zack
>>
>> -- Forwarded message -
>> From: Joel Sherrill 
>> Date: Wed, 8 Sept 2021 at 20:30
>> Subject: Re: Ticket 4503
>> To: Gedare Bloom 
>> Cc: zack leung , rtems-de...@rtems.org <
>> devel@rtems.org>
>>
>>
>>
>>
>> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:
>>
>>> Hi Zack,
>>>
>>> https://devel.rtems.org/ticket/4503
>>>
>>> The malloc implementation exists in the score as the Heap Manager.
>>> search for "Heap_" within cpukit to get some ideas where to look.
>>>
>>
>> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper
>> added to the protected heap wrapper for safety. I don't know if it has one.
>> It should be the equivalent functionality.
>>
>> newlib's malloc.h will need looking at to make sure we provide the right
>> methods.
>>
>>
>>
>>>
>>> @Joel are these two tickets duplicates?
>>> https://devel.rtems.org/ticket/4503
>>> https://devel.rtems.org/ticket/4271
>>>
>>
>> Yes. Closed #4271 and merged comments.
>>
>> --joel
>>
>>
>>>
>>>
>>> -Gedare
>>>
>>> On Tue, Sep 7, 2021 at 7:14 PM zack leung 
>>> wrote:
>>>
>>>> I was wondering about ticket 4503. I was wondering where The required
>>>> functionality should be in the underlying score/ capability used can be
>>>> found to write this function. Also how does this relate  to
>>>>
>>>> Add common malloc family extension method malloc_usable_size()
>>>> <https://devel.rtems.org/ticket/4271>?
>>>> Thanks
>>>> Zack
>>>> ___
>>>> 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: Ticket 4429

2021-10-18 Thread zack leung
bump


On Wed, 6 Oct 2021 at 00:30, zack leung  wrote:

> For relative times, the clock identifier is not used to select the clock
> and instead always the CLOCK_MONOTONIC is used. A side-effect is that
> sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of
> CLOCK_REALTIME).
>
> I don't understand how the monotonic clock is not being used. I know that
> if it's not a realtime clock then
> Thread_queue_Context_set_enqueue_timeout_monotonic_timespec is called and i
> believe that all the appropriate branches are there to make the monotonic
> clock work.
>
> Zack
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH] fix memory leak within calloc.c libtests

2021-10-18 Thread zack leung
fix came from github code inspector, flagged by one of the analysis that
was done
---
 testsuites/libtests/POSIX/calloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/POSIX/calloc.c
b/testsuites/libtests/POSIX/calloc.c
index bd04faa800..a7537c8cc4 100644
--- a/testsuites/libtests/POSIX/calloc.c
+++ b/testsuites/libtests/POSIX/calloc.c
@@ -16,6 +16,8 @@ int
 main (void)
 {
   void *foo = calloc (42, 43);
+  int rc = (foo != NULL);
+  free(foo);

-  return (foo != NULL);
+  return rc;
 }
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Ticket 4429

2021-10-05 Thread zack leung
For relative times, the clock identifier is not used to select the clock
and instead always the CLOCK_MONOTONIC is used. A side-effect is that
sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of
CLOCK_REALTIME).

I don't understand how the monotonic clock is not being used. I know that
if it's not a realtime clock then
Thread_queue_Context_set_enqueue_timeout_monotonic_timespec is called and i
believe that all the appropriate branches are there to make the monotonic
clock work.

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


Re: Ticket 4503

2021-09-24 Thread zack leung
bump

On Thu, 9 Sept 2021 at 02:17, zack leung  wrote:

> >Thanks! I guess i'm really unsure about how the pointer relates to the
> amount of memory that you can use. I assume the Malloc keeps track of the
> sections being used in the heap. Does this function Allocate 2 blocks since
> the pointer is set to
>
> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
>
> >(I know it's a bit naive to assume this given my first question)
>
> think the method is _Heap_Size_of_alloc_area. It may need a wrapper added
> to the protected heap wrapper for safety. I don't know if it has one. It
> should be the equivalent functionality.
> > How would i implement a wrapper and what safety measures need to be
> implemented. So far it's checking if :  the block is not in the heap and if
> it's been previously used. Is the usable memory in the heap calculated by:
> the size of the block * # of blocks?
>
> Thanks, Zack
>
> -- Forwarded message -
> From: Joel Sherrill 
> Date: Wed, 8 Sept 2021 at 20:30
> Subject: Re: Ticket 4503
> To: Gedare Bloom 
> Cc: zack leung , rtems-de...@rtems.org <
> devel@rtems.org>
>
>
>
>
> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:
>
>> Hi Zack,
>>
>> https://devel.rtems.org/ticket/4503
>>
>> The malloc implementation exists in the score as the Heap Manager. search
>> for "Heap_" within cpukit to get some ideas where to look.
>>
>
> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper
> added to the protected heap wrapper for safety. I don't know if it has one.
> It should be the equivalent functionality.
>
> newlib's malloc.h will need looking at to make sure we provide the right
> methods.
>
>
>
>>
>> @Joel are these two tickets duplicates?
>> https://devel.rtems.org/ticket/4503
>> https://devel.rtems.org/ticket/4271
>>
>
> Yes. Closed #4271 and merged comments.
>
> --joel
>
>
>>
>>
>> -Gedare
>>
>> On Tue, Sep 7, 2021 at 7:14 PM zack leung 
>> wrote:
>>
>>> I was wondering about ticket 4503. I was wondering where The required
>>> functionality should be in the underlying score/ capability used can be
>>> found to write this function. Also how does this relate  to
>>>
>>> Add common malloc family extension method malloc_usable_size()
>>> <https://devel.rtems.org/ticket/4271>?
>>> Thanks
>>> Zack
>>> ___
>>> 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: [PATCHv5] improve the format error reporting on i386

2021-09-24 Thread zack leung
bump


On Thu, 23 Sept 2021 at 00:21, zack leung  wrote:

> I can send an example of the exception if you want.
>
> zack
>
> On Wed, 22 Sept 2021 at 18:01, Gedare Bloom  wrote:
>
>> Joel,
>>
>> This looks good to me. I don't know if you can easily test it?
>>
>> Gedare
>>
>> On Wed, Sep 22, 2021 at 11:26 AM zack leung 
>> wrote:
>> >
>> > ll hex values now have 8 character width
>> > thread id is now hex
>> > updates #4203
>> > ---
>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> > index 77b7a7161c..786cf8b0b6 100644
>> > --- a/cpukit/score/cpu/i386/cpu.c
>> > +++ b/cpukit/score/cpu/i386/cpu.c
>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>> > CPU_Exception_frame *ctx)
>> >  {
>> >unsigned int faultAddr = 0;
>> >
>> printk("--\n");
>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > PRId32 "\n",
>> > +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread
>> 0x%08"
>> > PRIx32 "\n",
>> >   ctx->idtIndex,
>> >   ctx->eip,
>> >   _Thread_Executing->Object.id);
>> >
>> printk("--\n");
>> >printk("Processor execution context at time of the fault was  :\n");
>> >
>> printk("--\n");
>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>> > EDX = %" PRIx32 "\n",
>> > +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
>> > 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>> > ESP = %" PRIx32 "\n",
>> > +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
>> > 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>> >
>> printk("--\n");
>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>> > "\n",
>> > --
>> > 2.33.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: [PATCHv5] improve the format error reporting on i386

2021-09-22 Thread zack leung
I can send an example of the exception if you want.

zack

On Wed, 22 Sept 2021 at 18:01, Gedare Bloom  wrote:

> Joel,
>
> This looks good to me. I don't know if you can easily test it?
>
> Gedare
>
> On Wed, Sep 22, 2021 at 11:26 AM zack leung 
> wrote:
> >
> > ll hex values now have 8 character width
> > thread id is now hex
> > updates #4203
> > ---
> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > index 77b7a7161c..786cf8b0b6 100644
> > --- a/cpukit/score/cpu/i386/cpu.c
> > +++ b/cpukit/score/cpu/i386/cpu.c
> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> > CPU_Exception_frame *ctx)
> >  {
> >unsigned int faultAddr = 0;
> >
> printk("--\n");
> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRId32 "\n",
> > +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread
> 0x%08"
> > PRIx32 "\n",
> >   ctx->idtIndex,
> >   ctx->eip,
> >   _Thread_Executing->Object.id);
> >
> printk("--\n");
> >printk("Processor execution context at time of the fault was  :\n");
> >
> printk("--\n");
> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> > EDX = %" PRIx32 "\n",
> > +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
> > 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> > ESP = %" PRIx32 "\n",
> > +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
> > 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
> >
> printk("--\n");
> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> > "\n",
> > --
> > 2.33.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


[PATCHv5] improve the format error reporting on i386

2021-09-22 Thread zack leung
ll hex values now have 8 character width
thread id is now hex
updates #4203
---
 cpukit/score/cpu/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..786cf8b0b6 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
 {
   unsigned int faultAddr = 0;
   printk("--\n");
-  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread 0x%08"
PRIx32 "\n",
  ctx->idtIndex,
  ctx->eip,
  _Thread_Executing->Object.id);
   printk("--\n");
   printk("Processor execution context at time of the fault was  :\n");
   printk("--\n");
-  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
EDX = %" PRIx32 "\n",
+  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
-  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
ESP = %" PRIx32 "\n",
+  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
   printk("--\n");
   printk("Error code pushed by processor itself (if not 0) = %" PRIx32
"\n",
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCHv5] improve the format error reporting on i386

2021-09-21 Thread zack leung
all hex values now have 8 character width
thread id is now hex
---
 cpukit/score/cpu/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..786cf8b0b6 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
 {
   unsigned int faultAddr = 0;
   printk("--\n");
-  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRIx32 "\n",
  ctx->idtIndex,
  ctx->eip,
  _Thread_Executing->Object.id);
   printk("--\n");
   printk("Processor execution context at time of the fault was  :\n");
   printk("--\n");
-  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
EDX = %" PRIx32 "\n",
+  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
-  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
ESP = %" PRIx32 "\n",
+  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
   printk("--\n");
   printk("Error code pushed by processor itself (if not 0) = %" PRIx32
"\n",
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v4] improve the format of error reporting on i386

2021-09-20 Thread zack leung
  printk(" EAX = 0%08" PRIx32 "EBX = 0%08" PRIx32 "ECX = 0%08"
PRIx32 "EDX = 0%08" PRIx32 "\n",
should it look like this gedare? will send once you give the ok



On Sun, 19 Sept 2021 at 17:42, zack leung  wrote:

> Bumo
>
> Il ven 17 set 2021, 19:57 zack leung  ha
> scritto:
>
>> Where am i missing it?
>>
>> Zack
>>
>> On Fri, 17 Sept 2021 at 23:15, Gedare Bloom  wrote:
>>
>>> Hi Zack,
>>>
>>> I think you have also missed Joel's request to add an 8-character
>>> width specifier.
>>>
>>> On Thu, Sep 16, 2021 at 6:19 PM zack leung 
>>> wrote:
>>> >
>>> > Thread id is now a Hex value. formatting improved for hex values
>>> > Updates #4203
>>> > ---
>>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
>>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>>> > index 77b7a7161c..0f17cf0148 100644
>>> > --- a/cpukit/score/cpu/i386/cpu.c
>>> > +++ b/cpukit/score/cpu/i386/cpu.c
>>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>>> > CPU_Exception_frame *ctx)
>>> >  {
>>> >unsigned int faultAddr = 0;
>>> >
>>> printk("--\n");
>>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>>> > PRId32 "\n",
>>> > +  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread
>>> 0x%"
>>> > PRIx32 "\n",
>>> >   ctx->idtIndex,
>>> >   ctx->eip,
>>> >   _Thread_Executing->Object.id);
>>> >
>>> printk("--\n");
>>> >printk("Processor execution context at time of the fault was  :\n");
>>> >
>>> printk("--\n");
>>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>>> > EDX = %" PRIx32 "\n",
>>> > +  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%"
>>> PRIx32
>>> > "EDX = 0x%" PRIx32 "\n",
>>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>>> > ESP = %" PRIx32 "\n",
>>> > +  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%"
>>> PRIx32
>>> > "ESP = 0x%" PRIx32 "\n",
>>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>>> >
>>> printk("--\n");
>>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>>> > "\n",
>>> > --
>>> > 2.33.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 v4] improve the format of error reporting on i386

2021-09-19 Thread zack leung
Bumo

Il ven 17 set 2021, 19:57 zack leung  ha scritto:

> Where am i missing it?
>
> Zack
>
> On Fri, 17 Sept 2021 at 23:15, Gedare Bloom  wrote:
>
>> Hi Zack,
>>
>> I think you have also missed Joel's request to add an 8-character
>> width specifier.
>>
>> On Thu, Sep 16, 2021 at 6:19 PM zack leung 
>> wrote:
>> >
>> > Thread id is now a Hex value. formatting improved for hex values
>> > Updates #4203
>> > ---
>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> > index 77b7a7161c..0f17cf0148 100644
>> > --- a/cpukit/score/cpu/i386/cpu.c
>> > +++ b/cpukit/score/cpu/i386/cpu.c
>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>> > CPU_Exception_frame *ctx)
>> >  {
>> >unsigned int faultAddr = 0;
>> >
>> printk("--\n");
>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > PRId32 "\n",
>> > +  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread
>> 0x%"
>> > PRIx32 "\n",
>> >   ctx->idtIndex,
>> >   ctx->eip,
>> >   _Thread_Executing->Object.id);
>> >
>> printk("--\n");
>> >printk("Processor execution context at time of the fault was  :\n");
>> >
>> printk("--\n");
>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>> > EDX = %" PRIx32 "\n",
>> > +  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%"
>> PRIx32
>> > "EDX = 0x%" PRIx32 "\n",
>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>> > ESP = %" PRIx32 "\n",
>> > +  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%"
>> PRIx32
>> > "ESP = 0x%" PRIx32 "\n",
>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>> >
>> printk("--\n");
>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>> > "\n",
>> > --
>> > 2.33.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 v4] improve the format of error reporting on i386

2021-09-17 Thread zack leung
Where am i missing it?

Zack

On Fri, 17 Sept 2021 at 23:15, Gedare Bloom  wrote:

> Hi Zack,
>
> I think you have also missed Joel's request to add an 8-character
> width specifier.
>
> On Thu, Sep 16, 2021 at 6:19 PM zack leung 
> wrote:
> >
> > Thread id is now a Hex value. formatting improved for hex values
> > Updates #4203
> > ---
> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > index 77b7a7161c..0f17cf0148 100644
> > --- a/cpukit/score/cpu/i386/cpu.c
> > +++ b/cpukit/score/cpu/i386/cpu.c
> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> > CPU_Exception_frame *ctx)
> >  {
> >unsigned int faultAddr = 0;
> >
> printk("--\n");
> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRId32 "\n",
> > +  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread
> 0x%"
> > PRIx32 "\n",
> >   ctx->idtIndex,
> >   ctx->eip,
> >   _Thread_Executing->Object.id);
> >
> printk("--\n");
> >printk("Processor execution context at time of the fault was  :\n");
> >
> printk("--\n");
> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> > EDX = %" PRIx32 "\n",
> > +  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%"
> PRIx32
> > "EDX = 0x%" PRIx32 "\n",
> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> > ESP = %" PRIx32 "\n",
> > +  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%"
> PRIx32
> > "ESP = 0x%" PRIx32 "\n",
> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
> >
> printk("--\n");
> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> > "\n",
> > --
> > 2.33.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


[PATCH v4] improve the format of error reporting on i386

2021-09-16 Thread zack leung
Thread id is now a Hex value. formatting improved for hex values
Updates #4203
---
 cpukit/score/cpu/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..0f17cf0148 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
 {
   unsigned int faultAddr = 0;
   printk("--\n");
-  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%"
PRIx32 "\n",
  ctx->idtIndex,
  ctx->eip,
  _Thread_Executing->Object.id);
   printk("--\n");
   printk("Processor execution context at time of the fault was  :\n");
   printk("--\n");
-  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
EDX = %" PRIx32 "\n",
+  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%" PRIx32
"EDX = 0x%" PRIx32 "\n",
  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
-  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
ESP = %" PRIx32 "\n",
+  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%" PRIx32
"ESP = 0x%" PRIx32 "\n",
  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
   printk("--\n");
   printk("Error code pushed by processor itself (if not 0) = %" PRIx32
"\n",
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v4] improve the format of error reporting on i386

2021-09-15 Thread zack leung
printk("--\n");
printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%"
PRIx32 "\n",
ctx->idtIndex,
ctx->eip,
_Thread_Executing->Object.id);
printk("--\n");
printk("Processor execution context at time of the fault was :\n");
printk("--\n");
printk(" EAX = %" PRIx32 " EBX = 0x%" PRIx32 " ECX = %" PRIx32 " EDX = %"
PRIx32 "\n",
ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
printk(" ESI = 0x%" PRIx32 " EDI = 0x%" PRIx32 " EBP = 0x%" PRIx32 " ESP =
0x%" PRIx32 "\n",
ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);


Before I send my patch here is what i'll change . So i can do this for
example format the hex values with 0x and
have the thread id as a hex value.

On Wed, 15 Sept 2021 at 15:18, Gedare Bloom  wrote:

> On Mon, Sep 13, 2021 at 6:10 PM zack leung 
> wrote:
> >
> > Gedare told me just to change the ID when I submitted the other I sent
> you
> > in discord. Sorry for things bouncing back and forth.
> >
>
> I said not to change the `type` of the register context variables from
> 32 to ptr. You can change their representation to hex that's fine by
> me, with the fixed width and 0x prepended.
>
> > On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
> >
> > > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
> > > wrote:
> > > >
> > > > Thread id is now a Hex value.
> > > > Updates #4203
> > > > ---
> > > > cpukit/score/cpu/i386/cpu.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/cpukit/score/cpu/i386/cpu.c
> b/cpukit/score/cpu/i386/cpu.c
> > > > index 77b7a7161c..06af57418d 100644
> > > > --- a/cpukit/score/cpu/i386/cpu.c
> > > > +++ b/cpukit/score/cpu/i386/cpu.c
> > > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > > > CPU_Exception_frame *ctx)
> > > > {
> > > > unsigned int faultAddr = 0;
> > > >
> printk("--\n");
> > > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > > PRId32 "\n",
> > > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > > PRIx32 "\n",
> > >
> > > PC and ID should use  PC 0x%08" PRIx32.
> > >
> > > Prefixing with 0x to indicate that the number is hexadecimal. Printing
> > > it with leading zero's and 8 digits wide helps since the address and
> > > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> > > 0x0a010004
> > >
> > > Does this patch have all your other changes? I've slept since seeing
> > > this time and thought there were changes..
> > >
> > > --joel
> > >
> > > > ctx->idtIndex,
> > > > ctx->eip,
> > > > _Thread_Executing->Object.id);
> > > > --
> > > > 2.33.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 v4] improve the format of error reporting on i386

2021-09-13 Thread zack leung
Gedare told me just to change the ID when I submitted the other I sent you
in discord. Sorry for things bouncing back and forth.

On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:

> On Sun, Sep 12, 2021 at 7:02 PM zack leung 
> wrote:
> >
> > Thread id is now a Hex value.
> > Updates #4203
> > ---
> > cpukit/score/cpu/i386/cpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > index 77b7a7161c..06af57418d 100644
> > --- a/cpukit/score/cpu/i386/cpu.c
> > +++ b/cpukit/score/cpu/i386/cpu.c
> > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > CPU_Exception_frame *ctx)
> > {
> > unsigned int faultAddr = 0;
> > printk("--\n");
> > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRId32 "\n",
> > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRIx32 "\n",
>
> PC and ID should use  PC 0x%08" PRIx32.
>
> Prefixing with 0x to indicate that the number is hexadecimal. Printing
> it with leading zero's and 8 digits wide helps since the address and
> thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> 0x0a010004
>
> Does this patch have all your other changes? I've slept since seeing
> this time and thought there were changes..
>
> --joel
>
> > ctx->idtIndex,
> > ctx->eip,
> > _Thread_Executing->Object.id);
> > --
> > 2.33.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


[PATCH v4] improve the format of error reporting on i386

2021-09-12 Thread zack leung
Thread id is now a Hex value.
Updates #4203
---
cpukit/score/cpu/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..06af57418d 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
{
unsigned int faultAddr = 0;
printk("--\n");
- printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+ printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRIx32 "\n",
ctx->idtIndex,
ctx->eip,
_Thread_Executing->Object.id);
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Subject: [PATCH] improve the format error reporting on i386

2021-09-10 Thread zack leung
Where are the duplicates been trying to fix the commit messages?

 Thanks zack
Il gio 9 set 2021, 22:30 Gedare Bloom  ha scritto:

> Hi Zack,
>
> It looks like something got a little messed up with your commit
> message. Please see if you can fix it to remove the duplication(s).
>
> On Thu, Sep 9, 2021 at 6:00 PM zack leung 
> wrote:
> >
> > score/i386: improve the format of exception reporting
> >
> > Updates #4203."Updates #4203."
> > ---
> > cpukit/score/cpu/i386/cpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > index 77b7a7161c..06af57418d 100644
> > --- a/cpukit/score/cpu/i386/cpu.c
> > +++ b/cpukit/score/cpu/i386/cpu.c
> > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
> > {
> > unsigned int faultAddr = 0;
> > printk("--\n");
> > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRIx32 "\n",
> > ctx->idtIndex,
> > ctx->eip,
> > _Thread_Executing->Object.id);
> > --
> > 2.33.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


Subject: [PATCH] improve the format error reporting on i386

2021-09-09 Thread zack leung
score/i386: improve the format of exception reporting

Updates #4203."Updates #4203."
---
cpukit/score/cpu/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..06af57418d 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
{
unsigned int faultAddr = 0;
printk("--\n");
- printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+ printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRIx32 "\n",
ctx->idtIndex,
ctx->eip,
_Thread_Executing->Object.id);
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ticket 4503

2021-09-08 Thread zack leung
>Thanks! I guess i'm really unsure about how the pointer relates to the
amount of memory that you can use. I assume the Malloc keeps track of the
sections being used in the heap. Does this function Allocate 2 blocks since
the pointer is set to

(uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;

>(I know it's a bit naive to assume this given my first question)

think the method is _Heap_Size_of_alloc_area. It may need a wrapper added
to the protected heap wrapper for safety. I don't know if it has one. It
should be the equivalent functionality.
> How would i implement a wrapper and what safety measures need to be
implemented. So far it's checking if :  the block is not in the heap and if
it's been previously used. Is the usable memory in the heap calculated by:
the size of the block * # of blocks?

Thanks, Zack

-- Forwarded message -
From: Joel Sherrill 
Date: Wed, 8 Sept 2021 at 20:30
Subject: Re: Ticket 4503
To: Gedare Bloom 
Cc: zack leung , rtems-de...@rtems.org <
devel@rtems.org>




On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:

> Hi Zack,
>
> https://devel.rtems.org/ticket/4503
>
> The malloc implementation exists in the score as the Heap Manager. search
> for "Heap_" within cpukit to get some ideas where to look.
>

I think the method is _Heap_Size_of_alloc_area. It may need a wrapper added
to the protected heap wrapper for safety. I don't know if it has one. It
should be the equivalent functionality.

newlib's malloc.h will need looking at to make sure we provide the right
methods.



>
> @Joel are these two tickets duplicates?
> https://devel.rtems.org/ticket/4503
> https://devel.rtems.org/ticket/4271
>

Yes. Closed #4271 and merged comments.

--joel


>
>
> -Gedare
>
> On Tue, Sep 7, 2021 at 7:14 PM zack leung 
> wrote:
>
>> I was wondering about ticket 4503. I was wondering where The required
>> functionality should be in the underlying score/ capability used can be
>> found to write this function. Also how does this relate  to
>>
>> Add common malloc family extension method malloc_usable_size()
>> <https://devel.rtems.org/ticket/4271>?
>> Thanks
>> Zack
>> ___
>> 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] improve the format of error reporting on i386

2021-09-08 Thread zack leung
Thread ID is now  a hex value part of ticket #4203


On Wed, 8 Sept 2021 at 23:58, Zacchaeus Leung 
wrote:

> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..06af57418d 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRIx32 "\n",
>  ctx->idtIndex,
>  ctx->eip,
>  _Thread_Executing->Object.id);
> --
> 2.33.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket 4503

2021-09-07 Thread zack leung
I was wondering about ticket 4503. I was wondering where The required
functionality should be in the underlying score/ capability used can be
found to write this function. Also how does this relate  to

Add common malloc family extension method malloc_usable_size()
?
Thanks
Zack
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improve the format error reporting on i386

2021-09-07 Thread zack leung
- thread id is printed as a hex value
- EBP ESP is now printed as a address pointer %p
- Program counter is printed as a pinter
Part of ticket #4203

On Wed, 8 Sept 2021 at 00:17, Zacchaeus Leung 
wrote:

> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..3c5b7db316 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC %p" " by thread 0x%" PRIx32
> "\n",
>  ctx->idtIndex,
>  ctx->eip,
>  _Thread_Executing->Object.id);
> @@ -224,7 +224,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>printk("--\n");
>printk(" EAX = %" PRIx32 "   EBX = %" PRIx32 "   ECX = %" PRIx32 "
>  EDX = %" PRIx32 "\n",
>  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %" PRIx32 "
>  ESP = %" PRIx32 "\n",
> +  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %p" "
>  ESP = %p" "\n",
>  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> "\n",
> @@ -250,7 +250,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
> printk("Call Stack Trace of EIP:\n");
> if ( fp ) {
> for ( i=1; fp->up; fp=fp->up, i++ ) {
> -   printk("0x%08" PRIx32 " ",fp->pc);
> +   printk("0x%08"PRIx32 " ",fp->pc);
> if ( ! (i&3) )
> printk("\n");
> }
> --
> 2.33.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ticket #4203 clarification

2021-09-03 Thread zack leung
Say i find an exception (ex format string printing a decimal.) How do I
test that my improvement works?

Thanks
Zack

On Fri, 3 Sept 2021 at 01:36, Joel Sherrill  wrote:

> On Thu, Sep 2, 2021 at 8:01 PM zack leung 
> wrote:
> >
> > Hello!
> >
> > I'd like to begin working on 4203. It involves improving the exception
> output  I'd like to know how I spot exceptions that could be reported
> better by the system?   How do I also know how do I test it and what BSPs i
> can test with only my computer Also joel told me The list of exception
> number/names is in the manual for the architecture. For an i386 or later,
> that should be in many places. Where do i find the documentation of the
> bsps?
> >
>
> Bringing this over from chat.
>
> The methods are architecture specific and may be in score/cpu or
> bsps/shared or a specific BSP (hope now there). For an example,
> score/cpu/i386/cpu.c has an exception printer. It seems to be the one
> cited as an example that could be improved. The thread id is printed
> in decimal, not hex. The exception type is only printed as a number.
> This could be turned into a number and exception name. The list of
> exception number/names is in the manual for the architecture. For an
> i386 or later, that should be in many places. There is only so much
> information in the exception frame passed in, so just make it more
> useful. If you look on other architectures for similar exception
> printers, you may find some print RTEMS state. Perhaps that's common
> info that could be printed by a shared subroutine.
>
> For a manual, this is the grandparent for i386 info:
>
> https://css.csail.mit.edu/6.858/2014/readings/i386.pdf
>
> And yes, that is from 1986 and I think I have a paper copy that old.
> But all x86 info should be essentially the same as what's presented in
> there. There may be additions but that's the original root.
>
> I wouldn't look actively at other architecture exception handlers. You
> could easily get lost in the details of each architecture and
> confused. Focus on the i386 first and how it could be better. For
> example, taking the exception number of printing a string name so you
> don't have to look it up. You find the list in the manual.
>
> FWIW I think the PowerPC prints numbers also.
>
> The name of the handler may be architecture specific. Hopefully
> someone can point to some for other architectures. But a good solution
> on x86 would be a good start.
>
> --joel
>
> --joel
> > Thanks
> >
> > Zack
> > ___
> > 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

Ticket #4203 clarification

2021-09-02 Thread zack leung
Hello!

I'd like to begin working on 4203. It involves improving the exception
output  I'd like to know how I spot exceptions that could be reported
better by the system?   How do I also know how do I test it and what BSPs i
can test with only my computer Also joel told me The list of exception
number/names is in the manual for the architecture. For an i386 or later,
that should be in many places. Where do i find the documentation of the
bsps?

Thanks

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

Re: [PATCH v3] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-06 Thread zack leung
How do i report the findings of the  psx and  tests?


Thanks
Zack

On Thu, 5 Aug 2021 at 19:23, Gedare Bloom  wrote:

> On Thu, Aug 5, 2021 at 12:36 PM Zacchaeus Leung
>  wrote:
> >
> > the timer_create() method can use CLOCK_MONOTONIC but there was  no test
> for this
> >
> The commit message needs to be improved, because this patch is doing
> more than adding a "test", it is implementing the functionality to
> create a CLOCK_MONOTONIC timer and to gettime() on it.
>
> > Closes #3888
> https://devel.rtems.org/ticket/3888  ??
>
> >
> > ---
>
> [...]
>
> > +
> > + if ( rtems_timespec_less_than( ,  ) ) {
> > +  rtems_timespec_subtract( , ,  );
> > +} else {
> > +  result.tv_nsec = 0;
> > +  result.tv_sec  = 0;
> > +}
> The indentation level is wrong in this block.
>
> > +
> > +  value->it_value = result;
> > +  value->it_interval = ptimer->timer_data.it_interval;
> > +
> > +  _POSIX_Timer_Release( cpu, _context );
> > +  return 0;
> > +}
> > \ No newline at end of file
> > diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> > index 9f79d33c42..1a79369efb 100644
> > --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> > +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> > @@ -126,6 +126,32 @@ void *POSIX_Init (
> >puts( "timer_delete - bad id - EINVAL" );
> >status = timer_delete( timer );
> >fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> > +
> > +  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
> > +  status = timer_create( CLOCK_MONOTONIC, , NULL );
> > +  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
> > +
> > +  puts( "timer_create (monotonic) - OK" );
> > +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> > +  posix_service_failed( status, "timer_create OK" );
> > +
> > +  puts( "timer_create (monotonic) - too many - EAGAIN" );
> > +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> > +  fatal_posix_service_status_errno( status, EAGAIN, "too many" );
> > +
> > +  clock_gettime( CLOCK_MONOTONIC,  );
> > +  itimer.it_value = now;
> > +  itimer.it_value.tv_sec = itimer.it_value.tv_sec - 1;
> > +  puts( "timer_settime (monotonic) - bad itimer value - previous time -
> EINVAL" );
> > +  status = timer_settime( timer, TIMER_ABSTIME, , NULL );
> > +  fatal_posix_service_status_errno( status, EINVAL, "bad itimer value
> #3" );
> > +
> > +  clock_gettime( CLOCK_MONOTONIC,  );
> > +  itimer.it_value = now;
> > +  itimer.it_value.tv_sec = itimer.it_value.tv_sec + 1;
> > +  puts( "timer_settime (monotonic) - bad id - EINVAL" );
> > +  status = timer_settime( timer1, TIMER_ABSTIME, , NULL );
> > +  fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> >
>
> Please provide updated psxtimer02.scn and report the results for
> running rtems-test for at least the sparc/erc32 with sis including the
> sptests and psxtests. If you need help how to run rtems-test, consult
> the documentation and ask questions.
> https://docs.rtems.org/branches/master/user/testing/index.html
>
> >TEST_END();
> >rtems_test_exit (0);
> > --
> > 2.32.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] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-05 Thread zack leung
Here you could add an assert that ptimer->clock_type ==
CLOCK_MONOTONIC || ptimer->clock_type == CLOCK_REALTIME.

Would I need to assert that the timer is not a valid timer type?  Also In
psxtimer create I check if the timer is invalid.

I can do a similar if statement as I did in psxtimercreate

if ( ptimer->clock_type != CLOCK_REALTIME && ptimer->clock_type !=
CLOCK_MONOTONIC )
rtems_set_errno_and_return_minus_one( EINVAL );
Zack

On Wed, 4 Aug 2021 at 16:02, Gedare Bloom  wrote:

> On Wed, Jul 28, 2021 at 6:28 PM Zacchaeus Leung
>  wrote:
> >
> > the timer_create() method can use CLOCK_MONOTONIC but there was  no test
> for this
> >
> > Closes #3888
> > ---
> >  cpukit/include/rtems/posix/timer.h|  1 +
> >  cpukit/posix/src/psxtimercreate.c |  3 +-
> >  cpukit/posix/src/timergettime.c   | 52 ++-
> >  testsuites/psxtests/psxtimer02/psxtimer.c | 26 
> >  4 files changed, 60 insertions(+), 22 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> > index bcbf07a65a..7ae089173a 100644
> > --- a/cpukit/include/rtems/posix/timer.h
> > +++ b/cpukit/include/rtems/posix/timer.h
> > @@ -48,6 +48,7 @@ typedef struct {
> >uint32_t  ticks;  /* Number of ticks of the
> initialization */
> >uint32_t  overrun;/* Number of expirations of the timer
>   */
> >struct timespec   time;   /* Time at which the timer was started
>  */
> > +  clockid_t clock_type; /* The type of timer */
> >  } POSIX_Timer_Control;
> >
> >  /**
> > diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> > index a63cf1d100..2b5a10140f 100644
> > --- a/cpukit/posix/src/psxtimercreate.c
> > +++ b/cpukit/posix/src/psxtimercreate.c
> > @@ -40,7 +40,7 @@ int timer_create(
> >  {
> >POSIX_Timer_Control *ptimer;
> >
> > -  if ( clock_id != CLOCK_REALTIME )
> > +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
> >  rtems_set_errno_and_return_minus_one( EINVAL );
> >
> >if ( !timerid )
> > @@ -91,6 +91,7 @@ int timer_create(
> >ptimer->timer_data.it_value.tv_nsec= 0;
> >ptimer->timer_data.it_interval.tv_sec  = 0;
> >ptimer->timer_data.it_interval.tv_nsec = 0;
> > +  ptimer->clock_type = clock_id;
> >
> >_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
> >_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> > diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> > index ee2a566f0e..b29d03efa1 100644
> > --- a/cpukit/posix/src/timergettime.c
> > +++ b/cpukit/posix/src/timergettime.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   *  - When a timer is initialized, the value of the time in
> > @@ -39,35 +40,44 @@
> >  int timer_gettime(
> >timer_ttimerid,
> >struct itimerspec *value
> >  )
> >
> >  {
> >POSIX_Timer_Control *ptimer;
> > -  ISR_lock_Context lock_context;
> > -  uint64_t now;
> > -  uint32_t remaining;
> > +  ISR_lock_Context lock_context;
> > +  Per_CPU_Control *cpu;
> > +  struct timespec now;
> > +  struct timespec expire;
> > +  struct timespec result;
> >
> >if ( !value )
> >  rtems_set_errno_and_return_minus_one( EINVAL );
> >
> >ptimer = _POSIX_Timer_Get( timerid, _context );
> > -  if ( ptimer != NULL ) {
> > -Per_CPU_Control *cpu;
> > -
> > -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> > -now = cpu->Watchdog.ticks;
> > -
> > -if ( now < ptimer->Timer.expire ) {
> > -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> > -} else {
> > -  remaining = 0;
> > -}
> > +  if ( ptimer == NULL ) {
> > +rtems_set_errno_and_return_minus_one( EINVAL );
> > +  }
> >
> > -_Timespec_From_ticks( remaining, >it_value );
> > -value->it_interval = ptimer->timer_data.it_interval;
> > +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> > +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
> >
> > -_POSIX_Timer_Release( cpu, _context );
> > -return 0;
> > +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> > +  _Timecounter_Nanouptime();
> > +  }
> > +  if ( ptimer->clock_type == CLOCK_REALTIME ) {
> Minor nit: this could be 'else if'
>
> > +_TOD_Get();
> >}
> Here you could add an assert that ptimer->clock_type ==
> CLOCK_MONOTONIC || ptimer->clock_type == CLOCK_REALTIME. Or you can
> add:
>  else {
> _POSIX_Timer_Release( cpu, _context );
> rtems_set_errno_and_return_minus_one( EINVAL );
>   }
> and make sure to test by calling this function directly with an
> invalid clock_type. This of course depends on making the above into
> 'else if'.
>
> >
> > -  rtems_set_errno_and_return_minus_one( EINVAL );
> > -}
> > +
> > + if ( rtems_timespec_less_than( ,  ) ) {
> > +  rtems_timespec_subtract( , ,  );
> > +} else {
> > +  result.tv_nsec = 0;
> > +  

Re: [PATCH v2] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-04 Thread zack leung
bump

On Thu, 29 Jul 2021 at 00:28, Zacchaeus Leung 
wrote:

> the timer_create() method can use CLOCK_MONOTONIC but there was  no test
> for this
>
> Closes #3888
> ---
>  cpukit/include/rtems/posix/timer.h|  1 +
>  cpukit/posix/src/psxtimercreate.c |  3 +-
>  cpukit/posix/src/timergettime.c   | 52 ++-
>  testsuites/psxtests/psxtimer02/psxtimer.c | 26 
>  4 files changed, 60 insertions(+), 22 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a65a..7ae089173a 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t  ticks;  /* Number of ticks of the initialization
> */
>uint32_t  overrun;/* Number of expirations of the timer
> */
>struct timespec   time;   /* Time at which the timer was started
>  */
> +  clockid_t clock_type; /* The type of timer */
>  } POSIX_Timer_Control;
>
>  /**
> diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d100..2b5a10140f 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
>  {
>POSIX_Timer_Control *ptimer;
>
> -  if ( clock_id != CLOCK_REALTIME )
> +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,6 +91,7 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec  = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> +  ptimer->clock_type = clock_id;
>
>_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> index ee2a566f0e..b29d03efa1 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   *  - When a timer is initialized, the value of the time in
> @@ -39,35 +40,44 @@
>  int timer_gettime(
>timer_ttimerid,
>struct itimerspec *value
>  )
>
>  {
>POSIX_Timer_Control *ptimer;
> -  ISR_lock_Context lock_context;
> -  uint64_t now;
> -  uint32_t remaining;
> +  ISR_lock_Context lock_context;
> +  Per_CPU_Control *cpu;
> +  struct timespec now;
> +  struct timespec expire;
> +  struct timespec result;
>
>if ( !value )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> -
> -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> -now = cpu->Watchdog.ticks;
> -
> -if ( now < ptimer->Timer.expire ) {
> -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> -} else {
> -  remaining = 0;
> -}
> +  if ( ptimer == NULL ) {
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -_Timespec_From_ticks( remaining, >it_value );
> -value->it_interval = ptimer->timer_data.it_interval;
> +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
>
> -_POSIX_Timer_Release( cpu, _context );
> -return 0;
> +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> +  _Timecounter_Nanouptime();
> +  }
> +  if ( ptimer->clock_type == CLOCK_REALTIME ) {
> +_TOD_Get();
>}
>
> -  rtems_set_errno_and_return_minus_one( EINVAL );
> -}
> +
> + if ( rtems_timespec_less_than( ,  ) ) {
> +  rtems_timespec_subtract( , ,  );
> +} else {
> +  result.tv_nsec = 0;
> +  result.tv_sec  = 0;
> +}
> +
> +  value->it_value=result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
> +}
> \ No newline at end of file
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33c42..1a79369efb 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -126,6 +126,32 @@ void *POSIX_Init (
>puts( "timer_delete - bad id - EINVAL" );
>status = timer_delete( timer );
>fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> +
> +  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
> +  status = timer_create( CLOCK_MONOTONIC, , NULL );
> +  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
> +
> +  puts( "timer_create (monotonic) - OK" );
> +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> +  posix_service_failed( status, "timer_create OK" );
> +
> +  puts( "timer_create (monotonic) - too many - EAGAIN" );
> +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> +  

Re: [PATCH] closes #3889

2021-07-24 Thread zack leung
> -  remaining = 0;
> +  result->tv_nsec=0;
> +  result->tv_sec=0;
This isn't correct. result is an uninitialized pointer.

So then how do  I set the timespec's value to 0? I have changed the
timespec variables i have declared from pointers to regular variables.
in the original code the result ( used to be the remaining time) should be
0.




> +_TOD_Get(now);
>This isn't correct. now is an uninitialized pointer.  How do you
>compile and run this code? I'm surprised it passes tests with this
>kind of bug.

Since the now timespec is defined as
struct timesepc now
TOD_GET used like this :
_TOD_GET(now)
I think the code will now work as intended as it now has a reference.


>
> -  ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> +  ptimer = _POSIX_Timer_Get(timerid, _context);
avoid whitespace changes. This change is inconsistent with our coding
conventions.


Can  you explain where the whilespace is?  Sometimes i have issues with
trailing whitespace as sometimes when i run format patch it's different
from the file that I'm working on.

> +
> +
> +
> +
Don't add extra whitespaces. We don't use more than one blank line in
a row in RTEMS C
 Again  I may have to change it manually within the patch file.  I may talk
with people on discord for help to avoid flooding the mailing list.


Also how i solved the  nesting was the completely delete the repository and
then i would rebuilt rtems.  After making a emailed patch how do i do
another one without running into the same problem?






On Fri, 23 Jul 2021 at 22:15, Joel Sherrill  wrote:

> I concur with Gedare's comments.
>
> I would think your commit message would be similar to the subject of the
> ticket.
> This looks like a decent example:
>
>
> https://git.rtems.org/rtems/commit/?id=6c23252cdd8ea63d0fe13d9f99b7befbf070fe80
>
> Please update and submit. Pay attention to compiler warnings.
>
> On Fri, Jul 23, 2021 at 12:02 PM Gedare Bloom  wrote:
> >
> > Hi Zak,
> >
> > Please provide a useful first commit line. I think I've mentioned this
> > before, but the current guidance is found at
> > https://devel.rtems.org/wiki/Developer/Git#GitCommits
> >
> > Put the ticket closing line within the commit message, usually on its
> > own line at the end of your  commit message
> >
> >
> > On Thu, Jul 22, 2021 at 6:29 PM Zacchaeus Leung
> >  wrote:
> > >
> > > ---
> > >  cpukit/include/rtems/posix/timer.h |  1 +
> > >  cpukit/posix/src/psxtimercreate.c  |  1 +
> > >  cpukit/posix/src/timergettime.c| 61 +++---
> > >  3 files changed, 41 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> > > index bcbf07a65a..7ae089173a 100644
> > > --- a/cpukit/include/rtems/posix/timer.h
> > > +++ b/cpukit/include/rtems/posix/timer.h
> > > @@ -48,6 +48,7 @@ typedef struct {
> > >uint32_t  ticks;  /* Number of ticks of the
> initialization */
> > >uint32_t  overrun;/* Number of expirations of the
> timer*/
> > >struct timespec   time;   /* Time at which the timer was
> started   */
> > > +  clockid_t clock_type; /* The type of timer */
> > >  } POSIX_Timer_Control;
> > >
> > >  /**
> > > diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> > > index a63cf1d100..804c7a41e7 100644
> > > --- a/cpukit/posix/src/psxtimercreate.c
> > > +++ b/cpukit/posix/src/psxtimercreate.c
> > > @@ -91,6 +91,7 @@ int timer_create(
> > >ptimer->timer_data.it_value.tv_nsec= 0;
> > >ptimer->timer_data.it_interval.tv_sec  = 0;
> > >ptimer->timer_data.it_interval.tv_nsec = 0;
> > > +  ptimer->clock_type = clock_id;
> > >
> > >_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
> > >_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> > > diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> > > index ee2a566f0e..ff2176ac60 100644
> > > --- a/cpukit/posix/src/timergettime.c
> > > +++ b/cpukit/posix/src/timergettime.c
> > > @@ -28,6 +28,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  /*
> > >   *  - When a timer is initialized, the value of the time in
> > > @@ -35,39 +36,55 @@
> > >   *  - When this function is called, it returns the difference
> > >   *between the current time and the initialization time.
> > >   */
> > > -
> > avoid random whitespace changes.
> >
> > >  int timer_gettime(
> > >timer_ttimerid,
> > >struct itimerspec *value
> > > -)
> > > +)
> > avoid random whitespace changes. I can't even tell what this one changes.
> >
> > >  {
> > >POSIX_Timer_Control *ptimer;
> > > -  ISR_lock_Context lock_context;
> > > -  uint64_t now;
> > > -  uint32_t remaining;
> > > +  ISR_lock_Context lock_context;
> > > +  uint32_t remaining;
> > > +  Per_CPU_Control *cpu;
> > > + 

Re: [PATCH V2] closes #3889 new defect Test needed for timer_create with CLOCK_MONOTONIC

2021-07-19 Thread zack leung
The code i wrote is  not based on  my previous patch. I ran the same
commands in the guide as well as my first patch:

git add
git commit
 git send-email --to=devel@rtems.org -1

is there a  way to only submit the second patch? I tried to delete the
patch file before sending the first patch
Also, I have made changes to reduce code duplication. The structure of the
code has changed so I had to format things.


Thanks
Zack



On Thu, 15 Jul 2021 at 15:29, Gedare Bloom  wrote:

> The first line of the commit should be shorter. Use a blank line, and
> then close the ticket with the Closes # command.
>
> https://devel.rtems.org/wiki/Developer/Git#GitCommits
>
> We need to move this information into
> https://docs.rtems.org/branches/master/eng/management.html
>
>
> On Thu, Jul 8, 2021 at 1:50 PM Zacchaeus Leung 
> wrote:
> >
> > ---
> >  ...or-timer_create-with-clock_monotonic.patch | 234 ++
> >  cpukit/include/rtems/posix/timer.h|   2 +-
> >  cpukit/posix/src/psxtimercreate.c |  86 +++
> >  cpukit/posix/src/timergettime.c   |  76 ++
> >  4 files changed, 300 insertions(+), 98 deletions(-)
> >  create mode 100644
> 0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> >
> > diff --git
> a/0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> b/0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> > new file mode 100644
> > index 00..33be528411
> > --- /dev/null
> > +++ b/0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> > @@ -0,0 +1,234 @@
> > +From f1cac2a4b64e5076f0ceff014b78be41e5f00389 Mon Sep 17 00:00:00 2001
> > +From: Zack 
> > +Date: Mon, 28 Jun 2021 14:23:42 -0400
> > +Subject: [PATCH] Addded test for timer_create with clock_monotonic
> > +
>
> It seems that you have included a patch within your patch. Please
> check your commit before you email it, to make sure only the changes
> you want included are there. Since I'm not sure what changes you are
> intending to send, I'm going to stop here.
>
> A few general comments:
>
> Avoid reformatting existing code. Keep your changes limited to
> functional changes only, and send reformatting/documentation changes
> separately. Make sure you write new code consistently to our style
> guide. (https://docs.rtems.org/branches/master/eng/coding.html) If in
> doubt, write your code consistent with code near it.
>
> Provide all the patches for your commits that go from the current HEAD
> (most recent commit on master). We can't review commits that are based
> on other commits on your local repo only, unless you include those
> commits also for review.
>
> > +---
> > + cpukit/include/rtems/posix/timer.h|  1 +
> > + cpukit/posix/src/psxtimercreate.c |  5 +-
> > + cpukit/posix/src/timergettime.c   | 79 ---
> > + testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
> > + 4 files changed, 98 insertions(+), 25 deletions(-)
> > +
> > +diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> > +index bcbf07a65a..839fe3293c 100644
> > +--- a/cpukit/include/rtems/posix/timer.h
> >  b/cpukit/include/rtems/posix/timer.h
> > +@@ -48,6 +48,7 @@ typedef struct {
> > +   uint32_t  ticks;  /* Number of ticks of the
> initialization */
> > +   uint32_t  overrun;/* Number of expirations of the timer
>   */
> > +   struct timespec   time;   /* Time at which the timer was
> started   */
> > ++clockid_t clock_type;
> > + } POSIX_Timer_Control;
> > +
> > + /**
> > +diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> > +index a63cf1d100..b60be3f229 100644
> > +--- a/cpukit/posix/src/psxtimercreate.c
> >  b/cpukit/posix/src/psxtimercreate.c
> > +@@ -40,7 +40,7 @@ int timer_create(
> > + {
> > +   POSIX_Timer_Control *ptimer;
> > +
> > +-  if ( clock_id != CLOCK_REALTIME )
> > ++  if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC  )
> > + rtems_set_errno_and_return_minus_one( EINVAL );
> > +
> > +   if ( !timerid )
> > +@@ -91,7 +91,8 @@ int timer_create(
> > +   ptimer->timer_data.it_value.tv_nsec= 0;
> > +   ptimer->timer_data.it_interval.tv_sec  = 0;
> > +   ptimer->timer_data.it_interval.tv_nsec = 0;
> > +-
> > ++  ptimer->clock_type=clock_id;
> > ++
> > +   _Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
> > +   _Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> > +   _Objects_Open_u32(&_POSIX_Timer_Information, >Object, 0);
> > +diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> > +index ee2a566f0e..57b0ab4918 100644
> > +--- a/cpukit/posix/src/timergettime.c
> >  b/cpukit/posix/src/timergettime.c
> > +@@ -6,6 +6,14 @@
> > +  * @brief Function Fetches State of POSIX Per-Process Timers
> > +  */
> > +
> > ++/**
> > ++ * @file
> > ++ *
> > ++ * @ingroup POSIXAPI
> > ++ *
> > ++ * @brief Function Fetches State of POSIX Per-Process Timers
> > ++ */
> > 

Re: [PATCH] Addded test for timer_create with clock_monotonic

2021-06-30 Thread zack leung
> +  remaining = (uint32_t)result->tv_nsec + result->tv_sec;
What does "remaining" mean here?  What do you get if you add a
(truncated) nanoseconds value to a seconds value? (Hint: the units
aren't the same, so the arithmetic is meaningless.)

I thought I could convert it back into the uint32_t. I thought Adding will
give me the remaining time.

 remaining = (uint32_t) ( ptimer->Timer.expire - now );

something similar to what was done there.



> -_Timespec_From_ticks( remaining, >it_value );

> +_Timespec_From_ticks(remaining, >it_value);

Why convert back and forth between timespec and ticks? why not just

update this function to use timespec values?


Do you want me to change remaining to be a timespec? change the field
it_value to a timespec?

Zack

Ps: thanks for being so patient with my patch. I'm still learning !


On Tue, 29 Jun 2021 at 16:44, Gedare Bloom  wrote:

> Hi Zack,
>
> Please provide a full name in your git-commit author metadata
> (git-config.user)
>
> Please use a short tag at the start of your commit to identify the
> scope, in this case, it will be "posix/timer"
>
> Check typo "addded" in your commit message. I think this commit is
> related to a ticket? if it finishes it, please use
> Closes #.
> where  is the ticket number, or
> Updates #.
> If the patch does not close the ticket out.
>
> On Tue, Jun 29, 2021 at 9:19 AM Zack  wrote:
> >
> > ---
> >  cpukit/include/rtems/posix/timer.h|  1 +
> >  cpukit/posix/src/psxtimercreate.c |  5 +-
> >  cpukit/posix/src/timergettime.c   | 79 ---
> >  testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
> >  4 files changed, 98 insertions(+), 25 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> > index bcbf07a65a..839fe3293c 100644
> > --- a/cpukit/include/rtems/posix/timer.h
> > +++ b/cpukit/include/rtems/posix/timer.h
> > @@ -48,6 +48,7 @@ typedef struct {
> >uint32_t  ticks;  /* Number of ticks of the
> initialization */
> >uint32_t  overrun;/* Number of expirations of the timer
>   */
> >struct timespec   time;   /* Time at which the timer was started
>  */
> > +clockid_t clock_type;
> To be consistent, add a comment like the lines above.
>
> >  } POSIX_Timer_Control;
> >
> >  /**
> > diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> > index a63cf1d100..b60be3f229 100644
> > --- a/cpukit/posix/src/psxtimercreate.c
> > +++ b/cpukit/posix/src/psxtimercreate.c
> > @@ -40,7 +40,7 @@ int timer_create(
> >  {
> >POSIX_Timer_Control *ptimer;
> >
> > -  if ( clock_id != CLOCK_REALTIME )
> > +  if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC  )
> >  rtems_set_errno_and_return_minus_one( EINVAL );
> >
> >if ( !timerid )
> > @@ -91,7 +91,8 @@ int timer_create(
> >ptimer->timer_data.it_value.tv_nsec= 0;
> >ptimer->timer_data.it_interval.tv_sec  = 0;
> >ptimer->timer_data.it_interval.tv_nsec = 0;
> > -
> > +  ptimer->clock_type=clock_id;
> add spaces around =. Here, the lines above are aligned on the =, so
> you should also align. Write code that uses a consistent style as
> surrounding code / as the RTEMS Style.
>
> > +
> This blank line adds a lot of whitespace characters (spaces). Blank
> lines should be empty.
>
> >_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
> >_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> >_Objects_Open_u32(&_POSIX_Timer_Information, >Object, 0);
> > diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> > index ee2a566f0e..57b0ab4918 100644
> > --- a/cpukit/posix/src/timergettime.c
> > +++ b/cpukit/posix/src/timergettime.c
> > @@ -6,6 +6,14 @@
> >   * @brief Function Fetches State of POSIX Per-Process Timers
> >   */
> >
> > +/**
> > + * @file
> > + *
> > + * @ingroup POSIXAPI
> > + *
> > + * @brief Function Fetches State of POSIX Per-Process Timers
>
> A file isn't a function
>
> > + */
> > +
> >  /*
> >   *  14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
> >   *
> > @@ -21,13 +29,13 @@
> >  #include "config.h"
> >  #endif
> >
> > -#include 
> >  #include 
> > -
> Why delete the space separating the two groups of includes, system
> includes and rtems includes?
>
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> Why do you reorder the includes?
>
> >
> >  /*
> >   *  - When a timer is initialized, the value of the time in
> > @@ -36,38 +44,65 @@
> >   *between the current time and the initialization time.
> >   */
> >
> > -int timer_gettime(
> > -  timer_ttimerid,
> > -  struct itimerspec *value
> > -)
> > -{
> > +int timer_gettime(timer_t timerid, struct itimerspec *value) {
> Why do you reformat the style of the function declaration? I shouldn't
> need to spend time reviewing your style changes, focus instead on
> writing code in the