It's not the CML1 language spec that interests me, just the user interface. All
I care about is being able to do make menuconfig and make oldconfig, and get the
same results as before. What goes on "under the surface" doesn't interest me at
all.
In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right
now I upgrade my kernel like this (simplified slightly):
<apply latest patches>
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep
make bzlilo modules modules_install
<reboot>
Will I still be able to do it this simply in 2.5.x? (Assuming there's
eventually a 2.5.x I can get to compile cleanly. :-)
Wayne
John Stoffel <[email protected]> on 12/04/2001 10:31:10 AM
To: Christoph Hellwig <[email protected]>
cc: Keith Owens <[email protected]>, [email protected],
[email protected], [email protected] (bcc: Wayne
Brown/Corporate/Altec)
Subject: Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Christoph> I still strongly object to it and I know lots of kernel
Christoph> hackers are the same opinion.
I'm not a hacker, but I think it's a good thing to move to CML2. I've
tested it and it's got some nice features. The Python issue I don't
think is too onerous to require of people. And wasn't there someone
out there porting CML2 to straight C code?
Why are people so wedded to the CML1 language spec anyway?
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
[email protected] wrote:
>
> In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right
> now I upgrade my kernel like this (simplified slightly):
>
> <apply latest patches>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
> <reboot>
>
> Will I still be able to do it this simply in 2.5.x? (Assuming there's
> eventually a 2.5.x I can get to compile cleanly. :-)
>
Yes you can do.
hmm. only for the CML2 part. The new kbuild-2.5 (also the new Makefile)
will no more work with your command:
make dep: is no more needed
make bzlilo modules modules_install: it would be a simble
make install: (and you configure with CML1/CML2 what install
means).
giacomo
[email protected] <[email protected]>:
> It's not the CML1 language spec that interests me, just the user
> interface. All I care about is being able to do make menuconfig and
> make oldconfig, and get the same results as before. What goes on
> "under the surface" doesn't interest me at all.
>
> In fact, here's all I want to know about the whole CML2/kbuild 2.5
> issue. Right now I upgrade my kernel like this (simplified
> slightly):
>
> <apply latest patches>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
> <reboot>
>
> Will I still be able to do it this simply in 2.5.x? (Assuming there's
> eventually a 2.5.x I can get to compile cleanly. :-)
Yes.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Never trust a man who praises compassion while pointing a gun at you.
On Tue, Dec 04, 2001 at 06:21:15PM +0000, Alan Cox wrote:
> > make bzlilo modules modules_install: it would be a simble
> > make install: (and you configure with CML1/CML2 what install
> > means).
>
> How does it handle that when install means different things on each box of
> a set of them NFS sharing the kernel tree. This is a real world example
I'd guess you can change the module install path, and re-run 'install'
without having anything rebuilt. Admiditly a bit worse off than
INSTALL_MOD_PATH=/nfs/boxA. Or set the install paths to
.../kernel-XXX/, tar and untar.
Or if /usr/local/src/linux is NFS'ed, and you're installing per box, I
don't get it. Wouldn't you always install modules into /lib/modules/XXX
?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
> make bzlilo modules modules_install: it would be a simble
> make install: (and you configure with CML1/CML2 what install
> means).
How does it handle that when install means different things on each box of
a set of them NFS sharing the kernel tree. This is a real world example
On Tue, 4 Dec 2001 18:21:15 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>> make bzlilo modules modules_install: it would be a simble
>> make install: (and you configure with CML1/CML2 what install
>> means).
>
>How does it handle that when install means different things on each box of
>a set of them NFS sharing the kernel tree. This is a real world example
I made kbuild 2.5 install very flexible to cater for cases like this.
The answer depends on whether you want every compile to be the same
with different install steps on the target machines or each compile is
different.
In the different compile case you have a single source tree (mounted
read only if you like) and separate object trees for each compile run.
The .config lives in the object directory so is machine local. The
object trees can be NFS mounted or can use local disk on each build
machine, as a bonus this avoids NFS writes and runs much faster.
If you want a common compile on one machine followed by different
installs on each machine then you have three choices.
(1) make install with an install prefix path (say /var/tmp) will
install the kernel, modules, System.map and .config in a holding
directory on the build machine, the other machines can then copy
the install data to wherever they need it. Whether the copy is
done from the build machine to the target directories or on the
target machine is an NFS implementation detail.
(2) make installable (the default target) on the build machine then run
make install with overrides on the target machines. All the
install config variables are exposed for override on the install
step.
(3) make installable on the build machine with .config specifying an
install script name. Then make install on each target system, the
version of the install script is local to the target machine.
If none of those suit your environment, let me know what you are trying
to achieve and I will see about adding support to kbuild 2.5.
On Wed, Dec 05, 2001 at 10:00:32AM +1100, Keith Owens wrote:
> On Tue, 4 Dec 2001 18:21:15 +0000 (GMT),
> Alan Cox <[email protected]> wrote:
> >> make bzlilo modules modules_install: it would be a simble
> >> make install: (and you configure with CML1/CML2 what install
> >> means).
> >
> >How does it handle that when install means different things on each box of
> >a set of them NFS sharing the kernel tree. This is a real world example
>
> I made kbuild 2.5 install very flexible to cater for cases like this.
> The answer depends on whether you want every compile to be the same
> with different install steps on the target machines or each compile is
> different.
>
> In the different compile case you have a single source tree (mounted
> read only if you like) and separate object trees for each compile run.
> The .config lives in the object directory so is machine local. The
> object trees can be NFS mounted or can use local disk on each build
> machine, as a bonus this avoids NFS writes and runs much faster.
>
> If you want a common compile on one machine followed by different
> installs on each machine then you have three choices.
>
> (1) make install with an install prefix path (say /var/tmp) will
> install the kernel, modules, System.map and .config in a holding
> directory on the build machine, the other machines can then copy
> the install data to wherever they need it. Whether the copy is
> done from the build machine to the target directories or on the
> target machine is an NFS implementation detail.
>
> (2) make installable (the default target) on the build machine then run
> make install with overrides on the target machines. All the
> install config variables are exposed for override on the install
> step.
>
> (3) make installable on the build machine with .config specifying an
> install script name. Then make install on each target system, the
> version of the install script is local to the target machine.
>
> If none of those suit your environment, let me know what you are trying
> to achieve and I will see about adding support to kbuild 2.5.
Would it be easy to add hooks for make-rpm and make-kpkg and alike,
as methods for make installable?
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Wed, 5 Dec 2001 00:05:53 +0100,
David Weinehall <[email protected]> wrote:
>Would it be easy to add hooks for make-rpm and make-kpkg and alike,
>as methods for make installable?
I don't want details for any packaging method in kbuild. kbuild's job
is to build and install the kernel, not wrap it up in a pretty package
for distribution, I have to draw the line somewhere. In particular I
am not going to support 3-5 different packaging methods in kbuild, nor
am I going to worry about changes in the packaging process, it is SEP.
Having said that, kbuild is extensible. Users can specify additional
targets, dependencies and rules on the command line, those become part
of the build process. So redhat, debian, slackware, new distribution
on the block can supply a packaging script and run this command :-
make ADD0=pkg ADD0_DEP=install ADD0_CMD='my-package-script' pkg
The packaging script is maintained by the package supplier, not by the
kbuild group.
BTW, that example is straight out of the kbuild 2.5 documentation in
Documentation/kbuild/kbuild-2.5.txt, I wish people would read that
file first.