GSOC 2015 Monkey HTTP Server

[Gedare Bloom]

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