Re: [rawhide social experiments] kernel-source(code) package removed once again ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 22 August 2004 11:45, Bob Arendt wrote:

Now the kernel headers are included with each kernel install!
Fantastic!  No more special builds.  ASCII headers compress really
well, so there's little inflation in binary-kernel rpm size.  And it's
much easier to build & install the 3rd party hardware drivers we use.
Now 3rd party delivered build scripts "just work" since the correct
headers can always be found with the kernel.  Vendors have gotten
fewer callbacks regarding installation.  It no longer depends on the
last state of the /usr/src/linux* since someone last used the
kernel-source.  In fact, it removes the kernel-source requirement
entirely.


What do I need to tell my vendors then? I constantly have to dig up header files that aren't in /lib/modules/`uname -r`/build/ such as SCSI headers. sd.h scsi_mod.h hosts.h etc.... I have to pull them from a sourcecode or src.rpm in order to build my 3rd party module. Having the matching sourcecode rpm helped, although I can get around that. I'm more interested in educating my vendors so that I don't have to dig this stuff up.


So far, none of the 3rd party vendor's we've worked with have required the actual kernel source to build. If in fact their driver represents a modification of an existing driver, it seems in the vendor's best interest to get their additions accepted upstream, so their product "just works" without having to build and install a kernel-specific driver. Otherwise copy (if legal) the source into their source tree so they can build off the provided headers. Otherwise they're tempting fate - relying on the implementation of the code rather than just the interface.

Of the files noted, I couldn't find sd.h or scsi_mod.h in the kernel source.
The contents of /usr/src/linux-2.6.8-1.521/drivers/scsi/hosts.h:
  #warning "This file is obsolete, please use <scsi/scsi_host.h> instead"
  #include <scsi/scsi_host.h>
.. and there is a /lib/modules/2.6.8-1.521/build/include/scsi/scsi_host.h
Perhaps the restructuring of the 2.6 kernel has made it more practical to
use the build/include headers api. Your vendor should hopefully be able
to adapt to this.

RedHat 9 did have some kernel interface headaches for our vendors.
The VM interface calling structure changed (due to 2.5 backports?) late
in it's life. Despite the 2.4.20 kernel version, some of the VM calls
didn't have the same call interface as the vanilla kernel or other distro's
with the same kernel version number.  They threw in a manual hack - basically
"if the build errors out, assert this flag and build again".  Hopefully
Fedora's "close to upstream" minimal patching stance avoids this.

Cheers,
-Bob Arendt



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux