Re: [PATCH rtems] dosfs: Fix memory leak on failed mounts.

[Chris Johns]

On 4/8/20 4:29 pm, Christian Mauderer wrote:
> Thanks for all Feedback. I integrated the changes suggested by
> Sebastian, cretated the tickets and pushed to 5 and master.

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

Doubt in testsuite design on smp schedulers

[Richi Dubey]

Hi,

I wanted to learn about how the reset

function in
the smpschededf02/init.c works/what it aims for.

First
,
we set the priority of the task in correspondence with their index, so Task
0 gets highest priority and set the affinity of all the task to both the
processor.

Then
,
we suspend all the task by suspending their thread and enable the dispatch
on thread's CPU.

After that, why do we resume

the first two task and then again suspend
them
by using the object id of their thread?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doubt in testsuite design on smp schedulers

[Richi Dubey]

Also, heir means something that would be executing later, after the current
thread leaves cpu, right?

Why is it then that we are checking

against is_idle not against cpu->executing but for cpu->heir?

Please let me know.
Thanks

On Tue, Aug 4, 2020 at 3:18 PM Richi Dubey  wrote:

> Hi,
>
> I wanted to learn about how the reset
> 
>  function in
> the smpschededf02/init.c works/what it aims for.
>
> First
> ,
> we set the priority of the task in correspondence with their index, so Task
> 0 gets highest priority and set the affinity of all the task to both the
> processor.
>
> Then
> ,
> we suspend all the task by suspending their thread and enable the dispatch
> on thread's CPU.
>
> After that, why do we resume
> 
> the first two task and then again suspend
> them
> by using the object id of their thread?
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] smpschededf02: Document reset() function

[Sebastian Huber]

---
 testsuites/smptests/smpschededf02/init.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/testsuites/smptests/smpschededf02/init.c 
b/testsuites/smptests/smpschededf02/init.c
index cd8895edd5..fae2d76bf3 100644
--- a/testsuites/smptests/smpschededf02/init.c
+++ b/testsuites/smptests/smpschededf02/init.c
@@ -216,6 +216,12 @@ static void set_affinity(rtems_id id, uint32_t cpu_set_32)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
+/*
+ * The goal of the reset() function is to bring back a defined initial system
+ * state for each test case.  All tasks of the test shall be suspended.  The
+ * idle threads shall be ordered in the scheduled chain according to the CPU
+ * index.
+ */
 static void reset(test_context *ctx)
 {
   rtems_status_code sc;
@@ -236,7 +242,13 @@ static void reset(test_context *ctx)
 rtems_test_assert(sc == RTEMS_SUCCESSFUL || sc == RTEMS_INCORRECT_STATE);
   }
 
-  /* Order the idle threads explicitly */
+  /*
+   * Order the idle threads explicitly.  Test cases may move the idle threads
+   * around.  We have to ensure that the idle threads are ordered according to
+   * the CPU index, otherwise the processor allocations cannot be specified for
+   * a test case.  The idle threads of a scheduler have all the same priority,
+   * so we have to take the FIFO ordering within a priority group into account.
+   */
   for (i = 0; i < CPU_COUNT; ++i) {
 const Per_CPU_Control *c;
 const Thread_Control *h;
-- 
2.26.2

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

Re: Doubt in testsuite design on smp schedulers

[Sebastian Huber]

Hello Richi,

please have a look at:

https://lists.rtems.org/pipermail/devel/2020-August/061112.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] smpschededf02: Document reset() function

[Richi Dubey]

This helps. Thank you.

On Tue, Aug 4, 2020 at 3:58 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  testsuites/smptests/smpschededf02/init.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/testsuites/smptests/smpschededf02/init.c
> b/testsuites/smptests/smpschededf02/init.c
> index cd8895edd5..fae2d76bf3 100644
> --- a/testsuites/smptests/smpschededf02/init.c
> +++ b/testsuites/smptests/smpschededf02/init.c
> @@ -216,6 +216,12 @@ static void set_affinity(rtems_id id, uint32_t
> cpu_set_32)
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>  }
>
> +/*
> + * The goal of the reset() function is to bring back a defined initial
> system
> + * state for each test case.  All tasks of the test shall be suspended.
> The
> + * idle threads shall be ordered in the scheduled chain according to the
> CPU
> + * index.
> + */
>  static void reset(test_context *ctx)
>  {
>rtems_status_code sc;
> @@ -236,7 +242,13 @@ static void reset(test_context *ctx)
>  rtems_test_assert(sc == RTEMS_SUCCESSFUL || sc ==
> RTEMS_INCORRECT_STATE);
>}
>
> -  /* Order the idle threads explicitly */
> +  /*
> +   * Order the idle threads explicitly.  Test cases may move the idle
> threads
> +   * around.  We have to ensure that the idle threads are ordered
> according to
> +   * the CPU index, otherwise the processor allocations cannot be
> specified for
> +   * a test case.  The idle threads of a scheduler have all the same
> priority,
> +   * so we have to take the FIFO ordering within a priority group into
> account.
> +   */
>for (i = 0; i < CPU_COUNT; ++i) {
>  const Per_CPU_Control *c;
>  const Thread_Control *h;
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

unused static functions

[Aschref Ben-Thabet]

Dear RTEMS developers Team,
i am a new member focusing now on fixing the GCC10 warnings 
Compiler.this last has told that these both functions are declared but 
not used.
In /rtems/testsuites/libtests/dl10/dl-load.c,the test file includes this 
both functions without further use. that can generate a warning like 
Wunused-function.
can you tell me please for which issue are these static functions in 
this test file declared, and when they have any effect in the test, is 
it helpful to erase them (it fixes the warning)?

staticvoiddl_close (void* handle)
{
intr;
printf ("handle: %p closing\n", handle);
r = dlclose (handle);
if(r != 0)
printf("dlclose failed: %s\n", dlerror()) ;
rtems_test_assert (r == 0);
}
staticintdl_call (void* handle, constchar* func)
{
call_sig call = dlsym (handle, func);
if(call == NULL)
{
printf("dlsym failed: symbol not found: %s\n", func);
return1;
}
call ();
return0;
}
Beste regards
Aschref Ben thabet
Embedded Brains GmbH
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

legacy stack or libbsd

[Heinz Junkes]

I'm trying to figure out when compiling a third party software (EPICS),
whether the RTEMS for a target bsp was created with the legacy stack or 
uses the libbsd stack.

Unfortunately I have found some different definitions:

in target.cfg : RTEMS_HAS_NETWORKING
in bsp.cfg : HAS_NETWORKING
in header files #if defined(RTEMS_NETWORKING)

Which one should I take best?

I tend to RTEMS_HAS_NETWORKING in target.cfg ;-)

