From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Jul 23 2009 - 20:06:48 PDT
Alan, We would be happy to see you prepare and maintain packed versions of BLCR for Debian, just as Neal Becker has been maintaining RPMs for rmpfusion. Some answers: 1) As you guess, the userspace parts require that the loaded kernel module be the right BLCR version (and they perform an interface-version check at startup to be paranoid). Nothing about the kernel version is encoded in the userspace portions. 2) You are right that a stripped down source tree for the kernel portions would be nice, but as you also observe that is potentially a big change. For now, I am afraid my recommendation is to live with the bloat of the full tarball. In the future, however, I would like to separate the configure into three portions: common, kernel and user. My motivation for wanting this is to allow building of both 32-bit and 64-bit userspace in a way more natural than how we do it now, and as a side-effect allow the choice between the 32- or 64-bit utilities (right now a multilib build always installs the 64-bit utils). However, it would also help with packaging the kernel-module sources. I have no immediate plans to do this split myself, but would be happy to consider contributed work if anybody reading this wants to take a stab at it. The --use-installed-* stuff already controls which portions of configure get run, so the "common", "kernel" and "user" portions are already identified. Best of luck with this endeavor. -Paul Alan Woodland wrote: > Hi, > > A Debian user has requested packages of BLCR. > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529619) > > As a BLCR user and Debian developer, with a vested interest in seeing > BLCR packages I thought I'd give it a go myself (I hope that's ok with > you?). I'm in the process of packaging things, but I've got a few > questions/issues I'd like to check up on: > > 1) Are the userspace parts (library, utilities and development > headers) are independent of the running kernel version? They only > depend upon a kernel module of the same BLCR version for the current > running kernel correct? The package structure that fits best with the > Debian way is to make libcr0, libcr-dev blcr-util, blcr-source (and on > amd64 lib32cr0), as well as blcr-modules-KERNEL appropriate to the > release. To build all the userspace bits I'm currently configuring > with the '--with-installed-modules' option. > > 2) To build the blcr-modules-KERNEL the ideal solution would be to use > module assistant (this means that even on custom kernels users could > type 'm-a a-i blcr' and get a working kernel module automagicaly built > for them. In order to do this there needs to be a cut down source > tarball built, which lives inside the blcr-source package that can > build the kernel modules for a given kernel. At the moment I'm just > re-taring the whole of the BLCR source tree for this and then making > module assistant call the whole configure script again, with > --with-installed-libcr --with-installed-util --with-components=modules > so that it only builds the kernel modules. Is there a nicer way of > going about this? The configure script is obviously critical here, but > can you suggest a nice way of trimming things down? Most modules seem > to end up just shipping *.c and *.h required for the kernel module in > this, along with a paired down makefile. I did wonder about moving the > kernel space bits into a sub-tree and having configure call configure > on a subdirectory, but that's a pretty substantial patch. > > Does this sound reasonable? Would someone be willing to test (and > review?) this for me? I'd very much like to see BLCR in Debian, but I > don't want to end up acting unilaterally! > > Thanks, > Alan > -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory