Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Nov 2001 00:04:29 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Warner Losh <imp@harmony.village.org>, Ian Dowse <iedowse@maths.tcd.ie>, Arjan de Vet <devet@devet.org>
Cc:        bmah@FreeBSD.ORG, Sheldon Hearn <sheldonh@starjuice.net>, stable@FreeBSD.ORG
Subject:   Patches to Try wrt 'the size of stable /modules increased...'
Message-ID:  <p05101022b820d60f758e@[128.113.24.47]>
In-Reply-To: <200111201614.fAKGEC785608@harmony.village.org>
References:  <200111201514.aa72952@salmon.maths.tcd.ie> <200111201614.fAKGEC785608@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 9:14 AM -0700 11/20/01, Warner Losh wrote:
>Ian Dowse writes:
>:
>: I probably missed something important earlier in this thread, but
>: installing the debug versions of the modules seems like a bug,
>: since we don't install the debug version of the kernel. Adding
>: "DEBUG=-g" has always simply required more space in /usr/src, but
>: not affected the installed size. Does installing the debug versions
>: of modules make sense at all, or is it just hard to fix the makefiles
>: to stop it happening?
>
>I think it is an oversight.  The kernel makefile has special code to
>build -g, but not install (by doing a strip --debug, or the moral
>equivalent) the -g image.  Likely we should do the same thing for
>modules, now that I think about it.

Well, this idea intrigued me, as did some of the comments from Arjan
in a separate message.  So, I thought I'd try to come up with
something that might be useful and interesting for everyone.

So, here's a patch to sys/conf/Makefile.i386 and sys/conf/kmod.mk
that might be of interest.  This has worked for me, but note that I
have NOT TESTED IT MUCH.  It would be prudent to BACK UP all your
/kernel* and /modules* files before trying this!  Also, I'm sure a
number of decisions I made are quite debatable, so I see this as more
of a "good starting point for a discussion" than anything else.

This patch is *ONLY* for stable.  I have made no attempt to even
look at these makefiles in current, because I needed to be working
on stable today (for other reasons), and couldn't afford that much
of a detour.

I probably should write a few more disclaimers, but I don't want to
scare everyone away.  I really do think this has some good ideas in
it, even if they need to be polished off a bit.

My email client sometimes mixes up a patch, so if you want to apply
the patch you may need to pick up the copy at:
     http://people.freebsd.org/~gad/debugmod4.diff

Some notes on what these changes do:

  1) I have modules processed the same way wrt DEBUG as the kernel
     has been.  Thus, the modules will be compiled with DEBUG on
     (if it was set for the kernel), but that will be compiled into
     <kmod>.ko.debug, and then run thru '${OBJCOPY} --strip-debug'
     to create <kmod>.ko (with no .debug).  It is the <kmod>.ko
     which will get installed in /modules, and not the version with
     all the symbolic-debugging info in it.  All of this was just
     a duplicate of how 'install' is done on a kernel when DEBUG
     is set.

  2) I changed the install targets for both kernel and the modules
     to check if a symbol called KERNSAVDBGDIR is defined.  That's
     probably longer of a name than it needs to be, but I figured
     there was no way that would conflict with any other variables!
     Anyway, if you add 'KERNSAVDBGDIR=/somedir/somewhere' to your
     /etc/make.conf, *and* that directory exists, *and* you have
     specified DEBUG in your kernel, then the install target for
     kernel will install kernel.debug (the version with the symbol
     information) in /somedir/somewhere/kernel.debug .  The install
     target for modules will also install the <kmod>.ko.debug file
     in /somedir/somewhere/modules.debug/<kmod>.ko.debug .

     Note that I purposely picked a directory name of 'modules.debug',
     and not 'modules' (even though all the files will also have a
     .ko.debug on the end).  If someone set KERNSAVDBGDIR='/', I
     didn't want the processing of the debug-modules to run into the
     same directory as the non-debug ones.  (although, as I sit here,
     I'm not completely sure that KERNSAVDBGDIR='/' will actually
     *work*...).

  3) these debug targets will also keep backups when installing a
     new kernel, just like the main targets do.

  4) when doing the backup of /modules, the makefile target had
     been doing something along the lines of:
         mkdir -p /modules.old
         cp -p /modules/* /modules.old
     As one who watched this fail several times with '/' running out
     of disk space, I didn't much like that strategy.  So, I changed
     it to:
         rm -Rf /modules.old ; sync
         mv /modules /modules.old
         mkdir -p /modules
     The 'sync' is there for those of us who are running softupdates
     on '/'.  Maybe that's dumb, but it won't *hurt* anyone to have
     it there.
     It would not surprise me if there are good reasons to go with
     the 'cp' method instead of the 'mv', but my thinking was this.
     By 'mv'-ing the directory, you're sure that /modules.old is
     *exactly* the same as /modules had been, and you are also sure
     that /modules is being built from scratch.  Also, it just seemed
     like less work to do.  Also, you're not going to run out of
     disk space during that 'mv' operation, so you shouldn't end up
     with a 'half-backed-up' /modules.old directory.

  5) I noticed that the realinstall target for /modules in kmod.mk
     was using a destination of '${DESTDIR}${KMODDIR}', but that
     "backup of /modules" target (which is in Makefile.i386) had
     hardwired references to '${DESTDIR}/modules'.  I have no idea
     when KMODDIR might be different from "/modules", but I did not
     like the inconsistency so I changed Makefile.i386 to also use
     KMODDIR.  This might be something which is already correct in
     -current, but I have not checked.

  6) In Makefile.i386, there is a MKMODULESENV variable which is
     built up, and then used when calling 'make' in the modules
     directory.  It is a bunch of environment settings.  However,
     in one target (modules-clobber) it is used as:
         rm -rf ${MKMODULESENV}
     which did not seem like it could possibly be correct.  Again,
     I have to claim ignorance here as I have no idea what that
     target is used for.  However, I neutralized that, as I can
     not imagine it is correct.

  7) I changed that MKMODULESENV variable to pass along the
     setting of OBJCOPY to the modules makefile, for part #1 to
     work right.

  8) There was a comment that claimed that the target PROG for
     a kernel module was <kmod>.o, when it's really <kmod>.ko,
     so I changed that.

  9) I have a few 'echo' statements in there, just so I could be
     sure what was being executed when.  Obviously those 'echo's
     could be removed.

I might have a few other comments in the change, so obviously this
would merit some close scrutiny.  However, I wanted to get this
much of it out there for discussion.  I think something *like* this
would be very good to get into -stable before the next release,
just so people can turn on DEBUG in their kernel conf without
seeing so much disk space used up in '/'.  And I did like the idea
of Arjan's that modules.debug should be copied out of it's obscure
location in

/usr/obj/usr/src/sys/${KERNCONF}/modules/usr/src/sys/modules/*/*.ko.debug

(I had to use a 'find' command to track that down!) and into the
same general location as the matching /kerel.debug is copied.

I have done three or four installs with this code in the makefiles,
and it has worked as I wanted it to for those.  However, I certainly
did not test it extensively.  All my installs were basically the
same environment, so people with different setups could easily run
into something that I didn't check.

    +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
Well, if anyone's still reading, here's the patch:

