<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
Ilya A. Volynets-Evenbakh wrote:
<blockquote cite="mid:4B855F90.1080505@total-knowledge.com" type="cite">
  <pre wrap="">Michael Sternberg wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello everybody

I'm pretty new in Linux kernel development and seeking answers for
some questions related to binary compatibility between various kernels.

I know that there is no stable kernel interface in Linux.
Here are appropriate articles that describe the problem:
<a class="moz-txt-link-freetext" href="http://www.kroah.com/log/linux/stable_api_nonsense.html">http://www.kroah.com/log/linux/stable_api_nonsense.html</a>
<a class="moz-txt-link-freetext" href="http://tinyurl.com/yane5lb">http://tinyurl.com/yane5lb</a>

I understand that the best way to make the GPLed module to be
supported in all future versions of kernel is to add it into the main
kernel tree.

Question #1:
Where do I start if I want to add my module into main tree ?
What are chances that this process will succeed ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->If your module is well-written, chances are pretty high.
  </pre>
</blockquote>
If your module is well-written and does something useful, and you are
willing to spend the time answering change requests, and in some cases,
nagging the maintainers until they respond, then pretty high.<br>
<blockquote cite="mid:4B855F90.1080505@total-knowledge.com" type="cite"><br>
  <pre wrap="">If it really is binary-only, you'll have to go "blob" way - provide your
code inside
a binary which uses your API, and sources for a wrapper, which can be
compiled to
particular kernel. That's how ATI, Nvidia, and other binary-only driver
providers
do it.
  </pre>
</blockquote>
I should point out that this way has two reasons. One is the one you
stated. The other is that, under some circumstances, a GPL wrapper may
be seen to isolate the binary blob from the GPL kernel.<br>
<blockquote cite="mid:4B855F90.1080505@total-knowledge.com" type="cite">
  <blockquote type="cite">
    <pre wrap="">Question #2:
Let's say I built a binary kernel module with headers of
2.6.18-92.el5-i686 Red Hat kernel.
Will it work with another 2.6.18 Red Hat kernels ?
With plain vanilla 2.6.18 kernels ?
With other 2.6 kernels ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->Depending on kernel build options, it might work in some very rare
cases. Safe bet is "No"
  </pre>
</blockquote>
Basically, the answer is "it depends". If you happen to use an
interface that RedHat did not touch, then it will work. If you did,
tough cookie.<br>
<br>
Basically, the more similar the kernels are, the more likely your
module is to work. You will excuse me for stating the obvious.<br>
<blockquote cite="mid:4B855F90.1080505@total-knowledge.com" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">Are there any promises for kernel binary compatibility from, at least,
large vendors like RHEL and SLES ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->No.
  </pre>
</blockquote>
I'm not sure there are no promises regarding patch revisions inside
same version kernels (i.e. the different Redhat 2.6.18 kernels).<br>
<br>
Shachar<br>
<br>
<pre class="moz-signature" cols="72">-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>
</pre>
</body>
</html>