From owner-svn-src-all@freebsd.org Mon Oct 17 20:26:57 2016 Return-Path: Delivered-To: svn-src-all@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 9C8DCC152DB; Mon, 17 Oct 2016 20:26:57 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9D2C37; Mon, 17 Oct 2016 20:26:57 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3172420286; Mon, 17 Oct 2016 16:26:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 17 Oct 2016 16:26:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=5XwgTk9HpArVTCdbaMkjFOUer9s=; b=JGS1yc rol4jFCg1ZIEHgVGVKA0d696KeF9N4xeA6QcqS2jOOKzxpJXIGrzTYbHqAwbcfxa FeBQ37GOSENUDEPvgDBPA7VXZj8C+dvzAVjLTmAh41FzOKt1H8C2JSqYR9klmDtD 03C5dbvyw3TLo+H2Ju3bskuzuh647Dm6cOl1U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=5XwgTk9HpArVTCd baMkjFOUer9s=; b=h2JmrQmlu0QwZNmgEYEytSDz72MJTxMHOU4MRGNAeUij9qV +wnF0u8R8CV6bfZbCjL0VWlRL3mP6nmFMmp2iNpZ7h3BUleWkts+wJMHcNkbhUUp 68Jc4ORrT1+vUmuId8MPeuGY6456VqhxRMCz8sPDqaL1k6Tas0TkndQEuCEA= X-Sasl-enc: JuuIK7u2wbkhVjNaRwxUe8EQdsuQdmuBHkuz8LXftdkW 1476736015 Received: from [192.168.1.88] (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D3E8F29C9; Mon, 17 Oct 2016 16:26:55 -0400 (EDT) Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader To: John Baldwin , Warner Losh References: <201610141710.u9EHArlL089412@repo.freebsd.org> <20161014175542.GB65545@ambrisko.com> <1950201.IjTl3rpdGP@ralph.baldwin.cx> <2397b12d-ddd7-8fde-9575-44dd825d6f60@fastmail.net> Cc: Doug Ambrisko , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Doug Ambrisko , Ravi Pokala From: Bruce Simpson Message-ID: Date: Mon, 17 Oct 2016 21:26:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2397b12d-ddd7-8fde-9575-44dd825d6f60@fastmail.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 20:26:57 -0000 On 17/10/16 21:23, Bruce Simpson wrote: > On 17/10/16 18:40, John Baldwin wrote: >> I'm a bit hesitant to do all the type parsing in the kernel vs userland. >> However, I think having smbios(4) export a /dev/smbios that you can >> either >> read() or mmap() to access the table would be very convenient and let you >> keep the bits to parse the table in userland (and not require root if we >> allow read-only access to mortals on /dev/foo). > > This is probably a bit left-field, but I'm wondering if both methods > (expose-to-loader-kenv and user-space-accessible devfs node) can be > re-used for things like the Linux-oriented kernel environment page > exported by SYSLINUX/PXELINUX memdisk, which I've used with some success > to boot FreeBSD installers in heterogeneous private cloud/lab setups. PS Hit send too soon -- the main reason a FreeBSD installer, or image wrapper for a FreeBSD installer tool (akin to the Debian style of network driven installer), would need access to the memdisk's ACPI-style table (containing boot & textual 'environment' page, filled out by the TFTP boot server, perhaps by scripted means) is... ...where it can't intuit all system configuration settings by reference to its primary MAC address alone, or where it needs network bootstrap information to proceed with other provisioning methods (straight to Puppet/Ansible, and/or fetching a list of pkgng pkgs to grab from some trusted package server). The code required would just pretty much resemble what you guys are doing for EFI right now, but for BIOS-era systems (of which we've got a large installed base, and mass provisioning those would be great, for the sake of recycling.)