From owner-svn-src-head@freebsd.org Thu Sep 24 21:11:09 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 F344AA079F7 for ; Thu, 24 Sep 2015 21:11:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFA601588 for ; Thu, 24 Sep 2015 21:11:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgez77 with SMTP id z77so55566662qge.1 for ; Thu, 24 Sep 2015 14:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cTmbG0xbN5qWFXFBTv/0NBP22LPJ5Y1Dkq3eDM3HvSc=; b=RETfK3b5xEqfbt2XhCbATSvrVF373MDRHTFugZL5djH86bfOULcXQnhWUsDSTHNGxY JIZj7d/yNmYZFdOrKAGVd/G30owAmesgEFnEgVWrs9cdZ7pO7PFTndn+tUuxzwrrf1xg xVVuSfdY8Cqj1RZcbRzWBIPPIbQDxBCDOJBRxXgjzbYATzaC+83H9m5d1ZTrHy/VRjcq 1yCGmYijTV4ur3LWsHwzg4C7ibrTDqIWCct/VNc4H2liG1d7UWgEZcsw/Ef1dNH4HNWh ljkD/GKAaqvTEYCK5uF59deNkJ5TN040r5IBYHzv4ocLXK6I/uqF0BLM0oXSXo6rZE6b 7huw== X-Gm-Message-State: ALoCoQkMY9M04j7Ya0tpJRICDyq6QQk1pkBO/GErScv5ueRf+tjy9xWZpUrwFt7UCmpBPOZrK+i5 MIME-Version: 1.0 X-Received: by 10.140.19.175 with SMTP id 44mr2287061qgh.50.1443129061975; Thu, 24 Sep 2015 14:11:01 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Thu, 24 Sep 2015 14:11:01 -0700 (PDT) X-Originating-IP: [69.53.245.18] In-Reply-To: References: <35a0f1b6-0236-4b0e-b919-00cab07429be@me.com> <5427AC7C-1B0B-4273-B758-DB0C1BDF656F@bsdimp.com> <1443064383.14580.3.camel@me.com> Date: Thu, 24 Sep 2015 14:11:01 -0700 X-Google-Sender-Auth: yiT3ABxJd6ocrgBu_5lee-YWQEk Message-ID: Subject: Re: svn commit: r287934 - head/sys/boot/efi/loader From: Warner Losh To: Adrian Chadd Cc: Rui Paulo , John Baldwin , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Thu, 24 Sep 2015 21:11:09 -0000 That's the idea... When we load an 802.11 driver we'd need to then load the other associated modules. The key is, which ones and how do the special needs crowd do things other than the default. Warner On Thu, Sep 24, 2015 at 8:29 AM, Adrian Chadd wrote: > ... I'm confused about the "load it by hand" stuff in net80211. Why > don't we just do the kldload at that point? > > > -a > > > On 23 September 2015 at 21:06, Warner Losh wrote: > > You're right about the Wifi drivers. There's some number you'll want > loaded > > and we should have sensible defaults. But how to get there from here may > > be a bit interesting... Though if I go with the devd.conf writer early > in > > boot, > > I can make them be rc.conf variable controlled. > > > > Warner > > > > On Wed, Sep 23, 2015 at 8:13 PM, Rui Paulo wrote: > >> > >> Those were the issues that I encountered when I started using MINIMAL. > >> I didn't do a thorough investigation. > >> > >> Auto loading is a much bigger problem that just loading drivers for > >> PCI/USB/etc devices. For example, net80211 doesn't auto load the wlan > >> crypto modules by default nor the amrr module. > >> > >> On Mon, 2015-09-21 at 17:59 -0600, Warner Losh wrote: > >> > Apart from the inlining issue John raised (which I agree with his > >> > solution on, btw) > >> > and the one cam ctl module, what other modules are meaningfully > >> > different when > >> > compiled as modules. > >> > > >> > Assume that the auto-loading bit is solved, at least for devices on > >> > self-enumerating > >> > busses. > >> > > >> > Warner > >> > > >> > > >> > > On Sep 21, 2015, at 4:53 PM, Rui Paulo wrote: > >> > > > >> > > No, that doesn't work very well. Not only the modules don't auto > >> > > -load, the way the modules are compiled is different. See, for > >> > > example, cam ctl which doesn't compile the sg code when it's built > >> > > into the kernel, but compiles it when it's built as a module. The > >> > > sg code is currently buggy and causes insta-panics with GNOME 3 > >> > > (perhaps the auto-mounter in hald (?)). > >> > > -- > >> > > Rui Paulo > >> > > > >> > > > >> > > On Sep 21, 2015, at 11:24 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.. > >> > > > > >> > > > > >> > > > -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. > >> > > > > > >> > > > > -- > >> > > > > Rui Paulo > >> > > > > > >> > > > > > >> > > > > On Sep 17, 2015, at 01:36 PM, John Baldwin > >> > > > > wrote: > >> > > > > > >> > > > > Author: jhb > >> > > > > Date: Thu Sep 17 20:36:46 2015 > >> > > > > New Revision: 287934 > >> > > > > URL: https://svnweb.freebsd.org/changeset/base/287934 > >> > > > > > >> > > > > > >> > > > > Log: > >> > > > > The EFI boot loader allocates a single chunk of contiguous > >> > > > > memory to > >> > > > > hold the kernel, modules, and any other loaded data. This > >> > > > > memory block > >> > > > > is relocated to the kernel's expected location during the > >> > > > > transfer of > >> > > > > control from the loader to the kernel. > >> > > > > > >> > > > > The GENERIC kernel on amd64 has recently grown such that a > >> > > > > kernel + zfs.ko > >> > > > > no longer fits in the default staging size. Bump the default > >> > > > > size from > >> > > > > 32MB to 48MB to provide more breathing room. > >> > > > > > >> > > > > PR: 201679 > >> > > > > Reviewed by: imp > >> > > > > MFC after: 1 week > >> > > > > Differential Revision: https://reviews.freebsd.org/D3666 > >> > > > > > >> > > > > > >> > > > > Modified: > >> > > > > head/sys/boot/efi/loader/copy.c > >> > > > > > >> > > > > Modified: head/sys/boot/efi/loader/copy.c > >> > > > > =============================================================== > >> > > > > =============== > >> > > > > --- head/sys/boot/efi/loader/copy.c Thu Sep 17 20:36:34 2015 > >> > > > > (r287933) > >> > > > > +++ head/sys/boot/efi/loader/copy.c Thu Sep 17 20:36:46 2015 > >> > > > > (r287934) > >> > > > > @@ -38,7 +38,7 @@ __FBSDID("$FreeBSD$"); > >> > > > > #include > >> > > > > > >> > > > > #ifndef EFI_STAGING_SIZE > >> > > > > -#define EFI_STAGING_SIZE 32 > >> > > > > +#define EFI_STAGING_SIZE 48 > >> > > > > #endif > >> > > > > > >> > > > > #define STAGE_PAGES ((EFI_STAGING_SIZE) * 1024 * 1024 / 4096) > >> > > > > > >> > > >> > >> -- > >> Rui Paulo > >> > > >