From owner-freebsd-arch@FreeBSD.ORG Thu Mar 24 11:26:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036F91065670; Thu, 24 Mar 2011 11:26:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 924C08FC17; Thu, 24 Mar 2011 11:26:08 +0000 (UTC) Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2OBQ4ow025781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 22:26:05 +1100 Date: Thu, 24 Mar 2011 22:26:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Jennejohn In-Reply-To: <20110324083048.60862a0f@ernst.jennejohn.org> Message-ID: <20110324214320.K1149@besplex.bde.org> References: <20110323200200.GA85810@freebsd.org> <201103232050.p2NKov4g017463@lurza.secnetix.de> <4D8A7976.5090103@freebsd.org> <20110323232209.GA15486@freebsd.org> <20110324083048.60862a0f@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Best , Oliver Fromme , Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: kernel memory checks on boot vs. boot time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 11:26:09 -0000 On Thu, 24 Mar 2011, Gary Jennejohn wrote: > On Wed, 23 Mar 2011 23:22:09 +0000 > Alexander Best wrote: > >> On Thu Mar 24 11, Andriy Gapon wrote: >>> on 23/03/2011 22:50 Oliver Fromme said the following: >>>> Beware, I don't know if this is the *only* thing preventing >>>> boot2 from booting an amd64 kernel. There might be more. ["This" is setting up long mode.] I think amd64 also depends on loader to set up lots of page table, ELF and module stuff. Compare the size of amd64.locore.S with the size of i386/locore.s. I'm not sure how much of the simplification is automatic from using long mode. >>>> I haven't tried booting FreeBSD without the boot loader in >>>> a long time. Probably not in this century. Since I consider the existence of loader to be a bug, I try not to use it, and mostly use my version of biosboot (= biosboot with elf support copied from boot2) on i386. >>> Kind of hijacking the thread - while we are gradually moving from mbr+bsdlabel >>> to gpt and more, we are also moving from away from size-constrained boot2. This has been possible since ~1980 using disklabel. Either put the boot2 stage on a separate partition, or fix assumptions that the space reserved for the boot area (d_bbsize) is always 8K. >>> My vision is that boot2 and loader should fuse into something more powerful that >>> would reside in a boot partition, but with its config files on a "regular" >>> filesystem. My vision was that this would be named "/kernel". There might still be a boot2 stage, but it would have as many full kernel features as you want, to prepare for the full kernel, or perhaps for a reduced kernel. Unfortunately, in FreeBSD, instead of merging the second stage into the kernel, the second stage was split into boot2 and a loader stage, with enormous bloat in the loader stage. Yet the bloat isn't large enough to include necessary functionality for handling itself, starting with command line editing and history various search functions. >> +1. being able to control the whole boot process by /etc/boot.conf would be >> great. there are defenately too many files in /boot. new users have no clue >> what boot, boot0, boot1, boot2, cdboot, gptboot, etc. are all about. >> >> merging /boot/loader, /boot/gptboot and /boot/zfsgptboot would be really nice. >> building/installing all the mbr+bsdlabel boot files could be made dependable >> upon some variable (WITH_MBR_BOOT=), which could be disabled by default. >> >> also moving away from forth to something more modern might be thinkable. having >> support for a modern scripting language might make it easier to come up with a >> nice graphical bootloader e.g. there're probably more advantages. >> >> problem might be that the current gpart(8) manual recommends using 64k for the >> boot partition. that might not be enough, if ada0p1 should contain the >> functionality of all boot stages (including the loader), support for a modern >> scripting language and support for graphical menues (including a rudimentary >> vga/vesa driver for high res). > > I have no problem with any of these ideas as long as well-documented > knobs are provided to turn these "features" off and maintain "legacy" > functionality. > > I'm running off disks where FreeBSD was installed 8 years ago and I have > no intention of using gpart(8) on any of them. The same goes for > graphical bootloaders - I can't stand them. Me too. However, I liked userconfig and even the semi-graphical visual userconfig in FreeBSD-[2-4]. These were correctly placed from my point of view (in the kernel), and were optional so not using them was supported. Bruce