GSOC 2015 Monkey HTTP Server

Sun Mar 22 22:56:02 UTC 2015

I submitted the tentative proposal on the proposal page
devel.rtems.org/wiki/GSoC/2015 .

I have a few points to mention.
1. About the BSP to work upon, I have not mentioned anything
specifically in the proposal because that is to be discussed. I do not
have enough working experience with ARM/zynq architecture. ( I worked
with ARM last trying to make homebrew games for the Nintendo GBA where
the emulator was Visual Boy Advance :) )  I have always worked with
x86 architectures. But yes, I can easily switch over to it, in little
time if I am pointed towards some resources about emulating it with
QEMU, and any other specifics about zynq.

2.   The sample proposal talked about setting up repository on
code.google.com, which is not accepting any new project and will close
within an year.

3. About the second part of my project, About separate RSB packaging
of network stacks,
     i. should I include lwIP too?
     ii. Is anyone else working on it? Should that affect my including
lwIP in my proposal?
    iii. Does the project look too ambitious to be completed in the timeframe?
    iv. Will the inclusion of lwIP in the things to be done make the
project too big?

Regards,
Sujay Raj

On Fri, Mar 20, 2015 at 9:45 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 3/20/2015 11:03 AM, Sujay Raj wrote:
>> BSP: pc386 simulated on QEMU
>>
>> On Fri, Mar 20, 2015 at 9:27 PM, Gedare Bloom <gedare at gwu.edu> wrote:
>>> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj <sujayraaj at gmail.com> wrote:
>>>> Well I started writing the first draft of the project proposal ( which
>>>> I shall hopefully finish by tonight, Its 9 PM here ).
>>>>
>>>> I am making "porting the Monkey web server to RTEMS as well as a
>>>> partial reorganization of the network stacks present in RTEMS to make
>>>> it more modular", as the primary deliverable of this project.
>>>>
>>>> From what it appears, porting Monkey can be done in about a month + a
>>>> week for any delays. The development environment is already set up and
>>>> I am tweaking around with the code. So, by the mid-term evaluation I
>>>> expect to get monkey working on RTEMS (without enough time for
>>>> debugging).
>>>>
>>> What RTEMS target/BSP do you intend to use?
>>>
> The most likely candidates IMO are arm/zynq or i386/pc386 on qemu.
> Both include network simulators.  The ARM might be more better since
> there are active core developers on Zynq. And I don't know how much
> action Monkey has seen on non-x86 architectures.
>>>> For the second part, that is, getting the network stack of choice
>>>> built from RSB for the applications to be built against, I am a bit
>>>> apprehensive about the time limit. This task, at the first glance
>>>> doesn't appear that difficult, but it might be. So the second half (
>>>> till the final evaluation ) will involve getting the network stacks in
>>>> a separate build + a separate package for network tests + debugging.
>>>>
>>> I think there is a lot of complexity here.
> There is.  First goal should be Monkey against the new stack. I
> **think** that's
> the only stack that Zynq has a driver for.  Build order is:
>
> + rtems w/o networking
> + new stack
> + Monkey
>
> Once it is working, then upstream patches and make an RSB package. With
> documentation as needed.
>
> That is a good goal.
>
>>>> I think debugging and testing will be a major part of the project.
>>>>
>>> Always.
>>>
>>>> I was thinking along the lines, that the second part of the project
>>>> should be done first, but as Joel pointed out, the first step should
>>>> be monkey getting ported as a package.
>>>>
>>> I agree with Joel. The second part is harder to scope. It will be much
>>> better for you to have a solid task and deliverable (port Monkey) for
>>> the first-half.
> After Monkey is an RSB package, my idea was to decompose some of the network
> services in rtems/ now and make them independent packages (or a single
> add-on
> network services package) that is built separate from RTEMS.
>
> Ultimately, we do want RTEMS + network stack + services but there are steps.
>>>> kindly point out any comments/suggestions.
>>>>
>>> Be sure you identify when and where you plan to submit code. We like
>>> to see code pushed into RTEMS, and into upstream projects if needed,
>>> throughout the summer, not just at the end.
> +1 and documentation with example(s). Setup of any service like this on
> RTEMS
> may have details not applicable to any other host OS.
>
> --joel
>>>>
>>>> On Fri, Mar 20, 2015 at 6:27 AM, Chris Johns <chrisj at rtems.org> wrote:
>>>>> On 20/03/2015 2:57 am, Eduardo Silva wrote:
>>>>>> if there are some application for that project and some accepted
>>>>>> student, I would be glad to sign as a mentor to cover Monkey specifics.
>>>>>> Note: we will need a second mentor to cover RTEMS specifics,
>>>>>
>>>>> I can help, after all you and I have talked about the work to be done
>>>>> before.
>>>>>
>>>>> Chris
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>