--- sys/conf/Makefile.i386.orig	Mon Nov 12 20:19:21 2001
+++ sys/conf/Makefile.i386	Tue Nov 20 20:41:30 2001
@@ -221,6 +221,14 @@
  .endif
  	install -c -m 555 -o root -g wheel -fschg \
  		${KERNEL}${.TARGET:S/kernel-install//} ${DESTDIR}/${KERNEL}
+.if defined(DEBUG) && defined(KERNSAVDBGDIR) && exists(${KERNSAVDBGDIR})
+.if exists(${KERNSAVDBGDIR}/${KERNEL}.debug)
+	-chflags noschg ${KERNSAVDBGDIR}/${KERNEL}.debug
+	mv ${KERNSAVDBGDIR}/${KERNEL}.debug 
${KERNSAVDBGDIR}/${KERNEL}.old.debug
+.endif
+	install -c -m 555 -o root -g wheel \
+		${KERNEL}.debug ${KERNSAVDBGDIR}/${KERNEL}.debug
+.endif

  kernel-reinstall kernel-reinstall.debug:
  	install -c -m 555 -o root -g wheel -fschg \
@@ -237,7 +245,7 @@
  reinstall reinstall.debug: modules-reinstall
  .endif

-MKMODULESENV=	MAKEOBJDIRPREFIX=${.OBJDIR}/modules
+MKMODULESENV=	MAKEOBJDIRPREFIX=${.OBJDIR}/modules OBJCOPY=${OBJCOPY}
  .if defined(MODULES_OVERRIDE)
  MKMODULESENV+=	MODULES_OVERRIDE="${MODULES_OVERRIDE}"
  .endif
@@ -245,6 +253,7 @@
  MKMODULESENV+=	DEBUG="${DEBUG}" DEBUG_FLAGS="${DEBUG}"
  .endif

+#  XXXX - should all these references to /modules be ${KMODDIR} ?  (gad)
  modules:
  	@mkdir -p ${.OBJDIR}/modules
  	cd $S/modules ; env ${MKMODULESENV} ${MAKE} obj ; \
@@ -261,8 +270,10 @@
  modules-cleandepend:
  	cd $S/modules ; env ${MKMODULESENV} ${MAKE} cleandepend

+# XXX - this doesn't make any sense...   (gad)
  modules-clobber:	modules-clean
-	rm -rf ${MKMODULESENV}
+	echo ; echo "Eh?  we're going to 'rm -rf ${MKMODULESENV}'?"
+	/iDontThinkSo/rm -rf ${MKMODULESENV}

  modules-cleandir:
  	cd $S/modules ; env ${MKMODULESENV} ${MAKE} cleandir
@@ -272,10 +283,22 @@

  modules-install modules-install.debug:
  .if !defined(NO_MODULES_OLD)
-	if [ -d ${DESTDIR}/modules -a -n "`ls ${DESTDIR}/modules`" ]; then \
-		mkdir -p ${DESTDIR}/modules.old; \
-		cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old; \
+	if [ -d ${DESTDIR}${KMODDIR} -a -n "`ls 
${DESTDIR}${KMODDIR}`" ]; then \
+		rm -Rf ${DESTDIR}${KMODDIR}.old; sync ; \
+		mv ${DESTDIR}${KMODDIR} ${DESTDIR}${KMODDIR}.old; \
+	fi;
+	if [ ! -d ${DESTDIR}${KMODDIR} ]; then \
+		mkdir -p ${DESTDIR}${KMODDIR}; \
  	fi;
+.if defined(DEBUG) && defined(KERNSAVDBGDIR) && exists(${KERNSAVDBGDIR})
+	if [ -d ${KERNSAVDBGDIR}${KMODDIR}.debug -a -n "`ls 
${KERNSAVDBGDIR}${KMODDIR}.debug`" ]; then \
+		rm -Rf ${KERNSAVDBGDIR}${KMODDIR}.old.debug; sync ; \
+		mv ${KERNSAVDBGDIR}${KMODDIR}.debug 
${KERNSAVDBGDIR}${KMODDIR}.debug.old; \
+	fi;
+	if [ ! -d ${KERNSAVDBGDIR}${KMODDIR}.debug ] ; then \
+		mkdir -p ${KERNSAVDBGDIR}${KMODDIR}.debug; \
+	fi;
+.endif
  .endif
  	cd $S/modules ; env ${MKMODULESENV} ${MAKE} install

--- sys/conf/kmod.mk.orig	Sat Aug 11 15:42:51 2001
+++ sys/conf/kmod.mk	Tue Nov 20 20:44:50 2001
@@ -35,7 +35,7 @@
  # NOMAN		KLD does not have a manual page if set.
  #
  # PROG          The name of the kernel module to build.
-#		If not supplied, ${KMOD}.o is used.
+#		If not supplied, ${KMOD}.ko is used.
  #
  # SRCS          List of source files
  #
@@ -131,8 +131,21 @@
  PROG=	${KMOD}.ko
  .endif

-${PROG}: ${KMOD}.kld ${KMODDEPS}
+.if !defined(DEBUG)
+FULLPROG=     ${PROG}
+.else
+FULLPROG=     ${PROG}.debug
+${PROG}: ${FULLPROG}
+	@echo " - - - - - - - - - - - - - - -"
+	@echo "       Making ${PROG} from ${FULLPROG}"
+	${OBJCOPY} --strip-debug ${FULLPROG} ${PROG}
+.endif
+
+${FULLPROG}: ${KMOD}.kld ${KMODDEPS}
  .if ${OBJFORMAT} == elf
+	@echo
+	@echo " - - - - - - - - - - - - - - -"
+	@echo "       Making ${FULLPROG} with PROG = ${PROG} DEBUG = ${DEBUG}"
  	gensetdefs ${KMOD}.kld
  	${CC} ${CFLAGS} -c setdef0.c
  	${CC} ${CFLAGS} -c setdef1.c
@@ -221,6 +234,10 @@
  realinstall: _SUBDIR
  	${INSTALL} ${COPY} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
  	    ${_INSTALLFLAGS} ${PROG} ${DESTDIR}${KMODDIR}/
+.if defined(DEBUG) && defined(KERNSAVDBGDIR) && exists(${KERNSAVDBGDIR})
+	${INSTALL} ${COPY} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \
+		${PROG}.debug ${KERNSAVDBGDIR}${KMODDIR}.debug/${PROG}.debug
+.endif
  .if defined(LINKS) && !empty(LINKS)
  	@set ${LINKS}; \
  	while test $$# -ge 2; do \


-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101022b820d60f758e>