Re: [Xenomai-core] [PATCH-STACK] more timer rework, group-based access control
On Sat, 2007-06-30 at 07:56 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> >> rt-caps-group.patch
> >
> > Good idea, but totally untested on my side (did I already mention my
> > laziness?). Will merge and backport to 2.3.x, XENO_OPT_SECURITY_ACCESS
> > was too cheap to be good anyway.
>
> What about moving that scheduling parameter settings into the
> trampoline? Some legacy RTOS libs would still have to be adapted.
>
We could do that since the caller is always synchronized with the new
thread and blocks on the completion flag until xnshadow_map() has run,
so this would solve potential priority issues. This would also keep the
existing work around for a silly bug from some Linuxthreads
implementations which just did not consider the scheduling policy
setting passed to pthread_create(), and would leave the spawned thread
in SCHED_NORMAL mode in any case. However, this would still not work
with pthread libs overeagerly checking for root permissions.
> >
> >> ---
> >>
> >> See dedicated posts earlier on this list.
> >>
> >>
> >> refactor-timer-modes.patch
> >> --
> >>
> >> xntimers are now of three kinds: XNTM_MONOREL, XNTM_MONOABS, or
> >> XNTM_REALABS. This mode is passed on xntimer_start or on invocation of
> >> higher services (xnpod_suspend_thread e.g.). Users were widely
> >> automatically converted and may lack optimisation for the new scheme.
> >> Please review carefully for regressions!
> >>
> >
> > The only reason for me to whine about this one so far concerns naming
> > issues. Why do things need to be that picky?
> >
> > I mean, we have only three modes, relative, absolute monotonic and
> > absolute realtime and we discussed in great length why we won't have
> > more than those. Given that "relative non-monotonic" would make no sense
> > here, and that "realtime" carries a strong notion of absoluteness in
> > relation to the wallclock, let's keep "relative", "absolute" and
> > "realtime". In any case, "mono" is not widespread enough for people to
> > immediately catch "monotonic" anyway, so in case of doubt: I'd say
> > _RTFM_.
> >
> > Additionally, having XN_INFINITE and XNTM_RELATIVE/ABSOLUTE/REALTIME is
> > a clear sign of discrepancy. Please, keep my laziness intact, and let's
> > keep XN_ for general macros. I know that this is somehow in
> > contradiction with the current practice for the native skin, but I'm
> > full of contradictions anyway, so...
>
> Hmm, everything has it's pros and cons, but mostly you are right. Here
> is a new proposal, please tell me if it's acceptable so that I can
> rebase the rest:
>
> --- xenomai.orig/include/nucleus/types.h
> +++ xenomai/include/nucleus/types.h
> @@ -62,8 +62,13 @@ typedef int (*xniack_t)(unsigned irq);
>
> #define XN_INFINITE (0)
> #define XN_NONBLOCK ((xnticks_t)-1)
> -#define XN_RELATIVE 0
> -#define XN_ABSOLUTE 1
> +
> +/* Timer modes */
> +typedef enum xntmode {
> + XN_RELATIVE,
> + XN_ABSOLUTE,
> + XN_REALTIME
> +} xntmode_t;
>
> #define XN_APERIODIC_TICK 0
> #define XN_NO_TICK ((xnticks_t)-1)
>
Looks ok, provided we can always represent the mode as a set of discrete
values. This said, switching from a enum to a plain integer would be a
no-brainer if needed.
>
> Last issue pending is the xintr locking thing. Will try to have a closer
> look again and kick Dmitry for some more explanations of his patch.
>
> Jan
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH-STACK] more timer rework, group-based access control
Philippe Gerum wrote:
>> rt-caps-group.patch
>
> Good idea, but totally untested on my side (did I already mention my
> laziness?). Will merge and backport to 2.3.x, XENO_OPT_SECURITY_ACCESS
> was too cheap to be good anyway.
What about moving that scheduling parameter settings into the
trampoline? Some legacy RTOS libs would still have to be adapted.
>
>> ---
>>
>> See dedicated posts earlier on this list.
>>
>>
>> refactor-timer-modes.patch
>> --
>>
>> xntimers are now of three kinds: XNTM_MONOREL, XNTM_MONOABS, or
>> XNTM_REALABS. This mode is passed on xntimer_start or on invocation of
>> higher services (xnpod_suspend_thread e.g.). Users were widely
>> automatically converted and may lack optimisation for the new scheme.
>> Please review carefully for regressions!
>>
>
> The only reason for me to whine about this one so far concerns naming
> issues. Why do things need to be that picky?
>
> I mean, we have only three modes, relative, absolute monotonic and
> absolute realtime and we discussed in great length why we won't have
> more than those. Given that "relative non-monotonic" would make no sense
> here, and that "realtime" carries a strong notion of absoluteness in
> relation to the wallclock, let's keep "relative", "absolute" and
> "realtime". In any case, "mono" is not widespread enough for people to
> immediately catch "monotonic" anyway, so in case of doubt: I'd say
> _RTFM_.
>
> Additionally, having XN_INFINITE and XNTM_RELATIVE/ABSOLUTE/REALTIME is
> a clear sign of discrepancy. Please, keep my laziness intact, and let's
> keep XN_ for general macros. I know that this is somehow in
> contradiction with the current practice for the native skin, but I'm
> full of contradictions anyway, so...
Hmm, everything has it's pros and cons, but mostly you are right. Here
is a new proposal, please tell me if it's acceptable so that I can
rebase the rest:
--- xenomai.orig/include/nucleus/types.h
+++ xenomai/include/nucleus/types.h
@@ -62,8 +62,13 @@ typedef int (*xniack_t)(unsigned irq);
#define XN_INFINITE (0)
#define XN_NONBLOCK ((xnticks_t)-1)
-#define XN_RELATIVE 0
-#define XN_ABSOLUTE 1
+
+/* Timer modes */
+typedef enum xntmode {
+ XN_RELATIVE,
+ XN_ABSOLUTE,
+ XN_REALTIME
+} xntmode_t;
#define XN_APERIODIC_TICK 0
#define XN_NO_TICK ((xnticks_t)-1)
Last issue pending is the xintr locking thing. Will try to have a closer
look again and kick Dmitry for some more explanations of his patch.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH-STACK] more timer rework, group-based access control
On Thu, 2007-06-28 at 19:06 +0200, Jan Kiszka wrote: > Hi, > > here is an overview of my latest patch stack at > > http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/ > > > fix-timer-wrap-arounds-v2.patch > --- > > More or less academic fixes (hopefully without regressions) When applied to switching to signed arithmetics in a world of unsignedness, this sounds like the famous last words: "Hey! life is short, let's play Russian roulette!". Still, you are right, so let's have fun: will merge. > around the > scenario when the underlying raw timer wraps around. However, I don't > think we should leave this unfixed, risking an "Ariane-bug". > run-aclocal-first.patch, Indeed, call order was wrong. Will merge (+backport). > link-check-sched_setaffinity.patch, uClibc is just evil. Will merge (+backport). > fix-patch-election.patch, Another proof of my laziness. Will merge (+backport). > run-default-preparation.patch, Seems you want to be able to be lazy too. Ok, will merge (+backport). > rt-caps-group.patch Good idea, but totally untested on my side (did I already mention my laziness?). Will merge and backport to 2.3.x, XENO_OPT_SECURITY_ACCESS was too cheap to be good anyway. > --- > > See dedicated posts earlier on this list. > > > refactor-timer-modes.patch > -- > > xntimers are now of three kinds: XNTM_MONOREL, XNTM_MONOABS, or > XNTM_REALABS. This mode is passed on xntimer_start or on invocation of > higher services (xnpod_suspend_thread e.g.). Users were widely > automatically converted and may lack optimisation for the new scheme. > Please review carefully for regressions! > The only reason for me to whine about this one so far concerns naming issues. Why do things need to be that picky? I mean, we have only three modes, relative, absolute monotonic and absolute realtime and we discussed in great length why we won't have more than those. Given that "relative non-monotonic" would make no sense here, and that "realtime" carries a strong notion of absoluteness in relation to the wallclock, let's keep "relative", "absolute" and "realtime". In any case, "mono" is not widespread enough for people to immediately catch "monotonic" anyway, so in case of doubt: I'd say _RTFM_. Additionally, having XN_INFINITE and XNTM_RELATIVE/ABSOLUTE/REALTIME is a clear sign of discrepancy. Please, keep my laziness intact, and let's keep XN_ for general macros. I know that this is somehow in contradiction with the current practice for the native skin, but I'm full of contradictions anyway, so... As already discussed, we do need this for -rc1 though. > > isol-timebase.patch > --- > > Isolates time bases from the master base if XNTBISO is set on > xntbase_alloc. This becomes default for all skins except POSIX, native, > and RTDM. The other skins can join the system clock group by passing a > non-zero "sync_time" module parameter on startup. The patch also > enhances the output of /proc/xenomai/timebases. To-do: document the API > changes... > Will merge. > > re-adjust-timers.patch > -- > > Yet an empty placeholder. It shall contain the changes to make real-time > timers follow wallclock adjustments. > As mentioned recently, will be postponed to -rc2/3. > > rtdm-timer-v2.patch > --- > > Revised and documented version of RTDM timers, now based on the latest > xntimer version. The timer mode is passed on start, just like it's done > in the xntimer API. Moreover, rtdm_task_sleep_abs is introduced as a > replacement for the deprecated rtdm_task_sleep_until. The new service > works both with monotonic and real-time dates, the old service will > eventually by removed. > Will merge, I guess we need refactor-timer-modes.patch to be fixed first. > > The rest is unchanged or was just refreshed. > Will merge rtutils - or whatever name we'll pick - before -rc1 is out. Ok, the merge window for new features in -rc1 is officially CLOSED. Thanks for your work. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH-STACK] more timer rework, group-based access control
Hi, here is an overview of my latest patch stack at http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/ fix-timer-wrap-arounds-v2.patch --- More or less academic fixes (hopefully without regressions) around the scenario when the underlying raw timer wraps around. However, I don't think we should leave this unfixed, risking an "Ariane-bug". run-aclocal-first.patch, link-check-sched_setaffinity.patch, fix-patch-election.patch, run-default-preparation.patch, rt-caps-group.patch --- See dedicated posts earlier on this list. refactor-timer-modes.patch -- xntimers are now of three kinds: XNTM_MONOREL, XNTM_MONOABS, or XNTM_REALABS. This mode is passed on xntimer_start or on invocation of higher services (xnpod_suspend_thread e.g.). Users were widely automatically converted and may lack optimisation for the new scheme. Please review carefully for regressions! isol-timebase.patch --- Isolates time bases from the master base if XNTBISO is set on xntbase_alloc. This becomes default for all skins except POSIX, native, and RTDM. The other skins can join the system clock group by passing a non-zero "sync_time" module parameter on startup. The patch also enhances the output of /proc/xenomai/timebases. To-do: document the API changes... re-adjust-timers.patch -- Yet an empty placeholder. It shall contain the changes to make real-time timers follow wallclock adjustments. rtdm-timer-v2.patch --- Revised and documented version of RTDM timers, now based on the latest xntimer version. The timer mode is passed on start, just like it's done in the xntimer API. Moreover, rtdm_task_sleep_abs is introduced as a replacement for the deprecated rtdm_task_sleep_until. The new service works both with monotonic and real-time dates, the old service will eventually by removed. The rest is unchanged or was just refreshed. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
