On 07/02/2015 07:03 PM, Gilles Chanteperdrix wrote: > On Thu, Jul 02, 2015 at 06:56:00PM +0200, Philippe Gerum wrote: >> On 07/02/2015 06:49 PM, Gilles Chanteperdrix wrote: >>> On Thu, Jul 02, 2015 at 06:44:06PM +0200, Jan Kiszka wrote: >>>> On 2015-07-02 18:30, Philippe Gerum wrote: >>>>> On 07/02/2015 05:39 PM, Jan Kiszka wrote: >>>>>> On 2015-07-02 17:24, Philippe Gerum wrote: >>>>>>> On 07/02/2015 05:20 PM, git repository hosting wrote: >>>>>>>> Module: xenomai-jki >>>>>>>> Branch: for-forge >>>>>>>> Commit: 99736c29a21a5e5536f8db9e580fd11cdb0eb0f2 >>>>>>>> URL: >>>>>>>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=99736c29a21a5e5536f8db9e580fd11cdb0eb0f2 >>>>>>>> >>>>>>>> Author: Jan Kiszka <[email protected]> >>>>>>>> Date: Thu Jul 2 17:12:39 2015 +0200 >>>>>>>> >>>>>>>> cobalt/kernel: Remove unused mode parameter from COBALT_SYSCALL >>>>>>> >>>>>>> We want to keep this. At some point, maybe, we will be able to use this >>>>>>> information to instrument the code with calling context guards, or as >>>>>>> the source of the mode data in the syscall table. Today, it's at least >>>>>>> useful inline documentation, without having to browse the table. >>>>>> >>>>>> This only makes sense when cobalt_sysmodes can be generated from it. >>>>>> Currently it isn't, and I bet there are already plenty of >>>>>> inconsistencies, minimizing the value captured via COBALT_SYSCALL >>>>>> massively. So we should either get rid of cobalt_sysmodes or of that >>>>>> parameter. >>>>>> >>>>> >>>>> "currently" is the point. If you feel implementing either aspects, i.e. >>>>> automatic tagging of the current context when traversing a cobalt call >>>>> based on the mode in the syscall macro, or generating the table data >>>>> based on the info, please do. If you feel fixing any consistency between >>>>> the two mode specs proving your bet right, please do as well. But for >>>>> now, I won't pick that commit. >>>> >>>> The approach of using COBALT_SYSCALL to define the mode only works if >>>> that is also the only place to define it. Let's see first if/how that >>>> can be achieved. >>> >>> That can be achieved by getting the macro to adding data in a >>> special section, then use that section as the syscall table with >>> linker generate symbols. A lot of stuff works like this, like the >>> init table, or glibc constructors, so, this can definitely be >>> achieved. This probably requires the I-pipe patch to modify the >>> kernel linker script, of which there are several instances (one >>> instance by arch maybe). >>> >> >> Yes. Having to fixup the linker script was the reason not to implement >> this immediately, as there could be some backward compat issues to >> address with legacy pipelines running a most recent 3x cobalt core. > > The linker script uses wildcards, maybe we can use a section name in > that namespace to avoid changing the script. >
I was referring to the Xenomai side, properly handling kernels patched with pipelines supporting the feature or not. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
