[GSOC 2014] Some thoughts about the code and the proposal

yangmin zhu zym0017d at gmail.com
Fri Mar 21 12:22:44 UTC 2014


On Tue, Mar 18, 2014 at 9:09 PM, Philippe Ombredanne
<pombredanne at nexb.com> wrote:
> yangmin zhu:
> I think you are the right track!
> This is a very thorough approach you are taking there which is very good!
>
> Small note: try avoid using HTML emails and stick to plain text on the list.
>
>
>> From this mail
>> (http://sourceforge.net/p/strace/mailman/strace-devel/thread/4515571.KdWbzpdtLr%40vapier/#msg32095710),
>> I find "the advanced path decoding itself would be large enough to fill a
>> whole 3 month GSOC project".
>>
>> So, Are you suggesting us not to choose the "advanced path decoding" as the
>> proposal?
>
> Forget this post, I was just suggesting someone to look into "advanced
> path decoding" too in addition to his suggestion.
>
> Please make a proposal!
>
>> I read the discuss in the mail and found the "Structured output" is also a
>> good choice and from my current understanding of strace, we can just modify
>> the output part of strace alone to finish the work.
>>
>> From this mail(http://sourceforge.net/p/strace/mailman/message/32072591/ ),
>>
>> Is it means that I should first finish a very basic prototype addressed some
>> of the problems in the list and post the patch to the mailing list?
>
> This pots was just a list of several details to possibly consider in a
> proposal and an implmentation.
> This is great if you can post a few patches and ideas ahead of your
> proposal but is not an absolute requirement.
> The work mode if you submit a proposal, and if this is accepted by
> starce and the GSOC would be to discuss your approach and submit
> pathes as you go for review to the mailing list.
>
>
>> by the way, I find in this
>> mail(http://sourceforge.net/p/strace/mailman/message/31924683/) that the
>> current strace is "Printing of decoded C constructs is mostly open-coded" "
>> Support of other formats inevitably means introducing some API for
>> structured output " and "the strace code base would have a framework to call
>> an output module and that would take care of the exact output details."  .
>>
>> So I am just wondering why strace hard-coded these decoding function and why
>> use the method using in flex/bison, such as:
>>
>> we first define a specification file(plain text with a specific grammar)
>> like:
>>
>> define sys_open: open ( $1, $2 ) = $0
>>
>> and then strace parse this file and substitute these $1,$2,$0 variable with
>> real arguments and output the result string. because I ever used flex/bison
>> and I think this maybe better than the hard-coded way?
>>
>> this is just my very first thoughts and I know it's immature(we still need
>> some special way to handle those complex syscall's argument and this
>> requires really a great lot work to do).
>
> This is an intriguing idea! I like it, I am sure the devil is the
> details though.
> Are you suggesting to use a string template for the output, or to have
> a grammar to do the actual decoding or arguments?
>
>
> Thank you again for this detailed and thorough email!
> Cordially
>
> --
> Philippe Ombredanne
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel


Hi Ombredanne,
Sorry for the HTML email. it's a mistake.
I had submitted my proposal to GSOC and you can find a basic prototype
in my proposal. In order to make it better, I contacted some strace's
output parser's authors to collect their real-world demands (I find
the list from [1]). Some of them had replied their suggestions. Their
real-world demands absolutely give me a shock and made me think more
and deep about what I should do. I will made changes to reflect their
suggestions.
I think to use a string template for the output may ease the burden
for supporting different output format. And It would be great if we
can find a way to do this job elegantly. I want to first try to figure
out how to do this in JSON with hard-coded  output code. Once I
collected enough information and hava a sufficient understanding about
the interface degisn, argument process and the special signal events,
I will try to introduce the string template to make it better. It's my
ultimate goal to replace the strace's output code with string
template.
If you have any suggestion to my proposal, please feel free to let me know.

[1] http://sourceforge.net/p/strace/mailman/message/31924683/

Thank you
--
Yangmin Zhu




More information about the Strace-devel mailing list