On Sun Mar 20 2011 at 23:08:56 +0200, Vladimir Kirillov wrote:
> Hello, tech-kern@!
> 
> I've been browsing around the 2011 GSoC ideas and have hit this:
> 
> Research converting system interfaces to XML
> http://wiki.netbsd.org/projects/gsoc_2011/xmlif/
> 
> I have been researching on the topic of consolidation and systematization
> of system APIs and interfaces with goals to provide better documentation
> and facilities for further semi-automated code transformations to
> simplify API transitions and code integration.
> 
> Last year I was using clang compiler's abstract syntax tree to
> gather a 'component model' of the kernel code and stored into a
> database for further analysis, however the project kind of stalled
> at the moment.
> 
> I find this research idea a great fit to redirect the potential and
> breathe in some real use case into my previous work.
> 
> The suggested interface specification language and the specifications
> itself can be used to produce the following analysis data (from my
> point of view):
> 
> - graphical representations of interface dependencies (autogenerated
>   UML-like graphs)
> - detect loose API dependencies and API misuses all over the code
> - headers autogeneration
> - runtime debugging information
>       - ddb pretty-printers (as suggested on the page)
>       - probably more stuff to aid runtime kernel inspection
>               like solaris mdb?
> 
> 
> I'm an undergraduate student at Kiev Polytechic Institute with BSD
> internals experience and willing to take part in such GSoC project
> if the suggested mentors will be as enthusiastic about this as me.
> 
> What do you think?

Hi,

Since you have familiarity with the subject, be sure to quote some tools
you are planning to use.  One of the problems here is that the NetBSD
base system lacks XML tools, and naming some of the ones likely to be
required gives a fairly good idea where on the research<->usable axis
the project lies.

Also, the proposal should include one or two use cases you actually plan
to implement to evaluate your work -- preferably something with a little
more impact than header autogeneration.  This will give anyone reading
your proposal a good idea of what the potential and impact to NetBSD is.
The use cases can of course be later adjusted if some better idea pops
up as a result of the research.

  - antti

Reply via email to