Backporting vs forward porting

Backporting vs forward porting

Posted Jan 31, 2007 15:04 UTC (Wed) by proski (subscriber, #104)
In reply to: Free Linux driver development offered by sasha
Parent article: Free Linux driver development offered

Actually, backporting of the driver is usually easier than "forward porting". Many API changes serve the purpose of making drivers easier to write with less errors. When backporting, the missing code and definitions can be taken from the new kernel.

When the driver is written for an old kernel, it may not fit the model of how the driver should behave in the future kernels. It's harder to take the missing pieces from the old kernel, because some of them were removed with the purpose to forbid or to discourage some behavior or to force the driver developers to recheck some assumptions.

A recent example is the new INIT_WORK with two arguments. It's much easier to go back to the three-argument INIT_WORK just by using the first argument as the third argument as well. Going forward to the two-argument INIT_WORK actually requires changes in the worker function so it can assess the data it needs.

The same applies to sparse annotation. It's easier to provide a replacement for __le32 for old kernels than to actually do the annotation and find a couple of actual bugs in process.

It would be easier for manufacturers to concentrate on backporting and new features, and let the kernel hackers do the routine API updates of the driver.

---

(Log in to post comments)