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.
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
