From owner-svn-src-all@freebsd.org Mon Oct 17 20:23:07 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 C94EEC15021; Mon, 17 Oct 2016 20:23:07 +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 98E13901; Mon, 17 Oct 2016 20:23:07 +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 408CD2083F; Mon, 17 Oct 2016 16:23:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 17 Oct 2016 16:23:06 -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=e8UDR1Do4Tx6r06Qe59GbfGRVE8=; b=BPOz0A vBuMrzqbUTM+tsR7jzOFdMNXty9AKFH1LhXYH0SOyDdN+AseciWvPcy4I9cF21Ul M1ZBg57Z1/tC5n9ByQREopvgVzVXWypI1w1BS/VDN+tM3BTRYp3ye8o3F/Q37jIc b4JuSRkzpeMGtiEZGfIA2Hq4EtU3MsrtaAfj8= 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=e8UDR1Do4Tx6r06 Qe59GbfGRVE8=; b=ryooaBYgEkV1OERD4zXOFy2yV4j4LE7QPHAHvurUM/q8619 b3mbD9IWNbsRoi7rtM7yCb4KWziegiOjDewHch0+cUgJTfSNgK+MLiEKg/1bgdrL HVvWq5Q+p3cH+pyrwItyg0VccS5YAwu6qXaBNTA0Q0aR9X94cBgrTIWZYDHc= X-Sasl-enc: 2MylpfjoJTjB9N0Nt2NClOAGc1deJ2D+s8ExK0/yYMk1 1476735785 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 24E85F29C9; Mon, 17 Oct 2016 16:23:05 -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> Cc: Doug Ambrisko , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Doug Ambrisko , Ravi Pokala From: Bruce Simpson Message-ID: <2397b12d-ddd7-8fde-9575-44dd825d6f60@fastmail.net> Date: Mon, 17 Oct 2016 21:23:04 +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: <1950201.IjTl3rpdGP@ralph.baldwin.cx> 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:23:07 -0000 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. It exports this information using an ACPI-like table in that BIOS HBA type area in x86 address space, but the table is not DSDT linked (it's not produced by the BIOS). Having a coherent means of dealing with it would be very useful, as such FreeBSD installers (which I've deployed as mfsBSD images) can then basically re-use what's been done for EFI variables for those legacy systems which don't support/can't use EFI network boot. As yet, I've not tried this with 64-bit EFI systems.