On Fri, Nov 28, 2014 at 4:17 PM, Dominik Taborsky <bre...@seznam.cz> wrote: > Hello, > > I am a university student and am looking for a school project. I am > interested in RTEMS and so I thought I could help out with development. > The project should take several "school months". It should also involve > the kernel space, not user space. > Welcome!
What areas are you most interested in working on? Are you interested in something that might continue beyond your project? Do you want to be more into core kernel development, hardware abstraction, "middleware" (networks, drivers, etc)? Based on the three projects you posted, I'm guessing the latter, something that operates between the kernel and the hardware. What is your expected hours/wk to spend on this? That will help in gauging the level of effort you should undertake. GSoC-size projects aim at full-time (40 hours) effort for 2 months AFTER getting through the "getting started" and defining project requirements and milestones. Keep in mind that many of the open projects we defined are aimed at GSoC size or greater. You'll probably need to carve off a smaller-size project from a larger one to fit your time constraints. You should also do the "Getting Started" with the RTEMS Source Builder to start getting comfortable with the tools. Ask if you need help, or especially if you run into broken links. Our website has recently migrated and some things broke. > I have browsed through the wiki/trac and I found these 3: > 1) CFI-standard flash device interface, > 2) CEXP integration, > 3) TCP stack rewrite. > I don't know that CEXP integration is that interesting anymore. One of the key features of CEXP is dynamic loading, which is not supported through the RTEMS linker and loader projects (RTL). You might ask Chris Johns if there are projects available for RTL. The TCP stack has mostly been refreshed from BSD by now. I'm not sure about its status. Improving the support for devices and especially frameworks for drivers is a timely project with good potential. See the recent commits that added cpukit/dev/i2c. You might try writing some drivers for i2c devices to fit the new framework. Sebastian Huber may have more info for you. The difficult part in this is testing. We had a GSoC student (Andre Marques) look at some I/O device frameworks as part of the raspberrypi effort too, so you might look for those conversations or contact him directly. > I don't have any experience with implementing TCP, but I have some > experience with data structures on block devices (manipulating MBR and GPT > labels). But I don't know how much of help my experience is. > > I have hard time guessing time requirements for these, so can anyone give > me a hint how complex these are? Or can you give me any other project > assignments? > Estimating time is hard! Especially without much context for your availability or skills. :) In general, I'd suggest scoping out a project with many smaller milestones so that you can make good progress, even if you don't get to the end, you should have a nice set of accomplishments. Gedare > Any input is welcome. > > Best regards, > Dominik Taborsky > _______________________________________________ > 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
