Redwood City, CA 94062 (650) 599-9791
Successfully ported the LMS, a large C++ application, from Linux-x86 to Solaris-Sparc, taking in to account several portability factors including alignment, byteswap, and TCP stack differences. While working with the product several performance bottlenecks were idenitified and significant improvements were implemented.
To gain even more performance and stability, some development was Linux-centric: Development of multiple Linux kernel modules, as well as finding, tracking, fixing, and often working around various bugs within the Linux kernels and its drivers were major contributions to the products success.
On top of the Linux work I was tasked with porting Traffic Server, a high performance web proxy-cache, to VxWorks on MIPS.
My second and much more interesting role was as a GDB Engineer where I was responsible for adding support for new target hardware to GDB. This entailed looking at chip specifications and making appropriate modifications and additions within the GDB source code to enable proper display and setting of registers, memory and breakpoints.
This built upon my previous experience with the GNU tools, porting and working with them, on QNX4 and Neutrino (QNX6) that I had acquired while working at QNX.
When I started as a summer student QNX was a small company of less than thirty people. The development team consisted of approximately twelve developers. This small team had been maintaining and extending QNX2 and were in the process of specifying and authoring QNX4. This was an exciting time for me because despite being youthful my opinions were taken quite seriously. I spent a great deal of time with the File System and Network Subsystem designers helping test and prototype things. At this time QNX decided that rather than purchase a POSIX-certified utility suite (ie. userland utilities) that they would implement their own. I took responsibility for several of the key utilities, implemented and documented them.
As well, my expertise was in modem and X.25 communications, so I was tasked with helping to improve QUICS -- QNX's customer support bulletin board system. As time progressed we moved on to a 56Kbps leased line, and later a full T1 that I was administrating while carrying on my other duties (such as programming).
Continuing at QNX I gained experience with ethernet drivers, disk drivers, and board support packages (BSPs) at the design and implementation level. On top of this I spent some time doing performance evaluation of the QNX4 File System, at which point I became part of a small team tasked with improving and maintaining QNX4 while others went on to dedicate their time to Neutrino (QNX6).
Not wanting to lose touch with Neutrino I took on a side project of porting 4.3BSD based networking code from an existing QNX4 codebase to Neutrino. The port involved re-implementing BSD kernel threads (co-routines) and modifying the existing interface to match what Neutrino offered. PPP, SL/IP and Ethernet were all made to work.
Next I spent some time collaborating with the Neutrino team and was tasked with doing the design and implementation of the next generation network buffering code.
This project involved writing the middle layer between the network card drivers/DLLs, user DLLs, and external fd-based clients (ie. /dev/enet1). Key elements to this project being a success were a consistent interface, high speed, and careful thought to allow the drivers to be as small and simple as possible, which meant moving as much logic as possible into the buffering code.
Of course, these are just a few highlights of my ten years at QNX...