I'm looking at the kernel makefiles, and in particular, files like
uts/common/Makefile.rules ... seems a bit wasteful.
Apart from the time it takes to process the file (and the increased
number of files required to edit with each new driver), it seems like
this design is not well designed for short build times. It also does
not lend itself well to separation of namespaces... in particular the
design requires pretty much every source file in the tree have a unique
name, regardless of where it lives in the source tree.
The reason it doesn't lend itself well to short build times, is that the
ruleset requires that make stat() pretty much all possible locations for
the source file (where *any* module might have a source file) until it
finds one with a matching name.
I'd far, far rather see a simpler approach. Such as, a single pair of
rules in Makefile.common that reads:
${OBJS_DIR}/%.o: ${SRCS_DIR}/%.c
$(COMPILE.c) -o $@ $<
${LINTS_DIR}/%.ln: ${SRCS_DIR}/%.c
$(COMPILE.c) -o $@ $<
And each module would declare, in Makefile.files, the value of
SRCS_DIR. For example, looking at wpi, we'd have
WPI_SRC = ${UTSBASE}/common/io
WPI_OBJS = wpi.o
Then, we could easily get the right rule to be used in the
module-specific Makefiles. For example, for the intel/wpi/Makefile, the
following definition could be added:
MODULE = wpi
SRCS_DIR = ${WPI_SRC)
OBJECTS = $(WPI_OBJS:%=$(OBJS_DIR)/%)
LINTS = $(WPI_OBJS:%.o=$(LINTS_DIR)/%.ln)
ROOTMODULE = $(ROOT_DRV_DIR)/$(MODULE)
This would increase the size of Makefile.files by one line for each
module, and add one line to each module's build Makefiles (in either
sparc or intel). But it would remove 6 lines (4 lines of text and two
blank lines) from Makefile.rules... and be one less file that has to be
touched when integrating new drivers. Further, it would simplify the
logic that make that has to use when building kernel modules, greatly
shrinking the number of rules it has to consider. And, it would allow
for object and source files to have the same name as long as they are in
different directories.
The only draw back that I can potentially see is that make will now have
more macros in memory. (Assignments to xxx_SRC.) I'm not sure if there
are finite limits to make's memory for macro assignments, but I'd still
guess this to be cheaper than the memory associated with the multiple rules.
Of course, ultimately I'd really like to clean up need for separate
uts/intel/<module>/ directories/trees, but that's a much different
problem. (In my ideal world, the module-specific makefiles and object
files would live in some common place, like uts/build/wpi, with
subdirectories named like "obj.sparc.32", "obj.sparc.64",
"obj.intel.32", and "obj.intel.64". (Possibly replacing sparc/intel
with uname -p output.) That way we could eliminate a lot of redundancy
in the kernel source tree that exists only to support both sparc and
x86. (I imagine that Neale Ferguson and the Polaris folks would
appreciate such an effort as well... it would *greatly* simplify life
for anyone considering a port to a new processor architecture! :-)
I'd guess such an effort would take several man-days of editing various
Makefiles, and testing the compilation, but the benefits to the
organization would probably reap several man-months of time saved after
just the first year.
Thoughts?
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
