| |||||||||||
Free Linux driver development offeredFree Linux driver development offeredPosted Jan 31, 2007 14:34 UTC (Wed) by sasha (subscriber, #16070)Parent article: Free Linux driver development offered
For some hardware manufacturers, it is important to get drivers for _existing_ enterprise distors, not for _future_. In such cases, this offer does not help: it is not easy to backport driver from the latest kernel to the old kernel used in, say, RHEL3. So, hardware manufacturers in any case have to fix/maintain the driver themselves. And they'll see no need to provide specs/code in such a case.
(Log in to post comments)
Backporting vs forward porting Posted Jan 31, 2007 15:04 UTC (Wed) by proski (subscriber, #104) [Link] 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.
Backporting vs forward porting Posted Jan 31, 2007 19:37 UTC (Wed) by grouch (subscriber, #27289) [Link]
Easier still is for manufacturers to take GKH up on the offer, let the kernel developers deal with maintaining the drivers for new kernels and let the distributions take care of the backporting. My guess is that the developers at Red Hat, as one example, would much rather backport an open, working driver than to get calls about closed drivers they can't fix.
|
|||||||||||