Re: Add FreeBSD PF Firewall to libbsd
Am 03.08.2016 um 08:46 schrieb Chris Johns: > On 03/08/2016 16:15, Christian Mauderer wrote: >> Basically it boils down to the following: Currently I use an >> __attribute__ on every variable that has to be initialized. That makes >> updates a little more difficult because we would have to look out for >> changed variables. In addition it is difficult for function static >> variables. > > Ok, this makes sense. > >> A solution that would be simpler to maintain would be to manipulate the >> object file. I would use objcopy to rename all sections with initialized >> variables to put them into the linker set. This would be a little less >> obvious if you read only the c code but it would solve both problems >> mentioned above. > > Having transparent source is more important. If you mean by "transparent" that it is less changed from FreeBSD then I agree. If you mean it should be more obvious where the section comes from (simpler to read - more transparent to the reader) I would not. The method with adding an attribute to every variable involves a lot of manual work and therefore is more likely to introduce bugs. > >> But it makes it necessary that the build system adds >> the object file manipulation step before it links the application. That >> is the point where I'm currently stuck. > > Should I wait for this to happen before adding any new control logic to > the build system? I think that my main problem is to understand enough of waf so I can add the object file manipulation. As soon as I managed that I should be able to adapt it to a new control logic too without too much effort. So feel free to make the changes whenever you can fit them into your schedule. -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Add a program in the shell command line in RTEMS-libbsd
Dear devels, I might need your help regarding RTEMS-libbsd. I would like to add a program into the RTEMS shell command line in order to run it with some parameter. In a first step, I created a file rtems-bsd-shell-*myprog.*c into the rtemsbsd/rtems folder to create the command. I would like to know how to link the program to the command. Any help could be great ! Kind Regards Babacar Diop 23 year Engineering student in Electronics and Computer Sciences of Embedded Systems 5th year ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add FreeBSD PF Firewall to libbsd
On 3/08/2016 5:00 PM, Christian Mauderer wrote: > Am 03.08.2016 um 08:46 schrieb Chris Johns: >> On 03/08/2016 16:15, Christian Mauderer wrote: >>> Basically it boils down to the following: Currently I use an >>> __attribute__ on every variable that has to be initialized. That makes >>> updates a little more difficult because we would have to look out for >>> changed variables. In addition it is difficult for function static >>> variables. >> >> Ok, this makes sense. >> >>> A solution that would be simpler to maintain would be to manipulate the >>> object file. I would use objcopy to rename all sections with initialized >>> variables to put them into the linker set. This would be a little less >>> obvious if you read only the c code but it would solve both problems >>> mentioned above. >> >> Having transparent source is more important. > > If you mean by "transparent" that it is less changed from FreeBSD then I > agree. > Yes this is what I mean. Source we take from FreeBSD with no changes is transparent. As we add changes the opacity level increases. I have added reporting to freebsd-to-rtems.py to provide us with a metric we can use to monitor this. > If you mean it should be more obvious where the section comes from > (simpler to read - more transparent to the reader) I would not. The > method with adding an attribute to every variable involves a lot of > manual work and therefore is more likely to introduce bugs. I agree, being as close to the FreeBSD source is important. >> >>> But it makes it necessary that the build system adds >>> the object file manipulation step before it links the application. That >>> is the point where I'm currently stuck. >> >> Should I wait for this to happen before adding any new control logic to >> the build system? > > I think that my main problem is to understand enough of waf so I can add > the object file manipulation. As soon as I managed that I should be able > to adapt it to a new control logic too without too much effort. So feel > free to make the changes whenever you can fit them into your schedule. OK. I will then take a look when I can. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Indroduce cancel job scheduler operation
Do not use a deadline value of zero to indicate a job cancellation. Use
a dedicated scheduler operation for this.
---
cpukit/rtems/src/ratemoncancel.c | 2 +-
cpukit/score/include/rtems/score/scheduler.h | 17
cpukit/score/include/rtems/score/schedulercbs.h| 1 +
cpukit/score/include/rtems/score/scheduleredf.h| 8 +++-
cpukit/score/include/rtems/score/schedulerimpl.h | 14 +++
.../score/include/rtems/score/schedulerpriority.h | 1 +
.../rtems/score/schedulerpriorityaffinitysmp.h | 1 +
.../include/rtems/score/schedulerprioritysmp.h | 1 +
cpukit/score/include/rtems/score/schedulersimple.h | 1 +
.../score/include/rtems/score/schedulersimplesmp.h | 1 +
.../score/include/rtems/score/schedulerstrongapa.h | 1 +
cpukit/score/src/schedulerdefaultreleasejob.c | 9 +
cpukit/score/src/scheduleredfreleasejob.c | 46 ++
13 files changed, 94 insertions(+), 9 deletions(-)
diff --git a/cpukit/rtems/src/ratemoncancel.c b/cpukit/rtems/src/ratemoncancel.c
index af6b1ec..41ba488 100644
--- a/cpukit/rtems/src/ratemoncancel.c
+++ b/cpukit/rtems/src/ratemoncancel.c
@@ -38,7 +38,7 @@ void _Rate_monotonic_Cancel(
cpu_self = _Thread_Dispatch_disable_critical( lock_context );
_Rate_monotonic_Release( owner, lock_context );
- _Scheduler_Release_job( owner, 0 );
+ _Scheduler_Cancel_job( owner );
_Thread_Dispatch_enable( cpu_self );
}
diff --git a/cpukit/score/include/rtems/score/scheduler.h
b/cpukit/score/include/rtems/score/scheduler.h
index c20e68c..20615a2 100644
--- a/cpukit/score/include/rtems/score/scheduler.h
+++ b/cpukit/score/include/rtems/score/scheduler.h
@@ -141,6 +141,12 @@ typedef struct {
uint64_t
);
+ /** @see _Scheduler_Cancel_job() */
+ void ( *cancel_job ) (
+const Scheduler_Control *,
+Thread_Control *
+ );
+
/** @see _Scheduler_Tick() */
void ( *tick )( const Scheduler_Control *, Thread_Control * );
@@ -376,6 +382,17 @@ void _Scheduler_default_Release_job(
);
/**
+ * @brief Does nothing.
+ *
+ * @param[in] scheduler Unused.
+ * @param[in] the_thread Unused.
+ */
+void _Scheduler_default_Cancel_job(
+ const Scheduler_Control *scheduler,
+ Thread_Control *the_thread
+);
+
+/**
* @brief Performs tick operations depending on the CPU budget algorithm for
* each executing thread.
*
diff --git a/cpukit/score/include/rtems/score/schedulercbs.h
b/cpukit/score/include/rtems/score/schedulercbs.h
index a46314c..bfad633 100644
--- a/cpukit/score/include/rtems/score/schedulercbs.h
+++ b/cpukit/score/include/rtems/score/schedulercbs.h
@@ -61,6 +61,7 @@ extern "C" {
_Scheduler_CBS_Node_initialize, /* node initialize entry point */ \
_Scheduler_default_Node_destroy, /* node destroy entry point */ \
_Scheduler_CBS_Release_job, /* new period of task */ \
+_Scheduler_EDF_Cancel_job, /* cancel period of task */ \
_Scheduler_default_Tick, /* tick entry point */ \
_Scheduler_default_Start_idle/* start idle entry point */ \
SCHEDULER_OPERATION_DEFAULT_GET_SET_AFFINITY \
diff --git a/cpukit/score/include/rtems/score/scheduleredf.h
b/cpukit/score/include/rtems/score/scheduleredf.h
index de06344..5d9b435 100644
--- a/cpukit/score/include/rtems/score/scheduleredf.h
+++ b/cpukit/score/include/rtems/score/scheduleredf.h
@@ -61,6 +61,7 @@ extern "C" {
_Scheduler_EDF_Node_initialize, /* node initialize entry point */ \
_Scheduler_default_Node_destroy, /* node destroy entry point */ \
_Scheduler_EDF_Release_job, /* new period of task */ \
+_Scheduler_EDF_Cancel_job, /* cancel period of task */ \
_Scheduler_default_Tick, /* tick entry point */ \
_Scheduler_default_Start_idle/* start idle entry point */ \
SCHEDULER_OPERATION_DEFAULT_GET_SET_AFFINITY \
@@ -227,12 +228,17 @@ Scheduler_Void_or_thread _Scheduler_EDF_Yield(
* the job was cancelled or deleted, thus a running task
* has to be suspended.
*/
-void _Scheduler_EDF_Release_job (
+void _Scheduler_EDF_Release_job(
const Scheduler_Control *scheduler,
Thread_Control *the_thread,
uint64_t deadline
);
+void _Scheduler_EDF_Cancel_job(
+ const Scheduler_Control *scheduler,
+ Thread_Control *the_thread
+);
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/include/rtems/score/schedulerimpl.h
b/cpukit/score/include/rtems/score/schedulerimpl.h
index dd7fa28..23b73f0 100644
--- a/cpukit/score/include/rtems/score/schedulerimpl.h
+++ b/cpukit/score/include/rtems/score/schedulerimpl.h
@@ -499,6 +499,20 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Release_job(
}
/**
+ * @brief Cancels a job of a thread with respect to the scheduler.
+ *
+ * @param[in] the_thread The thread.
+ */
+RTEMS_INLINE_ROUTINE void _Scheduler_Cancel_job(
+ Thread_Control *the_thread
+)
+{
+ const Scheduler_Control *scheduler = _Scheduler_Get( the_thread );
+
Re: [rtems-libbsd commit] pfctl: Adapt for RTEMS.
Am 03.08.2016 um 07:02 schrieb Sebastian Huber: > > > On 03/08/16 01:22, Chris Johns wrote: >> On 02/08/2016 21:21, Sebastian Huber wrote: >>> freebsd/contrib/pf/pfctl/parse-data.h | 42 >>> diff --git a/freebsd/contrib/pf/pfctl/parse-data.h >>> b/freebsd/contrib/pf/pfctl/parse-data.h >>> new file mode 100644 >>> index 000..22f6295 >>> --- /dev/null >>> +++ b/freebsd/contrib/pf/pfctl/parse-data.h >>> @@ -0,0 +1,42 @@ >>> +#include >>> + >>> +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, >>> +static struct antispoof_opts antispoof_opts); >> >> I am seeing ... >> >> [ 18/954] Compiling freebsd/contrib/pf/pfctl/pfctl_qstats.c >> In file included from ../../freebsd/contrib/pf/pfctl/parse.y:6138:0: >> ../../freebsd/contrib/pf/pfctl/parse-data.h:4:5: error: expected ')' >> before 'static' >> static struct antispoof_opts antispoof_opts); >> ^~ >> ../../freebsd/contrib/pf/pfctl/parse-data.h:5:44: error: expected ')' >> before 'static' >> RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, static int blockpolicy); >> ^~ >> Are these changes OK? > > Does it work after an RTEMS update? > Hello Chris, I agree with Sebastian. The libbsd patch depends on 5fe6d07ad5690e3d9c6445ca3a465a700a5a5015 that is in RTEMS for just a few days. Kind regards Christian -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
