[Planetlab-devel] format of .mk entries to install only kernel
headers ?
Luigi Rizzo
rizzo at iet.unipi.it
Fri Dec 11 14:27:02 EST 2009
Hi,
I am trying to setup a quick build environment to test my
kernel modules for planetlab, and I thought I could write
a couple of simple luigi.mk and luigi-tags.mk files
mkdir mytest ; cd mytest
svn co http://svn.planet-lab.org/svn/build/trunk XXX
cd XXX
cp ~/luigi.mk ~/luigi-tags.mk . # the two files are below
make stage1=true PLDISTRO=luigi
make ipfwslice ipfwroot
Now ipfwslice (which is only userland) is built correctly,
but ipfwroot (which is a kernel module for which I only need
the patched kernel headers) fails with
...
curl -H Pragma: -O -R -S --fail --show-error http://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2
...
rpmbuild --define "_sourcedir /home/unipiple_demo/test3/XXX/CODEBASES/kernel" --define "_builddir /home/unipiple_demo/test3/XXX/CODEBASES/kernel" --define "_srcrpmdir /home/unipiple_demo/test3/XXX/CODEBASES/kernel" --define "_rpmdir /home/unipiple_demo/test3/XXX/CODEBASES/kernel" --nodeps -bs /home/unipiple_demo/test3/XXX/SPECS/kernel.spec
error: Bad file: /home/unipiple_demo/test3/XXX/CODEBASES/kernel/luigi-2.6.22-x86_64.config: No such file or directory
error: Bad file: /home/unipiple_demo/test3/XXX/CODEBASES/kernel/luigi-2.6.22-i686.config: No such file or directory
The missing files kind-of exist, but in the form of symlinks
named 'onelab--2.6.22-...' pointing to the equivalent 'planetlab-...'
files.
If i manually create the missing files (copying planetlab-2.6.22-*)
then the build proceeds, but I wonder if there is a way to do it
from some of the .mk files or a command line (and in fact, i am
not even sure where the 'onelab' prefix in the names comes from).
Apart from the above, I am also unclear on what is the proper way
to specify that I only need the kernel headers; while the build
proceeds, it starts compiling stuff which I really don't think I need.
The content of the .mk and tags.mk files i am using is below,
it it can be of any help... if I omit BUILD-FROM-SRPM then the
headers are not expanded, but if i include it, the build seems
to build a lot of stuff...
thanks
luigi
#----- luigi.mk ----------------
kernel-MODULES := linux-2.6
kernel-SPEC := kernel-2.6.spec
kernel-BUILD-FROM-SRPM := yes
ifeq "$(HOSTARCH)" "i386"
kernel-RPMFLAGS:= --target i686
else
kernel-RPMFLAGS:= --target $(HOSTARCH)
endif
ALL += $(kernel)
ipfwroot-MODULES := ipfwxy
ipfwroot-SPEC := ipfw.spec
ipfwroot-DEPEND-DEVEL-RPMS := kernel-headers
ipfwroot-SPECVARS = kernel_version=$(kernel.rpm-version) \
kernel_release=$(kernel.rpm-release) \
kernel_arch=$(kernel.rpm-arch)
ALL += ipfwroot
ipfwslice-MODULES := ipfwxy
ipfwslice-SPEC := ipfw-slice.spec
ipfwslice-SPECVARS = kernel_version=$(kernel.rpm-version) \
kernel_release=$(kernel.rpm-release) \
kernel_arch=$(kernel.rpm-arch)
ALL += ipfwslice
#--------------------------------------------
#----- luigi-tags.mk -------------------------
linux-2.6-SVNBRANCH := 22
linux-2.6-SVNPATH := http://svn.planet-lab.org/svn/linux-2.6/tags/linux-2.6-22-39-1
ipfwxy-SVNPATH := svn+ssh://luigi%40onelab2.iet.unipi.it/home/svn/ports-luigi/dummynet-branches/ipfw_mod
#-----------------------------------------------
On Fri, Dec 11, 2009 at 06:11:07PM +0100, Thierry Parmentelat wrote:
> bringing this to devel...
>
>
>
> Begin forwarded message:
>
> > From: Sapan Bhatia <sapanb at CS.Princeton.EDU>
> > Date: December 11, 2009 4:48:56 PM GMT+01:00
> > To: caglar at princeton.edu
> > Cc: Bar???? Metin <baris at metin.org>, Thierry Parmentelat <Thierry.Parmentelat at sophia.inria.fr>, Marc Fiuczynski <mef at CS.Princeton.EDU>, Andy Bavier <acb at CS.Princeton.EDU>
> > Subject: Re: [CVS] svn.planet-lab.org - check in: r16073 - linux-2.6/trunk
> >
> > adding andy to this thread.
> >
> > My feeling would be that since we are basically done with the 2.6.27.14
> > kernel, we should go ahead with this smaller upgrade. Fortunately,
> > moving from 2.6.22.19 gets us half way through to 2.6.31, so it's not
>
> > as if the effort is wasted. For instance, a lot of the work we did to
> > make our code play well with NetNS will just get reused for 2.6.31.
>
> Past experience seems to show that it takes us quite a while to move to a new kernel sublevel; so I feel like it's useful for us to deploy some 2.6.27 asap, while we start moving to the 31 sublevel on the codebase side.
>
> About that, just to make myself clear and to answer Caglar's comment below, my 'f12' branch is only about rebuilding a vserver-capable kernel for a plain fedora box, and I plan on using this to set up a new f12-based build&test infrastructure over here.
> Turns out Daniel does not plan on publishing such a thing, and the current centos5.4 set up won't let us build for f11 and above.
>
> I do not plan on using this as a basis for a PL 2.6.31 kernel, and I agree that this would not be the right angle.
> (I've been lucky with this one though, as only 4 of the zillion of fedora patches turned out to conflict with the vs patch)
>
> Admittedly this f12 branch could sit some place else, if this is confusing.
>
> -- Thierry
>
>
> >
> > Sapan
> >
> > 2009/12/11 S.??a??lar Onur <caglar at princeton.edu>:
> >>
> >> Hi,
> >>
> >> On Fri 11/12/09 09:35 , Bar???? Metin <baris at metin.org> wrote:
> >>
> >>> Hi all,
> >>> I was thinking, shall we start moving to 2.6.31? If the next RH
> >>> release will be based on Fedora 12 and we're going to base ourself
> >>> on
> >>> Centos, it may be a good idea to start porting our patches.
> >>> There is an "experimental" linux-vserver (vs2.3.0.36.27) patch for
> >>> 2.6.31.6 and Thierry already created a branch called f12 as you may
> >>> know.
> >>> What do you think?
> >>
> >> I think starting to port the patches to a Fedora kernel may not be a good idea if we won't use the PL patchset on top of Fedora Kernel. IMHO currently RHEL is adding hundreds of patches to their kernel which makes the fedora porting obsolete.
> >>
> >> Best regards,
> >>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
More information about the Devel
mailing list