Glen Kyle McCready

Redwood City, CA 94062
(650) 599-9791




Principal Engineer
VMware Inc.
3401 Hillview Ave
Palo Alto, CA 94304

As a Principal Engineer at VMware the role is largely to identify cross-BU and company wide big picture problems and tackle them. Myself, as part of the Engineering, Trust & Assurance organization, I focused on extending the reach of Product Security as well as looking deeply at Open Source usage and contributions. For Product Security, I became the escalation point, doing deep risk assessments and being the interface with BU GMs and e-staff as the need arose. For Open Source, I am the driving force around process for consumption, the mechanism for open sourcing our own code, and streamlining the process for making contributions to open source packages.

On top at that, the Principal Engineer & Fellow community at VMware is a group of approximately 40 engineers at the top of our R&D ladder. I am the "PE Council Chair," the voice of the Principal Engineers, and have put extensive efforts in to broadening the community and having them be more engaged at a higher level. PE's are VP level individual contributors and as such have a wide purview with significant responsibility for mentoring, strategy, architecture and implementation of product & process.

Sr. Staff Software Engineer - Platform Security
VMware Inc.
3401 Hillview Ave
Palo Alto, CA 94304

Extensive work in threat modeling, risk assessment, and driving change in development processes. A wide reaching role interacting with everybody from executive staff to engineers in the trenches. Most important achievements in this role were ensuring that security concerns were addressed pre-release rather than becoming expensive to fix post-release; this entailed training Quality Engineering, Continuing Product Development, and Core Engineering to have the ability to spot and prioritize these issues appropriately. In many cases this required hands-on assessment and influence to ensure the right thing happened for a given issue.

Sr. Staff Software Engineer - ESX Server/VMkernel
VMware Inc.
3401 Hillview Ave
Palo Alto, CA 94304

Member of the Architecture Review Board. Consulting on numerous projects about architecture, design, and implementation across the VMkernel as opposed to those largely focused on improving storage workloads. Responsible for driving many significant, and minor, changes through all stages of development.

Staff Software Engineer - ESX Server/VMkernel
VMware Inc.
3401 Hillview Ave
Palo Alto, CA 94304

One of the leads on a team rearchitecting and reimplementing the legacy storage stack in the VMkernel into what is now known as the Pluggable Storage Architecture (PSA). Keeping the team honest and on target with the proper layering and goals was a major part of this project.

Authored the document leading the re-design of the VMkernel multipathing module. I took the PSA work as an opportunity to take a step back and put together a design that re-engineered the multipathing layer with a lockless hot-path, a significant improvement over the legacy implementation.

Through the course of the vSphere 4.0 release I lead a small team and successfully cut the cycles per IO approximately in half when compared to the previous major ESX release.

October 2004-2006
Senior Software Engineer - ESX Server Storage/VMkernel
VMware Inc.
3401 Hillview Ave
Palo Alto, CA 94304

I was responsible for porting SAS (Serial-Attached-SCSI) drivers from Linux to the VMkernel. Adding support for new Fibre Channel arrays. General improvements to the entire IO stack from the virtual devices exposed to the guest OS, through the core storage stack, multipathing, the Linux emulation layer and drivers.

September 2002-October 2004
Senior Clustered Storage Engineer
Addamark Technologies (aka SenSage Inc)
74 New Montgomery St, Suite 450
San Francisco, CA 94105

I worked on a filesystem-based database for the Log Management System (LMS), implementing such features as backup and restore to ensure a 100% uptime server.

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.

June 2000-September 2002
Senior Software Engineer
Inktomi Corporation
4100 East Third Avenue
Foster City, CA 94040

In the Content Network Solutions Group my key role was as an expert in UNIX kernels and software portability. As a member of their IO Core team we were responsible for the lower, portable, and yet high performance layer.

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.

June 1999-June 2000
Member of Technical Staff
Cygnus Solutions Canada Ltd.
2323 Yonge Street
Toronto, Ontario, Canada

As a Release Engineer, I was exposed to MS Visual Studio (VC++6.0), and authored InstallShield installers on Windows NT. It also permitted me to apply previous experience with build and release processes, and shell scripting, as the product was partially cross built from a Linux box, and partially natively built with MS VC++ on WinNT. The product in question centered around embedded systems, which is why I was brought on in an advisory capacity at a higher level.

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.

1988-June 1999
Research and Development
QNX Software Systems Ltd.
175 Terence Matthews Crescent
Kanata, Ontario, Canada

Summer student until July 1991; from July 1991 until June 1999, full time.

At QNX I was responsible for many projects including programming tasks, technical support, quality assurance, technical writing, along with training people on both existing systems and systems of my design and implementation.

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...


Available upon request.