Re: Building a new kernel

[turnbull@example.com (Stephen J. Turnbull)]

>>>>> "Jim" == Jim Schweizer <schweiz@example.com> writes:

    Jim> Hi y'all, It's been awful quiet lately - it must be time for
    Jim> another newbie question:-) When is this group going to
    Jim> attract someone who knows less than me about Linux???

Wow!  Now THAT is a newbie question!

    Jim> Before Steve T. gets his dander up, I've read all the HOWTOs 

You said you're a newbie, so I'm going to take you at your word.  So
that means that the HOWTOs and books don't necessarily address what
you don't know.

    Jim> and even a couple of books about building a kernel. So after
    Jim> all of this studying I finally get up the nerve to try it and
    Jim> guess what happened - you're right, nothing!

That happens....

    Jim> All the docs say the same thing: after you set up the
    Jim> symbolic links cd /usr/src/linux (in my case linux is sym
    Jim> linked to linux-1.2.13: I don't know why the Slackware 3.0
    Jim> setup routine did this, but it did when I installed the

This is so that you can use multiple kernels.  Programs that use
operating system stuff directly look in /usr/src/linux/include/* for
the interface definitions (look in /usr/include; you'll see a bunch of
symlinks to /usr/src/linux/include/*).  So suppose you're using
v1.2.13 most of the time, but you'd really like to use your Whizbang
Periph-o-matic by Acme.  Unfortunately, the driver requires features
that aren't supported until version 1.3.23; but those versions are
really unstable and you don't want to use them everyday.

So, for development, you "ln -s linux-1.3.23 /usr/src/linux", and for
production programs, you "ln -s linux-1.2.13 /usr/src/linux".  This
doesn't affect most things, since they go through the libraries which
use the public kernel interface (which changes rarely since it's
mostly defined by POSIX), but really affects things like device
drivers and kernel modules which directly access kernel functions.

    Jim> source) and type 'make config' then start answering a lot of
    Jim> questions.

What version are you compiling?  1.2.13?  I assume that's the same
kernel you selected for daily use in Slackware's setup script?
Starting by building the same kernel version that you normally use is
a good idea.  NB: Besides "cd /usr/src/linux," you need to be root.
(Not being root shouldn't get make upset, though, you just won't be
able to rm, mv, and chmod the relevant files, not to mention being
unable to open objects for writing to ;-)

    Jim> When I type 'make config' I get dissed with:

    Jim> make: *** No rule to make target 'config'. Stop.

Question 1:  Can you read the Makefile?
Question 2:  Can you read the Makefile?

These are really two different questions.  :-)

Make does not tell you it can't find a Makefile if you specifiy a
target.  I'm not exactly sure why that is; I don't know anybody who
uses make without the Makefile.  What it does tell you is that there
is "*** No rule....  Stop."  So: can you read the Makefile in
/usr/src/linux, by "less Makefile" or something like that?  If not,
you need to find it (probably in linux-1.2.13.tar.gz :-) and/or make
it available to make ("chmod u+rw Makefile").  While you're at it, you 
should check to see that there seem to be a reasonable complement of
files and directories (COPYING, ..., Makefile, README, arch/, drivers/, fs/,
..., scripts/, and maybe vmlinux).

Question 2 is "do you understand the Makefile?"  Makefiles come with
three basic kinds of components:

Comments - to tell you what the Makefile's author wants you to think
Definitions - to make the Makefile more intelligible or more easily
    configurable (there are also preprocessor-like commands
Rules - what to actually do, and when to do it

You already know what Comments and Definitions are, I'm sure (but GNU
make supports some pretty arcane sorts of Definition, see "info
make"), despite being a self-proclaimed Newbie.  What's a Rule?  A
Rule looks like

<target>:[<dependency>...]
[<TAB><action>...]

In GNU make, if an action is present, it MUST be preceded by "\n\t".
I'm not sure why this syntax was chosen, most makes accept any
whitespace after the newline.  If there is no <TAB>, GNU make will
tell you there's a "missing separator in line nnnn".  This often
happens with poorly configured imakes (comes with X Windows---since
some of the macros don't get expanded), with makefiles ported from
other makes, and with some editors that don't like literal tabs.  I
forget exactly the rules about other whitespace, GNU make is very
particular about that <TAB> and somewhat picky about <NEWLINE>s, but
otherwise pretty forgiving about whitespace, I think.

So, if you've got a Makefile, the next step is to look for the "target
'config'": "grep 'config.*:' Makefile" (the kernel makefiles use
multiple targets, so you can't be sure that "config" can be tied to
either the beginning of the line or to the colon---searching for
"config" only will probably give lots of false positives, though).  Or
you can use the search function in 'less'.  If you don't find
"config:" then you've probably got a munged Makefile and should
reuntar the kernel.  (Unfortunately, it is possible to use variables
for targets, and that would be very confusing....)

A dependency is a task that must be done before the current rule can
be executed (eg, compiling an object file before linking it into an
executable).  Dependencies come in two flavors:  files (which if
present and younger than the current target are satisfied) and other
targets in the makefile (which simply must be completed).  Actions are 
any executable programs, like compilers and so on (and a few internal
make commands, like looping constructs).

There are some common rules that are built into make (like if you need 
an executable named 'foo', look for an object named 'foo.o' and link
it with the standard libraries:

foo: foo.o
	gcc -o foo foo.o

or compiling the C program:

foo.o: foo.c
	gcc -o foo.o -c foo.c

and so on).  These default rules can make figuring out what the
makefile does a little difficult at times, but most makefiles are
pretty explicit.  (I guess default rules also answers my question
about targets without Makefiles:  if you have a file "love.c", you
could do "make love" without a Makefile or even a partner. :-)

A common trick in these very complicated programs with large
development teams is to put each major module in a subdirectory and
invoke make recursively:

SUBDIRS=memory process drivers
kernel:
	for i in $(SUBDIRS); do (cd $i; make); cp $i/*.o .; done
	gcc -o linux *.o
	rm -f *.o

(This naive approach probably won't work since linking is order
dependent.)

Obviously, since configuration and dependencies need to be set up
before anything else is done, it makes sense to have rules to ensure
this.  Typically, files which should be generated by the make process
either have a "This file was automatically generated; do not edit.  Do 
'make config' instead." comment or are hidden files (.config and
.depend are very common; sometimes a Makefile template will be hidden
as .Makefile).  It's even possible to have a Makefile target
(Ghostscript does this, for example.)

Many of the actions in the Makefile are likely to be either recursive
makes (as above) or shell scripts (especially for configuration).
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096