makefiles.txt

讲述linux的初始化过程

    compressed		i386, m68k, mips, mips64, sh
    dasdfmt		s390
    Image		arm
    image		s390
    install		arm, i386
    lilo		m68k
    msb			alpha, ia64
    my-special-boot	alpha, ia64
    orionboot		mips
    rawboot		alpha
    silo		s390
    srmboot		alpha
    tftpboot.img	sparc, sparc64
    vmlinux.64		mips64
    vmlinux.aout	sparc64
    zImage		arm, i386, m68k, mips, mips64, ppc, sh
    zImage.initrd	ppc
    zdisk		i386, mips, mips64, sh
    zinstall		arm
    zlilo		i386
    znetboot.initrd	ppc



--- 5.4 Mandatory arch-specific goals

An arch Makefile must define the following arch-specific goals.
These goals provide arch-specific actions for the corresponding goals
in the top Makefile:

    archclean		clean
    archdep		dep
    archmrproper	mrproper



=== 6 The structure of a subdirectory Makefile

A subdirectory Makefile has five sections.



--- 6.1 Comments

The first section is a comment header.  Just write what you would
write if you were editing a C source file, but use "# ..." instead of
"/* ... */".  Historically, many anonymous people have edited kernel
Makefiles without leaving any change histories in the header; comments
from them would have been valuable.



--- 6.2 Goal definitions

The second section is a bunch of definitions that are the heart of the
subdirectory Makefile.  These lines define the files to be built, any
special compilation options, and any subdirectories to be recursively
entered.  The declarations in these lines depend heavily on the kernel
configuration variables (CONFIG_* symbols).

In some Makefiles ("old-style Makefiles"), the second section looks
like this:

	# drivers/parport/Makefile
	ifeq ($(CONFIG_PARPORT_PC),y)
	  LX_OBJS += parport_pc.o
	else
	  ifeq ($(CONFIG_PARPORT_PC),m)
	    MX_OBJS += parport_pc.o
	  endif
	endif

In most Makefiles ("new-style Makefiles"), the second section looks
like this:

	# drivers/block/Makefile
	obj-$(CONFIG_MAC_FLOPPY)	+= swim3.o
	obj-$(CONFIG_BLK_DEV_FD)	+= floppy.o
	obj-$(CONFIG_AMIGA_FLOPPY)	+= amiflop.o
	obj-$(CONFIG_ATARI_FLOPPY)	+= ataflop.o

The new-style Makefiles are more compact and easier to get correct
for certain features (such as CONFIG_* options that enable more than
one file).  If you have a choice, please write a new-style Makefile.



--- 6.3 Adapter section

The third section is an adapter section.  In old-style Makefiles, this
third section is not present.  In new-style Makefiles, the third section
contains boilerplate code which converts from new-style variables to
old-style variables.  This is because Rules.make processes only the
old-style variables.

See section 8.2 ("Converting to old-style") for examples.



--- 6.4 Rules.make section

The fourth section is the single line:

	include $(TOPDIR)/Rules.make



--- 6.5 Special rules

The fifth section contains any special Makefile rules needed that are
not available through the common rules in Rules.make.



=== 7 Rules.make variables

The public interface of Rules.make consists of the following variables:



--- 7.1 Subdirectories

    ALL_SUB_DIRS, SUB_DIRS, MOD_IN_SUB_DIRS, MOD_SUB_DIRS

	$(ALL_SUB_DIRS) is an unconditional list of *all* the
	subdirectories in a given directory.  This list should not depend
	on the kernel configuration.

	$(SUB_DIRS) is a list of subdirectories which may contribute code
	to vmlinux.  This list may depend on the kernel configuration.

	$(MOD_SUB_DIRS) and $(MOD_IN_SUB_DIRS) are lists of subdirectories
	which may build kernel modules.  Both names have exactly the
	same meaning.  (In version 2.2 and earlier kernels, these
	variables had different meanings -- hence the different names).

	For new code, $(MOD_SUB_DIRS) is recommended and $(MOD_IN_SUB_DIRS)
	is deprecated.

	Example:

		# fs/Makefile
		ALL_SUB_DIRS = coda minix ext2 fat msdos vfat proc isofs nfs \
			       umsdos ntfs hpfs sysv smbfs ncpfs ufs efs affs \
			       romfs autofs hfs lockd nfsd nls devpts devfs \
			       adfs partitions qnx4 udf bfs cramfs openpromfs \
			       autofs4 ramfs jffs
		SUB_DIRS :=

		...

		ifeq ($(CONFIG_EXT2_FS),y)
		SUB_DIRS += ext2
		else
		  ifeq ($(CONFIG_EXT2_FS),m)
		  MOD_SUB_DIRS += ext2
		  endif
		endif

		ifeq ($(CONFIG_CRAMFS),y)
		SUB_DIRS += cramfs
		else
		  ifeq ($(CONFIG_CRAMFS),m)
		  MOD_SUB_DIRS += cramfs
		  endif
		endif

	Example:

		# drivers/net/Makefile
		SUB_DIRS     := 
		MOD_SUB_DIRS :=
		MOD_IN_SUB_DIRS :=
		ALL_SUB_DIRS := $(SUB_DIRS) fc hamradio irda pcmcia tokenring \
				wan sk98lin arcnet skfp tulip appletalk

		...

		ifeq ($(CONFIG_IRDA),y)
		SUB_DIRS += irda
		MOD_IN_SUB_DIRS += irda
		else
		  ifeq ($(CONFIG_IRDA),m)
		  MOD_IN_SUB_DIRS += irda
		  endif
		endif

		ifeq ($(CONFIG_TR),y)
		SUB_DIRS += tokenring
		MOD_IN_SUB_DIRS += tokenring
		else
		  ifeq ($(CONFIG_TR),m)
		  MOD_IN_SUB_DIRS += tokenring
		  endif
		endif



