Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

On Sat, Aug 15, 2020 at 12:39 AM Gedare Bloom wrote: > On Fri, Aug 14, 2020 at 9:25 AM Utkarsh Rai > wrote: > > > > Sorry for the late reply, I somehow missed the mail notification! > > > > On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom wrote: > >> > >> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On Fri, Aug 14, 2020, 7:04 PM Chris Johns wrote: > On 15/8/20 8:31 am, Joel Sherrill wrote: > > On Fri, Aug 14, 2020 at 4:42 PM Chris Johns > > wrote: > > > > On 15/8/20 5:57 am, Jan Sommer wrote: > > > Hello, > > > > > > I finally got around to port the

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 15/8/20 8:31 am, Joel Sherrill wrote: > On Fri, Aug 14, 2020 at 4:42 PM Chris Johns > wrote: > > On 15/8/20 5:57 am, Jan Sommer wrote: > > Hello, > > > > I finally got around to port the e1000 driver fixes which are already > > present in the

Re: What happens during boot time in terms of scheduling?

On Fri, Aug 14, 2020 at 10:51 AM Richi Dubey wrote: > My god. There's so much that a bachelor's degree does not teach. > This particular one definitely qualifies as an example of Arthur C. Clarke's Third Law to me. :) Clarke's Third Law: Any sufficiently advanced technology is

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On Fri, Aug 14, 2020 at 4:42 PM Chris Johns wrote: > On 15/8/20 5:57 am, Jan Sommer wrote: > > Hello, > > > > I finally got around to port the e1000 driver fixes which are already > > present in the 5-freebsd-12 branch of rtems-libbsd also for the master > > (and 5) branch. > > Thanks. I will

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

On 15/8/20 5:57 am, Jan Sommer wrote: > Hello, > > I finally got around to port the e1000 driver fixes which are already > present in the 5-freebsd-12 branch of rtems-libbsd also for the master > (and 5) branch. Thanks. I will push these soon. I am not sure if the 5 branch in the

RTEMS 5.1 RC2 Available

Hello, RTEMS 5.1 RC2 is available for testing. You can find the release at: https://ftp.rtems.org/pub/rtems/releases/5/rc/5.1-rc2 Please report your successes or problems here. You can also raise a ticket if you prefer. Please select the 5.1 milestone. The RC is now correctly named with a 2

[PATCH v1 3/6] i386: Add missing files to build system

- Update FreeBSD files in libbsd.py to required by i386 based BSPs - Add missing files e1000 network driver (iflib*) --- libbsd.py | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/libbsd.py b/libbsd.py index e02226f3..08931401 100644 --- a/libbsd.py +++ b/libbsd.py

[PATCH v1 6/6] i386: Delete old machine dependent files

- The files in the i386 directory have been moved to common x86 directories by FreeBSD: - freebsd/sys/i386/include/machine/bus.h - freebsd/sys/x86/include/machine/legacyvar.h - freebsd/sys/x86/include/machine/specialreg.h - Add header files in rtemsbsd directory to direct compiler to new

[PATCH v1 5/6] iflib.c: Deactivate use of ifc_cpus

- cpusets and SMP are currently not supported in libbsd for RTEMS - Disable the ifc_cpus context variable and replace its usage, essentially hard-coding for cpu 0 --- freebsd/sys/dev/e1000/if_em.c | 6 ++ freebsd/sys/net/iflib.c | 22 ++ 2 files changed, 28

[PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

Hello, I finally got around to port the e1000 driver fixes which are already present in the 5-freebsd-12 branch of rtems-libbsd also for the master (and 5) branch. I created two corresponding tickets for it: https://devel.rtems.org/ticket/4052 and https://devel.rtems.org/ticket/4053. Could

[PATCH v1 4/6] Callout: Redefine callout_reset_on for rtems

- callout_reset_on takes a cpu which is ignored by the subsequent call to callout_reset_sbt_on in RTEMS. - The macro is redefined to discard the cpu argument directly which enables uses of it with cpu-dependent variables (disabled in RETMS) without further changes, e.g. in iflib.c. ---

[PATCH v1 2/6] waf: Add path-mappings feature

- path-mappings allow to fix autogenerated include paths for some corner cases of target platforms without the need to change the build system - Currently used for i386 based bsps --- libbsd.py | 8 waf_libbsd.py | 13 +++-- 2 files changed, 19 insertions(+), 2 deletions(-)

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

On Fri, Aug 14, 2020 at 9:25 AM Utkarsh Rai wrote: > > Sorry for the late reply, I somehow missed the mail notification! > > On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom wrote: >> >> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai wrote: >> > >> > -This patch provides thread-stack isolation and

Re: crypt and POSIX

On Thu, Aug 13, 2020 at 11:49 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 13/08/2020 21:52, Chris Johns wrote: > > > On 13/8/20 11:47 pm, Joel Sherrill wrote: > >> On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber > >> sebastian.hu...@embedded-brains.de>> > >> wrote: > >>

Re: What happens during boot time in terms of scheduling?

My god. There's so much that a bachelor's degree does not teach. Thank you for your answer. On Fri, Aug 14, 2020 at 6:18 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 14/08/2020 11:25, Richi Dubey wrote: > > > Is _RTEMS_tasks_Initialize_user_task responsible for starting

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

Sorry for the late reply, I somehow missed the mail notification! On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom wrote: > On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai > wrote: > > > > -This patch provides thread-stack isolation and thread-stack sharing > > mechanism for a POSIX thread. > > >

Re: Need help in figuring out how a node gets its afffinity when it is created

On 14/08/2020 14:35, Richi Dubey wrote: telling me earlier that by default a node/task/thread is allowed to execute on all the processors? The thread's affinity is set to all processor when it gets initialized :

Re: What happens during boot time in terms of scheduling?

On 14/08/2020 11:25, Richi Dubey wrote: Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init task? Yes. Also how does the following code which is part of rtems_initialize_executive:   /* Invoke the registered system initialization handlers */   RTEMS_LINKER_SET_FOREACH(

Re: Need help in figuring out how a node gets its afffinity when it is created

> > telling me earlier that by default a node/task/thread is allowed to > execute on all the processors? The thread's affinity is set to all processor when it gets initialized : https://git.rtems.org/rtems/tree/cpukit/score/src/threadinitialize.c#n217 On Fri, Aug 14, 2020 at 5:58 PM Richi Dubey

Re: Need help in figuring out how a node gets its afffinity when it is created

Hi, Follow up of my progress to this question: I 'stepped inside' the important functions to make the observation that the flow of code is actually: - _Scheduler_strong_APA_Node_initialize _Scheduler_Node_initialize _Thread_Initialize rtems_task_create

Re: about FAST_IDLE in Clock_isr

On Thu, Aug 13, 2020 at 9:49 PM 朱忠杰 wrote: > Hi, everyone > > Is there any consideration why the FAST_IDLE is separated from normal > path，can I change the FAST_IDLE like the following? > The looks reasonably clean. It evolved over time so a clean up may just have been overdue. Just to be

Re: What happens during boot time in terms of scheduling?

I am looking at cpukit/include/rtems/confdefs/inittask.h right now and so, I know the answer to: Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init task? Still need help with other things. Thanks. On Fri, Aug 14, 2020 at 2:55 PM Richi Dubey wrote: > Hi, > > I've been

Need help in figuring out how a node gets its afffinity when it is created

Hi, My code is failing because its logic assumed (code here ) that it would never get a node with an empty affinity (i.e. no affinity to any processor or a 0 affinity).

What happens during boot time in terms of scheduling?

Hi, I've been trying to debug my program and I request someone to help me learn more about what happens when a system starts. Logically, what is the flow of things happening? Do all the CPUs start at the same time in the beginning? Which is the first node that gets scheduled on the CPU? The

Re: Quick question: How do I get the name of the scheduler from _Scheduler_Control

Got it, thank you. On Fri, Aug 14, 2020 at 1:02 AM Gedare Bloom wrote: > cpukit/include/rtems/rtems/support.h:RTEMS_INLINE_ROUTINE void > rtems_name_to_characters( > > On Thu, Aug 13, 2020 at 1:15 PM Richi Dubey wrote: > > > > Hi, > > > > It's hard to find this with the help of cscope and I