From owner-svn-src-head@freebsd.org Mon Sep 21 22:31:37 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B750DA0576B; Mon, 21 Sep 2015 22:31:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FFE81568; Mon, 21 Sep 2015 22:31:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8D255B91E; Mon, 21 Sep 2015 18:31:35 -0400 (EDT) From: John Baldwin To: Adrian Chadd Cc: Rui Paulo , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r287934 - head/sys/boot/efi/loader Date: Mon, 21 Sep 2015 15:31:11 -0700 Message-ID: <7425989.fyHR6C7Hof@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <13e1fdb2-6e22-4371-95e4-a556c357fa8d@me.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 21 Sep 2015 18:31:35 -0400 (EDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 22:31:37 -0000 On Monday, September 21, 2015 11:24:27 AM Adrian Chadd wrote: > Hi, > > Warner has been working on the modular kernel thing. But honestly, I > think we should just start biting that bullet and ship a modules-only > GENERIC by default.. That will not help. In fact, that will probably make it worse. The modules have to fit into the same staging area as the kernel, and each module adds overhead in the form of headers, etc. OTOH, since we penalize performance in modules by not inlining locks and such, that may even out. If we decide to fix those instead then it would be back to being worse. :) (I'm of the opinion we should inline atomics and locks, etc. in modules built as part of a kernel to match that kernel's config and only use shims for modules built standalone. Most of this can probably be accomplished by having modules built as part of a kernel not define KLD_MODULE during their build but only use that for standalone modules. However, I haven't audited all the uses of KLD_MODULE to see if we might want some of them to be on for "bundled" modules in which case we'd need to add a new #define that gets defined for "bundled" modules but not standalone modules (or gets defined for both?) and fixup the code appropriately.) > -a > > > On 21 September 2015 at 11:02, Rui Paulo wrote: > > So, we're going to keep ignoring the problem and keep patching things up? > > It's a bit sad that a single driver (pmspcv) is able to cause so much > > problems. It's a harder problem to solve. Feel free to submit patches. One option is to let the staging code allocate more memory chunks from EFI and chain them together. However, your relocate code will now have to be smart enough to order the various copies in such a way that none of them copy over top of each other. I haven't sat down to see if that's easy to solve or not. The other approach I suggested earlier is to make the kernel relocatable (and allow the module metadata to be anywhere and live in a chain instead of an array) so that we can just load things wherever and leave them there without having to relocate. -- John Baldwin