On Tue, Jul 06, 2004 at 01:02:33PM +0200, Philippe Gerum wrote: > > The Xenomai system is very flexible, but there is one point that could > > be more generic. I mean the processing of the events caught by Adeos > > from the Linux kernel. There are two problems, you cannot use the > > linux-tasks's ptd to provide own userspace services, without > > interfering with the fusion specific handlers defined in shadow.
> You can, provided you reserve a new ptd slot for your sub-system using > adeos_alloc_ptdkey(). Okay - I overlooked this possibility. > > The > > second is that there is no interface to change these handlers in > > xenomai (of course you can call the adeos functions directly). > > > > A possible, but time consuming, solution could be to provide an > > interface to register these handlers, a wrapper around the adeos calls > > perhaps, and separate the shadow code into a fusion specific (mapping, > > migration, handling of from-linux-kernel-catched-events) and a general > > part. This general part could stay in the main xenomai module, whereas > > the fusion specific code could be merged into the fusion module. This > > would also save memory when not using the shadow/fusion services... (I > > know that the seperate fusion module has been abandoned in the fusion > > branch.) > The shadow support bears the mapping/migration/shielding/interception > parts which the fusion layer uses, and not the other way around. In this > respect, dissociating the shadow support from the fusion interface (like > it is in 3.x) would not spare the kernel event handling. The Xenomai Nucleus groups common RTOS features and behaviours together in a generic interface, which in used by the skins (posix, vxworks, ...) to implement their API. Presumed that GNU/Linux/Adeos is used as the Xenomai Host Software Architecture, these skins provide a Kernel only API. The Programms they run are kernel only. In this usage scenario of Xenomai the whole shadow (and in the fusion branch the fusion code too) is unused in memory. A good objection by you is to make the shadow support a build time option. Good point. But wouldn't it be nice if xenomai would also export generic services for the userspace i.e. pluggable event handlers. The lower part of shadow (attach/detach skin, register/unregister skin, gatekeeper (for signals), interception of linux syscalls) is so generic that it could be used by other realtime userspace implementation than fusion. > > As a quick solution and minimal invasive solution I've implemented a > > event handler register function. It's a simple wrapper around the > > adeos call. The usage can be outlined as follows: By default the > > fusion/shadow handlers are active (no code change so far). If you want > > to register an alternative handler you simply call a > > "xnshadow_register_<EVENT>_handler(...)". That's a simple wrapper > > around the appropriate "adeos_catch_event(...)" function. This call > > would normally made in the init_module function. In corresponding > > cleanup_module function a call to > > "xnshadow_unregister_<EVENT>_handler(void)" would restore the default > > behaviour (fusion/shadow's event handlers). > Basically, what you ask for is a mere override of the user-space support > in Xenomai in order to put yours instead, which is acceptable, but I'd > rather see this as a build option, i.e. > CONFIG_RTAI_XENOMAI_SHADOW_SUPPORT [y/n]. In such a case, you would be > able to trap whatever suits your needs. I don't want to turn of all the whole shadow and fusion code, only the fusion specific part :) A pod is a pluggable container for the in-kernel-API, a skin deals with the syscalls from userspace and is also plugable. But there is a lack of a pluggable mechanism for the userspace event handlers. It must be like a pod, I mean, there is only one at the same time allowed. > However, the user-space support is so fundamental for the fusion branch > that having it optional there would be inconsistent with its main goal: > pervasive hard RT support in user-space. This is why the fusion module > has been merged to the nucleus btw. There are scenarios where you don't need the usersapce services, or want to provide your own. And development in other parts is also ongoing in the fusion branch (e.g. posix skin). BTW: The IPCs in RTAI 3.x are also highly modular.... > There is another solution: you could just add a daisy chain of callbacks > to the shadow support, allowing to fire some user-defined handlers on > behalf of the regular interception handlers (xnshadow_realtime_sysentry > et al.). Providing a small API to register/unregister them would do it. > Defining some convention like "if the chained handler returns non-zero, > then do not run the rest of the standard handler" would leave you total > freedom on the behaviour. A daisy chain means more overhead and IMHO is unnecessary, because if I provide my own userspace services, I have my own pod, and fusion can not be loaded anyway. > There may be a third solution: if your sub-system must override the > user-space support provided by Xenomai, then you could just add an Adeos > domain above RTAI in the pipeline just for the purpose of intercepting > the events you need to see before Xenomai catches them. Your handlers > would then be executed before the shadow sub-system's, and you could > choose whether to propagate the events to it or not. This is basically > the same approach than the above one, but using the "canonical" Adeos > way. I've also discussed that with Jan, but we think it's not a very clear solution. On one side use the skin service of Xenomia, but on the other intercept the events from the Linux kernel before Xenomai. This would break the design of Xenomai, it's a shortcut between the Adeos and the Pod/Skin. Marc -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh
