Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Heinz Junkes]

Thanks Chris for the explanation. It all makes sense.

I stumbled over the following point:

I tested the rc-2 and followed the Quick Guide to Building.
“
To build the tools for the ARM architecture:

../source-builder/sb-set-builder \
  --prefix=$HOME/development/rtems/5.1-rc2 \
  5/rtems-arm

To build the tools, kernel and all packages for the Beagleboneblack:

../source-builder/sb-set-builder \
  --prefix=$HOME/development/rtems/5.1-rc2 \
  5/bsps/beagleboneblack
“

After that I tried to build EPICS and ran into the error of a missing header 
file.
“librtemsNFS.h could not be found”
This header file is in rtems-libbsd which I then had to reinstall and build for 
the target.

Then I thought about whether a recipe could/should consider this dependency.

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



> On 24. Aug 2020, at 01:59, Chris Johns  wrote:
> 
> On 24/8/20 12:38 am, Heinz Junkes wrote:
>> But shouldn't the dependencies for the RTEMS basic installation
>> be taken into account. 
> 
> Dependences are normally checked by the application, package or tool being
> built. In the case of EPICS it should check for a suitable RTEMS, libbsd etc 
> and
> configure itself. Given the high quality of the EPICS software I have assumed 
> it
> does this. The RSB can perform some checks but these are limited and specific.
> If we need to we can add something.
> 
> The RSB builds something based on a recipe someone creates. You can collect 
> one
> or more of these recipes as a set of things to build. You can collect sets of
> things to build as a further set creating a vertical stack of software. A
> vertical stack is one of those classic software stack pictures with the 
> hardware
> at the bottom, then the drivers and OS, networking, protocols, middle-ware and
> an application at the top.
> 
> The RSB is a tool in the RTEMS eco-system that can build a vertical stack for 
> a
> BSP, for example a beagleboneblack or zedboard or you can break down a 
> vertical
> stack to manage and customise any of the steps for your specific needs.
> 
> Customising the steps lets a project, company, who ever create a build set 
> that
> targets a specific configuration for a selected board or sets of boards. A
> company, a large organisation or EPICS can also do this. We call it 
> deployment.
> 
> As an open source project we learnt a hard lesson that supporting deployment 
> is
> a whole project in itself. Deploy is really important but it became a
> distraction from our core focus, the OS and the kernel, consuming more and 
> more
> of our resources. As a result we have focused on tools that help users do 
> this.
> We also welcome commercial support services to do this for users.
> 
>> Maybe I don't understand the purpose of the source-builder.
> 
> This could be due to it's role not being explained clearly. I hope this post 
> helps.
> 
>> But I thought that the necessary rtems-modules (compiler for architecture, 
>> libbsd, etc.) are checked and if something is missing, they are installed?
> 
> The depends on the how the vertical stack is put together. The EPICS build set
> should concentrate on EPICS. Now Mritunjay has included the RSB's
> `rtems-bsp.cfg` BSP configuration file some checks will be made. Once we have
> EPICS building as a package we can move to discuss if it becomes part of the
> default package set the BSPs build set's build:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/6/rtems-packages.bset
> 
> The packages are pull in on the last line of of a BSP build set:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/bsps/xilinx_zynq_zedboard.bset
> 
> Integration like this has and still is a long term goal Joel and I have. We
> would like EPICS to sit here with NASA's core flight executive so the bar is 
> as
> low as possible to have these important software packages build ready to run.
> 
>> And when do the tests (epics: make runtests and qemu) come into play? 
> 
> This is something we will need to address. The RSB cleans a build environment
> once it completes a build. The model is unpack source, patch, configure, 
> build,
> install, and then clean. In the case of the RTEMS kernel the test executables
> are optionally installed so a user can run them:
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-common.cfg#n255
> 
> How is EPICS used in real systems? Is the production executable built by EPICS
> from the EPICS source tree? Is it a set of libraries that get installed and an
> application links in these libraries?
> 
> Chris



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

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

[Niteesh G. S.]

ping.

On Sat, Aug 22, 2020 at 10:15 PM Niteesh G. S.  wrote:

