On 2015-07-02 19:55, Gilles Chanteperdrix wrote: > On Thu, Jul 02, 2015 at 07:35:08PM +0200, Gilles Chanteperdrix wrote: >> On Thu, Jul 02, 2015 at 07:31:38PM +0200, Jan Kiszka wrote: >>> On 2015-07-02 18:56, Gilles Chanteperdrix wrote: >>>> On Thu, Jul 02, 2015 at 06:49:33PM +0200, 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 >>>> >>>> Use that section to build the syscall table. Or sort it. The section >>>> can not be used directoy, the syscalls are not in the right order. >>> >>> What would be the key for sorting? Semantically the syscall number, but >>> how to translate that into a key (i.e. a symbol name) that the linker >>> could sort properly? >>> >>> As far as I can see for x86, the kernel uses a host script to generate >>> the syscall table which is defined arch/x86/syscalls/syscall_*.tbl - >>> presorted. That step also generates the #defines for the syscall numbers. >> >> Yes, we probably need to add the syscall number to the >> COBALT_SYSCALL macro. Or build it from the function name. A second >> possibility is to keep the current table, but do not fill the flag >> field, and use the information in the section to find back each >> syscall and fill the blanks. > > Yet another possibility is to run a script on the sources, which > generates the table as .c code. The script would simply handle the > calls to the COBALT_SYSCALL macro. This can be done with sed or awk > even. And this does not require playing with the linker script.
I more and more believe that is actually only feasible approach. The linker tricks seem to fail because we cannot prepare the required input as needed. If they worked, the kernel would surely use one of them. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
