[OpenAFS] Re: 1.4.2 client on RHEL5 beta 2

[Axel Thimm]

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2006 at 04:16:51PM +0100, Stephan Wiesand wrote:
> On Mon, 20 Nov 2006, Axel Thimm wrote:
>=20
> >On Mon, Nov 20, 2006 at 07:13:47PM +0100, Stephan Wiesand wrote:
> >>I don't know what you have in /build/kernels/, and hence what you're
> >>building against, but whatever it is: chances are it's not the same as =
in
> >>RH's kernel-devel RPM.
> >
> >I (always) use the kernel src.rpm to gain access to the full sources
> >as kernel-devel fails many external kernel module builds.
>=20
> I tried building against the full source tree from the kernel srpm. This=
=20
> works before a "make modules" in this tree has created the Module.symvers=
=20
> file. Afterwards it does not anymore, the error being exactly the one=20
> I posted yesterday.
>=20
> Removing this file from the tree from the kernel-devel RPM has the same=
=20
> effect: building an unpatched openafs-1.4.2 against this tree now works.
>=20
> I guess there is no Module.symvers in your kernel tree?

Indeed, I stop at the same spot, before actually creating the image
and/or the modules. Therefore I'm missing the Module.symvers which
usually is of no harm, in fact technically it turned out here to be a
blessing ;)

But politically this is a bug nonetheless, the symbols are not
supposed to be used :(

> And hence no build problems with GPL-only symbols? And no
> modversions either, but that's no problem since you build
> specifically for each kernel?

Exactly.

> But isn't loading such a module supposed to fail? Is it only in this=20
> special case that it doesn't, because of the "weak" definition of=20
> tasklist_lock in the AFS module and/or because of the fallback to=20
> rcu_read_lock?

I honestly don't know whether it will fail, taint or whatever. From a
license POV contrary to common belief (!but! IANAL) it *is* possible
to link non-GPL and GPL, just that the product is non-distributable,
e.g. an end user is allowed to link any non-GPL bits using kernel
headers. The kernel module check mechanisms can't judge on whether
this kernel & kernel modules is going to be redistributed, so it
shouldn't fail.

But that's all academic, perhaps trying out the packages will show
whether it fails, taints or remains silent. :)
--=20
Axel.Thimm at ATrpms.net

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFYxsgQBVS1GOamfERAqZbAJ4tkSPreytIaVRg2gNObIOf2iD4IwCeKx6E
m/e6DkArTVaxaptJW8mUM0Q=
=XMCi
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--