Danke Heinz

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: legacy stack or libbsd

[Joel Sherrill]

On Tue, Aug 4, 2020 at 8:10 AM Heinz Junkes 
wrote:

> I'm trying to figure out when compiling a third party software (EPICS),
> whether the RTEMS for a target bsp was created with the legacy stack or
> uses the libbsd stack.
>
> Unfortunately I have found some different definitions:
>
> in target.cfg : RTEMS_HAS_NETWORKING
> in bsp.cfg : HAS_NETWORKING
> in header files #if defined(RTEMS_NETWORKING)
>
> Which one should I take best?
>
> I tend to RTEMS_HAS_NETWORKING in target.cfg ;-)
>

rtems/score/cpuopts.h defines it in the installed headers. but
I think either bsp.cfg or target.cfg would be trustworthy. target.cfg
has more info in it.

This doesn't help you know before building which network stacks
a BSP supports though.

--joel


>
> Danke Heinz___
> 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] smpschededf02: Document reset() function

[Sebastian Huber]

On 04/08/2020 14:25, Richi Dubey wrote:


This helps. Thank you.
If things are still unclear, don't hesitate to ask again. Your questions 
are really helpful to improve the documentation.


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

Doubt in scheduler SMP function _Scheduler_SMP_Schedule_highest_ready

[Richi Dubey]

Hi,

I have a quick doubt about the logic in the else

part of the _Scheduler_SMP_Schedule_highest_ready function.

We get

the action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK if the node returned by
get_highest_ready is already SCHEDULED and has a pinning level of 1 (or
<=1). This means that the highest ready eligible node is already scheduled
and pinned to a processor.

Why do we

then change its state to BLOCKED and remove it from the chain of ready
nodes?

I would appreciate your help with this.
Thanks.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Explanation about the high level design choices of Strong APA

[Richi Dubey]

Hi,

Implementing the Strong APA scheduler requires finding places to put the
two most important algorithms (pages 5 and 6 from the paper
) in the current
RTEMS SMP scheduler framework.

I have chosen get_highest_ready and get_lowest_ready to implement these
function and my reasoning behind doing so is documented in the blog post-
https://rtemswithrichi.wordpress.com/adding-strong-apa-to-rtems-identifying-relevant-functions/
.

I would love to hear your insights about the post.
Thanks,
Richi.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] smpschededf02: Document reset() function

[Richi Dubey]

Thanks.

So for the code:
--
  for (i = 0; i < CPU_COUNT; ++i) {
const Per_CPU_Control *c;
const Thread_Control *h;

c = _Per_CPU_Get_by_index(CPU_COUNT - 1 - i);
h = c->heir;

sc = rtems_task_suspend(h->Object.id);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
  }
--
 would it have the same effect if we replace all this by :

  for (i = CPU_COUNT -1 ; i >=0 ; --i) {
sc = rtems_task_suspend(ctx->task_ids[i]);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
  }
--

Please let me know.


On Tue, Aug 4, 2020 at 7:17 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/08/2020 14:25, Richi Dubey wrote:
>
> > This helps. Thank you.
> If things are still unclear, don't hesitate to ask again. Your questions
> are really helpful to improve the documentation.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 2/2] wscript: add uninstall command

[Vijay Kumar Banerjee]

Hi Chris,

Is this patch OK to push to the master?

On Thu, Jul 30, 2020 at 3:51 PM Vijay Kumar Banerjee  wrote:
>
> ---
>  wscript | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/wscript b/wscript
> index 3ca9478e..74fc1f48 100644
> --- a/wscript
> +++ b/wscript
> @@ -151,7 +151,7 @@ def bsp_init(ctx, env, contexts):
>  # Transform the commands to per build variant commands
>  commands = []
>  for cmd in waflib.Options.commands:
> -if cmd.startswith(('build', 'clean', 'install')):
> +if cmd.startswith(('build', 'clean', 'install', 'uninstall')):
>  for builder in builders:
>  commands += [str(cmd + '-' + builder)]
>  else:
> @@ -226,6 +226,9 @@ def configure(conf):
>  update_builders(conf, conf.env.BUILDSET)
>  rtems.configure(conf, bsp_configure)
>
> +def test(bld):
> +rtems.test_uninstall(bld)
> +
>  def build(bld):
>  rtems.build(bld)
>  builders[bld.libbsd_buildset_name].build(bld)
> --
> 2.21.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doubt in scheduler SMP function _Scheduler_SMP_Schedule_highest_ready

[Gedare Bloom]

On Tue, Aug 4, 2020 at 8:14 AM Richi Dubey  wrote:
>
> Hi,
>
> I have a quick doubt about the logic in the else part of the 
> _Scheduler_SMP_Schedule_highest_ready function.
>
I'll give my understanding. Only Sebastian really understands this stuff ;)

> We get the action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK if the node returned 
> by get_highest_ready is already SCHEDULED and has a pinning level of 1 (or 
> <=1). This means that the highest ready eligible node is already scheduled 
> and pinned to a processor.
>
This means that the highest ready node cannot be scheduled right now,
for some reason. It is the thread that is already scheduled, or the
node is busy helping.

> Why do we then change its state to BLOCKED and remove it from the chain of 
> ready nodes?
>
If the thread that owns the node can't be scheduled right now (e.g.,
it is already scheduled on a different node), then the node should be
blocked so we can maybe pick a different node to schedule.

> I would appreciate your help with this.
> Thanks.
> ___
> 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: legacy stack or libbsd

[Heinz Junkes]

Because the libbsd stack does not support some things yet (e.g. ntp) I have to 
call different 
functions at rtems_init in EPICS. Therefore, when building EPICS for a target, 
I need
to know which stack the target was built with. 

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 4. Aug 2020, at 15:44, Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Aug 4, 2020 at 8:10 AM Heinz Junkes  wrote:
> I'm trying to figure out when compiling a third party software (EPICS),
> whether the RTEMS for a target bsp was created with the legacy stack or 
> uses the libbsd stack.
> 
> Unfortunately I have found some different definitions:
> 
> in target.cfg : RTEMS_HAS_NETWORKING
> in bsp.cfg : HAS_NETWORKING
> in header files #if defined(RTEMS_NETWORKING)
> 
> Which one should I take best?
> 
> I tend to RTEMS_HAS_NETWORKING in target.cfg ;-)
> 
> rtems/score/cpuopts.h defines it in the installed headers. but
> I think either bsp.cfg or target.cfg would be trustworthy. target.cfg
> has more info in it.
> 
> This doesn't help you know before building which network stacks
> a BSP supports though.
> 
> --joel
>  
> 
> Danke Heinz___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: unused static functions

[Gedare Bloom]

Hello Aschref Ben thabet,

On Tue, Aug 4, 2020 at 6:35 AM Aschref Ben-Thabet
 wrote:
>
> Dear RTEMS developers Team,
> i am a new member focusing now on fixing the GCC10 warnings Compiler.this 
> last has told that these both functions are declared but not used.
> In /rtems/testsuites/libtests/dl10/dl-load.c,the test file includes this both 
> functions without further use. that can generate a warning like 
> Wunused-function.
> can you tell me please for which issue are these static functions in this 
> test file declared, and when they have any effect in the test, is it helpful 
> to erase them (it fixes the warning)?

I think these functions are just copied from other dltests. Chris
Johns may comment on their elimination.

You would want to look at the purpose of the test, and how similar
tests are structured. Was it a mistake not to call these functions? Or
are they not needed for this test?

> static void dl_close (void* handle)
> {
> int r;
> printf ("handle: %p closing\n", handle);
> r = dlclose (handle);
> if (r != 0)
> printf("dlclose failed: %s\n", dlerror()) ;
> rtems_test_assert (r == 0);
> }
> static int dl_call (void* handle, const char* func)
> {
> call_sig call = dlsym (handle, func);
> if (call == NULL)
> {
> printf("dlsym failed: symbol not found: %s\n", func);
> return 1;
> }
> call ();
> return 0;
> }

It may be helpful to avoid html markup in mailing lists. We don't
filter it out, but some mailing lists (and clients) may.

> Beste regards
> Aschref Ben thabet
> Embedded Brains GmbH
> ___
> 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: unused static functions

[Joel Sherrill]

On Tue, Aug 4, 2020 at 11:12 AM Gedare Bloom  wrote:

> Hello Aschref Ben thabet,
>
> On Tue, Aug 4, 2020 at 6:35 AM Aschref Ben-Thabet
>  wrote:
> >
> > Dear RTEMS developers Team,
> > i am a new member focusing now on fixing the GCC10 warnings
> Compiler.this last has told that these both functions are declared but not
> used.
> > In /rtems/testsuites/libtests/dl10/dl-load.c,the test file includes this
> both functions without further use. that can generate a warning like
> Wunused-function.
> > can you tell me please for which issue are these static functions in
> this test file declared, and when they have any effect in the test, is it
> helpful to erase them (it fixes the warning)?
>
> I think these functions are just copied from other dltests. Chris
> Johns may comment on their elimination.
>
> You would want to look at the purpose of the test, and how similar
> tests are structured. Was it a mistake not to call these functions? Or
> are they not needed for this test?
>

The inclusion of these may generate special relocation records. Chris
would know that.

If they have to be there, there are examples on how to disable a specific
warning around a block of code.

>
> > static void dl_close (void* handle)
> > {
> > int r;
> > printf ("handle: %p closing\n", handle);
> > r = dlclose (handle);
> > if (r != 0)
> > printf("dlclose failed: %s\n", dlerror()) ;
> > rtems_test_assert (r == 0);
> > }
> > static int dl_call (void* handle, const char* func)
> > {
> > call_sig call = dlsym (handle, func);
> > if (call == NULL)
> > {
> > printf("dlsym failed: symbol not found: %s\n", func);
> > return 1;
> > }
> > call ();
> > return 0;
> > }
>
> It may be helpful to avoid html markup in mailing lists. We don't
> filter it out, but some mailing lists (and clients) may.
>
> > Beste regards
> > Aschref Ben thabet
> > Embedded Brains GmbH
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: OFW Import To RTEMS License Issue

[Niteesh G. S.]

ping.


On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S.  wrote:

>
>
> On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. 
>> wrote:
>>
>>> Hello,
>>>
>>> In a recent review of these patches
>>> https://lists.rtems.org/pipermail/devel/2020-July/060653.html
>>> Gedare mentioned that we cannot use these patches with the
>>> current license. More details regarding the conversation can be
>>> found in the following archive.
>>> https://lists.rtems.org/pipermail/devel/2020-July/061000.html
>>>
>>> The following files have been ported to RTEMS to implement
>>> the OFW API.
>>> 1) openfirm.h  -- BSD-4 License
>>> 2) openfirm.c  -- BSD-4 License
>>> 3) ofw_fdt.c-- BSD-2 License
>>>
>>> The files with BSD4 cannot be used and Gedare suggested to
>>> check if we can remove the entire 4-clause cluster or remove
>>> clauses #3 and #4. I checked this along with the help of Christian
>>> and it seems that we can't remove those. Christian suggested
>>> that we can use the header file with the BSD-4 license to some
>>> extent but the source files to pose a problem. We also checked
>>> OpenBSD it has the same licensing.
>>>
>>
>> NetBSD appears to be the origin of the code and although I believe
>> they did a largely blanket change from BSD-4, this code is old and
>> normally, I would doubt they found the original submitter.  Which
>> would be odd in this case because this is his website with email:
>>
>> https://solfrank.net/Wolfgang/
>>
>> I have privately emailed to politely ask him to relicense it to BSD-2
>> for use in RTEMS. And try to do that in a way that gets it on a path
>> to get changed upstream.
>>
>> Hopefully this will solve it.
>>
>
> Thanks for doing this Joel :).
>
>>
>>
>>> So we have come up with the following suggestions
>>> 1) Use the header files as it is.
>>>
>>
>> How close are you to being able to merge? Do we have time to let
>> him answer?
>>
>
> Yes, we do have a lot of time. All of my patches are based on the new build
> system so we won't be able to merge until the build system is merged. And
> also there are other things that have to be discussed regarding the patch.
>
>>
>>
>>> 2) Most OF_* functions defined in openfirm.c have 1:1 mapping
>>> with the FDT implementation in ofw_fdt.c so there is a possibility
>>> to remove openfirm.c and only use openfirm.h and ofw_fdt.c.
>>> For those functions which don't have a 1:1 mapping, we can add
>>> an implementation in ofw_fdt.c. And remove the functions which
>>> don't have an FDT based implementation eg. OF_write, OF_open etc.
>>>
>>> Also please remember that these patches were created with a goal
>>> to import the OFW into RTEMS and remove them from libBSD so
>>> will using the above approach has a chance of breaking libBSD
>>> compatibility in the future?
>>>
>>
>> Yikes. That would mean having to create our own files that are
>> compatible but don't have the license issue.
>>
>> And that our implementation is in a source transparent form that
>> allows updates easily from the upstream source.
>>
>> If we can't get relicense permission, I think we have to rewrite the
>> BSD-4 code and provide compatible versions. :(
>>
>
> As of now, this seems to be the only option but let's hope for someone
> to come up with a better approach or get the license relaxed.
>
> Thanks,
> Niteesh
>
>
>>
>>> Thanks,
>>> Niteesh.
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Niteesh G. S.]

Ping.

On Sun, Aug 2, 2020 at 2:44 PM Niteesh G. S.  wrote:

> Hello,
>
> I went through some of my previous conversations to summarize the various
> directories
> suggested by people. Maybe this will help to come up with a conclusion.
>
> In my first porting commit, I placed the files under cpukit/libfreebsd
> this caused issues like
> accessing BSP dependent functions like bsp_fdt_get() therefore Christian
> suggested moving
> the files to bsps/shared.
> https://lists.rtems.org/pipermail/devel/2020-May/059959.html
> I then posted the patches on the mailing lists after moving the files to
> bsps/shared. After this
> Sebastian suggested moving these back to cpukit since they are BSP
> independent. And add
> an API to register FDTs since this would allow for unit testing. But later
> instead of API we
> started using linker wrappers.
> https://lists.rtems.org/pipermail/devel/2020-May/059978.html
> https://lists.rtems.org/pipermail/devel/2020-June/060025.html
> Gedare also suggested having the files in cpukit since this would allow
> for easier synchronization
> with FreeBSD.
> https://lists.rtems.org/pipermail/devel/2020-May/059807.html
>
> Thanks,
> Niteesh.
>
> On Thu, Jul 30, 2020 at 1:03 AM Gedare Bloom  wrote:
>
>> On Wed, Jul 29, 2020 at 12:33 PM Christian Mauderer 
>> wrote:
>> >
>> >
>> >
>> > On 29/07/2020 20:21, Gedare Bloom wrote:
>> > > On Wed, Jul 29, 2020 at 12:10 PM Christian Mauderer <
>> o...@c-mauderer.de> wrote:
>> > >>
>> > >> On 29/07/2020 19:55, Gedare Bloom wrote:
>> > >>> On Wed, Jul 29, 2020 at 10:44 AM Christian Mauderer <
>> o...@c-mauderer.de> wrote:
>> > 
>> >  On 29/07/2020 18:07, Gedare Bloom wrote:
>> > > On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu <
>> niteesh...@gmail.com> wrote:
>> > >>
>> > >> ---
>> > >>  spec/build/testsuites/libtests/grp.yml|   3 +
>> > >>  .../testsuites/libtests/openfirmware01.yml|  20 +++
>> > >>  testsuites/libtests/openfirmware01/init.c | 147
>> ++
>> > >>  .../openfirmware01/openfirmware01.doc |  29 
>> > >>  .../openfirmware01/openfirmware01.scn |   2 +
>> > >>  testsuites/libtests/openfirmware01/some.c |  52 +++
>> > >>  testsuites/libtests/openfirmware01/some.dts   |  54 +++
>> > >>  testsuites/libtests/openfirmware01/some.h |  15 ++
>> > >>  8 files changed, 322 insertions(+)
>> > >>  create mode 100644
>> spec/build/testsuites/libtests/openfirmware01.yml
>> > >>  create mode 100644 testsuites/libtests/openfirmware01/init.c
>> > >>  create mode 100644
>> testsuites/libtests/openfirmware01/openfirmware01.doc
>> > >>  create mode 100644
>> testsuites/libtests/openfirmware01/openfirmware01.scn
>> > >>  create mode 100644 testsuites/libtests/openfirmware01/some.c
>> > >>  create mode 100644 testsuites/libtests/openfirmware01/some.dts
>> > >>  create mode 100644 testsuites/libtests/openfirmware01/some.h
>> > >>
>> > >> diff --git a/spec/build/testsuites/libtests/grp.yml
>> b/spec/build/testsuites/libtests/grp.yml
>> > >> index f1de6cd75f..56e84d2c89 100644
>> > >> --- a/spec/build/testsuites/libtests/grp.yml
>> > >> +++ b/spec/build/testsuites/libtests/grp.yml
>> > >> @@ -11,6 +11,7 @@ install: []
>> > >>  ldflags:
>> > >>  - -Wl,--wrap=printf
>> > >>  - -Wl,--wrap=puts
>> > >> +- -Wl,--wrap=bsp_fdt_get
>> > >>  links:
>> > >>  - role: build-dependency
>> > >>uid: optbin2c
>> > >> @@ -312,6 +313,8 @@ links:
>> > >>uid: write
>> > >>  - role: build-dependency
>> > >>uid: writev
>> > >> +- role: build-dependency
>> > >> +  uid: openfirmware01
>> > >>  type: build
>> > >>  use-after:
>> > >>  - rtemstest
>> > >> diff --git a/spec/build/testsuites/libtests/openfirmware01.yml
>> b/spec/build/testsuites/libtests/openfirmware01.yml
>> > >> new file mode 100644
>> > >> index 00..8feb69eb1e
>> > >> --- /dev/null
>> > >> +++ b/spec/build/testsuites/libtests/openfirmware01.yml
>> > >> @@ -0,0 +1,20 @@
>> > >> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>> > >> +build-type: test-program
>> > >> +cflags: []
>> > >> +copyrights:
>> > >> +- Copyright (C) 2020 Niteesh G S
>> > >> +cppflags: []
>> > >> +cxxflags: []
>> > >> +enabled-by: true
>> > >> +features: c cprogram
>> > >> +includes: []
>> > >> +ldflags: []
>> > >> +links: []
>> > >> +source:
>> > >> +- testsuites/libtests/openfirmware01/init.c
>> > >> +- testsuites/libtests/openfirmware01/some.c
>> > >> +stlib: []
>> > >> +target: testsuites/libtests/openfirmware01.exe
>> > >> +type: build
>> > >> +use-after: []
>> > >> +use-before: []
>> > >> diff --git a/testsuites/libtests/openfirmware01/init.c
>> b/testsuites/libtests/openfirmware01/init.c
>> > >> new file mode 100644
>> > >> index 00..fc38e6c513
>> > >> -

