GSOC 2015 Monkey HTTP Server

Tue Mar 24 10:21:51 UTC 2015

Thanks.
I submitted the proposal online at the GSOC website. Also, I included
lwIP in the proposal.

On Mon, Mar 23, 2015 at 8:52 PM, Gedare Bloom <gedare at gwu.edu> wrote:
> On Sun, Mar 22, 2015 at 6:56 PM, Sujay Raj <sujayraaj at gmail.com> wrote:
>> I submitted the tentative proposal on the proposal page
>> devel.rtems.org/wiki/GSoC/2015 .
>>
> Please also submit your proposal to the official GSOC Melange system.
> You can revise it until the deadline, and it is better to get it in
> early to avoid any technical difficulties.
>
>> 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.
>>
> The BSP / arch shouldn't matter too much, although Monkey is probably
> more-used on x86 platforms. Really, it would be best for you to use
> both platforms so you can shake out any bugs that are arch-dependent.
>
>> 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.
>>
> Use github. We need to update the sample.
>
>> 3. About the second part of my project, About separate RSB packaging
>> of network stacks,
>>      i. should I include lwIP too?
> Yes.
>
>>      ii. Is anyone else working on it? Should that affect my including
>> lwIP in my proposal?
> Possibly, but don't let it affect your proposal. The most recent port
> of lwIP appears to be for the beagleboard. We might have a student
> work on integrating it, possibly even into RSB. But you should still
> anticipate that you might get to do it yourself.
>
>>     iii. Does the project look too ambitious to be completed in the timeframe?
> Hard to say. Sometimes things that look hard turn out easy, and vice versa.
>
>>     iv. Will the inclusion of lwIP in the things to be done make the
>> project too big?
> No. I think it is a good set. You always want to have "stretch goals".
>
>> 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
>>>
>>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel