Date: Mon, 21 Sep 2015 15:31:11 -0700 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Rui Paulo <rpaulo@me.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r287934 - head/sys/boot/efi/loader Message-ID: <7425989.fyHR6C7Hof@ralph.baldwin.cx> In-Reply-To: <CAJ-Vmok6%2B2vcekUZLU0uRSGqQtgNqmBQBu82sOiSMR_BPy0U2w@mail.gmail.com> References: <13e1fdb2-6e22-4371-95e4-a556c357fa8d@me.com> <CAJ-Vmok6%2B2vcekUZLU0uRSGqQtgNqmBQBu82sOiSMR_BPy0U2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rpaulo@me.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7425989.fyHR6C7Hof>