GSoC 2012

[Joel Sherrill]

On 03/25/2012 08:14 PM, Kevin Polulak wrote:
> On Sun, Mar 25, 2012 at 8:05 PM, Joel Sherrill 
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>     If you are willing to try, then we are willing to help. No one
>     else has expressed interest in this.
>
>
> Thank you. Headache slowly fading... ;)
>
> On Sun, Mar 25, 2012 at 8:05 PM, Joel Sherrill 
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>     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.
>
>
> Ok, maybe that's not so bad; I enjoy bit bashing. Is in_cksum() an 
> implementation of RFC 1071 
> <http://www.rfc-editor.org/rfc/rfc1071.txt>? If so, I think I can 
> handle that. How must the checksum algorithm be optimized though? By 
> "optimize" do you mean, as RFC 1071 says, "carefully hand-craft the 
> checksum routine, exploiting every machine-dependent trick possible"? 
> Are they to be implemented in C or the native assembly language of the 
> architecture? I would imagine assembly.
I would recommend avoiding writing new implementations. There are
current FreeBSD implementations for some architectures, implementations
in cpukit/libnetworking for others, and a generic algorithm to fall back on
when there is not an architecture specific one. That's all we would expect
as a baseline -- ensure that all architectures covered by union of two 
source
bases have optimized versions. If you can find appropriately licensed 
versions
for other architectures, they could be included. But the goal is 
"compile and
link" for this.
>
> On Sun, Mar 25, 2012 at 8:05 PM, Joel Sherrill 
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>     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.
>
>
> Also not so bad. However, I've never written a NIC driver before. Are 
> they easy enough to understand that I might be able to familiarize 
> myself with them before coding starts? Are there any drivers in 
> particular I could look at that would serve as a good place to start 
> learning?
>
The cool thing here is that you are not really writing a NIC driver. You are
writing the glue that ties the generic driver to the proper BSP specific
access methods (e.g. bus) to use the generic driver.

In other cases, we may see that say a PowerPC system on chip has its own
unique NIC. The decision process is:

+ Does the FreeBSD source have this driver?
     - If yes, add it to rtems-libbsd build and add BSP specific glue.
     - If no, add it to set needing update from current to new stack.

Eventually, you will do that for all existing drivers in the RTEMS tree
and then have to figure out what is required to modify a driver in
the current RTEMS source to the new stack. We want this to be as
automated (e.g. script driven) and mundane as possible. Say you
can fix 80% by script and have to document the other 20% of
changes to do by hand.


> On Sun, Mar 25, 2012 at 8:05 PM, Joel Sherrill 
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>     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'm comfortable with that. That's exactly how I'd like to start as a 
> newcomer.
>
> Maybe having lwIP being tossed won't be such a bad thing. In fact, I 
> think it might work out for the better. After a little more detail, 
> the tasks you've described so far all seem like decent places to start.
>
> At this point, here's what I think I need to do:
>
>   * Read through RFC 1071 to familiarize myself with the Internet
>     checksum algorithm.
>
Yes but you shouldn't expect to write an architecture optimized one from 
scratch.
>
>   * Look through FreeBSD and RTEMS source for architecture-specific
>     implementations of in_cksum().
>
Grab rtems-libbsd.git and see what is in there already. Also the libbsd 
tarball in
http://www.rtems.org/ftp/pub/rtems/people/joel/freebsd/ is what we are using
as "upstream" source. For example, I know cpukit/libnetworking has a m68k
optimized version and there is not one in the current FreeBSD source. We 
want
to get that one into the new tree.

Also consider NetBSD as a source. They support more architectures. A quick
search showed sparc which looks like it supports the sparc (not sparc64) 
port
in RTEMS.

Between the libbsd.txt Asciidoc file and the wiki task page, you should 
get a better
feel.

>   * Find a simple NIC driver to learn how they're written to help
>     gauge my proposal timeline.
>
Try to build things as they are now. Build rtems with --disable-networking
and them build rtems-libbsd per the instructions.

For this part of the project, you aren't as much writing a driver from
scratch as determining what is required to get one from the current
RTEMS stack to build with the new FreeBSD stack code. Surely we
can find one quickly which might be interesting to try and see areas
require changes. Even if you have to "if 0" out blocks of code and
say "X won't compile".
>
>   * Look at NIC spreadsheet and see if a FreeBSD version exists.
>
First may be to see if I can point you to a specific driver and we
both try to see if it exists in the FreeBSD tree. This would help
make sure you knew how to navigate it. :)
> Is that appropriate? Is there anything that should be added?
>
There are other tasks in this like the linkcmds update. Check your list 
against
the Open Project description. :)
> -- 
> - Kevin Polulak (soh_cah_toa)
> - http://cybercrud.net
>


-- 
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/20120326/faa9bed1/attachment-0001.html>