From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Linux-libre-4.15 and the NVMe module Date: Tue, 30 Jan 2018 12:07:29 +0100 Message-ID: <20180130120729.38fbaaed@scratchpost.org> References: <87fu6obvfa.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egTlP-0002fz-NM for guix-devel@gnu.org; Tue, 30 Jan 2018 06:07:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egTlH-000347-Uy for guix-devel@gnu.org; Tue, 30 Jan 2018 06:07:43 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:48842) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1egTlH-00033k-NQ for guix-devel@gnu.org; Tue, 30 Jan 2018 06:07:35 -0500 In-Reply-To: <87fu6obvfa.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, On Mon, 29 Jan 2018 09:18:17 -0500 Mark H Weaver wrote: > Unfortunately, it seems that in linux-libre-4.15, we must now have > CONFIG_BLK_DEV_NVME=y (built-in) if we wish to keep CONFIG_NVM=y > (Open-Channel SSD target support), which we've had enabled in our kernel > configurations since 4.4. CONFIG_NVM cannot be made modular, and in > 4.15 it now depends on CONFIG_BLK_DEV_NVME=y. I wonder whether that's a regression or on purpose... > Since I don't see a nice way in our current 'base-initrd' implementation > to conditionally include "nvme.ko" depending on the kernel > configuration, I simply removed "nvme.ko" from the list of modules, and > changed all of our kernel configurations to have CONFIG_BLK_DEV_NVME=y. I think that's fine for the time being. That said, it would be nice if we extended our base-initrd implementation to take a list of modules to try to copy, and to skip each which doesn't exist. It would make the initrds more reusable and I don't see a downside if we supported both this new list of modules and the existing list of modules. > While I was at it, I updated our older kernel configurations to the > current point releases, using "make oldconfig". My main motivation for > doing this was to explicitly show in our config files that we've enabled > the mitigations for meltdown and spectre. Good idea.