--- 7.2 Object file goals

    O_TARGET, O_OBJS, OX_OBJS

	The subdirectory Makefile specifies object files for vmlinux in
	the lists $(O_OBJS) and $(OX_OBJS).  These lists depend on the
	kernel configuration.

	The "X" in "OX_OBJS" stands for "eXport".  Files in $(OX_OBJS)
	may use the EXPORT_SYMBOL macro to define public symbols which
	loadable kernel modules can see.  Files in $(O_OBJS) may not use
	EXPORT_SYMBOL (and you will get a funky error message if you try).

	[Yes, it's kludgy to do this by hand.  Yes, you can define all
	your objects as $(OX_OBJS) whether they define symbols or not;
	but then you will notice a lot of extra compiles when you edit
	any source file.  Blame CONFIG_MODVERSIONS for this.]

	Data that is passed to other objects via registration functions
	(e.g. pci_register_driver, pm_register) does not need to be marked
	as EXPORT_SYMBOL.  The objects that pass data via registration
	functions do not need to be marked as OX_OBJS, unless they also have
	exported symbols.

	Rules.make compiles all the $(O_OBJS) and $(OX_OBJS) files.
	It then calls "$(LD) -r" to merge these files into one .o file
	with the name $(O_TARGET).  This $(O_TARGET) name also appears
	in the top Makefile.

	The order of files in $(O_OBJS) and $(OX_OBJS) is significant.
	All $(OX_OBJS) files come first, in the order listed, followed by
	all $(O_OBJS) files, in the order listed.  Duplicates in the lists
	are allowed: the first instance will be linked into $(O_TARGET)
	and succeeding instances will be ignored.  (Note: Rules.make may
	emit warning messages for duplicates, but this is harmless).

	Example:

		# arch/alpha/kernel/Makefile
		O_TARGET := kernel.o
		O_OBJS   := entry.o traps.o process.o osf_sys.o irq.o \
			    irq_alpha.o signal.o setup.o ptrace.o time.o \
			    semaphore.o
		OX_OBJS  := alpha_ksyms.o

		ifdef CONFIG_SMP
		O_OBJS   += smp.o irq_smp.o
		endif

		ifdef CONFIG_PCI
		O_OBJS   += pci.o pci_iommu.o
		endif

	Even if a subdirectory Makefile has an $(O_TARGET), the .config
	options still control whether or not its $(O_TARGET) goes into
	vmlinux.  See the $(M_OBJS) example below.

	Sometimes the ordering of all $(OX_OBJS) files before all
	$(O_OBJS) files can be a problem, particularly if both
	$(O_OBJS) files and $(OX_OBJS) files contain __initcall
	declarations where order is important.   To avoid this imposed
	ordering, the use of $(OX_OBJS) can be dropped altogether and
	$(MIX_OBJS) used instead.

	If this approach is used, then:
	 - All objects to be linked into vmlinux should be listed in
	   $(O_OBJS) in the desired order.
	 - All objects to be created as modules should be listed in
	   $(M_OBJS)
	 - All objects that export symbols should also be listed in
	   $(MIX_OBJS).

	This has the same effect as maintaining the
	exported/non-exported split, except that there is more control
	over the ordering of object files in vmlinux.
	


