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

This will generally work. I would just give it a try, but there are a few things you need to be aware of:

• When building, binaries need to be built for the CPU architecture and capabilities of your target. Given that they're both x86, this will help a lot, but you still need to be careful about using processor features like sse3, etc. If you build a binary that takes advantage of features that are absent on your target installation, it won't work.

• Your build system's kernel might exert some influence over the behaviour of your chrooted environment. You can't use a different kernel for a chroot vs the host system, so you may encounter discrepancies between the two. Apps generally ultimately communicate with the kernel via libc though, which provides a standard interface that can help prevent such problems.

• Your libc needs to be compatible with your kernel, to some degree. The libc from your embedded system might not be totally compatible with your kernel, depending on interface changes; however, if the libc predates your kernel, this is unlikely to be a problem (old kernel interfaces are more likely to stick around to support old binaries).

• Your host system's services will be visible to your embedded system. This is common to any chroot, as they share process tables, network interfaces, etc.

• For your 'additional libraries', you could use static linking to link those to your application. Then you can avoid deploying the libraries to the device. Your mileage may vary.

You might consider using a virtual machine to do this instead. It won't necessarily remove all the concerns (like processor features/flags), but you can have an environment that matches your embedded system much more closely. That is, you can use the same kernel, run the same boot process, avoid contamination by the host's services...

Be aware that if you set up a build toolchain inside your chroot, you might want to think about how you will copy the new files back to your embedded system; you probably do not want to copy the toolchain files (gcc, etc).

Try setting it up and writing a test application, build some libraries or whatever, and see how well they work when moved to the embedded system.

This question has a lot of assumptions in it.

Here are some reasons.

The kernel interface is not stable so a module for one version may not compile for a different version.

The kernel may not expose a required facility.

The kernel may expose a required facility but not in a way that is acceptable, for example requiring the module to have a particular license.

The people writing the code found it quicker to write the code this way.

As to your options if you need a newer kernel.

1. find someone else who has already ported the code
2. port it yourself
3. pay someone else to port it (may not need money, beer, flattery and curiosity may work).