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

Re: Kernel modules mini-policy?

>>"Gregory" == Gregory S Stark <gsstark@mit.edu> writes:

 Gregory> Did we ever establish a policy for how to package kernel modules?

 Gregory> I just released arla, the free AFS client to nonus, but the
 Gregory> .deb is probably useless to anyone who doesn't have the same
 Gregory> 2.0.36-pre7 kernel, which is not many people.

	If you follow the guidelines laid out in kernel package (which
 are supposed to be expanded by the maintainers of kernel modules
 like pcmcia-source or something (I forget who it was that
 volunteered)), all you need do is put the source in
 /usr/src/modules<package>, and set the rules file to follow the
 guidelines, and then peole can compile their own modules.deb files
 when the compile a new kernel.

 Gregory> I've seen some packages go by like ntfs2.0.32 and lsof2.0.33. are there
 Gregory> instructions on how these packages are supposed to be constructed?

	Hmm. Here is what I have. I'd appreciate any additional
 information and tips.


		Add on modules and the kernel-package
                === == ======= === === ==============

	There are a number of add-on modules (that is, kernel modules
 are are developed apart fromt he Linux kernel and do not appear in
 the mainstream kernel sources). Notables, at the time of writing, are
 the pcmcia-cs and and the alsa sound modules.

	Most of these modules need to be compiled for each kernel
 version; they are very dependent on kernel structures. It was
 suggested that it would be nice to be able to build the add-on
 modules whenever one created a new kernel, and kernel-package
 provides some mechanisms to do so for co-operating add-on modules. 

	In order for this to work, the add on modules must appear in
 a standard location, choosen to be /usr/src/modules/<mod-name>/, and
 must arrange to be manipulated by the kernel-package mechanisms.

==== ============

     1)   Ensure that the module source tree is in a subdirectory of the
          /usr/src/modules directory.  Use a symbolic link to the actual
          source tree if you must.  

     2)   As root, go to the the base of the kernel source tree
          (usually the /usr/local/src/linux directory).  If you are
          building a kernel that is custom configured to your
          specifications, go ahead and configure the kernel with `make
          config,' `make menuconfig,' or `make xconfig.'

     3)   To build a new kernel-image package, execute:
               make-kpkg --revision number kernel_image
          This will generate a kernel-image-<kernel version> deb file
          in the parent directory.  Here number (the argument supplied
          after the --revision flag) is a version number for your
          custom built kernel.  You may also do this on the fly by
          setting the DEBIAN_REVISION environmental variable.  It is
          important that you choose the revision number in such a way
          that a generic kernel-image package will not override the
          custom package while using dselect (or `dpkg -BOGiE').  I
          recommend a two-level scheme where the major level starts
          with a letter.  One such scheme is your (short) host name
          followed by a dot (.) and a number.  For example, if your
          machine is named myhost, you would use --revision myhost.1
          in the command line.  If you had to rebuild your custom
          kernel, you would use --revision myhost.2 and so on.  See
          /usr/doc/kernel-package/README.gz for more information on
          revision numbers.

     3)   To build the PCMCIA modules, execute:
               make-kpkg --revision number modules_image
          where number is the same revision number used to build the
          kernel-image package in the previous step. This will generate a
          pcmcia-modules-<kernel version> deb file in the parent directory.

     4)   Install the two newly created deb files (you can use `dpkg -i

        kernel-package provides for three targets for the use of
 stand-alone kernel modules packages.

	The special targets to give to make-kpkg are:
 a) modules-image modules_image:   only generate module binary packages
 b) modules:                       generate the modules packages and
                                   sign them with dchanges (this
                                   creates the sorce and diff packages
                                   as well)
 c) modules-config modules_config: only configure the module

	So, add to the 
4% fakeroot make-kpkg --revision=custom.1.0 kernel_image 
4a% fakeroot make-kpkg --revision=custom.1.0 modules_image,
        and remember to install the modules (after you have installed
 the kernel-image) by saying 
5# dpkg -i ../kernel-image-X.XXX_1.0_<arch>.deb
5a# dpkg -i /usr/src/modules/<mode-name>-<version>.deb
MODULE Packaging hints
====== ========= =====

        make-kpkg arranges to cd into each modules top directory,
 /usr/src/modules/<mod-name>/, and runs ./debian/rules <target>. 
 Additionally, the following information is provided in the
 a) KVERS  Contains the kernel version
 b) KSRC   Contains the location of the kernel sources 
 c) KMAINT Contains the Name of the maintainer to pass to PGP
 d) KEMAIL Caontains the email address of the maintainer

	Have fun,

Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

 It is now quite lawful for a Catholic woman to avoid pregnancy by a
 resort to mathematics, though she is still forbidden to resort to
 physics and chemistry. H.L. Mencken
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Reply to: