GSOC 2016

[Philippe Ombredanne]

On Sun, Mar 13, 2016 at 7:54 PM, ayushIIITD <ayush12029 at iiitd.ac.in> wrote:
> On 04-Mar-2016, at 6:02 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
>> On Fri, Mar 04, 2016 at 12:14:32AM +0530, Ayush Goel wrote:
[...]
>>> I’ve been working on something similar for the past one year.
>>> I’ve been trying to see if there’s a perfect semantic similarity between two
>>> versions of the same library, by comparing their sequence of system calls.
>>> The tool i’m building assumes that the end user won’t have any access to the
>>> library’s source code, so I’m only working with binaries. I dynamically
>>> instrument them, using tools like Intel’s pin, bit blaze and then extract
>>> the sequence of system calls.
>>
>> Is the tool you are talking about published under a free software license?
[...]
> No the tool is not published. This tool is a part of my research, and we just
> submitted our research to FSE 2016. We’ll open source it once it gets
> published.

If you have some code of yours that would be publicly visible it would be useful
to support your application.

> I can see strace currently supports 13 output formats.

What do you mean by 13 outputs formats?

> Regarding GSOC 2016, I can see one of the projects “Refactor the
> output-related code to support JSON as an output format” still listed despite
> it being there for the past two years.
> I can see the reason for this not being a part of the main codebase, is
> because the patch was too big to be accepted.

Big is one reason, but there were also other: the patch still required quite a
bit of work. As for last year GSOC, there was no good project proposal on that
topic.

> I’d like to streamline this code and submit it in form of a number of smaller
> patches. Given the patch, it makes it extremely easy to reverse engineer what
> he did and also understand the changes that need to be made.

That could work, but how would you submit smaller swallowable patches and still
get so something that would reach some completion and would be achievable in
the GSOC timeframe? A structured output will require to touch a _lot_ of code:
It may require so many code changes that it may not be a realistic GSOC project
altogether. So it would be good if you can describe how you would approach this
in the details.

The key difficulty is this: say you submit small patches and they are accepted.
But the amount of work to get to some usable is such that you cannot complete
something that works and you cannot contribute further after the GSOC.
So we are now with a bunch of partial code that is eventually useful towards a
structured output but incomplete; and this may possibly bloat the codebase
and create other problems.
So while incremental patches may work in theory, this is hard in practice as we
cannot leave a half finished structured output in the codebase.

> I’d like to take this up for the upcoming GSOC.
> Initially I think I can submit a small patch, just declaring the print
> functions for the json format, in the definitions header (def.h) file as a
> part of my proposal.

Could you elaborate on this?

PS: Please do not top post...

-- 
Cordially
Philippe Ombredanne