i'm just following the logic used in populating the romfs/ directory
in preparation for building the final initramfs, and i have a couple
questions.
first, i notice that, if i run "make romfs", the subdirs that will
be processed are defined by:
DIRS = $(VENDOR_TOPDIRS) include lib include user
but WRT to making romfs/, what is the value of processing the include/
directory? the file include/Makefile defines a completely empty
"romfs" target so, while it clearly doesn't hurt, it seems pointless
to even enter the include/ directory when processing the "romfs"
target.
also, just to be clear, is the purpose of "make romfs" in general to
create and populate the directory romfs/ with its final contents. i
ask since the romfs target is defined thusly:
.PHONY: romfs
romfs: romfs.newlog romfs.subdirs modules_install romfs.post
and romfs.post is defined as:
.PHONY: romfs.post
romfs.post:
$(MAKEARCH) -C vendors romfs.post
-find $(ROMFSDIR)/. -name CVS | xargs -r rm -rf
. $(LINUXDIR)/.config; if [ "$$CONFIG_INITRAMFS_SOURCE" != "" ]; then \
$(MAKEARCH_KERNEL) -j$(HOST_NCPU) -C $(LINUXDIR) $(LINUXTARGET)
|| exit 1; \
fi
now, while configuring the kernel and building it based on
CONFIG_INITRAMFS_SOURCE is certainly an important step in the *final*
construction of the initramfs image, i don't see what it has to do
with the romfs step. quite simply, it looks out of place. unless
there's something unusual happening here, i would think that it's not
the romfs target's responsibility to do that kernel step -- that
should be left for the final initramfs image creation step, no?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
