GSoC 2017: proposal v2

Edgar Kaziahmedov edos at linux.com
Mon Apr 3 14:33:53 UTC 2017


On Mon, 3 Apr 2017 17:20:32 +0300
"Dmitry V. Levin" <ldv at altlinux.org> wrote:

> On Mon, Apr 03, 2017 at 05:06:02PM +0300, Edgar Kaziahmedov wrote:
> > On Mon, 3 Apr 2017 15:46:03 +0300, Dmitry V. Levin wrote:  
> > > On Mon, Apr 03, 2017 at 02:35:17PM +0200, Eugene Syromiatnikov
> > > wrote:  
> > > > On Sun, Apr 02, 2017 at 04:29:36AM +0300, Edgar Kaziahmedov
> > > > wrote:  
> > > > > https://github.com/edosedgar/xs-pkg/blob/master/proposal.txt  
> > > > 
> > > > The other thing (besides syscallents.h) I think might useful to
> > > > leverage is the current syscall filtering mechanism, so it
> > > > would be possible to check out which system calls are filtered
> > > > by the provided filtering expression, like "-e
> > > > info=0,write,%sched -e info=!file".  
> > > 
> > > Yet, this information is stored in syscallent.h files.  
> > An actually, I think I will be able to implement the basic
> > processing of filtering expressions in this program.  
> > >   
> > > > Note also that syscall number does depend on leveraged
> > > > personality (and the way syscall is called on some
> > > > architectures, like x86_64).  
> > > 
> > > This is something we might want to be able to filter in the
> > > future.  
> > Yes, I suppose that the first release of this program will be quite
> > draft and support just x86_64 and it will be time to think about
> > some layer between all archs and the main layer of asinfo tool.  
> > >   
> > > > Also I do not see much sense in separating this code into a
> > > > separate executable (after leveraging both syscallents and
> > > > qualify code).  
> > > 
> > > Imagine the tool includes all syscallent.h files to support all
> > > architectures.
> > >   
> > In the short time available, should I add this feature to
> > proposal?  
> 
> iirc, the final edition of proposal cannot be changed.
> 
> Let's just note that support of all architectures in a single binary
> might be a good idea for this project.  For example, ausyscall(8) can
> be built with support of many architectures enabled.
> 
> 

It's possible, I have got one and a half hour to do it.
I do say that it is a good idea, I mean, that the first
version supporting one arch will be extended. To date, as you said,
the task means literally to unit all syscallent.h files in linux/any-arch/
folders.

Regards,
Edgar Kaziakhmedov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170403/7bd24bed/attachment.bin>


More information about the Strace-devel mailing list