Re: GSoC 2020: OFW Import To RTEMS License Issue

[Christian Mauderer]

I think for this one we can only hope that the original author agrees to
a re-licensing. Otherwise it is only possible to add a replacement.

On 04/08/2020 20:34, Niteesh G. S. wrote:
> ping.
> 
> 
> On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S.  > wrote:
> 
> 
> 
> On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill  > wrote:
> 
> 
> 
> On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
> mailto:niteesh...@gmail.com>> wrote:
> 
> Hello,
> 
> In a recent review of these patches
> https://lists.rtems.org/pipermail/devel/2020-July/060653.html
> Gedare mentioned that we cannot use these patches with the
> current license. More details regarding the conversation can be
> found in the following archive.
> https://lists.rtems.org/pipermail/devel/2020-July/061000.html
> 
> The following files have been ported to RTEMS to implement
> the OFW API.
> 1) openfirm.h  -- BSD-4 License
> 2) openfirm.c  -- BSD-4 License
> 3) ofw_fdt.c    -- BSD-2 License
> 
> The files with BSD4 cannot be used and Gedare suggested to
> check if we can remove the entire 4-clause cluster or remove
> clauses #3 and #4. I checked this along with the help of
> Christian
> and it seems that we can't remove those. Christian suggested
> that we can use the header file with the BSD-4 license to some
> extent but the source files to pose a problem. We also checked
> OpenBSD it has the same licensing.
> 
> 
> NetBSD appears to be the origin of the code and although I believe 
> they did a largely blanket change from BSD-4, this code is old and
> normally, I would doubt they found the original submitter.  Which 
> would be odd in this case because this is his website with email:
> 
> https://solfrank.net/Wolfgang/  
> 
> I have privately emailed to politely ask him to relicense it to
> BSD-2 
> for use in RTEMS. And try to do that in a way that gets it on a
> path 
> to get changed upstream.
> 
> Hopefully this will solve it.
> 
> 
> Thanks for doing this Joel :).
> 
> 
> 
> So we have come up with the following suggestions
> 1) Use the header files as it is.
> 
> 
> How close are you to being able to merge? Do we have time to let
> him answer?
> 
> 
> Yes, we do have a lot of time. All of my patches are based on the
> new build
> system so we won't be able to merge until the build system is
> merged. And
> also there are other things that have to be discussed regarding the
> patch.
> 
>  
> 
> 2) Most OF_* functions defined in openfirm.c have 1:1 mapping
> with the FDT implementation in ofw_fdt.c so there is a
> possibility
> to remove openfirm.c and only use openfirm.h and ofw_fdt.c.
> For those functions which don't have a 1:1 mapping, we can add
> an implementation in ofw_fdt.c. And remove the functions which
> don't have an FDT based implementation eg. OF_write, OF_open
> etc.
> 
> Also please remember that these patches were created with a goal
> to import the OFW into RTEMS and remove them from libBSD so
> will using the above approach has a chance of breaking libBSD 
> compatibility in the future?
> 
> 
> Yikes. That would mean having to create our own files that are
> compatible but don't have the license issue. 
> 
> And that our implementation is in a source transparent form that
> allows updates easily from the upstream source.
> 
> If we can't get relicense permission, I think we have to rewrite the
> BSD-4 code and provide compatible versions. :(
> 
> 
> As of now, this seems to be the only option but let's hope for someone
> to come up with a better approach or get the license relaxed.
> 
> Thanks,
> Niteesh
>  
> 
> 
> Thanks,
> Niteesh.
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Christian Mauderer]

Hello,

I think the big question is: Should we make that a public API and keep
it in cpukit or should we make it a BSP support code and move ti to the
bsps/shared section?

Sebastian and Gedare: Like Niteesh said: There have been some different
directions in the past. Which one should be the target?

Best regards

Christian

On 04/08/2020 20:36, Niteesh G. S. wrote:
> Ping.
> 
> On Sun, Aug 2, 2020 at 2:44 PM Niteesh G. S.  > wrote:
> 
> Hello,
> 
> I went through some of my previous conversations to summarize the
> various directories
> suggested by people. Maybe this will help to come up with a conclusion.
> 
> In my first porting commit, I placed the files under
> cpukit/libfreebsd this caused issues like
> accessing BSP dependent functions like bsp_fdt_get() therefore
> Christian suggested moving
> the files to bsps/shared.
> https://lists.rtems.org/pipermail/devel/2020-May/059959.html
> I then posted the patches on the mailing lists after moving the
> files to bsps/shared. After this
> Sebastian suggested moving these back to cpukit since they are BSP
> independent. And add
> an API to register FDTs since this would allow for unit testing. But
> later instead of API we
> started using linker wrappers.
> https://lists.rtems.org/pipermail/devel/2020-May/059978.html
> https://lists.rtems.org/pipermail/devel/2020-June/060025.html
> Gedare also suggested having the files in cpukit since this would
> allow for easier synchronization
> with FreeBSD.
> https://lists.rtems.org/pipermail/devel/2020-May/059807.html
> 
> Thanks,
> Niteesh.
> 
> On Thu, Jul 30, 2020 at 1:03 AM Gedare Bloom  > wrote:
> 
> On Wed, Jul 29, 2020 at 12:33 PM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 29/07/2020 20:21, Gedare Bloom wrote:
> > > On Wed, Jul 29, 2020 at 12:10 PM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> > >>
> > >> On 29/07/2020 19:55, Gedare Bloom wrote:
> > >>> On Wed, Jul 29, 2020 at 10:44 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> > 
> >  On 29/07/2020 18:07, Gedare Bloom wrote:
> > > On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu
> mailto:niteesh...@gmail.com>> wrote:
> > >>
> > >> ---
> > >>  spec/build/testsuites/libtests/grp.yml        |   3 +
> > >>  .../testsuites/libtests/openfirmware01.yml    |  20 +++
> > >>  testsuites/libtests/openfirmware01/init.c     | 147
> ++
> > >>  .../openfirmware01/openfirmware01.doc         |  29 
> > >>  .../openfirmware01/openfirmware01.scn         |   2 +
> > >>  testsuites/libtests/openfirmware01/some.c     |  52
> +++
> > >>  testsuites/libtests/openfirmware01/some.dts   |  54
> +++
> > >>  testsuites/libtests/openfirmware01/some.h     |  15 ++
> > >>  8 files changed, 322 insertions(+)
> > >>  create mode 100644
> spec/build/testsuites/libtests/openfirmware01.yml
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/init.c
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/openfirmware01.doc
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/openfirmware01.scn
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/some.c
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/some.dts
> > >>  create mode 100644
> testsuites/libtests/openfirmware01/some.h
> > >>
> > >> diff --git a/spec/build/testsuites/libtests/grp.yml
> b/spec/build/testsuites/libtests/grp.yml
> > >> index f1de6cd75f..56e84d2c89 100644
> > >> --- a/spec/build/testsuites/libtests/grp.yml
> > >> +++ b/spec/build/testsuites/libtests/grp.yml
> > >> @@ -11,6 +11,7 @@ install: []
> > >>  ldflags:
> > >>  - -Wl,--wrap=printf
> > >>  - -Wl,--wrap=puts
> > >> +- -Wl,--wrap=bsp_fdt_get
> > >>  links:
> > >>  - role: build-dependency
> > >>    uid: optbin2c
> > >> @@ -312,6 +313,8 @@ links:
> > >>    uid: write
> > >>  - role: build-dependency
> > >>    uid: writev
> > >> +- role: build-dependency
> > >> +  uid: openfirmware01
> > >>  type: build
> > >>  use-after:
> > >>  - rtemstest
> > >> diff --git
> a/spec/build/testsuites/libtests/openfirmware01.yml
> b/spec/build/testsuites/libtests/o

Re: GSoC 2020: OFW Import To RTEMS License Issue

[Gedare Bloom]

On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer  wrote:
>
> I think for this one we can only hope that the original author agrees to
> a re-licensing. Otherwise it is only possible to add a replacement.
>

I suggest starting to make a plan for a clean room re-implementation.
Ideally, one entity can extract the requirements from the current code
or interface and write them up, so that another entity can
re-implement the code from the written requirements. This is a little
bit challenging in our situation, since the only entities that will
write the code have already been exposed to the copyrighted version.
(https://en.wikipedia.org/wiki/Clean_room_design) But we can still try
our best!

Interfaces are not, in general, copyright-protected. So, the person
that captures the requirements can rely on the interface, but needs to
write the requirements for implementing the interface in their own
words.

Gedare

> On 04/08/2020 20:34, Niteesh G. S. wrote:
> > ping.
> >
> >
> > On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S.  > > wrote:
> >
> >
> >
> > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill  > > wrote:
> >
> >
> >
> > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
> > mailto:niteesh...@gmail.com>> wrote:
> >
> > Hello,
> >
> > In a recent review of these patches
> > https://lists.rtems.org/pipermail/devel/2020-July/060653.html
> > Gedare mentioned that we cannot use these patches with the
> > current license. More details regarding the conversation can be
> > found in the following archive.
> > https://lists.rtems.org/pipermail/devel/2020-July/061000.html
> >
> > The following files have been ported to RTEMS to implement
> > the OFW API.
> > 1) openfirm.h  -- BSD-4 License
> > 2) openfirm.c  -- BSD-4 License
> > 3) ofw_fdt.c-- BSD-2 License
> >
> > The files with BSD4 cannot be used and Gedare suggested to
> > check if we can remove the entire 4-clause cluster or remove
> > clauses #3 and #4. I checked this along with the help of
> > Christian
> > and it seems that we can't remove those. Christian suggested
> > that we can use the header file with the BSD-4 license to some
> > extent but the source files to pose a problem. We also checked
> > OpenBSD it has the same licensing.
> >
> >
> > NetBSD appears to be the origin of the code and although I believe
> > they did a largely blanket change from BSD-4, this code is old and
> > normally, I would doubt they found the original submitter.  Which
> > would be odd in this case because this is his website with email:
> >
> > https://solfrank.net/Wolfgang/
> >
> > I have privately emailed to politely ask him to relicense it to
> > BSD-2
> > for use in RTEMS. And try to do that in a way that gets it on a
> > path
> > to get changed upstream.
> >
> > Hopefully this will solve it.
> >
> >
> > Thanks for doing this Joel :).
> >
> >
> >
> > So we have come up with the following suggestions
> > 1) Use the header files as it is.
> >
> >
> > How close are you to being able to merge? Do we have time to let
> > him answer?
> >
> >
> > Yes, we do have a lot of time. All of my patches are based on the
> > new build
> > system so we won't be able to merge until the build system is
> > merged. And
> > also there are other things that have to be discussed regarding the
> > patch.
> >
> >
> >
> > 2) Most OF_* functions defined in openfirm.c have 1:1 mapping
> > with the FDT implementation in ofw_fdt.c so there is a
> > possibility
> > to remove openfirm.c and only use openfirm.h and ofw_fdt.c.
> > For those functions which don't have a 1:1 mapping, we can add
> > an implementation in ofw_fdt.c. And remove the functions which
> > don't have an FDT based implementation eg. OF_write, OF_open
> > etc.
> >
> > Also please remember that these patches were created with a goal
> > to import the OFW into RTEMS and remove them from libBSD so
> > will using the above approach has a chance of breaking libBSD
> > compatibility in the future?
> >
> >
> > Yikes. That would mean having to create our own files that are
> > compatible but don't have the license issue.
> >
> > And that our implementation is in a source transparent form that
> > allows updates easily from the upstream source.
> >
> > If we can't get relicense permission, I think we have to rewrite the
> > BSD-4 code and provide compatible versions. :(
> >
> >
> > As of now, thi

[rtems-libbsd] Question how to treat necessary changes from freebsd master

[Jan.Sommer]

Hello,

I have now a patchset ready which should also properly enable the e1000 driver 
for the master branch of rtems-libbsd.
There is just a small problem:

The commit the current freebsd-org submodule points to has this line in the 
e1000/if_em.c 
(https://github.com/freebsd/freebsd/blob/6b0307a/sys/dev/e1000/if_em.c#L1839)

>   if (adapter->hw.mac.type < em_mac_min)
>   lem_smartspeed(adapter);
>   E1000_WRITE_REG(&adapter->hw, E1000_IMS, EM_MSIX_LINK | E1000_IMS_LSC);

This works fine on qemu, but hangs when tested on actual hardware.
With the current master of freebsd this has been changed to:

>   if (hw->mac.type < em_mac_min)
>   lem_smartspeed(adapter);
>   else if (hw->mac.type == e1000_82574 &&
>   adapter->intr_type == IFLIB_INTR_MSIX)
>   E1000_WRITE_REG(&adapter->hw, E1000_IMS, EM_MSIX_LINK |
>   E1000_IMS_LSC);

And this also works on the hardware.
So, should I add this change with an ifdef __rtems__ to the patch set which has 
to be resolved during the next bump of freebsd-org?
Or should I leave it out for the moment and it will be added automatically with 
the next bump of the submodule?

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Simulation and Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

Updates of Smart India Hackathon 2020 Finale

[Mritunjay Sharma]

Hello everyone!

I feel elated to share with the community that my Team 'Altruist'
won the first Prize in the Grand Finale of the World's
Biggest Hackathon - Smart India Hackathon 2020! We will not
only be awarded with INR 100,000 but also the Government of India
will help us to scale our project!

Thank you so much to the community for understanding my concern
and allowing me to take a break from 31st July to 3rd August.

I am resuming my work from today and will start a new thread
to ask the doubts after proper research work!

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

Re: Updates of Smart India Hackathon 2020 Finale

[Eshan Dhawan]

On Wed, Aug 5, 2020 at 2:18 AM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> Hello everyone!
>
> I feel elated to share with the community that my Team 'Altruist'
> won the first Prize in the Grand Finale of the World's
> Biggest Hackathon - Smart India Hackathon 2020! We will not
> only be awarded with INR 100,000 but also the Government of India
> will help us to scale our project!
>
Congratulations Mritunjay :)

>
> Thank you so much to the community for understanding my concern
> and allowing me to take a break from 31st July to 3rd August.
>
> I am resuming my work from today and will start a new thread
> to ask the doubts after proper research work!
>
> Thanks
> Mritunjay
> ___
> 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: Updates of Smart India Hackathon 2020 Finale

[Joel Sherrill]

Congratulations! That's awesome!

On Tue, Aug 4, 2020 at 4:01 PM Eshan Dhawan  wrote:

>
>
> On Wed, Aug 5, 2020 at 2:18 AM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>> Hello everyone!
>>
>> I feel elated to share with the community that my Team 'Altruist'
>> won the first Prize in the Grand Finale of the World's
>> Biggest Hackathon - Smart India Hackathon 2020! We will not
>> only be awarded with INR 100,000 but also the Government of India
>> will help us to scale our project!
>>
> Congratulations Mritunjay :)
>
>>
>> Thank you so much to the community for understanding my concern
>> and allowing me to take a break from 31st July to 3rd August.
>>
>> I am resuming my work from today and will start a new thread
>> to ask the doubts after proper research work!
>>
>> Thanks
>> Mritunjay
>> ___
>> 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: Updates of Smart India Hackathon 2020 Finale

[Chris Johns]

Well done, that is a great result.

On 5/8/20 8:13 am, Joel Sherrill wrote:
> Congratulations! That's awesome!
> 
> On Tue, Aug 4, 2020 at 4:01 PM Eshan Dhawan  > wrote:
> 
> 
> 
> On Wed, Aug 5, 2020 at 2:18 AM Mritunjay Sharma
> mailto:mritunjaysharma...@gmail.com>> 
> wrote:
> 
> Hello everyone! 
> 
> I feel elated to share with the community that my Team 'Altruist'
> won the first Prize in the Grand Finale of the World's 
> Biggest Hackathon - Smart India Hackathon 2020! We will not
> only be awarded with INR 100,000 but also the Government of India
> will help us to scale our project! 
> 
> Congratulations Mritunjay :)
> 
> 
> Thank you so much to the community for understanding my concern 
> and allowing me to take a break from 31st July to 3rd August. 
> 
> I am resuming my work from today and will start a new thread
> to ask the doubts after proper research work! 
> 
> Thanks
> Mritunjay
> ___
> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: unused static functions

[Chris Johns]

