From owner-svn-src-all@freebsd.org Fri Oct 14 17:33:33 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 DD927C1263C; Fri, 14 Oct 2016 17:33:33 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0268EDF; Fri, 14 Oct 2016 17:33:33 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OF100G00SACXS00@mr11p00im-asmtp004.me.com>; Fri, 14 Oct 2016 17:33:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1476466397; bh=zvPoYPQq03zjqodIMcPo2HdMU/Juo2b/Cju/W+4Sqdk=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=qYoARebOuSTQ3uZdaNPXAAO2vd4EzsG2AqZDPZ/ANbrUA1pesaRid5rs1xGjfdUZI vZ/4VDjD/koyLWc3Avgh+N0cjjwuxrkEobcvF2rMegLBUf1I8YdQEDInABVkyov+BH 3nQkXZJYx44y5O4Ecg2i+Ot/o4NkMeHt1huUt3Ta9xWS1oDE4xxnxv9nLi1fMiz+fg gTDxCMbeqBrE40WDsMNyY0q7dSI1smYCERZ4Yu90QgCDWLXKPbhXruL4vQ5q7c6ghF Kh202gJUduQJbMRw4dtq4zc9kqFUoYzm3Gu8j7fmVR8Zw97aAyM8hju0hETuBdIvTl jQFgNTThcLq+A== Received: from [192.168.1.4] (c-67-188-225-23.hsd1.ca.comcast.net [67.188.225.23]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OF1004J0SRGC920@mr11p00im-asmtp004.me.com>; Fri, 14 Oct 2016 17:33:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-14_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1610140313 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Fri, 14 Oct 2016 10:33:15 -0700 Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader From: Ravi Pokala Sender: "Pokala, Ravi" To: Doug Ambrisko , Warner Losh Cc: Doug Ambrisko , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Message-id: <3FF8A9D8-0C8A-4033-A7FC-8B64E9AB025F@panasas.com> Thread-topic: svn commit: r307326 - head/sys/boot/efi/loader References: <201610141710.u9EHArlL089412@repo.freebsd.org> <20161014172705.GA65545@ambrisko.com> In-reply-to: <20161014172705.GA65545@ambrisko.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 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: Fri, 14 Oct 2016 17:33:34 -0000 -----Original Message----- > From: on behalf of Doug Ambrisko > Date: 2016-10-14, Friday at 10:27 > To: Warner Losh > Cc: Doug Ambrisko , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader > > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote: > | Love the functionality, but don't like using the 'hint' namespace for > | this. Can we change it now before too many things depend on it? We had > | similar issues in ACPI and moved it to the 'acpi' space. Can we move > | this to the 'smbios' space please? > | > | The reason is that 'hint' is special and sometimes filtered out, so it > | is a poor choice to export data from the boot loader to the kernel. > > The reason I picked hint was it could be put /boot/device.hints > to make it work as well and that it was a hint. Other standards in the > future might use other methods. Looking back over the email I had > with John he had suggested hint.smbios.0.anchor to make this look > different. This code had been hanging around for so long I forgot > about that and we were using hint.smbios.0.mem in our shipping code base. > > However, I hope that nothing would use this except for smbios(4) and > for people to make smbios(4) useful for this info. Doug's looking at me when he says that. :-) We talked about this last night at BAFUG; right now, even if smbios(4) is able to find the SMBIOS info -- it currently only looks at the aforementioned 0xf0000 - 0xfffff range, so it can't find it on UEFI -- smbios(4) doesn't actually provide any interface for that information. Doug and I have talked about making smbios(4) useful, by parsing the data and providing KPIs and APIs, for years now; I think I'll *finally* have the time and motivation to do so "soon". -Ravi (rpokala@) > Thanks, > > Doug A.