GSoC 2012

[Joel Sherrill]

On 03/25/2012 06:35 PM, Kevin Polulak wrote:
> Ultimately, I suppose it's up to you guys whether the lwIP port is a 
> suitable project. I'm just worried if it may be too late to 
> reconsider. Up until now, I've completely devoted my entire spring 
> break to learning about and trying to design this project. If it does 
> get tossed (which I'm guessing it already has at this point), then I'm 
> pretty much starting over at the same time I'm supposed to be 
> developing a proposal for a project I don't have yet. Even if the 
> project didn't get tossed, I don't want to spend my summer working on 
> something useless that there's no need for and will just end up in the 
> bit bucket.
It is never too late to reconsider. Applications haven't even officially 
opened.

If you are willing to try, then we are willing to help. No one else has 
expressed interest in this.
>
> Sure I'd love to work with everyone else on the BSD stack but to be 
> honest, I have zero experience with it. I do have a copy of TCP/IP 
> Illustrated Volume 2 that explains all the internals. However, it's 
> such a tremendous subject that I'm not completely sure I could 
> familiarize myself with it in the little amount of time I have left to 
> a point where I could accurately and confidently break the project 
> into smaller tasks and develop a timeline.
>
Did you look at the task list on the link I posted?

Let me break one item down -- the in_cksum one.  OAR is committed to the
port on two architectures (x86 and MIPS). That leaves potentially 13 other
architectures in RTEMS to address. We don't expect you to optimize the
in_cksum for all of those. Find an implementation in either the FreeBSD
or current RTEMS TCP/IP stack, integrate it into rtems-libbsd.git,
verify that it builds, and our tests continue to link. That's it for 
that task.

We have (or will have) a spreadsheet of NIC drivers in the current tree.
For NICs in BSP directories, identify if there is a FreeBSD version. If so,
integrate it into rtems-libbsd.git and verify it builds. If time 
permits, you
may take a stab at a version of the BSP specific glue code for that BSP
that is known to compile.

Most of the tasks are "point tasks" that have a BSP or target architecture
multiplier. Do X for each architecture. Or do Y for each BSP specific NIC.

No one has the hardware to test every RTEMS configuration so in
many cases, we are just doing "best effort" ports. Be care, review it,
hope it works and rely on someone else to debug it.
> I'll spend some time looking into the current state of the BSD stack 
> project. I don't want to disappoint anybody but I'm a little unsure of 
> whether I have enough knowledge about it to take it on as a project.
>

The first thing to realize is that you won't be a trailblazer on this 
project.
The team doing this is focusing on two BSPs and two NIC drivers to prove
that the stack works. That leaves other architectures, many other BSPs, and
many NICs to address. We are doing "depth" and you would be doing "breadth".
The mentorship here should actually be stronger than on many projects 
because
we are actively working on this.

I will also admit that I am leading the OAR team doing the FreeBSD port and
none of us feel 100% comfortable. We know the general path and the issues
facing us for the next few steps. We will kill those snakes and dragons and
see what lurks under the next rock.

Honestly, many "porting" efforts are just a matter of keeping focused on 
what
is required by the porting layer itself. Then debugging why test cases don't
work and fixing those issues in the porting.

I have ported many packages to RTEMS and would never claim to be an
expert in all the technologies they cover. But I am comfortable poking at
things, diving deep, and trying to find that magic point to "cut and 
replace".

--joel

> -- 
> - Kevin Polulak (soh_cah_toa)
> - http://cybercrud.net
>