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 <ged...@gwu.edu> wrote: > On Sun, Mar 22, 2015 at 6:56 PM, Sujay Raj <sujayr...@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.sherr...@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 <ged...@gwu.edu> wrote: >>>>> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj <sujayr...@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 <chr...@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@rtems.org >>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> devel@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
