Jason Kridner
Jason Kridner is best known in the Embedded Linux Community for his work on the BeagleBoard project. As the lead evangelist of the BeagleBoard project at Texas Instruments, Jason participates tirelessly in the Embedded Linux community mentoring and training developers new to the BeagleBoard or to embedded development in general. Jason has conducted several extremely popular hands-on hacking sessions at Embedded Linux conferences and continues to move the community forward at every opportunity.
The following is an interview with Jason where he shares a little about his current work and passions.
1. Can you tell us who you are, what you do, where you work, and what you're currently working on professionally and personally?
My name is Jason Kridner and I am a software architecture manager responsible for ARM Microprocessor Community Engagement at Texas Instruments. The project I'm working on for which most people know me is the BeagleBoard. It started more as a personal project between me and several people at TI including Gerald Coley (hardware designer), Steve Kipisz (debug and bring-up) and Khasim Syed Mohammed (u-boot and kernel pushes), but it has become a professional project as well. The BeagleBoard blurs the lines between a desktop platform and an embedded platform, bringing familiarity to developers as they look to transition from other development environments. On a personal project level, the BeagleBoard provides me a platform I can use to advance my ideas about web-based distributed collaboration.
My latest fascination is with Cloud9 IDE, Node.JS and Processing.JS, but I tend to have very short personal projects. I'm currently in the process of building a couple of 3D printers to which I can add some BeagleBoards for localized object scanning (to make a 3D copier).
2. Can you describe your history with Linux and Open Source Software?
My experience with open source software dates to about the time that I started attending Texas A&M University in 1990 and learned about public domain Unix application software available on the Internet instead of dealing with all of the DOS-based shareware on BBSes at the time. At school, I had access to Sun workstations running X11 and I became very interested in getting these Unix apps to run on my PC at home. I began using the DJGPP port of the GNU compiler collection as my compiler of choice. I eventually even ported Perl to DOS using DJGPP and wrote my own plug-ins for issuing automated tests against PC ISA plug-in cards. I even started using DGJPP for X11 applications once Desqview/X arrived.
I started using Linux with the TAMU distribution and using Unix apps got a whole lot easier than trying to use them on DOS. I stayed at the user space level and did most of my development for closed 16-bit embedded systems. I worked on FAT file system and USB mass storage class code that was at one point published as "open source" by one of our customers. For me, it felt like high praise for others to be interested in using that code and of only positive benefit to TI as that software functionality was rapidly on the way to being a mere commodity.
Of course, the BeagleBoard effort was focused on trying to appeal to kernel hackers and open source enthusiasts.
3. When and why did you become involved with Embedded Linux?
I got started with Embedded Linux when TI launched its DaVinci line of ARM+DSP embedded processors. I relied upon my experience as a user of Linux and embedded processing with DSPs. I'd certainly recommend for people today to become familiar with Linux as it is reaching more and more development environments it hasn't previously served.
My start with doing anything in the Linux kernel started with applying the lessons I learned by writing USB mass storage class drivers to an implementation in an embedded Linux design for a customer. Working with Linux experts in TI, we brought the performance from about 2-3MB/s to over 10-12MB/s, making it possible for our customer to be competitive in the market. After having seen the costs of not having these optimizations included in future implementations of our systems running Linux has done a lot to shape my views of the necessity to push all optimizations upstream quickly and I've been an advocate for working directly with the Linux community ever since.
4. What aspect of hacking embedded Linux and/or embedded devices is the most fun for you, and why?
While I love getting lost in coding something up and seeing a new board or application boot up in a usable way for the first time, what I love the most is seeing something that works reliably and consistently that others can reproduce. Whenever I see an elegant embedded solution that just seems to make the software disappear and the user can intuit not only how to utilize the design, but how to extend it and make something new, it just makes me smile.
5. Do you have a set of favourite tools, both hardware and software that you recommend most frequently?
Well, I most recommend the BeagleBoard and the Angstrom Distribution of Linux, but if I had to pick something I didn't work on, my #1, #2 and #3 would be git, git and git. There's just nothing like being able to manage code in a distributed manner like when using git. I only wish board design in VHDL was more mature and more interesting to a typical board designer such that we could manage our board designs in git as well.
6. MontaVista Linux currently supports open SDKs for the BeagleBoard and several other development boards. What's your opinion of commercial Linux companies supporting boards?
I think it is great! Having a simple way to both evaluate the capabilities of the hardware platform as well as the software platform in a time and cost effective way seems like a huge win to me. The experience with every SDK is a bit different and can have a significant impact on your overall productivity, so I certainly recommend you kick the tires on several before getting too deep into your project.
7. How important is community in the Embedded Linux world?
The community is everything! If I could fixate on a set of features that didn't move, I might be happy with some other more minimal architecture, but having problems solved for you before you face them is amazing. The size, capability and passion in the Embedded Linux community cannot be substituted.
8. What do you feel is the greatest change in the Embedded Linux ecosystem over the last two year, both for better and worse?
I see significant changes on two primary fronts, greater blurring of the lines between desktop, mobile and Embedded Linux as well as a growing interest in Embedded Linux by do-it-yourselfers new to Linux entirely, perhaps drawn in by Android or more affordable development platforms like the BeagleBoard. The good thing is that Embedded Linux is more capable than it was two years ago and more people are using it to do new and interesting things. The bad thing is that people coming in with bad habits or wrong expectations that might result in highly non-optimal solutions.
I guess I could have also given a nod to greater collaboration between vendors through organizations like the Yocto Project sponsored by the Linux Foundation and the non-profit Linaro consolidating some multi-vendor ARM activities into a jointly supported entity with the stated goal to improve mainline open source software from which we can all benefit, but I believe it is the new people we are bringing into the Embedded Linux ecosystem with new problems to solve who will make the greatest impact.
9. Where do you see the Embedded Linux hardware and software development moving in the next 12 months? For example, will the trend toward build systems continue?
I think build systems like OpenEmbedded will continue to grow in importance in Embedded Linux, but I think device tree and improvements in both kernel drivers and application libraries for I2C, SPI, USB and similar embedded serial-port connected peripherals to grow rapidly. With shops like Sparkfun and Adafruit appealing to individual hackers, I think you'll see a lot more of the sensors and actuators they sell get native support in the kernel.
