From owner-freebsd-current@FreeBSD.ORG Mon Aug 15 12:01:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 31256106566C; Mon, 15 Aug 2011 12:01:32 +0000 (UTC) Date: Mon, 15 Aug 2011 12:01:32 +0000 From: Alexander Best To: Robert Watson Message-ID: <20110815120132.GA21258@freebsd.org> References: <20110814215016.GA40704@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:01:32 -0000 On Mon Aug 15 11, Robert Watson wrote: > > On Sun, 14 Aug 2011, Alexander Best wrote: > > >has anybody seen this buildworld failure? > > Could you try the attached patch and see if it helps? I currently have it > in the re@ approval queue. It does appear to fix the problem here. thanks. the patch fixes the issue. > > Generally, I would strongly advise against using modules built with world, > and wonder if we should be de-supporting that explicitly at this point. > Checking that the below works for you would be great, but you might not > want to use MODULES_WITH_WORLD anymore. usually i set "MODULES_OVERRIDE =", because i don't have time to wait for buildkernel compiling all the modules. however i thought it might be handy to have the kernel modules available, so i set MODULES_WITH_WORLD instead. of course i know that building/installing a new kernel and keeping the old modules is not really a great idea, because quite often the outdated modules will fail to load. yet for me it's a timer saver and still gives me the option of loading a certain module. so personally i'd like to see MODULES_WITH_WORLD support stay. but if people decide it should go then that's not too much of a problem with me. ;) cheers. alex > > (If we do want to keep MODULES_WITH_WORLD, we may want to add it to the > tinderboxes.) > > Robert > > -- > > Fix two cases involving opt_capsicum.h and module builds: > > (1) opt_capsicum.h is no longer required in ffs_alloc.c, so remove the > #include. > > (2) portalfs depends on opt_capsicum.h, so have the Makefile generate one > if required. > > Note, however, that attempting to use modules built without a kernel > configuration is a bad idea generally -- it's a bit worrying that we still > provide MODULES_WITH_WORLD. > > Approved by: re (xxx) > Sponsored by: Google Inc > > Index: ufs/ffs/ffs_alloc.c > =================================================================== > --- ufs/ffs/ffs_alloc.c (revision 224860) > +++ ufs/ffs/ffs_alloc.c (working copy) > @@ -62,7 +62,6 @@ > #include > __FBSDID("$FreeBSD$"); > > -#include "opt_capsicum.h" > #include "opt_quota.h" > > #include > Index: modules/portalfs/Makefile > =================================================================== > --- modules/portalfs/Makefile (revision 224860) > +++ modules/portalfs/Makefile (working copy) > @@ -4,6 +4,7 @@ > > KMOD= portalfs > SRCS= vnode_if.h \ > - portal_vfsops.c portal_vnops.c > + portal_vfsops.c portal_vnops.c \ > + opt_capsicum.h > > .include