GSoC 2012

[Joel Sherrill]

On 03/23/2012 10:37 AM, Gedare Bloom wrote:
> On Thu, Mar 22, 2012 at 8:55 PM, Kevin Polulak<kpolulak at gmail.com>  wrote:
>> I've just completed my Hello World example so I can now begin seriously
>> considering my proposal.
Update 
http://www.rtems.org/wiki/index.php/RTEMSSummerOfCode#Students_Proposals
to list yourself with a link to your proposal in Google Docs.

Share it with at least myself (same email name at gmail.com)
and I will share it with the other mentors.

I personally don't recommend making them public.
>>
>> On Wed, Mar 21, 2012 at 7:24 AM, Joel Sherrill<joel.sherrill at oarcorp.com>
>> wrote:
>>> Other requirements include it being very desirable to be able to use the
>>> same driver with either stack. And to be able to use vanilla existing LWIP
>>> drivers with RTEMS LWIP port but not the BSD stack.
>>
>> While talking to Gedare Bloom on IRC yesterday, he too mentioned that part
>> of the project would include the addition of a BSD compatibility layer. This
>> would allow applications to freely switch between the BSD stack and LWIP.
>> Doing so wouldn't be too difficult as LWIP already includes a BSD socket
>> compatibility API. In fact, the documentation for LWIP even provides a
>> reference implementation.
>>
>> However, there are a few caveats. First, the BSD sockets compatibility API
>> does not support the select() and poll() functions since LWIP simply does
>> not have any functions for implementing them. According to Dunkel, such an
>> implementation could not use the API and instead would have to directly
>> communicate with the stack.
>>
>> Would implementing the select() and poll() functions be necessary? If so,
>> I'll have to look a little further into how they are implemented on other
>> systems. I worry about select() because when I was with the Parrot project,
>> the test suite was always failing on certain platforms due to the highly
>> platform-dependent nature of this function and is very tricky to implement.
>>
> I don't think so. I view the "compatibility" issue as being one of
> simplifying the transition of an application from lwIP to the BSD
> stack in RTEMS. If lwIP already has a decent compatibility layer for
> BSD then you might just be able to rely on that. We don't want to add
> much code on top of lwIP for applications that will use it.
>
> The real trick is to be able to reuse driver code for the two stacks...
+1 +1 +1 :)
>>  From what I've been able to gather from other LWIP implementations, it seems
>> that the BSD sockets compatibility API is not meant to be used as a complete
>> replacement for applications designed for a full implementation of the BSD
>> stack. Rather, it should only be used to help assist in porting existing
>> applications. So far, I haven't been able to determine exactly what features
>> aren't possible but I'll look into it a little further. Is that going to be
>> a problem? I will certainly do my best to implement as many features as I
>> can but if it's not possible, it's not possible.
>>
> Not a problem because those applications will have the option to use
> the BSD stack. This is why we want to have support for both stacks.
> The lwIP stack is meant for smaller devices and applications that need
> a smaller footprint.
+1

I have heard of an RTEMS application using LWIP on a system with
less than ~150K total code and data space. This included SNMP and
a fairly complicated application.

BSD stack is larger and more full featured. If it fits and you need the
features, it is a great solution. If you don't need the features or it
doesn't fit in your target, then LWIP is the option.
>> All that aside, I've found a good article on what should be included in the
>> operating system compatibility layer. Granted, it is for an older 0.6
>> version (the most recent is 1.4.0) but it should at least provide a decent
>> starting point for my proposal.
>>
> Great. See if you can get more updated material.
http://www.rtems.org/ftp/pub/rtems/people/joel/rtems-lwip/

is a port of lwip 1.1.0 to RTEMS for a single project. By the
time it was submitted, it was already way out of date but
it should be a good starting spot.
> -Gedare
>> --
>> - Kevin Polulak (soh_cah_toa)
>> - http://cybercrud.net
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120323/3653ff70/attachment-0001.html>