Re: Building modules for Debian sparc kernels

[Arne Nordmark <arne.nordmark@mech.kth.se>]

Ben Collins wrote:

Thanks for answering.

> 
> On Mon, Nov 26, 2001 at 08:28:19PM +0100, Arne Nordmark wrote:
> > Hello,
> >
> > When building kernel modules (specifically the OpenAFS module) to match
> > the kernels in the Debian archive for i386 and sparc, some questions
> > came up.
> >
> > For the i386 architecture, there is a separate kernel-headers package
> > for each kernel flavour, so building using these should produce working
> > modules. On sparc, there is only one kernel-headers package (for the
> > sun4cmd subarch?). Is building a kernel module say for sun4u-smp with
> > these headers guarateed to work? If not, one should probably have to get
> > the correct version of the kernel-source pachage (but this may have been
> > replaced in the archive) and the kernel-image source package (for
> > patches), so that way is not so desirable.
> 
> No, there is one kernel-headers package for sparc64 and sparc32 (both
> sets are in the same package).
> 
> I do not suggest using the headers to build modules. Use the whole
> source.

What would be a typical use of the kernel-headers, then?

> 
> > Another thing is that the kernel-image packages for sparc has the
> > sub-architecture in the package name, but not in the /lib/modules path.
> > The variables passed by make-kpkg to build a kernel module package does
> > not seem to be enough to inform about this situation, so the buildt
> > package will either miss the sun4xxx in the package name and kernel
> > dependencies, or have it in the /lib/modules path, dpeneding of how
> > make-kpkg is called, so in either case the .deb file will have to edited
> > by hand. For i386, there is no problem, as the flavour is present both
> > in the package name and the /lib/modules path.
> 
> You'll have to use the same method as the  source
> does.

What I was trying to point out, was that when running (at least in
potato, kernel-image-sparc-2.2 version 8)

make-kpkg --subarch sun4u-smp --arch_in _name modules_image

the module is built with

./debian/rules KVERS=2.2.19 KDREV=8 kdist_image

and the subarch info is not present. The module will have to construct a
control file and place the kernel modules in the file tree out of this
info. For example (like OpenAFS) one could use
Package: mymodules-$KVERS
Version: myversion+$KDREV
Recommends: kernel-image-$KVERS (= $KDREV)
and place the files in /lib/modules/$KVERS/xx/mymodule.o
but no matter what, there is no way to get different package names for
different subarchs.
Using

make-kpkg --flavour sun4u-smp modules_image

will not work either as the module is built with

./debian/rules KVERS=2.2.19-sun4u-smp KDREV=8 kdist_image

and the files will be incorrectly placed.

Thus, to me, it seems that the i386 way of making kernel-images and
-headers makes it easier to build modules (in the current kernel-package
framework), although it may be formally more correct to use --subarch
than --flavour.

Btw, many thanks for the great work done by all the Debian people.

Arne

> 
> Ben
> 
> --
>  .----------=======-=-======-=========-----------=====------------=-=-----.
> /                   Ben Collins    --    Debian GNU/Linux                  \
> `  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
>  `---=========------=======-------------=-=-----=-===-======-------=--=---'

-- 
	Arne Nordmark		Tel: +46 8 - 790 71 92
	KTH/Mekanik		Fax: +46 8 - 723 04 75
	SE-100 44 STOCKHOLM	Internet: arne.nordmark@mech.kth.se
	Sweden