On 5/8/20 3:28 am, Joel Sherrill wrote:
> On Tue, Aug 4, 2020 at 11:12 AM Gedare Bloom  > wrote:
> 
> Hello Aschref Ben thabet,
> 
> On Tue, Aug 4, 2020 at 6:35 AM Aschref Ben-Thabet
>  > wrote:
> >
> > Dear RTEMS developers Team,
> > i am a new member focusing now on fixing the GCC10 warnings 
> Compiler.this
> last has told that these both functions are declared but not used.
> > In /rtems/testsuites/libtests/dl10/dl-load.c,the test file includes this
> both functions without further use. that can generate a warning like
> Wunused-function.
> > can you tell me please for which issue are these static functions in 
> this
> test file declared, and when they have any effect in the test, is it 
> helpful
> to erase them (it fixes the warning)?
> 
> I think these functions are just copied from other dltests. Chris
> Johns may comment on their elimination.
> 
> You would want to look at the purpose of the test, and how similar
> tests are structured. Was it a mistake not to call these functions? Or
> are they not needed for this test?
> 
> The inclusion of these may generate special relocation records. Chris
> would know that.
> 
> If they have to be there, there are examples on how to disable a specific
> warning around a block of code.  

They are as Gedare says just copied over and not clean up. They can be removed.

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

Re: legacy stack or libbsd

[Chris Johns]

On 5/8/20 2:04 am, Heinz Junkes wrote:
> Because the libbsd stack does not support some things yet (e.g. ntp) 

I have PTP running on libbsd. I currently have no time (ha) to clean up the work
and create a patch. It requires some extra support in the score.

> I have to call different 
> functions at rtems_init in EPICS. Therefore, when building EPICS for a 
> target, I need
> to know which stack the target was built with. 

The rtems_waf waf checks the header file. The compile check is:

https://git.rtems.org/rtems_waf/tree/rtems.py#n355

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

Re: legacy stack or libbsd

[Chris Johns]

On 5/8/20 10:23 am, Chris Johns wrote:
> On 5/8/20 2:04 am, Heinz Junkes wrote:
>> Because the libbsd stack does not support some things yet (e.g. ntp) 
> 
> I have PTP running on libbsd. I currently have no time (ha) to clean up the 
> work
> and create a patch. It requires some extra support in the score.
> 
>> I have to call different 
>> functions at rtems_init in EPICS. Therefore, when building EPICS for a 
>> target, I need
>> to know which stack the target was built with. 
> 
> The rtems_waf waf checks the header file. The compile check is:
> 
> https://git.rtems.org/rtems_waf/tree/rtems.py#n355

I should also add rtems_waf detects libbsd with the following header check ...

https://git.rtems.org/rtems_waf/tree/rtems_bsd.py#n88

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

Re: legacy stack or libbsd

[Gedare Bloom]

On Tue, Aug 4, 2020 at 6:41 PM Chris Johns  wrote:
>
> On 5/8/20 10:23 am, Chris Johns wrote:
> > On 5/8/20 2:04 am, Heinz Junkes wrote:
> >> Because the libbsd stack does not support some things yet (e.g. ntp)
> >
> > I have PTP running on libbsd. I currently have no time (ha) to clean up the 
> > work
Is it precisely no time? ;)

> > and create a patch. It requires some extra support in the score.
> >
Is the hacked approach available, or you will get around to it eventually?

> >> I have to call different
> >> functions at rtems_init in EPICS. Therefore, when building EPICS for a 
> >> target, I need
> >> to know which stack the target was built with.
> >
> > The rtems_waf waf checks the header file. The compile check is:
> >
> > https://git.rtems.org/rtems_waf/tree/rtems.py#n355
>
> I should also add rtems_waf detects libbsd with the following header check ...
>
> https://git.rtems.org/rtems_waf/tree/rtems_bsd.py#n88
>
> 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: [PATCH] smpschededf02: Document reset() function

[Sebastian Huber]

On 04/08/2020 16:23, Richi Dubey wrote:

Thanks.

So for the code:
--
   for (i = 0; i < CPU_COUNT; ++i) {
     const Per_CPU_Control *c;
     const Thread_Control *h;

     c = _Per_CPU_Get_by_index(CPU_COUNT - 1 - i);
     h = c->heir;

     sc = rtems_task_suspend(h->Object.id);
     rtems_test_assert(sc == RTEMS_SUCCESSFUL);
   }
--
  would it have the same effect if we replace all this by :

   for (i = CPU_COUNT -1 ; i >=0 ; --i) {
     sc = rtems_task_suspend(ctx->task_ids[i]);
     rtems_test_assert(sc == RTEMS_SUCCESSFUL);
   }
--

Please let me know.


No, it would not have the same effect in general. You can try to change 
it and see if the test fails or not.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: legacy stack or libbsd

[Chris Johns]

On 5/8/20 2:13 pm, Gedare Bloom wrote:
> On Tue, Aug 4, 2020 at 6:41 PM Chris Johns  wrote:
>>
>> On 5/8/20 10:23 am, Chris Johns wrote:
>>> On 5/8/20 2:04 am, Heinz Junkes wrote:
 Because the libbsd stack does not support some things yet (e.g. ntp)
>>>
>>> I have PTP running on libbsd. I currently have no time (ha) to clean up the 
>>> work
> Is it precisely no time? ;)

About +/- 0, I am not sure which!

>>> and create a patch. It requires some extra support in the score.
>>>
> Is the hacked approach available, or you will get around to it eventually?

I will get back around to it. There are 2 sets of changes. In PTP itself a
change is to add kqueue support because select in libbsd does not support
signals. The PTP code runs a number of timers and they run of an alarm signal.
The other piece of support is to the score to bring in the FreeBSD kern_ntp
support to sit besides the timercounters.

There will be some unresolved issues like RTC driver support. I have this
commented out as I do not need it.

I would like to upstream the code however adding kqueue will trip that interface
on FreeBSD and may be others so I am not sure how much work that will create.

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

Re: [PATCH rtems-libbsd 2/2] wscript: add uninstall command

[Chris Johns]

On 5/8/20 1:52 am, Vijay Kumar Banerjee wrote:
> Hi Chris,
> 
> Is this patch OK to push to the master?

Yes, please push. I am sorry about the slow review.

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