Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2001399imm; Thu, 23 Aug 2018 12:23:49 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbNBz9egk7B39PUxqvjkSgsn9y2AzWkJ7wA9UIU5FpprPginCubEtfTtANtoxYTTkNy3/Rf X-Received: by 2002:a65:420c:: with SMTP id c12-v6mr6324922pgq.405.1535052229877; Thu, 23 Aug 2018 12:23:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535052229; cv=none; d=google.com; s=arc-20160816; b=lOfQrqi+VEhDWOTyPQO1JHkgLoxXBxEG5s7Ml83c1WkcnfQUHsoaWz+zWcLNgf9Sku K9NHlyBiVt6qSxw1MtxdqehM5aX7I6wJAyknsPrLA5GYnjtA9bQ3Wc2TABj/40K7F49g fVEs/AIW2FlvWbLahT2UHvfun70LpyE7yN3YC6oazlpEwqwiSOjKmO5OjrB6zRTtceH8 NwDV9TJpAtQS3CvwDpCT45pAAuYaW59/XqJ9oqUhW2yqWZlNerCgXFryvgcxmu0UzgeU ttujmY3mnbqpRw227R99oIzNspMnwLuM2Yt/VgcwaGYiw0qxBJjOpHuWM6wal9ZPrHEc eYsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=a0QN3AVzjKBcgOnECmDHF3Wl+pImT29K1BbaRI/ZI7I=; b=XAM/hlUQWbPOcle3f73n9IelH8kXoVtVCIM6OLEqjG9ySALoAtNK+qxbkf5nz0Hgcl cWGEbYj6lGsUFaGJJLm4OQRYzoLS4fyttKLCbtit4sc2UL72wXZa5NSRuvLETPA4+VvN TY/6qwm/WxQAiRnMHhPtxjejKaUs3ZQYc9XheqKKe3KbWsMgXTZ55x+HP7HUI7ygT5aI TyffyDy7Bt20jCyVaBBdcSsqnvOi83UfUAkU46GPGdlrFCOy9RLK8JhuwYAfXJTNafvg pF1mGdGT/949vCLy69tDr7vBFilwtRZsLE2/W1sD1L5474Qc6VKA973MMSPE87xgfQyQ NcAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r24-v6si5109918pgo.605.2018.08.23.12.23.34; Thu, 23 Aug 2018 12:23:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727355AbeHWWwb (ORCPT + 99 others); Thu, 23 Aug 2018 18:52:31 -0400 Received: from mslow2.mail.gandi.net ([217.70.178.242]:60798 "EHLO mslow2.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725979AbeHWWwb (ORCPT ); Thu, 23 Aug 2018 18:52:31 -0400 Received: from relay7-d.mail.gandi.net (unknown [217.70.183.200]) by mslow2.mail.gandi.net (Postfix) with ESMTP id 54B4B3A702F for ; Thu, 23 Aug 2018 21:12:48 +0200 (CEST) X-Originating-IP: 134.134.139.72 Received: from localhost (jfdmzpr03-ext.jf.intel.com [134.134.139.72]) (Authenticated sender: josh@joshtriplett.org) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 8A57120004; Thu, 23 Aug 2018 19:12:45 +0000 (UTC) Date: Thu, 23 Aug 2018 12:12:35 -0700 From: Josh Triplett To: "Paul E. McKenney" Cc: nicolas.pitre@linaro.org, linux-kernel@vger.kernel.org Subject: Re: Kernel-only deployments? Message-ID: <20180823191235.GA3243@localhost> References: <20180823174359.GA13033@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180823174359.GA13033@linux.vnet.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 23, 2018 at 10:43:59AM -0700, Paul E. McKenney wrote: > Hello! > > Does anyone do kernel-only deployments, for example, setting up an > embedded device having a Linux kernel and absolutely no userspace > whatsoever? I would very much *like* to do this. One day I'd like to have a CONFIG_USERSPACE that I can disable, and then just have the kernel call an in-kernel main() where it would normally start init. > Those who know me will not be at all surprised to learn that I went > overboard making the resulting initrd as small as possible. I started > by throwing out everything not absolutely needed by the dash and sleep > binaries, which got me down to about 2.5MB, 1.8MB of which was libc. > This situation of course prompted me to create an initrd containing > a statically linked binary named "init" and absolutely nothing else > (not even /dev or /tmp directories), which weighs in at not quite 800KB. > This is a great improvement over 10MB, to say nothing of 40MB, but 800KB > for a C-language "for" loop containing nothing more than a single call to > sleep()? Much of the code is there for things that I might do (dl_open(), > for example), but don't. All I can say is that there clearly aren't many > of us left who made heavy use of systems with naked-eye-visible bits! > (Or naked-finger-feelable, for that matter.) I have definitely built initramfs images containing nothing but a single statically linked /init before. If you want to make it even smaller, you could avoid linking in libc at all, and just write a short assembly stub, but I don't know any way to do that *portably* without writing raw assembly for each target platform. That would get you down to a few kB though. > This further prompted the idea of modifying kernel_init() to just loop > forever, perhaps not even reaping orphaned zombies [*], given an appropriate > Kconfig option and/or kernel boot parameter. I obviously cannot justify > this to save a sub-one-megabyte initrd for rcutorture, no matter how much > a wasted 800K might have offended my 30-years-ago self. If I take this > next step, there have to be quite a few others benefiting significantly > from it. I would *love* to have support for omitting userspace entirely. And once we have that, we can start ripping out so many other things... One thought, though: that won't necessarily give you a representative rcutorture experience, given that you need to test things like the nohz-on-non-idle support, which interacts with "am I in userspace".