> Hello,
>
> I went through the history of the OF implementation in NetBSD and FreeBSD.
> I have summarized the things I have found out below.
>
> The first OF implementation seems to come from NetBSD this is actually
> BSD-4
> licensed. FreeBSD and also other BSD have used this as the base and
> improved
> the API. For eg functions like OF_getprop_allloc_multi, OF_getencprop were
> not
> present in the original OF interface but were added by FreeBSD. And also
> NetBSD
> doesn't use KOBJS for function dispatch but rather uses platform-specific
> OF
> implementation, that is FDT implementation is present under
> sys/dev/fdt/fdt_openfirm.c
> powerPC implementation under arch/powerpc/openfirm.c.
> NetBSD openfirm.h:
> https://github.com/NetBSD/src/blob/trunk/sys/dev/ofw/openfirm.h
> And I think was adding the OF interface FreeBSD has added the BSD-2
> license.
>
>
> https://github.com/freebsd/freebsd/commit/d84d862cbd66f3f9ab4ce65fe69893664689c73b
> This is the commit where they have added OF interface to FreeBSD and from
> the
> commit it seems like they have added the BSD-2 license with the interface
> itself.
> And the functions where we worry about the similarity are all FreeBSD
> extension
> so I guess we won't have any issue since they would come under BSD-2
> license.
>
>
> Thanks,
> Niteesh.
>
> On Sat, Aug 22, 2020 at 7:23 PM Gedare Bloom  wrote:
>
>> On Fri, Aug 21, 2020 at 11:26 AM Niteesh G. S. 
>> wrote:
>> >
>> >
>> >
>> > On Fri, Aug 21, 2020 at 9:38 PM Gedare Bloom  wrote:
>> >>
>> >> Hi Niteesh,
>> >>
>> >> Can you explain how you developed the new code in a way that ensures
>> >> that we do not have any of the previously 4-BSD licensed code left?
>> >
>> > The FDT implementation of the OF interface present is ofw_fdt.c is,
>> fortunately,
>> > BSD-2 licensed so I was able to copy/reuse most of it for RTEMS ofw.c
>> >
>> > The interface(openfirm.h) and the implementation(opefirm.c) that calls
>> the
>> > respective KOBJs functions are BSD-4 licensed. Since it was mentioned
>> that
>> > copying the interface is fine I don't think there is an issue with it.
>> The OF
>> > interface in RTEMS is present in ofw_compat.h
>> >
>> > I also want to make note of one thing, there are few functions in ofw.c
>> > which look exactly the same as the ones present in openfirm.c can you
>> > please make sure that these functions won't cause any issues.
>> > Few examples are, rtems_ofw_get_enc_prop_alloc,
>> rtems_ofw_get_enc_prop_alloc_multi.
>> >
>> The similarity in these functions is problematic.
>>
>> I still think it would be worth the trouble to try to dig through the
>> history to find exactly what code was introduced with the 4-bsd. I
>> would guess that came out of netbsd.
>>
>> > Thanks,
>> > Niteesh.
>> >
>> >>
>> >> Gedare
>> >>
>> >> On Thu, Aug 20, 2020 at 1:52 AM G S Niteesh Babu 
>> wrote:
>> >> >
>> >> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
>> >> > interface. This API is created to be compatible with FreeBSD
>> >> > OpenFirmWare interface. The main intention is to make
>> >> > porting of FreeBSD drivers to RTEMS easier.
>> >> >
>> >> > Most functions implemented have an direct one-one mapping
>> >> > with the original OFW API and some extra auxiliary functions
>> >> > were implemented to make working with device trees easier in
>> >> > RTEMS.
>> >> >
>> >> > Update #3784
>> >> > ---
>> >> >  bsps/include/ofw/ofw.h| 548 +++
>> >> >  bsps/include/ofw/ofw_compat.h |  74 
>> >> >  bsps/shared/ofw/ofw.c | 670
>> ++
>> >> >  spec/build/bsps/obj.yml   |   4 +
>> >> >  4 files changed, 1296 insertions(+)
>> >> >  create mode 100644 bsps/include/ofw/ofw.h
>> >> >  create mode 100644 bsps/include/ofw/ofw_compat.h
>> >> >  create mode 100644 bsps/shared/ofw/ofw.c
>> >> >
>> >> > diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
>> >> > new file mode 100644
>> >> > index 00..50f64ff695
>> >> > --- /dev/null
>> >> > +++ b/bsps/include/ofw/ofw.h
>> >> > @@ -0,0 +1,548 @@
>> >> > +/* SPDX-License-Identifier: BSD-2-Clause */
>> >> > +
>> >> > +/**
>> >> > + * @file
>> >> > + *
>> >> > + * @ingroup ofw
>> >> > + *
>> >> > + * RTEMS FDT implementation of OpenFirmWare Interface.
>> >> > + *
>> >> > + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
>> interface.
>> >> > + * This API is created to be compatible with FreeBSD OpenFirmWare
>> interface.
>> >> > + * The main intention is to make porting of FreeBSD drivers to
>> RTEMS easier.
>> >> > + */
>> >> > +
>> >> > +/*
>> >> > + * Copyright (C) 2020 Niteesh Babu G S 
>> >> > + *
>> >> > + * 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 lis

mmap shared stack design was: [PATCH v4 1/3] Strict thread-stack isolation

[Gedare Bloom]

On Sat, Aug 22, 2020 at 11:27 PM Utkarsh Rai  wrote:
>
>
>
> On Sat, Aug 22, 2020 at 11:32 PM Gedare Bloom  wrote:
>>
>> I have some comments below. I'm not that happy with the lack of design
>> discussion during the iteration of this code. While it is a little
>> easier to critique the code, it is also a bit wasteful because I have
>> to also comment on stylistic problems, and when some decisions you
>> make while coding end up not being correct or aren't easily understood
>> during code review then you might have to spend more time recoding. It
>> can be hard to find the balance between design and code reviews,
>>
>> On Sat, Aug 22, 2020 at 9:19 AM Utkarsh Rai  wrote:
>> > +
>> > +#if defined ( RTEMS_THREAD_STACK_PROTECTION )
>> > +
>> > +/**
>> > + * The following defines the control block  of a shared stack. Each stack 
>> > can have
>> > + * different sharing attributes.
>> > + */
>> > +typedef struct
>> > +{
>> > +  /** Access flags of the shared stack */
>> > +  uint32_t access_flags;
>> > +  /** This is the stack address of the sharing thread*/
>> > +  void* shared_stack_area;
>> > +  /** Stack size of the sharing thread*/
>> > +  size_t shared_stack_size;
>> > +  /** This is the stack address of the target stack. Maybe this area is 
>> > not
>> > +   * needed but this helps in selecting the target thread during stack 
>> > sharing.
>> > +   */
>> > +  void* target_stack_area;
>> I'm confused about the difference between shared_stack_area and
>> target_stack_area
>>
>> > + /** Error checking for valid target stack address. This is also used to
>> > +  * distinguish between a normal mmap operation and a stack sharing 
>> > operation.
>> > +  */
>> I don't really know what this means.
>
>
> This is related to the mmap() call. When we share stack using mmap,  two of 
> the important parameters that reference to the target thread-stack
> and sharing thread-stack are -'void* addr' which is the address of the target 
> thread stack and 'int fd' that is the file descriptor to the shared memory
> object corresponding to the thread stack being shared. Now, stack sharing is 
> different from a normal mmap operation in the sense that we need to add
> the sharing stack attributes to the stack control structure of the thread 
> that is specified by 'addr' as compared to adding it to the chain of 
> mappings. To select the
> target thread we need to iterate over all the threads, in the case we do not 
> find any thread, we can proceed with our normal mmap operation otherwise we 
> add the
> sharing thread stack attribute to the stack control structure of the target 
> thread. We have the _Thread_Iterate() function but it only has two parameters 
> the pointer to the
> function that performs operation during each iteration and a parameter 
> related to this operation. My decision to specify the 'target_stack_area',  
> the 'shared_stack_area' and 'stack_shared' in the structure
> was so that I could squeeze in as much information to select the thread,  set 
> the sharing stack parameters in the thread,  and validate(through 
> stack_shared attribute) in the mmap() call that this is
> in fact a stack-sharing operation, in a single iteration.
>

Maybe I should ask this on the mmap patch itself, but I'm more
interested in the design than the code right now. I think I'll just
ask a few questions:

The 'sharing' stack is the stack that is getting r/w permission added
to another thread, and the 'target' thread is the thread that is
getting the r/w permission to access the shared stack. We should not
really care about the 'sharing thread' or the 'target stack'?

If mmap() assumes the calling context then the executing thread is the
"target thread" and you shouldn't have to search for it? In typical
POSIX implementations, mmap() assumes the executing process context
called it, but can we make the same assumption?

For mmap() the 'addr' should be the 'sharing' stack's (base) address
not the 'target' stack, because you want to be accessing the 'sharing'
stack memory? We don't have any virtual memory mapping, so the address
of the sharing stack needs to be used. Or maybe it can be NULL, or
even ignored, since the mmap() call should return the base address of
the 'sharing' stack? The fd should be able to find all the information
needed about the 'sharing' stack.

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

[PATCH v2] Pre Release: Strong APA

[Richi Dubey]

---
 cpukit/include/rtems/scheduler.h  |   6 +-
 .../include/rtems/score/schedulerstrongapa.h  | 284 --
 cpukit/score/src/schedulerstrongapa.c | 913 ++
 3 files changed, 901 insertions(+), 302 deletions(-)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index 955a83cfb4..b101842ba7 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -257,16 +257,14 @@
   #define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ) \
 static struct { \
   Scheduler_strong_APA_Context Base; \
-  Chain_ControlReady[ ( prio_count ) ]; \
+  Scheduler_strong_APA_Struct Struct[ CONFIGURE_MAXIMUM_PROCESSORS ]; \
 } SCHEDULER_STRONG_APA_CONTEXT_NAME( name )
 
   #define RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name ) \
 { \
   &SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Base.Base.Base, \
   SCHEDULER_STRONG_APA_ENTRY_POINTS, \
-  RTEMS_ARRAY_SIZE( \
-SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
-  ) - 1, \
+  SCHEDULER_STRONG_APA_MAXIMUM_PRIORITY, \
   ( obj_name ) \
   SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
diff --git a/cpukit/include/rtems/score/schedulerstrongapa.h 
b/cpukit/include/rtems/score/schedulerstrongapa.h
index 0ac28cb439..86d91688e8 100644
--- a/cpukit/include/rtems/score/schedulerstrongapa.h
+++ b/cpukit/include/rtems/score/schedulerstrongapa.h
@@ -6,31 +6,38 @@
  * @brief Strong APA Scheduler API
  */
 
-/*
- * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
+/* 
+ * Copyright (c) 2020 Richi Dubey
  *
- *  embedded brains GmbH
- *  Dornierstr. 4
- *  82178 Puchheim
- *  Germany
- *  
+ *  
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
+ * Copyright (c) 2013, 2018 embedded brains GmbH. All rights reserved.
+ *
+ *  embedded brains GmbH   
+ *  Dornierstr. 4  
+ *  82178 Puchheim 
+ *  Germany
+ *   
+ * 
+ * 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.
  */
-
+ 
 #ifndef _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 #define _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 
 #include 
-#include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
 
+#define STRONG_SCHEDULER_NODE_OF_CHAIN( node ) \
+  RTEMS_CONTAINER_OF( next, Scheduler_strong_APA_Node, Chain )
+
 /**
  * @defgroup RTEMSScoreSchedulerStrongAPA Strong APA Scheduler
  *
@@ -38,43 +45,98 @@ extern "C" {
  *
  * @brief Strong APA Scheduler
  *
- * This is an implementation of the global fixed priority scheduler (G-FP).  It
- * uses one ready chain per priority to ensure constant time insert operations.
- * The scheduled chain uses linear insert operations and has at most processor
- * count entries.  Since the processor and priority count are constants all
- * scheduler operations complete in a bounded execution time.
+ * This is an implementation of the Strong APA scheduler defined by
+ * Cerqueira et al. in Linux's Processor Affinity API, Refined: 
+ * Shifting Real-Time Tasks Towards Higher Schedulability.
  *
- * The the_thread preempt mode will be ignored.
+ * This is an implementation of the Strong APA scheduler defined by
+ * Cerqueira et al. in Linux's Processor Affinity API, Refined: 
+ * Shifting Real-Time Tasks Towards Higher Schedulability.
  *
  * @{
  */
 
 /**
- * @brief Scheduler context specialization for Strong APA
- * schedulers.
- */
-typedef struct {
-  Scheduler_SMP_ContextBase;
-  Priority_bit_map_Control Bit_map;
-  Chain_ControlReady[ RTEMS_ZERO_LENGTH_ARRAY ];
-} Scheduler_strong_APA_Context;
-
-/**
- * @brief Scheduler node specialization for Strong APA
- * schedulers.
+ * @brief Scheduler node specialization for Strong APA schedulers.
  */
 typedef struct {
   /**
* @brief SMP scheduler node.
*/
   Scheduler_SMP_Node Base;
+  
+ /**
+   * @brief Chain node for Scheduler_strong_APA_Context::All_nodes
+   */
+  Chain_Node Chain;
+  
+  /**
+   * @brief CPU that this node would preempt in the backtracking part of
+   * _Scheduler_strong_APA_Get_highest_ready and
+   * _Scheduler_strong_APA_Do_Enqueue.
+   */
+  Per_CPU_Control *invoker;
 
   /**
-   * @brief The associated ready queue of this node.
+   * @brief The associated affinity set of this node.
*/
-  Scheduler_priority_Ready_queue Ready_queue;
+  Processor_mask Affinity;
 } Scheduler_strong_APA_Node;
 
+
+/**
+ * @brief Struct for each index of the variable size arrays
+ */
+typedef struct
+{
+  /**
+   * @brief The node that called this CPU, i.e. a node which has
+   * the cpu at the index of Scheduler_strong_APA_Context::Struct in
+   * its affinity set.
+   */  
+  Scheduler_Node *caller;
+  
+/**
+   * @brief Cpu at the index of Scheduler_strong_APA_Context::Struct
+   * in Queue imp

Re: Pre release version: Strong APA Scheduler

[Richi Dubey]

Hi,

Please refer to this patch
https://lists.rtems.org/pipermail/devel/2020-August/061572.html for
reviewing my code. This new patch has some indentation corrections and
minor code fixes that I missed looking at earlier. The pull request remains
the same and can be used too.

Thank you,
Richi.

On Sun, Aug 23, 2020 at 3:33 AM Richi Dubey  wrote:

> v1 should point to the link:
> https://lists.rtems.org/pipermail/devel/2020-July/060645.html
>
> On Sun, Aug 23, 2020 at 3:27 AM Richi Dubey  wrote:
>
>> Hi,
>>
>> I am really excited to annonunce the pre-release verion of Strong APA
>> Scheduer for RTEMS that we've been working so hard for!
>>
>> The documentation for the scheduler is now live at :
>> https://richidubey.github.io/Strong-APA-Documentation/html/
>>
>> To understand how the code works, please go through these links (in
>> order):
>>
>> Documentation for Struct defined for various uses
>> 
>> Changes for Enqueue
>> 
>> Changes for Get_highest_ready
>> 
>>
>> Improvements over v1
>> 
>>  (after
>> last  review):
>>
>> - Better coding style and variable naming
>> - Better documentation
>> - Successfully runs the Strong APA test
>> 
>>
>> Plans for v2:
>>
>> - Use chain of scheduled nodes present in SMP Context rather than per cpu
>> variables based on this
>> 
>> discussion
>> - Work on the reviews
>>
>> I would request you to provide your reviews on whether the variables
>> names that I chose makes sense (like the array Struct) and if my code
>> follows the coding conventions. Also, please let me know if there's
>> anything that's still looks wrong in the code.
>>
>> Please use this
>>  patch
>> or this  pull request to
>> checkout my changes.
>>
>> Thanks,
>> Richi.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Gedare Bloom]

On Mon, Aug 24, 2020 at 8:34 AM Heinz Junkes  wrote:
>
> Thanks Chris for the explanation. It all makes sense.
>
> I stumbled over the following point:
>
> I tested the rc-2 and followed the Quick Guide to Building.
> “
> To build the tools for the ARM architecture:
>
> ../source-builder/sb-set-builder \
>   --prefix=$HOME/development/rtems/5.1-rc2 \
>   5/rtems-arm
>
> To build the tools, kernel and all packages for the Beagleboneblack:
>
> ../source-builder/sb-set-builder \
>   --prefix=$HOME/development/rtems/5.1-rc2 \
>   5/bsps/beagleboneblack
> “
>
> After that I tried to build EPICS and ran into the error of a missing header 
> file.
> “librtemsNFS.h could not be found”
> This header file is in rtems-libbsd which I then had to reinstall and build 
> for the target.
>
I believe 5/bsps/beagleboneblack should build and install the libbsd
with it. Something may have gone wrong?

> Then I thought about whether a recipe could/should consider this dependency.
>
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
>
>
>
> > On 24. Aug 2020, at 01:59, Chris Johns  wrote:
> >
> > On 24/8/20 12:38 am, Heinz Junkes wrote:
> >> But shouldn't the dependencies for the RTEMS basic installation
> >> be taken into account.
> >
> > Dependences are normally checked by the application, package or tool being
> > built. In the case of EPICS it should check for a suitable RTEMS, libbsd 
> > etc and
> > configure itself. Given the high quality of the EPICS software I have 
> > assumed it
> > does this. The RSB can perform some checks but these are limited and 
> > specific.
> > If we need to we can add something.
> >
> > The RSB builds something based on a recipe someone creates. You can collect 
> > one
> > or more of these recipes as a set of things to build. You can collect sets 
> > of
> > things to build as a further set creating a vertical stack of software. A
> > vertical stack is one of those classic software stack pictures with the 
> > hardware
> > at the bottom, then the drivers and OS, networking, protocols, middle-ware 
> > and
> > an application at the top.
> >
> > The RSB is a tool in the RTEMS eco-system that can build a vertical stack 
> > for a
> > BSP, for example a beagleboneblack or zedboard or you can break down a 
> > vertical
> > stack to manage and customise any of the steps for your specific needs.
> >
> > Customising the steps lets a project, company, who ever create a build set 
> > that
> > targets a specific configuration for a selected board or sets of boards. A
> > company, a large organisation or EPICS can also do this. We call it 
> > deployment.
> >
> > As an open source project we learnt a hard lesson that supporting 
> > deployment is
> > a whole project in itself. Deploy is really important but it became a
> > distraction from our core focus, the OS and the kernel, consuming more and 
> > more
> > of our resources. As a result we have focused on tools that help users do 
> > this.
> > We also welcome commercial support services to do this for users.
> >
This is excellent and should be refactored to add in
https://docs.rtems.org/branches/master/user/rsb/index.html#source-builder

> >> Maybe I don't understand the purpose of the source-builder.
> >
> > This could be due to it's role not being explained clearly. I hope this 
> > post helps.
> >
> >> But I thought that the necessary rtems-modules (compiler for architecture, 
> >> libbsd, etc.) are checked and if something is missing, they are installed?
> >
> > The depends on the how the vertical stack is put together. The EPICS build 
> > set
> > should concentrate on EPICS. Now Mritunjay has included the RSB's
> > `rtems-bsp.cfg` BSP configuration file some checks will be made. Once we 
> > have
> > EPICS building as a package we can move to discuss if it becomes part of the
> > default package set the BSPs build set's build:
> >
> > https://git.rtems.org/rtems-source-builder/tree/rtems/config/6/rtems-packages.bset
> >
> > The packages are pull in on the last line of of a BSP build set:
> >
> > https://git.rtems.org/rtems-source-builder/tree/rtems/config/bsps/xilinx_zynq_zedboard.bset
> >
> > Integration like this has and still is a long term goal Joel and I have. We
> > would like EPICS to sit here with NASA's core flight executive so the bar 
> > is as
> > low as possible to have these important software packages build ready to 
> > run.
> >
> >> And when do the tests (epics: make runtests and qemu) come into play?
> >
> > This is something we will need to address. The RSB cleans a build 
> > environment
> > once it completes a build. The model is unpack source, patch, configure, 
> > build,
> > install, and then clean. In the case of the RTEMS kernel the test 
> > executables
> > are optionally installed so a user can run them:
> >
> > https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-common.cfg#n255
> >
> > How is EPICS used in real systems? Is the production executable bu

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

[Gedare Bloom]

On Mon, Aug 24, 2020 at 8:42 AM Niteesh G. S.  wrote:
>
> ping.
>
pong. Most of us don't volunteer our time on the weekends. Some people
and open-source projects may, and I understand that the timeline for
finishing your project is getting tight, but you do want to be
courteous about other people's time. It is in general our most
precious commodity.

> On Sat, Aug 22, 2020 at 10:15 PM Niteesh G. S.  wrote:
>>
>> Hello,
>>
>> I went through the history of the OF implementation in NetBSD and FreeBSD.
>> I have summarized the things I have found out below.
>>
>> The first OF implementation seems to come from NetBSD this is actually BSD-4
>> licensed. FreeBSD and also other BSD have used this as the base and improved
>> the API. For eg functions like OF_getprop_allloc_multi, OF_getencprop were 
>> not
>> present in the original OF interface but were added by FreeBSD. And also 
>> NetBSD
>> doesn't use KOBJS for function dispatch but rather uses platform-specific OF
>> implementation, that is FDT implementation is present under 
>> sys/dev/fdt/fdt_openfirm.c
>> powerPC implementation under arch/powerpc/openfirm.c.
>> NetBSD openfirm.h: 
>> https://github.com/NetBSD/src/blob/trunk/sys/dev/ofw/openfirm.h
>> And I think was adding the OF interface FreeBSD has added the BSD-2 license.
>>
>> https://github.com/freebsd/freebsd/commit/d84d862cbd66f3f9ab4ce65fe69893664689c73b
>> This is the commit where they have added OF interface to FreeBSD and from the
>> commit it seems like they have added the BSD-2 license with the interface 
>> itself.
>> And the functions where we worry about the similarity are all FreeBSD 
>> extension
>> so I guess we won't have any issue since they would come under BSD-2 license.
>>
I think you could attempt to 'match' the imported 4-BSD code to any
current code, and remove it. see what is left.

Alternately, you can copy the code that you know came from commits
with 2-BSD code and see what gaps remain at the end.

My intuition here is that there are few if any original lines of code
left from that first 4-bsd import from NetBSD.

>>
>> Thanks,
>> Niteesh.
>>
>> On Sat, Aug 22, 2020 at 7:23 PM Gedare Bloom  wrote:
>>>
>>> On Fri, Aug 21, 2020 at 11:26 AM Niteesh G. S.  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Aug 21, 2020 at 9:38 PM Gedare Bloom  wrote:
>>> >>
>>> >> Hi Niteesh,
>>> >>
>>> >> Can you explain how you developed the new code in a way that ensures
>>> >> that we do not have any of the previously 4-BSD licensed code left?
>>> >
>>> > The FDT implementation of the OF interface present is ofw_fdt.c is, 
>>> > fortunately,
>>> > BSD-2 licensed so I was able to copy/reuse most of it for RTEMS ofw.c
>>> >
>>> > The interface(openfirm.h) and the implementation(opefirm.c) that calls the
>>> > respective KOBJs functions are BSD-4 licensed. Since it was mentioned that
>>> > copying the interface is fine I don't think there is an issue with it. 
>>> > The OF
>>> > interface in RTEMS is present in ofw_compat.h
>>> >
>>> > I also want to make note of one thing, there are few functions in ofw.c
>>> > which look exactly the same as the ones present in openfirm.c can you
>>> > please make sure that these functions won't cause any issues.
>>> > Few examples are, rtems_ofw_get_enc_prop_alloc, 
>>> > rtems_ofw_get_enc_prop_alloc_multi.
>>> >
>>> The similarity in these functions is problematic.
>>>
>>> I still think it would be worth the trouble to try to dig through the
>>> history to find exactly what code was introduced with the 4-bsd. I
>>> would guess that came out of netbsd.
>>>
>>> > Thanks,
>>> > Niteesh.
>>> >
>>> >>
>>> >> Gedare
>>> >>
>>> >> On Thu, Aug 20, 2020 at 1:52 AM G S Niteesh Babu  
>>> >> wrote:
>>> >> >
>>> >> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
>>> >> > interface. This API is created to be compatible with FreeBSD
>>> >> > OpenFirmWare interface. The main intention is to make
>>> >> > porting of FreeBSD drivers to RTEMS easier.
>>> >> >
>>> >> > Most functions implemented have an direct one-one mapping
>>> >> > with the original OFW API and some extra auxiliary functions
>>> >> > were implemented to make working with device trees easier in
>>> >> > RTEMS.
>>> >> >
>>> >> > Update #3784
>>> >> > ---
>>> >> >  bsps/include/ofw/ofw.h| 548 +++
>>> >> >  bsps/include/ofw/ofw_compat.h |  74 
>>> >> >  bsps/shared/ofw/ofw.c | 670 ++
>>> >> >  spec/build/bsps/obj.yml   |   4 +
>>> >> >  4 files changed, 1296 insertions(+)
>>> >> >  create mode 100644 bsps/include/ofw/ofw.h
>>> >> >  create mode 100644 bsps/include/ofw/ofw_compat.h
>>> >> >  create mode 100644 bsps/shared/ofw/ofw.c
>>> >> >
>>> >> > diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
>>> >> > new file mode 100644
>>> >> > index 00..50f64ff695
>>> >> > --- /dev/null
>>> >> > +++ b/bsps/include/ofw/ofw.h
>>> >> > @@ -0,0 +1,548 @@
>>> >> > +/* SPDX-License-Identifier: BSD-2-Clause */
>>> >> > +
>>> >>

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

[Niteesh G. S.]

On Mon, Aug 24, 2020 at 9:53 PM Gedare Bloom  wrote:

> On Mon, Aug 24, 2020 at 8:42 AM Niteesh G. S. 
> wrote:
> >
> > ping.
> >
> pong. Most of us don't volunteer our time on the weekends. Some people
> and open-source projects may, and I understand that the timeline for
> finishing your project is getting tight, but you do want to be
> courteous about other people's time. It is in general our most
> precious commodity.
>

I am really sorry for pinging so quickly. I just wanted to get this
ready before the deadline.


> > On Sat, Aug 22, 2020 at 10:15 PM Niteesh G. S. 
> wrote:
> >>
> >> Hello,
> >>
> >> I went through the history of the OF implementation in NetBSD and
> FreeBSD.
> >> I have summarized the things I have found out below.
> >>
> >> The first OF implementation seems to come from NetBSD this is actually
> BSD-4
> >> licensed. FreeBSD and also other BSD have used this as the base and
> improved
> >> the API. For eg functions like OF_getprop_allloc_multi, OF_getencprop
> were not
> >> present in the original OF interface but were added by FreeBSD. And
> also NetBSD
> >> doesn't use KOBJS for function dispatch but rather uses
> platform-specific OF
> >> implementation, that is FDT implementation is present under
> sys/dev/fdt/fdt_openfirm.c
> >> powerPC implementation under arch/powerpc/openfirm.c.
> >> NetBSD openfirm.h:
> https://github.com/NetBSD/src/blob/trunk/sys/dev/ofw/openfirm.h
> >> And I think was adding the OF interface FreeBSD has added the BSD-2
> license.
> >>
> >>
> https://github.com/freebsd/freebsd/commit/d84d862cbd66f3f9ab4ce65fe69893664689c73b
> >> This is the commit where they have added OF interface to FreeBSD and
> from the
> >> commit it seems like they have added the BSD-2 license with the
> interface itself.
> >> And the functions where we worry about the similarity are all FreeBSD
> extension
> >> so I guess we won't have any issue since they would come under BSD-2
> license.
> >>
> I think you could attempt to 'match' the imported 4-BSD code to any
> current code, and remove it. see what is left.
>
> Alternately, you can copy the code that you know came from commits
> with 2-BSD code and see what gaps remain at the end.
>

I'll do this.



> My intuition here is that there are few if any original lines of code
> left from that first 4-bsd import from NetBSD.
>
Yes. It is very little to almost no code that is BSD-4.



> >>
> >> Thanks,
> >> Niteesh.
> >>
> >> On Sat, Aug 22, 2020 at 7:23 PM Gedare Bloom  wrote:
> >>>
> >>> On Fri, Aug 21, 2020 at 11:26 AM Niteesh G. S. 
> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Aug 21, 2020 at 9:38 PM Gedare Bloom 
> wrote:
> >>> >>
> >>> >> Hi Niteesh,
> >>> >>
> >>> >> Can you explain how you developed the new code in a way that ensures
> >>> >> that we do not have any of the previously 4-BSD licensed code left?
> >>> >
> >>> > The FDT implementation of the OF interface present is ofw_fdt.c is,
> fortunately,
> >>> > BSD-2 licensed so I was able to copy/reuse most of it for RTEMS ofw.c
> >>> >
> >>> > The interface(openfirm.h) and the implementation(opefirm.c) that
> calls the
> >>> > respective KOBJs functions are BSD-4 licensed. Since it was
> mentioned that
> >>> > copying the interface is fine I don't think there is an issue with
> it. The OF
> >>> > interface in RTEMS is present in ofw_compat.h
> >>> >
> >>> > I also want to make note of one thing, there are few functions in
> ofw.c
> >>> > which look exactly the same as the ones present in openfirm.c can you
> >>> > please make sure that these functions won't cause any issues.
> >>> > Few examples are, rtems_ofw_get_enc_prop_alloc,
> rtems_ofw_get_enc_prop_alloc_multi.
> >>> >
> >>> The similarity in these functions is problematic.
> >>>
> >>> I still think it would be worth the trouble to try to dig through the
> >>> history to find exactly what code was introduced with the 4-bsd. I
> >>> would guess that came out of netbsd.
> >>>
> >>> > Thanks,
> >>> > Niteesh.
> >>> >
> >>> >>
> >>> >> Gedare
> >>> >>
> >>> >> On Thu, Aug 20, 2020 at 1:52 AM G S Niteesh Babu <
> niteesh...@gmail.com> wrote:
> >>> >> >
> >>> >> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
> >>> >> > interface. This API is created to be compatible with FreeBSD
> >>> >> > OpenFirmWare interface. The main intention is to make
> >>> >> > porting of FreeBSD drivers to RTEMS easier.
> >>> >> >
> >>> >> > Most functions implemented have an direct one-one mapping
> >>> >> > with the original OFW API and some extra auxiliary functions
> >>> >> > were implemented to make working with device trees easier in
> >>> >> > RTEMS.
> >>> >> >
> >>> >> > Update #3784
> >>> >> > ---
> >>> >> >  bsps/include/ofw/ofw.h| 548 +++
> >>> >> >  bsps/include/ofw/ofw_compat.h |  74 
> >>> >> >  bsps/shared/ofw/ofw.c | 670
> ++
> >>> >> >  spec/build/bsps/obj.yml   |   4 +
> >>> >> >  4 files changed, 1296 insertions(+)
> >>> >> >  cre

Re: mmap shared stack design was: [PATCH v4 1/3] Strict thread-stack isolation

[Utkarsh Rai]

On Mon, Aug 24, 2020 at 9:34 PM Gedare Bloom  wrote:

> On Sat, Aug 22, 2020 at 11:27 PM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Sat, Aug 22, 2020 at 11:32 PM Gedare Bloom  wrote:
> >>
> >> I have some comments below. I'm not that happy with the lack of design
> >> discussion during the iteration of this code. While it is a little
> >> easier to critique the code, it is also a bit wasteful because I have
> >> to also comment on stylistic problems, and when some decisions you
> >> make while coding end up not being correct or aren't easily understood
> >> during code review then you might have to spend more time recoding. It
> >> can be hard to find the balance between design and code reviews,
> >>
> >> On Sat, Aug 22, 2020 at 9:19 AM Utkarsh Rai 
> wrote:
> >> > +
> >> > +#if defined ( RTEMS_THREAD_STACK_PROTECTION )
> >> > +
> >> > +/**
> >> > + * The following defines the control block  of a shared stack. Each
> stack can have
> >> > + * different sharing attributes.
> >> > + */
> >> > +typedef struct
> >> > +{
> >> > +  /** Access flags of the shared stack */
> >> > +  uint32_t access_flags;
> >> > +  /** This is the stack address of the sharing thread*/
> >> > +  void* shared_stack_area;
> >> > +  /** Stack size of the sharing thread*/
> >> > +  size_t shared_stack_size;
> >> > +  /** This is the stack address of the target stack. Maybe this area
> is not
> >> > +   * needed but this helps in selecting the target thread during
> stack sharing.
> >> > +   */
> >> > +  void* target_stack_area;
> >> I'm confused about the difference between shared_stack_area and
> >> target_stack_area
> >>
> >> > + /** Error checking for valid target stack address. This is also
> used to
> >> > +  * distinguish between a normal mmap operation and a stack sharing
> operation.
> >> > +  */
> >> I don't really know what this means.
> >
> >
> > This is related to the mmap() call. When we share stack using mmap,  two
> of the important parameters that reference to the target thread-stack
> > and sharing thread-stack are -'void* addr' which is the address of the
> target thread stack and 'int fd' that is the file descriptor to the shared
> memory
> > object corresponding to the thread stack being shared. Now, stack
> sharing is different from a normal mmap operation in the sense that we need
> to add
> > the sharing stack attributes to the stack control structure of the
> thread that is specified by 'addr' as compared to adding it to the chain of
> mappings. To select the
> > target thread we need to iterate over all the threads, in the case we do
> not find any thread, we can proceed with our normal mmap operation
> otherwise we add the
> > sharing thread stack attribute to the stack control structure of the
> target thread. We have the _Thread_Iterate() function but it only has two
> parameters the pointer to the
> > function that performs operation during each iteration and a parameter
> related to this operation. My decision to specify the 'target_stack_area',
> the 'shared_stack_area' and 'stack_shared' in the structure
> > was so that I could squeeze in as much information to select the
> thread,  set the sharing stack parameters in the thread,  and
> validate(through stack_shared attribute) in the mmap() call that this is
> > in fact a stack-sharing operation, in a single iteration.
> >
>
> Maybe I should ask this on the mmap patch itself, but I'm more
> interested in the design than the code right now. I think I'll just
> ask a few questions:
>
> The 'sharing' stack is the stack that is getting r/w permission added
> to another thread, and the 'target' thread is the thread that is
> getting the r/w permission to access the shared stack. We should not
> really care about the 'sharing thread' or the 'target stack'?
>

If the mmap() call for sharing thread stack assumes that it is being called
from the context of the 'target thread', then no, we should not.


>
> If mmap() assumes the calling context then the executing thread is the
> "target thread" and you shouldn't have to search for it? In typical
> POSIX implementations, mmap() assumes the executing process context
> called it, but can we make the same assumption?
>
> For mmap() the 'addr' should be the 'sharing' stack's (base) address
> not the 'target' stack, because you want to be accessing the 'sharing'
> stack memory? We don't have any virtual memory mapping, so the address
> of the sharing stack needs to be used. Or maybe it can be NULL, or
> even ignored, since the mmap() call should return the base address of
> the 'sharing' stack? The fd should be able to find all the information
> needed about the 'sharing' stack.


My confusion was, as you asked above, whether we can assume that the mmap()
was called by the executing process
context. I was making the mmap() call from the 'POSIX_Init' thread and
passing the address of the target thread and then
selecting the thread inside mmap(). Can we do something like this

Re: [PATCH v2] Pre Release: Strong APA

[Gedare Bloom]

On Mon, Aug 24, 2020 at 10:14 AM Richi Dubey  wrote:
>
> ---
>  cpukit/include/rtems/scheduler.h  |   6 +-
>  .../include/rtems/score/schedulerstrongapa.h  | 284 --
>  cpukit/score/src/schedulerstrongapa.c | 913 ++
>  3 files changed, 901 insertions(+), 302 deletions(-)
>
> diff --git a/cpukit/include/rtems/scheduler.h 
> b/cpukit/include/rtems/scheduler.h
> index 955a83cfb4..b101842ba7 100644
> --- a/cpukit/include/rtems/scheduler.h
> +++ b/cpukit/include/rtems/scheduler.h
> @@ -257,16 +257,14 @@
>#define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ) \
>  static struct { \
>Scheduler_strong_APA_Context Base; \
> -  Chain_ControlReady[ ( prio_count ) ]; \
> +  Scheduler_strong_APA_Struct Struct[ CONFIGURE_MAXIMUM_PROCESSORS ]; \

I don't like this name at all either the type or the variable
"Struct". Just like I wouldn't call a variable
   int Int;

>  } SCHEDULER_STRONG_APA_CONTEXT_NAME( name )
>
>#define RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name ) \
>  { \
>&SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Base.Base.Base, \
>SCHEDULER_STRONG_APA_ENTRY_POINTS, \
> -  RTEMS_ARRAY_SIZE( \
> -SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
> -  ) - 1, \
> +  SCHEDULER_STRONG_APA_MAXIMUM_PRIORITY, \
>( obj_name ) \
>SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
>  }
> diff --git a/cpukit/include/rtems/score/schedulerstrongapa.h 
> b/cpukit/include/rtems/score/schedulerstrongapa.h
> index 0ac28cb439..86d91688e8 100644
> --- a/cpukit/include/rtems/score/schedulerstrongapa.h
> +++ b/cpukit/include/rtems/score/schedulerstrongapa.h
> @@ -6,31 +6,38 @@
>   * @brief Strong APA Scheduler API
>   */
>
> -/*
> - * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
> +/*
> + * Copyright (c) 2020 Richi Dubey
>   *
> - *  embedded brains GmbH
> - *  Dornierstr. 4
> - *  82178 Puchheim
> - *  Germany
> - *  
> + *  
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> + * Copyright (c) 2013, 2018 embedded brains GmbH. All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  
> + *
> + * 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.
relicense 2-bsd -- EB allows it, and your new code should be put under it

>   */
> -
> +
>  #ifndef _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
>  #define _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
>
>  #include 
> -#include 
>  #include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /* __cplusplus */
>
> +#define STRONG_SCHEDULER_NODE_OF_CHAIN( node ) \
> +  RTEMS_CONTAINER_OF( next, Scheduler_strong_APA_Node, Chain )
somehow this is not using 'node' parameter?

> +
>  /**
>   * @defgroup RTEMSScoreSchedulerStrongAPA Strong APA Scheduler
>   *
> @@ -38,43 +45,98 @@ extern "C" {
>   *
>   * @brief Strong APA Scheduler
>   *
> - * This is an implementation of the global fixed priority scheduler (G-FP).  
> It
> - * uses one ready chain per priority to ensure constant time insert 
> operations.
> - * The scheduled chain uses linear insert operations and has at most 
> processor
> - * count entries.  Since the processor and priority count are constants all
> - * scheduler operations complete in a bounded execution time.
> + * This is an implementation of the Strong APA scheduler defined by
> + * Cerqueira et al. in Linux's Processor Affinity API, Refined:
> + * Shifting Real-Time Tasks Towards Higher Schedulability.
>   *
> - * The the_thread preempt mode will be ignored.
> + * This is an implementation of the Strong APA scheduler defined by
> + * Cerqueira et al. in Linux's Processor Affinity API, Refined:
> + * Shifting Real-Time Tasks Towards Higher Schedulability.
repeating text?

You should add a bit more comment about the high-level design here. Of
course anyone wanting more details can go to the paper.

>   *
>   * @{
>   */
>
>  /**
> - * @brief Scheduler context specialization for Strong APA
> - * schedulers.
> - */
> -typedef struct {
> -  Scheduler_SMP_ContextBase;
> -  Priority_bit_map_Control Bit_map;
> -  Chain_ControlReady[ RTEMS_ZERO_LENGTH_ARRAY ];
> -} Scheduler_strong_APA_Context;
> -
> -/**
> - * @brief Scheduler node specialization for Strong APA
> - * schedulers.
> + * @brief Scheduler node specialization for Strong APA schedulers.
>   */
>  typedef struct {
>/**
> * @brief SMP scheduler node.
> */
>Scheduler_SMP_Node Base;
> +
> + /**
> +   * @brief Chain node for Scheduler_strong_APA_Context::All_nodes
> +   */
> +  Chain_Node Chain;

Don't call this Chain. We refer to a Chain_Control object as the
chain. Some other ideas:
* APA_Node
* All_nodes_Node
* All_nodes_Link
* Link
* Node (that could be confusing)
* Link_Node

Re: mmap shared stack design was: [PATCH v4 1/3] Strict thread-stack isolation

[Gedare Bloom]

On Mon, Aug 24, 2020 at 10:41 AM Utkarsh Rai  wrote:
>
>
>
> On Mon, Aug 24, 2020 at 9:34 PM Gedare Bloom  wrote:
>>
>> On Sat, Aug 22, 2020 at 11:27 PM Utkarsh Rai  wrote:
>> >
>> >
>> >
>> > On Sat, Aug 22, 2020 at 11:32 PM Gedare Bloom  wrote:
>> >>
>> >> I have some comments below. I'm not that happy with the lack of design
>> >> discussion during the iteration of this code. While it is a little
>> >> easier to critique the code, it is also a bit wasteful because I have
>> >> to also comment on stylistic problems, and when some decisions you
>> >> make while coding end up not being correct or aren't easily understood
>> >> during code review then you might have to spend more time recoding. It
>> >> can be hard to find the balance between design and code reviews,
>> >>
>> >> On Sat, Aug 22, 2020 at 9:19 AM Utkarsh Rai  
>> >> wrote:
>> >> > +
>> >> > +#if defined ( RTEMS_THREAD_STACK_PROTECTION )
>> >> > +
>> >> > +/**
>> >> > + * The following defines the control block  of a shared stack. Each 
>> >> > stack can have
>> >> > + * different sharing attributes.
>> >> > + */
>> >> > +typedef struct
>> >> > +{
>> >> > +  /** Access flags of the shared stack */
>> >> > +  uint32_t access_flags;
>> >> > +  /** This is the stack address of the sharing thread*/
>> >> > +  void* shared_stack_area;
>> >> > +  /** Stack size of the sharing thread*/
>> >> > +  size_t shared_stack_size;
>> >> > +  /** This is the stack address of the target stack. Maybe this area 
>> >> > is not
>> >> > +   * needed but this helps in selecting the target thread during stack 
>> >> > sharing.
>> >> > +   */
>> >> > +  void* target_stack_area;
>> >> I'm confused about the difference between shared_stack_area and
>> >> target_stack_area
>> >>
>> >> > + /** Error checking for valid target stack address. This is also used 
>> >> > to
>> >> > +  * distinguish between a normal mmap operation and a stack sharing 
>> >> > operation.
>> >> > +  */
>> >> I don't really know what this means.
>> >
>> >
>> > This is related to the mmap() call. When we share stack using mmap,  two 
>> > of the important parameters that reference to the target thread-stack
>> > and sharing thread-stack are -'void* addr' which is the address of the 
>> > target thread stack and 'int fd' that is the file descriptor to the shared 
>> > memory
>> > object corresponding to the thread stack being shared. Now, stack sharing 
>> > is different from a normal mmap operation in the sense that we need to add
>> > the sharing stack attributes to the stack control structure of the thread 
>> > that is specified by 'addr' as compared to adding it to the chain of 
>> > mappings. To select the
>> > target thread we need to iterate over all the threads, in the case we do 
>> > not find any thread, we can proceed with our normal mmap operation 
>> > otherwise we add the
>> > sharing thread stack attribute to the stack control structure of the 
>> > target thread. We have the _Thread_Iterate() function but it only has two 
>> > parameters the pointer to the
>> > function that performs operation during each iteration and a parameter 
>> > related to this operation. My decision to specify the 'target_stack_area', 
>> >  the 'shared_stack_area' and 'stack_shared' in the structure
>> > was so that I could squeeze in as much information to select the thread,  
>> > set the sharing stack parameters in the thread,  and validate(through 
>> > stack_shared attribute) in the mmap() call that this is
>> > in fact a stack-sharing operation, in a single iteration.
>> >
>>
>> Maybe I should ask this on the mmap patch itself, but I'm more
>> interested in the design than the code right now. I think I'll just
>> ask a few questions:
>>
>> The 'sharing' stack is the stack that is getting r/w permission added
>> to another thread, and the 'target' thread is the thread that is
>> getting the r/w permission to access the shared stack. We should not
>> really care about the 'sharing thread' or the 'target stack'?
>
>
> If the mmap() call for sharing thread stack assumes that it is being called 
> from the context of the 'target thread', then no, we should not.
>
>>
>>
>> If mmap() assumes the calling context then the executing thread is the
>> "target thread" and you shouldn't have to search for it? In typical
>> POSIX implementations, mmap() assumes the executing process context
>> called it, but can we make the same assumption?
>>
>> For mmap() the 'addr' should be the 'sharing' stack's (base) address
>> not the 'target' stack, because you want to be accessing the 'sharing'
>> stack memory? We don't have any virtual memory mapping, so the address
>> of the sharing stack needs to be used. Or maybe it can be NULL, or
>> even ignored, since the mmap() call should return the base address of
>> the 'sharing' stack? The fd should be able to find all the information
>> needed about the 'sharing' stack.
>
>
> My confusion was, as you asked above, whether we can assume that the mmap() 
> was called by the execut

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Chris Johns]

On 25/8/20 12:34 am, Heinz Junkes wrote:
> Thanks Chris for the explanation. It all makes sense.

My pleasure.

> I stumbled over the following point:
> 
> I tested the rc-2 and followed the Quick Guide to Building.
> “
> To build the tools for the ARM architecture:
> 
> ../source-builder/sb-set-builder \
>   --prefix=$HOME/development/rtems/5.1-rc2 \
>   5/rtems-arm
> 
> To build the tools, kernel and all packages for the Beagleboneblack:
> 
> ../source-builder/sb-set-builder \
>   --prefix=$HOME/development/rtems/5.1-rc2 \
>   5/bsps/beagleboneblack
> “
> 
> After that I tried to build EPICS and ran into the error of a missing header 
> file.
> “librtemsNFS.h could not be found”
> This header file is in rtems-libbsd which I then had to reinstall and build 
> for the target.

I could not find `librtemsNFS.h` but I found `librtemsNfs.h`? ...

$ find . -name librtems\*.h
./cpukit/libnetworking/librtemsNfs.h

> 
> Then I thought about whether a recipe could/should consider this dependency.
> 

The header should be there. I am more concerned about the contents of the that
header ... hmm.

What calls does EPICS use from this file? I suggest it gets reviewed. The
problem RTEMS has long term with the interface in `librtemsNfs.h` is it being
bespoke to the NFS implementation and we may not be able to maintain it in the
future, for example upgrading NFS to NFSv4.

In systems I work on for clients I encourage scripting of some form be used.
Commands hide the implementation details and this lets us (RTEMS) better
maintain compatibility. The scripting can be plain text files or `joel` scripts
or command sequences in another configuration format, for example YAML. You can
directly call shell commands.

To mount a remote disk use:

  mkdir /foobar
  mount -t nfs foo:/bar /foobar

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