Regular users of our Linux* and FreeBSD* offerings probably noticed a shift in our design a while back.  In "Ye olde days" all the shared code was contained in one file.  We were cramming a ton of code into one file and it was getting unsustainable.  The code was built around a ton of ‘if’ statements, and as the amount of supported hardware grew, so did the size of the ‘if’ and ‘switch’ statements.  We elected to break up the statements by segmenting the code into different hardware types by file.  To glue all this together we moved to using function tables.  Some people don't like using function tables, but we felt it was the best way to solve our technology issues.  The Linux kernel guys seem to have some issue with it, so we have to do some work to compress the redirection tables at times.

This also allows for a smaller driver to be built if you’re interested in that.  Right now you can do it with using the #ifdef labels that are built into the driver.

     Another common question about our shared code is around the difference between the FreeBSD and Linux shared code.  The difference is mostly in the names.  Because the driver is called em or igb on FreeBSD and e1000 or e1000e or igb on Linux the function names need to reflect the name of base driver.  We have scripts that change the names to driver names.  Otherwise they are they same.  We have to keep ownership of the IP of the shared code so we don’t always accept input to it.  But that’s a whole ‘nother post.

     Some drivers do remove those #ifdefs so if you want the unfiltered shared code, please contact your Intel sales team since some of the code may require a source license agreement.  Only a trained Intel representative can make this SLA.  If you’re interested in having us publish the near raw code without the SLA, I'll need to hear it in the comments!!  If you don't want to leave a comment, please contact your Intel field sales team and request it.

Big Review:

1)      The shared code principle lets us maximize quality, shorten development time all while keeping readable code.

2)      If you have a custom O/S Intel you can request access to the raw shared code to help give you accelerate your driver work.

3)      Thanks for using wired Intel® Ethernet