Christopher Turcksin <turcksin@raleigh.ibm.com> writes:
> "Eric W. Biederman" wrote:
>
> > If what you are after is a way to release a driver that is not a
> > hassle to add to an already working system, you will find a more
> > receptive ear. I have heard some talk, that it would be a good idea
> > to figure out how to standardize how to compile a kernel driver
> > outside the kernel tree, so it could be trivial enough that anyone
> > could do it. To date there are enough people around who don't have
> > problems compiling their own kernel that this hasn't become a major
> > issue.
>
> Eric,
>
> I am finding myself exactly in this situation, and I've got a feeling
> that this won't be the last time either.
>
> I expect that every future Linux driver I get involved with will be
> released under GPL. However, I think that the majority of our customers
> will be running a distribution that does not yet support a new driver,
> and even at Linux speeds, it'll take a long enough time that customers
> cannot afford to wait for the next release that includes the driver.
>
> So the big issue for us appears to be how we support these customers.
>
> There is no way that we can support customers who have custom kernels,
> but since they are 'in it' enough to compile their own kernel, I guess
> they're able to apply our patch and recompile it. I actually suspect
> that there aren't that many who do this anyway.
>
> Where we find we have a problem is the number of different 'standard'
> kernels out there. We find that we need to support all releases since
> the last year or so for each distribution. And for each of those, we
> find that there are many different kernel versions (some bugfixes, some
> provide half a dozen different kernels with the CDs, aso.). And since we
> do not expect these customers to compile their own kernel, we see no
> option but to provide a precompiled binary driver. The numbers multiply
> quickly and building all of those becomes an interesting problem.
>
> We had hoped that MODVERSIONS would allow us to provide a single (or at
> most a few) binary driver. Kernels with even minor version numbers are
> supposed to be stable (even if they are buggy) ie. not have wildly
> changing kernel interfaces.
>
> In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
> load with 2.2.16-5.0 (from RedHat 6.2) (just an example).
It's a good example of the problems, but a bad example of problems
caused be kernel maintenance.
RedHat does not run stock linux kernels, but instead seems to patch
the kernel to include work-around for various known bugs and
deficiencies. What this means is that they are more willing than the
mainstream kernel developers to include changes to the kernel. A
example that comes to mind are the md drivers that implement software
raid.
So for solutions (That I know of):
With recent kernels with modules_install a:
/lib/modules/`uname -r`/build
directory is created, that effectively points to the kernel source
tree the modules were built with. With the 2.4.x currently this is a
symlink so but it should be o.k. It needs to be checked that the
distributors are using this directory appropriately, but it looks like
a good thing to support. Longterm this looks like a solution
to the problem, of how to get kernel headers to match a kernel.
This should even has a chance to work with people who build their own
kernel.
With Redhat and many derivatives as a fallback there is kernel source in
/usr/src/linux that does it's best to match the currently running
kernel.
Using either of those locations for the source to kernel headers it
should be possible to build a package that as part of it's install
process compiles appropriate drivers, at least for most of the cases.
I suspect there is enough work in this for someone to create a support
package, that included makefiles and all the rest to assist in
building a drivers on various platforms. Any takers?
Eric.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 06 2001 - 21:31:46 EDT