--- 7.3 Library file goals

    L_TARGET, L_OBJS, LX_OBJS

	These names are similar to the O_* names.  Once again, $(L_OBJS)
	and $(LX_OBJS) specify object files for the resident kernel;
	once again, the lists depend on the current configuration; and
	once again, the files that call EXPORT_SYMBOL go on the "X" list.

	The difference is that "L" stands for "Library".  After making
	$(L_OBJS) and $(LX_OBJS), Rules.make uses the "$(AR) rcs" command
	to put these files into an archive file (a library) with the
	name $(L_TARGET).  This name also appears in the top Makefile.

	Example:

		# arch/i386/lib/Makefile
		L_TARGET = lib.a
		L_OBJS  = checksum.o old-checksum.o delay.o \
			usercopy.o getuser.o putuser.o iodebug.o

		ifdef CONFIG_X86_USE_3DNOW
		L_OBJS += mmx.o
		endif

		ifdef CONFIG_HAVE_DEC_LOCK
		L_OBJS += dec_and_lock.o
		endif

	The order of files in $(L_OBJS) and $(LX_OBJS) is not significant.
	Duplicates in the lists are allowed.  (Note: Rules.make may emit
	warning messages for duplicates, but this is harmless).

	A subdirectory Makefile can specify either an $(O_TARGET),
	an $(L_TARGET), or both.  Here is a discussion of the differences.

	All of the files in an $(O_TARGET) are guaranteed to appear in
	the resident vmlinux image.  In an $(L_TARGET), only the files
	that satisfy undefined symbol references from other files will
	appear in vmlinux.

	In a conventional link process, the linker processes some
	object files and creates a list of unresolved external symbols.
	The linker then looks in a set of libraries to resolve these
	symbols.  Indeed, the Linux kernel used to be linked this way,
	with the bulk of the code stored in libraries.

	But vmlinux contains two types of object files that cannot be
	fetched out of libraries this way:

	    (1) object files that are purely EXPORT_SYMBOL definitions
	    (2) object files that use module_init or __initcall initializers
		(instead of an initialization routine called externally)

	These files contain autonomous initializer sections which provide
	code and data without being explicitly called.	If these files
	were stored in $(L_TARGET) libraries, the linker would fail
	to include them in vmlinux.  Thus, most subdirectory Makefiles
	specify an $(O_TARGET) and do not use $(L_TARGET).

	Other considerations: $(O_TARGET) leads to faster re-link times
	during development activity, but $(L_TARGET) gives better error
	messages for unresolved symbols.



--- 7.4 Loadable module goals

    M_OBJS, MX_OBJS

	$(M_OBJS) and $(MX_OBJS) specify object files which are built
	as loadable kernel modules.  As usual, the "X" in $(MX_OBJS)
	stands for "eXport"; source files that use EXPORT_SYMBOL must
	appear on an $(MX_OBJS) list.

	A module may be built from one source file or several source
	files.	In the case of one source file, the subdirectory
	Makefile simply adds the file to either $(M_OBJS) or $(MX_OBJS),
	as appropriate.

	Example:

		# drivers/net/irda/Makefile
		ifeq ($(CONFIG_IRTTY_SIR),y)
		L_OBJS += irtty.o
		else
		  ifeq ($(CONFIG_IRTTY_SIR),m)
		  M_OBJS += irtty.o
		  endif
		endif

		ifeq ($(CONFIG_IRPORT_SIR),y)
		LX_OBJS += irport.o
		else
		  ifeq ($(CONFIG_IRPORT_SIR),m)
		  MX_OBJS += irport.o
		  endif
		endif

	If a kernel module is built from several source files, there
	are two ways to specify the set of source files.  One way is to
	build a single module for the entire subdirectory.  This way is
	popular in the file system and network protocol stacks.

	Example:

		# fs/ext2/Makefile
		O_TARGET := ext2.o
		O_OBJS   := acl.o balloc.o bitmap.o dir.o file.o fsync.o \
			    ialloc.o inode.o ioctl.o namei.o super.o symlink.o \
			    truncate.o
		M_OBJS   := $(O_TARGET)

	In this example, the module name will be ext2.o.  Because this
	file has the same name has $(O_TARGET), Rules.make will use
	the $(O_TARGET) rule to build ext2.o: it will run "$(LD) -r"
	on the list of $(O_OBJS) files.

	Note that this subdirectory Makefile defines both an $(O_TARGET)
	and an $(M_OBJS).  The control code, up in fs/Makefile, will
	select between these two.  If CONFIG_EXT2_FS=y, then fs/Makefile
	will build $(O_TARGET); and if CONFIG_EXT_FS=m, then fs/Makefile
	will build $(M_OBJS) instead.  (Yes, this is a little delicate
	and a little confusing).



--- 7.5 Multi-part modules

    MI_OBJS, MIX_OBJS

	Some kernel modules are composed of several object files
	linked together, but do not include every object file in their
	subdirectory.  $(MI_OBJS) and $(MIX_OBJS) are for this case.

	"M" stands for Module.
	"I" stands for Intermediate.
	"X", as usual, stands for "eXport symbol".

	Example:

		# drivers/sound/Makefile
		gus-objs  := gus_card.o gus_midi.o gus_vol.o gus_wave.o ics2101.o
		pas2-objs := pas2_card.o pas2_midi.o pas2_mixer.o pas2_pcm.o
		sb-objs	  := sb_card.o

		gus.o: $(gus-objs)
			$(LD) -r -o $@ $(gus-objs)

		pas2.o: $(pas2-objs)
			$(LD) -r -o $@ $(pas2-objs)

		sb.o: $(sb-objs)
			$(LD) -r -o $@ $(sb-objs)