Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.