What considerations need to be made when choosing the version of kernel for an embedded device?

Question

I have used buildroot to successfully create a kernel, root file system and cross-compilers to enable me to write application code to run on an embedded device. Currently I have no need to write device drivers and currently have no idea how to go about it anyway but it is quite likely that in future I may need to do this. From my research I have come to understand that the kernel API can change between versions and that writing a device driver is specific to a kernel version unlike writing a user level application. Basically I would like to know:

1. Is the above correct?
2. What factors need consideration when deciding on a what kernel version to use?

The reason I ask is that from all the literature that I have read on the subject (and the attendance at an embedded linux course) deals with version 2.6.x kernels. I am building by embedded system using a 3.6.11 kernel but I am wondering why the course and literature seems to deal with these older kernels. Are there beneficial aspects to using an older kernel, or are there drawbacks to using newer versions?

Answer 1

3.x is just continuation of 2.x - at one point Linus decided that the "x" part of the version is too big. Generally you probably want reasonably recent kernel, probably one marked as "longterm". A lot also depends on your application as well - while remote security holes in kernel are rather scarce, local problems are much more prevalent.

Answer 2

Picking a kernel is a constraining problem:

1. kernel must be new enough to reliably support hardware you're running on (i.e.: NIC drivers)
2. kernel must be new enough to reliably support software features you're planning to use (i.e.: iptables)
3. kernel must be new enough to get rid of as many vulnerabilities as possible
4. kernel must be old enough to be proven reliable (there is such a thing as 'bleeding edge')
5. kernel must be of series that will receive long term updates (unless it's a system that once deployed has no chance of being updated, then it doesn't matter, but you must put more weight on #4 and #3)

Once you run through that list, the list of kernels that actually fulfill your needs tend to be very small, so the solution tends to be clear.

Answer 3

Can't you just use the most recent stable kernel? If you have old source code for device drivers I think that all you should check is that the device names match (like /dev/eth0 is /dev/enp2s0f0 -> I still don't know why this is any good).