From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 8ce10349 for ; Wed, 10 Apr 2019 17:32:01 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 532F494BEE; Thu, 11 Apr 2019 03:32:00 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2E73094929; Thu, 11 Apr 2019 03:31:36 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id C4B2994926; Thu, 11 Apr 2019 03:31:34 +1000 (AEST) X-Greylist: delayed 660 seconds by postgrey-1.36 at minnie.tuhs.org; Thu, 11 Apr 2019 03:31:34 AEST Received: from cesium.clock.org (cesium.clock.org [157.22.10.65]) by minnie.tuhs.org (Postfix) with ESMTPS id 642CA94925 for ; Thu, 11 Apr 2019 03:31:34 +1000 (AEST) Received: from cesium.clock.org (localhost [127.0.0.1]) by cesium.clock.org (Postfix) with ESMTP id 85F7ECC072; Wed, 10 Apr 2019 10:20:14 -0700 (PDT) From: "Erik E. Fair" In-reply-to: To: Pat Barron Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Date: Wed, 10 Apr 2019 10:20:14 -0700 Message-ID: <17458.1554916814@cesium.clock.org> Subject: Re: [TUHS] Paper discussing Unix boot process? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Pat, Any such description is either going to be very hardware/system = specific, or vague to the point of uselessness. The experience of the NetBSD = community, which prides itself on extreme portability and working around broken = or ... let's say "incomplete" vendor firmware, is that such things are highly = system-specific. The vague description is easy: some booter or firmware loads the kernel into RAM, the kernel initializes the MMU and the rest of the processor(s), devices are somehow probed or listed and device drivers called to initialize minimally necessary I/O devices (console, data storage so you can mount / (root)), a process is created, and /sbin/init is exec'd. Details of firmware or booter provided environment and parameters to the kernel = vary a lot; thus that famously small-ish percentage of any Unix kernel that = is written in assembler for the processor involved, rather than C. See also https://www.quora.com/Are-bootloaders-like-GRUB-and-LILO-hardware-specific/answer/Erik-Fair https://www.quora.com/What-is-a-concise-explanation-for-the-UNIX-bootstrap-process/answer/Erik-Fair Erik