GSOC 2015 Monkey HTTP Server
Joel Sherrill
joel.sherrill at oarcorp.com
Wed Mar 11 21:12:07 UTC 2015
cc'ing Eduardo Silva from the Monkey project. Eduardo,
you may have to subscribe to get messages back to the
RTEMS list.
On 3/11/2015 3:45 PM, Sujay Raj wrote:
> Hi,
> I am interested in working on porting the Monkey HTTP Server to RTEMS
> as a GSOC project.
>
> This is the first time I am applying to GSOC and though I have written
> a lot of code, it is also my first attempt at working in an Open
> Source project.
>
> Some personal projects that I have worked on include developing a
> hobby operating system ( following Bran's Kernel Development Tutorial
> and osdev ), writing ray tracers, as well as porting the nweb web
> server ( 200 lines of C code ) to python ( it was undertaken as an
> exercise to learn more about the functioning and implementation of
> webservers ). Further I have familiarity with x86 assembly (nasm), not
> extraordinary, but fluent.
>
> I have successfully compiled and executed sample programs for
> sparc-sis but from what I have read sparc-sis doesn't support TCP/IP.
> So I followed the wiki and compiled it for pc386 on QEMU too as it had
> networking support.
You either want to use pc386 on qemu or arm/zynq on qemu.
> I was wondering if this may be the required architecture and simulator
> for this project.
>
> Further, I would like to mention, that though this may be an approach
> with GSOC in mind, but I wish to end up as a full time contributor for
> the RTEMS project in time to come as it suits my taste and past
> experience.
>
> Kindly point out things I need to do to proceed and other comments.
Eduardo mentioned that this may not be enough to occupy your entire
summer. So we would need to identify other work to bundle with this.
Monkey for RTEMS should get built as a package inside the RSB. This
is like the BSD ports where it always builds from source. Fetch upstream,
patch as needed and build for the embedded architecture.
Random idea which would need other mentors to buy into. We have an
old IPV4 stack in the current tree. We have a newer IPV4/V6 IP stack
outside the tree. And there is a working LWIP port. My concept long
term has been to divide things into packages:
+ RTEMS (ok done)
+ network stack of choice - done for new IPV4/IPV6 stack. current
stack is in tree, would need to be pulled out into its own build
module, LWIP is a candidate for RSB packaging but could get done
by another student as part of BeagleBone work.
+ network tests - some in the tree, some in network-demos
+ network servers - ftpd, web servers, telnetd, pppd, etc should be
packages that can be built against your network stack of choice
This idea hasn't been reviewed by anyone so would need feedback
but conceptually, it makes network services an add-on to the RTEMS
core and makes it easier for users to pick a stack. More modular
pieces.
The first step though is getting Monkey ported as a package. The
other steps would need discussing.
> Regards
> _______________________________________________
> 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
More information about the devel
mailing list