From owner-freebsd-hackers@freebsd.org Sun May 26 00:20:29 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43A3315BA8B6 for ; Sun, 26 May 2019 00:20:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3886C69A06; Sun, 26 May 2019 00:20:27 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-67-180-169-236.hsd1.ca.comcast.net [67.180.169.236]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id x4Q0KQla011211 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 25 May 2019 17:20:26 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-67-180-169-236.hsd1.ca.comcast.net [67.180.169.236] claimed to be yv.noip.me Subject: Re: What is the portable 128-bit floating point type? To: Dimitry Andric , Konstantin Belousov Cc: Freebsd hackers list References: <20190525200437.GV2748@kib.kiev.ua> <20190525210311.GW2748@kib.kiev.ua> <3E0ACABC-D17B-45AD-9810-06ADA52F597A@FreeBSD.org> From: Yuri Message-ID: <6d9857d7-9624-2013-81e0-191c78ed3a4f@rawbw.com> Date: Sat, 25 May 2019 17:20:24 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3E0ACABC-D17B-45AD-9810-06ADA52F597A@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 3886C69A06 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of yuri@rawbw.com designates 198.144.192.42 as permitted sender) smtp.mailfrom=yuri@rawbw.com X-Spamd-Result: default: False [-4.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[236.169.180.67.zen.spamhaus.org : 127.0.0.10]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:198.144.192.32/27]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[rawbw.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx.rawbw.net]; NEURAL_HAM_SHORT(-0.89)[-0.894,0]; RCVD_IN_DNSWL_NONE(0.00)[42.192.144.198.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.76)[ip: (-5.44), ipnet: 198.144.192.0/19(-4.61), asn: 7961(-3.69), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 00:20:29 -0000 On 2019-05-25 14:30, Dimitry Andric wrote: > But from clang's OSTargets.h file, it looks like 128 bit float support > is never set to enabled for FreeBSD. If clang supports __float128, and clang is FreeBSD's main compiler, shouldn't it be enabled on FreeBSD then? Yuri From owner-freebsd-hackers@freebsd.org Sun May 26 10:02:37 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E26E91598402 for ; Sun, 26 May 2019 10:02:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85E0181C01; Sun, 26 May 2019 10:02:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 435021B2B9; Sun, 26 May 2019 10:02:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::e082:61e0:bde3:71aa] (unknown [IPv6:2001:470:7a58:0:e082:61e0:bde3:71aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 957753D8BC; Sun, 26 May 2019 12:02:34 +0200 (CEST) From: Dimitry Andric Message-Id: <6183B49B-76F2-4ABF-A6A2-D170C6164553@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D8F96939-0B14-4509-BACD-2E6C94BD62B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: What is the portable 128-bit floating point type? Date: Sun, 26 May 2019 12:02:34 +0200 In-Reply-To: <6d9857d7-9624-2013-81e0-191c78ed3a4f@rawbw.com> Cc: Konstantin Belousov , Freebsd hackers list To: Yuri References: <20190525200437.GV2748@kib.kiev.ua> <20190525210311.GW2748@kib.kiev.ua> <3E0ACABC-D17B-45AD-9810-06ADA52F597A@FreeBSD.org> <6d9857d7-9624-2013-81e0-191c78ed3a4f@rawbw.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 85E0181C01 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 10:02:37 -0000 --Apple-Mail=_D8F96939-0B14-4509-BACD-2E6C94BD62B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 May 2019, at 02:20, Yuri wrote: >=20 > On 2019-05-25 14:30, Dimitry Andric wrote: >> But from clang's OSTargets.h file, it looks like 128 bit float = support >> is never set to enabled for FreeBSD. >=20 >=20 > If clang supports __float128, and clang is FreeBSD's main compiler, = shouldn't it be enabled on FreeBSD then? It probably should, but those kinds of things don't just magically = appear out of thin air: Somebody(TM) has to do the actual work to implement the support, test it, maintain it, and so on. Apparently there has not yet been any great need for this floating point precision. Are you volunteering? :) -Dimitry P.S.: I believe one of the first requirements is a header. --Apple-Mail=_D8F96939-0B14-4509-BACD-2E6C94BD62B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXOpkOgAKCRCwXqMKLiCW o1hXAJwO6EeBoALAyO7monTPzU0jSJ5iPwCffFDr7hKsxd7GUC5W8ulNaXjoZC4= =NiLV -----END PGP SIGNATURE----- --Apple-Mail=_D8F96939-0B14-4509-BACD-2E6C94BD62B7-- From owner-freebsd-hackers@freebsd.org Sun May 26 11:58:57 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE11D15A3B73 for ; Sun, 26 May 2019 11:58:57 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 10C4084777 for ; Sun, 26 May 2019 11:58:55 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (artemis.db.net [45.32.229.41]) by artemis.db.net (Postfix) with ESMTP id AD8111023E; Sun, 26 May 2019 11:58:52 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id 4909939874; Sun, 26 May 2019 07:58:51 -0400 (EDT) Date: Sun, 26 May 2019 07:58:51 -0400 From: Diane Bruce To: Steve Kargl Cc: Konstantin Belousov , Yuri , Freebsd hackers list Subject: Re: What is the portable 128-bit floating point type? Message-ID: <20190526115851.GA65430@night.db.net> References: <20190525200437.GV2748@kib.kiev.ua> <20190525210311.GW2748@kib.kiev.ua> <20190525231310.GB56490@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190525231310.GB56490@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 10C4084777 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.585,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.00)[0.003,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1-us2.ppe-hosted.com]; NEURAL_SPAM_LONG(0.87)[0.871,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:20473, ipnet:45.32.224.0/21, country:US]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(0.00)[asn: 20473(0.07), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 11:58:57 -0000 On Sat, May 25, 2019 at 04:13:10PM -0700, Steve Kargl wrote: > On Sun, May 26, 2019 at 12:03:11AM +0300, Konstantin Belousov wrote: > > On Sat, May 25, 2019 at 01:50:24PM -0700, Yuri wrote: > > > On 2019-05-25 13:04, Konstantin Belousov wrote: ... > > On the other hand, I have no idea if any support is required from > > libgcc (probably it is), and we almost certainly do not have it in > > the base library. > > This is part of the problem with gfortran finding the wrong > libgcc_s.so. Regarding this see https://reviews.freebsd.org/D11482#423561 and https://wiki.freebsd.org/libgcc%20problem -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@freebsd.org Sun May 26 12:08:13 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 530C715A4DA3 for ; Sun, 26 May 2019 12:08:13 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7E36E850AF; Sun, 26 May 2019 12:08:12 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (artemis.db.net [45.32.229.41]) by artemis.db.net (Postfix) with ESMTP id B3728101B8; Sun, 26 May 2019 12:08:09 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id 5A5B239872; Sun, 26 May 2019 08:08:09 -0400 (EDT) Date: Sun, 26 May 2019 08:08:09 -0400 From: Diane Bruce To: Dimitry Andric Cc: Yuri , Konstantin Belousov , Freebsd hackers list , emaste@freebsd.org, cy@freebsd.org Subject: Re: What is the portable 128-bit floating point type? Message-ID: <20190526120809.GB65430@night.db.net> References: <20190525200437.GV2748@kib.kiev.ua> <20190525210311.GW2748@kib.kiev.ua> <3E0ACABC-D17B-45AD-9810-06ADA52F597A@FreeBSD.org> <6d9857d7-9624-2013-81e0-191c78ed3a4f@rawbw.com> <6183B49B-76F2-4ABF-A6A2-D170C6164553@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6183B49B-76F2-4ABF-A6A2-D170C6164553@FreeBSD.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 7E36E850AF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.88 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.66)[0.655,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.28)[0.282,0]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx1-us2.ppe-hosted.com]; NEURAL_SPAM_LONG(0.95)[0.954,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:20473, ipnet:45.32.224.0/21, country:US]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[asn: 20473(0.07), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 12:08:13 -0000 On Sun, May 26, 2019 at 12:02:34PM +0200, Dimitry Andric wrote: > On 26 May 2019, at 02:20, Yuri wrote: > > > > On 2019-05-25 14:30, Dimitry Andric wrote: > >> But from clang's OSTargets.h file, it looks like 128 bit float support > >> is never set to enabled for FreeBSD. > > > > > > If clang supports __float128, and clang is FreeBSD's main compiler, shouldn't it be enabled on FreeBSD then? > > It probably should, but those kinds of things don't just magically appear > out of thin air: Somebody(TM) has to do the actual work to implement the > support, test it, maintain it, and so on. Apparently there has not yet > been any great need for this floating point precision. > > Are you volunteering? :) I've been slowly looking at it already in my copious spare time. It's really something we should be supporting. The libgcc_s wrong version problem is being dealt with by others by linking gfortran with a static version of libgcc_s (!). (As discussed with Cy at BSDCan 2019) See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120#c24 specifically comment 35 > > -Dimitry > > P.S.: I believe one of the first requirements is a header. > - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@freebsd.org Sun May 26 15:39:29 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1363D15A9A72 for ; Sun, 26 May 2019 15:39:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9291F8B2B8 for ; Sun, 26 May 2019 15:39:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x4QFdIuj060683 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 26 May 2019 08:39:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x4QFdGxQ060682; Sun, 26 May 2019 08:39:16 -0700 (PDT) (envelope-from sgk) Date: Sun, 26 May 2019 08:39:16 -0700 From: Steve Kargl To: Diane Bruce Cc: Konstantin Belousov , Yuri , Freebsd hackers list Subject: Re: What is the portable 128-bit floating point type? Message-ID: <20190526153916.GA60618@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190525200437.GV2748@kib.kiev.ua> <20190525210311.GW2748@kib.kiev.ua> <20190525231310.GB56490@troutmask.apl.washington.edu> <20190526115851.GA65430@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190526115851.GA65430@night.db.net> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 9291F8B2B8 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.70 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_HAM_SHORT(-0.25)[-0.251,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.51)[-0.512,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.78)[0.780,0]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.14), country: US(-0.06)]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 15:39:29 -0000 On Sun, May 26, 2019 at 07:58:51AM -0400, Diane Bruce wrote: > On Sat, May 25, 2019 at 04:13:10PM -0700, Steve Kargl wrote: > > On Sun, May 26, 2019 at 12:03:11AM +0300, Konstantin Belousov wrote: > > > On Sat, May 25, 2019 at 01:50:24PM -0700, Yuri wrote: > > > > On 2019-05-25 13:04, Konstantin Belousov wrote: > ... > > > On the other hand, I have no idea if any support is required from > > > libgcc (probably it is), and we almost certainly do not have it in > > > the base library. > > > > This is part of the problem with gfortran finding the wrong > > libgcc_s.so. > > Regarding this see https://reviews.freebsd.org/D11482#423561 > and https://wiki.freebsd.org/libgcc%20problem > I was aware of the latter wiki page. The former is interesting. I wasn't aware of the former. Nice to see someone(s) taking an interest in the missing libgcc_s.so symbols. Seems that my efforts [1] to track the symbols missing for gfortran may have paiid off. [1] https://lists.freebsd.org/pipermail/freebsd-ports/2019-February/115593.html -- Steve From owner-freebsd-hackers@freebsd.org Sun May 26 22:55:52 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5948315B312F for ; Sun, 26 May 2019 22:55:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0963271F30; Sun, 26 May 2019 22:55:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id V20ih6aEtldkPV20jh7vsn; Sun, 26 May 2019 16:53:03 -0600 X-Authority-Analysis: v=2.3 cv=Ko4zJleN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=E5NmQfObTbMA:10 a=PDjUHgQ1AAAA:8 a=FnIUHYMPAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=lBi6uGXonejG0e1VBfcA:9 a=CjuIK1q_8ugA:10 a=bRK04h3HnY3C5mYB2GCI:22 a=U794neO1_LHRLYKJrBZ3:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 9D244B9D; Sun, 26 May 2019 15:52:59 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x4QMqwLb044742; Sun, 26 May 2019 15:52:58 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x4QMquSw044739; Sun, 26 May 2019 15:52:57 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201905262252.x4QMquSw044739@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Diane Bruce cc: Dimitry Andric , Yuri , Konstantin Belousov , Freebsd hackers list , emaste@freebsd.org, cy@freebsd.org Subject: Re: What is the portable 128-bit floating point type? In-Reply-To: Message from Diane Bruce of "Sun, 26 May 2019 08:08:09 -0400." <20190526120809.GB65430@night.db.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 May 2019 15:52:56 -0700 X-CMAE-Envelope: MS4wfL7zM5O5iwEp5t1r9pPPfIK9UmYRtJcGgGbYkZwJdSYqi93oZDXijcWwXe6ouy/TR63D9WV9TPGIF6yZQXuHG6KjI6xiJ2EykTAIlVzG19iV7KH8AolO y0YFLtnNPCxfhsUFqLGLuOhOL3n0sCZhWtLmCghM2SI7DzOZalKq71T/1Sooc2gltxZzwImYo/SVTPNKhId5HHH166iKenlS2I/BlwzObALalDORFPL6mVzC odF8M7jmmHKnr8ma6xz4nugPKfiKoAa48YAvR+m+05nSn96WsrYxconXpft70XppQME7a3QayM8M9b99dKq2yikqUr/44ghnNeWNVeDwLK8= X-Rspamd-Queue-Id: 0963271F30 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.86)[-0.860,0]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; SUBJECT_ENDS_QUESTION(1.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.51)[ip: (-6.74), ipnet: 64.59.128.0/20(-3.25), asn: 6327(-2.50), country: CA(-0.09)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 22:55:52 -0000 In message <20190526120809.GB65430@night.db.net>, Diane Bruce writes: > On Sun, May 26, 2019 at 12:02:34PM +0200, Dimitry Andric wrote: > > On 26 May 2019, at 02:20, Yuri wrote: > > > > > > On 2019-05-25 14:30, Dimitry Andric wrote: > > >> But from clang's OSTargets.h file, it looks like 128 bit float support > > >> is never set to enabled for FreeBSD. > > > > > > > > > If clang supports __float128, and clang is FreeBSD's main compiler, shoul > dn't it be enabled on FreeBSD then? > > > > It probably should, but those kinds of things don't just magically appear > > out of thin air: Somebody(TM) has to do the actual work to implement the > > support, test it, maintain it, and so on. Apparently there has not yet > > been any great need for this floating point precision. > > > > Are you volunteering? :) > > I've been slowly looking at it already in my copious spare time. > It's really something we should be supporting. The libgcc_s wrong version > problem is being dealt with by others by linking gfortran with a static > version of libgcc_s (!). (As discussed with Cy at BSDCan 2019) > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120#c24 > specifically comment 35 My thoughts were that the base libgcc_s should have a different name so as not to be confused with the real libgcc_s from ports. > > > > > -Dimitry > > > > P.S.: I believe one of the first requirements is a header. > > > > - Diane > -- > - db@FreeBSD.org db@db.net http://www.db.net/~db -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Mon May 27 14:32:04 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AE30159829C for ; Mon, 27 May 2019 14:32:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8C106F6F5; Mon, 27 May 2019 14:32:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-vs1-xe41.google.com with SMTP id z11so10659366vsq.9; Mon, 27 May 2019 07:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Fg0lgS4zhvfac/k27bd5Kn5PT5y+wQSPk8PwouWm3Ns=; b=kvojdgm4NyhSlmjuPq33xdZqr+ghXwa+4VkEePOH8Hdw3xtzYQ8i7qonJya7mQsjw8 P5y5scZLXFOhFq7f/IqQkFdET9fWmI2YL+Khtq0r1j+epiS56kSwgs+A/XK8Vlvh9kIq AWSTytu/einj4kVAEd81+zK7ycQW+OexFBsmqk/Rpw5sovX/AlEu7mvQThKOEVXAawx4 N3ol5k/f/aocCdGe2kypOY0mbeGw+FaeDn2TBeJCHe6gZpJt+bWP3WvrnEVF+J37SeNH StcprZBSkl7oXtFYSo2lNM3vdineWvI40AtFuTZjPABGBDNVKDK0GVCuRlZjUFDyWge1 v0pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Fg0lgS4zhvfac/k27bd5Kn5PT5y+wQSPk8PwouWm3Ns=; b=fDJP5R1nQhkOlmnzqcYqSWM07BZKeaHgguYdauxoYV1hVL7LPEXPVpb+rty7sjTwDq PTbPKsEZiiPqbS6jgzUSrAsvRX1TbmxK+Bc6MuBThhWs+TkdWtsRwfgv2/VTR73UfYFH t0f00KSul9rCyWwY6RyVmy2DY8XuRGXHrGbjKb3dBqJx+fevEdUANWXmfEV4LFQaya3M rmsaOQGoa9SOvEkJNZYwOU6zkgEsiXwezNf4LmazmpcEePUNT5jci/ln0WtChggh4fkd llGY/O7wOsitL2vqQwW3VnXyolxGY2h/yXiOGDZtKYjUEzKLf7CYYqO2ChO0eGWHjixo gFDg== X-Gm-Message-State: APjAAAUbzWY2nujyQOxr0Q69D/3VV762O5VacJOtl0nEtqPjALcGlI3U BGgGlt5yXt+60GZ1fJvXxUHc1MVA X-Google-Smtp-Source: APXvYqxnIP3v5jjaG0H+I6hHdIqDC6oidJkgsrZL3PnFAAh+fEHNRPsO76v3/v1VUv8VRKWdoPIfXg== X-Received: by 2002:a67:2e15:: with SMTP id u21mr42839819vsu.50.1558967523210; Mon, 27 May 2019 07:32:03 -0700 (PDT) Received: from raichu (toroon0560w-lp130-12-70-50-22-99.dsl.bell.ca. [70.50.22.99]) by smtp.gmail.com with ESMTPSA id e76sm12136054vke.54.2019.05.27.07.32.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 27 May 2019 07:32:02 -0700 (PDT) Sender: Mark Johnston Date: Mon, 27 May 2019 10:31:57 -0400 From: Mark Johnston To: Cy Schubert Cc: freebsd-hackers@freebsd.org, rmacklem@freebsd.org Subject: Re: DTrace instrumentation build error Message-ID: <20190527143157.GA82831@raichu> References: <20190524145650.GB72269@raichu> <201905252142.x4PLgmEo098646@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201905252142.x4PLgmEo098646@slippy.cwsent.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: B8C106F6F5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=kvojdgm4; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::e41 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[1.4.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; IP_SCORE(-0.54)[ip: (2.94), ipnet: 2607:f8b0::/32(-3.30), asn: 15169(-2.29), country: US(-0.06)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 14:32:04 -0000 On Sat, May 25, 2019 at 02:42:48PM -0700, Cy Schubert wrote: > In message <20190524145650.GB72269@raichu>, Mark Johnston writes: > > On Fri, May 24, 2019 at 05:55:51AM -0700, Cy Schubert wrote: > > > Hi, > > > > > > I'm helping rmacklem@ with instrumentation of mountd with USDT > > > probes.It builds fine on amd64 however fails on i386 > > > > > > ===> sbin/sconfig (all) > > > ld: error: cannot open /usr/lib32/dtrace/drti.o: No such file or > > > directory > > > dtrace: failed to link script /home/cy/stable12/usr.sbin/mountd/mountd_d > > > t.d: fai > > > led to link mountd_dt.o: ld exited with status 1 > > > --- mountd_dt.o --- > > > *** [mountd_dt.o] Error code 1 > > > > > > make[6]: stopped in /home/cy/stable12/usr.sbin/mountd > > > 1 error > > > > > > make[6]: stopped in /home/cy/stable12/usr.sbin/mountd > > > --- all_subdir_usr.sbin/mountd --- > > > *** [all_subdir_usr.sbin/mountd] Error code 2 > > > > > > A couple of interesting things here: > > > > > > 1. /usr/lib32/dtrace/drti.o doesn't exist in the universe12a and > > > universe12b jails. > > > > /usr/lib32 is entirely missing in those jails. > > > > > 2. Why would buildworld (tinderbox in this case) link against an object > > > outside of /usr/obj? > > > > It is simply dtrace(1)'s default behaviour. I believe this patch is > > sufficient to fix the problem for both native and 32-bit compat builds. > > I think it is a bit too hacky though: we should probably only add > > -x libdir during a world build. A standalone make -C usr.sbin/mountd > > should use the host drti.o. What's the right predicate for that? > > > > diff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk > > index 5d0aac91f1b4..ce008fdba324 100644 > > --- a/share/mk/bsd.dep.mk > > +++ b/share/mk/bsd.dep.mk > > @@ -147,6 +147,9 @@ OBJS_DEPEND_GUESS.${_YC:R}.o+= ${_YC} > > # DTrace probe definitions > > .if ${SRCS:M*.d} > > CFLAGS+= -I${.OBJDIR} > > +.if exists(${OBJTOP}/cddl/lib/drti/drti.o) > > +DTRACEFLAGS+= -x libdir=${OBJTOP}/cddl/lib/drti > > +.endif > > .endif > > .for _DSRC in ${SRCS:M*.d:N*/*} > > .for _D in ${_DSRC:R} > > Thanks Mark. I'll run another tinderbox with this. > > Wouldn't -L also work? Yes, -L and -x libdir are synonyms. > incdir will also need updating. I'm not sure why. dtrace should probably get whatever include paths are defined in CFLAGS. > My initial thoughts were to add a -R option implementing --sysroot. I don't see why it's needed. From owner-freebsd-hackers@freebsd.org Mon May 27 15:13:58 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFDD9159F813; Mon, 27 May 2019 15:13:57 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEBE70EF8; Mon, 27 May 2019 15:13:57 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 61C5611BE; Mon, 27 May 2019 15:13:50 +0000 (UTC) To: FreeBSD Current , "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: FreeBSD and Coreboot Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXMXabRYJKwYBBAHaRw8BAQdAJ2yzSUUR7u7H/bLAFOzhPII7vvJ45zQeB60TxyCoio20 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiWBBMWCAA+FiEEG/v8wt9b D9+AxsV/6Y4m2LfgVbIFAlzF2m0CGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ6Y4m2LfgVbJ9mwD/YpSeQ5F9gpvKFS5Bs5w1Bw7zTOfO7zJQrh9NzDbWtd0BAOSGr/i5 zJer2pAjwambsyU0bhgHNy9IDQ7AGnidIyMHuDgEXMXabRIKKwYBBAGXVQEFAQEHQEBwYuBK iJPJEDtS6hbLgcDSUSbfUNA2rGp3TJ1G+7EqAwEIB4h+BBgWCAAmFiEEG/v8wt9bD9+AxsV/ 6Y4m2LfgVbIFAlzF2m0CGwwFCQHhM4AACgkQ6Y4m2LfgVbJ2kwEAlJj1z3zRJm3mmi6N81by nuwAxk3qcKa67WX2/F3C4soA/iwVuPMnx5RWaoX3i2eKXVNzNwzvTFfeGKxfQBOzMocM Message-ID: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> Date: Mon, 27 May 2019 11:13:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3TIj6TfZlOozBpG1IFXlam5oyFEhyFrxE" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 15:13:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3TIj6TfZlOozBpG1IFXlam5oyFEhyFrxE Content-Type: multipart/mixed; boundary="6htyX95lFWE5crKa5A6cQDnuT8DXDN3WK"; protected-headers="v1" From: Eric McCorkle To: FreeBSD Current , "freebsd-hackers@freebsd.org" Message-ID: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> Subject: FreeBSD and Coreboot --6htyX95lFWE5crKa5A6cQDnuT8DXDN3WK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello everyone, I'm through enough of my job change that I can start working on FreeBSD again. One thing I've had on my list to examine is using FreeBSD with coreboot, so I wanted to put out a call for anyone who has done work on this, or knows anything about it. Here is what I know: * Coreboot _can_ boot kernels directly, but this requires two things: 1) you must flash your BIOS every time you update a kernel, 2) the kernel must be able to work without the usual device initialization that the BIOS does. * Coreboot has two significant payload options beyond a kernel: Seabios and GRUB (supposedly Tianocore EFI is an option, but it apparently doesn't really work). * Scrounging the coreboot wiki seems to produce some conflicting information. One page claims that the FreeBSD kernel can boot directly as a coreboot payload; another claims GRUB or Seabios to be the only options. * The PC Engines boards evidently use coreboot, and I've heard multiple reports of them running FreeBSD systems without a problem. I don't know whether they use GRUB or Seabios. (Aside: I'm thinking about ordering some of these boards for my own use, so I'm generally interested in how well they function with FreeBSD) My plan is roughly this: * Refurbish the GRUB port, get it working again in QEMU (possibly on one of my machines), also possibly push a patch to GRUB to use the keybufs mechanism to pass in GELI keys. * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU * Possibly create a coreboot port (uncertain how this would work, since Coreboot has its own extensive config menu) * Hold my breath and test it out on real hardware (I have a Librem 13 r1 for this purpose) * Possibly try getting the FreeBSD kernel to work as a coreboot payload. Here's what I don't know/what would be useful knowledge for me: * Anyone else who's been experimenting/working on coreboot support, and what they found * Any working examples of using Coreboot with FreeBSD * Down the road, anything about adapting the FreeBSD kernel to work with a new boot platform (ie. low level details about how to set it up in memory on a bare-metal system and start execution) --6htyX95lFWE5crKa5A6cQDnuT8DXDN3WK-- --3TIj6TfZlOozBpG1IFXlam5oyFEhyFrxE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQb+/zC31sP34DGxX/pjibYt+BVsgUCXOv+rQAKCRDpjibYt+BV skEKAQCUHfKPzTGFHmB6FQqdpmeMwEwelIuKtVa8/evNB0m6tAD/aj1/ZhwbUo6Y BlaR2LtGUbXwigNgDqr0KoufJQkkWQg= =A08d -----END PGP SIGNATURE----- --3TIj6TfZlOozBpG1IFXlam5oyFEhyFrxE-- From owner-freebsd-hackers@freebsd.org Mon May 27 15:18:58 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A09C5159FC5F for ; Mon, 27 May 2019 15:18:58 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12A507129A for ; Mon, 27 May 2019 15:18:58 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-vs1-xe42.google.com with SMTP id q64so10773511vsd.1 for ; Mon, 27 May 2019 08:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vKK7tgehwjOFBLNF6c1a2oDiro+bV+eGUcpTyZwq+Fo=; b=R1ZREN6hmNhXc1/xZ7QeBAIdQcXN8PJkDzfcQ6+i0C5hdbPaYSRXjC74aRQzi46tao O293P13DnmcPhLeXuLyYMI0jBUhz8kNN58T7cHkCPZVegGpkllxYLMO3BFtcG919NY1+ YoixhZUn8HCnTHYKAme6Gz+symmNnTCoI2eyplPM4lfE1TOkAzkeHBARueNCfUP/KzRA L+wmqH2TO4RyFS6HAnYdMDiDGKeP82Xi4tKs/PCQmNF0jSeBdIa/2aTqkFJTu6r7Ly8I /DuqxyaWtGU/k7fXkkoHoiqy7QFlSBdk2BrxRNDC8/N8uXDVNl4KE3ufhFuS/yuZJKXF UJMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vKK7tgehwjOFBLNF6c1a2oDiro+bV+eGUcpTyZwq+Fo=; b=JXx6PSKJIG/cG+VozHXqlCTXw5Bb9oFrfKRaesOe1rlgXNC/KOnyddJo646SAfBKAM rSsvwlp+mAYbzVaV3ZnDQrGvTzUzvJoCvjxy+C76Uksnnl8bH8ZE/mQRvHAdYD2gDGno Ktt06BGo9UkjvZ3W2qnncrGgOd2Ns2ypTNHTa7Oyt1eP0EilaMBu+RlvQzShjWsRJjQm gpNZqCLMoC6AsuY8E1ngue6c+JDjyG0q080B51fu2ruqeToJIxjAe/WbJvmOQ6GJ/G1P x4O/SW8n35R02A6qTpVzVgiEVghQ/BJaIIVI2PilfYZG4+/N81a1vMO0eq/sI6gcKg2a agkQ== X-Gm-Message-State: APjAAAVzHAQ+hI6m11F31iV0y5QAO3VTkWHVPzG1P2T9Nbm8KDOK9FNc OWDYoqCL00sJjGvZWLaNs/yr8FMfrPg= X-Google-Smtp-Source: APXvYqww/cdCpJHZoYqrsviq/z1CpsXYLdR6qLFQQI4pwqTfnc1uh/OgtUPMVXiiEiCvD30ioPHrvA== X-Received: by 2002:a67:db88:: with SMTP id f8mr35791378vsk.14.1558970337256; Mon, 27 May 2019 08:18:57 -0700 (PDT) Received: from mutt-hbsd ([151.196.118.239]) by smtp.gmail.com with ESMTPSA id n23sm9775238vsj.27.2019.05.27.08.18.56 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 27 May 2019 08:18:56 -0700 (PDT) Date: Mon, 27 May 2019 11:18:55 -0400 From: Shawn Webb To: Eric McCorkle Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD and Coreboot Message-ID: <20190527151855.iqbkedo7r6n5hgab@mutt-hbsd> References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jo3orqfnivhqnbvw" Content-Disposition: inline In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD HARDENEDBSD-13-CURRENT amd64 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 12A507129A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 15:18:58 -0000 --jo3orqfnivhqnbvw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Eric, My response is inline. On Mon, May 27, 2019 at 11:13:46AM -0400, Eric McCorkle wrote: > Hello everyone, >=20 > I'm through enough of my job change that I can start working on FreeBSD > again. One thing I've had on my list to examine is using FreeBSD with > coreboot, so I wanted to put out a call for anyone who has done work on > this, or knows anything about it. >=20 > Here is what I know: >=20 > * Coreboot _can_ boot kernels directly, but this requires two things: 1) > you must flash your BIOS every time you update a kernel, 2) the kernel > must be able to work without the usual device initialization that the > BIOS does. >=20 > * Coreboot has two significant payload options beyond a kernel: Seabios > and GRUB (supposedly Tianocore EFI is an option, but it apparently > doesn't really work). >=20 > * Scrounging the coreboot wiki seems to produce some conflicting > information. One page claims that the FreeBSD kernel can boot directly > as a coreboot payload; another claims GRUB or Seabios to be the only > options. >=20 > * The PC Engines boards evidently use coreboot, and I've heard multiple > reports of them running FreeBSD systems without a problem. I don't know > whether they use GRUB or Seabios. (Aside: I'm thinking about ordering > some of these boards for my own use, so I'm generally interested in how > well they function with FreeBSD) I own several PC Engines APU boards. They definitely use Coreboot as maintained by these peeps: https://twitter.com/3mdeb_com The Coreboot for the APU boards uses Seabios. >=20 >=20 > My plan is roughly this: >=20 > * Refurbish the GRUB port, get it working again in QEMU (possibly on one > of my machines), also possibly push a patch to GRUB to use the keybufs > mechanism to pass in GELI keys. >=20 > * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU >=20 > * Possibly create a coreboot port (uncertain how this would work, since > Coreboot has its own extensive config menu) >=20 > * Hold my breath and test it out on real hardware (I have a Librem 13 r1 > for this purpose) >=20 > * Possibly try getting the FreeBSD kernel to work as a coreboot payload. >=20 >=20 > Here's what I don't know/what would be useful knowledge for me: >=20 > * Anyone else who's been experimenting/working on coreboot support, and > what they found >=20 > * Any working examples of using Coreboot with FreeBSD >=20 > * Down the road, anything about adapting the FreeBSD kernel to work with > a new boot platform (ie. low level details about how to set it up in > memory on a bare-metal system and start execution) >=20 Reach out to 3mdeb (feel free to CC me, if you'd like). See what they'd like help with. There's certainly a lot more work that could be done. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 --jo3orqfnivhqnbvw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAlzr/9oACgkQ/y5nonf4 4fpd6A/+Lwya5qx8dlQbXbI+4qqcT44EzRPe9llW0kmJIaktgi5cJoQcUHBpmdOQ 5ToHGHBQavTnhlj3DueIFfxiV2jru45VDPJMWcf3TYGrmair/E43a85pN2gAoCRy hjH+8QVTi6NdSu6hynXCkMwBioJb/21X8NwtYuHtdZ3KD64L7P6+k9V5BvO5ZKWS 4HrCAtep26Bi+JBfvG3v5VDFHokxmhB1VvxbH0+6EIpwOtOu13GLOPAW+sxINuHY xJZEuMVY8x9aFjAjVcFVGXMuauGW5IJ0EdDtciCTIVumksWuwYExAARMe1YgdQC/ NIMVO6hFplYFS6798pqCHx9bkeVsHoJquMAF51LKTEN+K7YgKV9OdyAc2fy4XIrz UxctKrA0ggE4wgHUtqaS+oTRqRtrZJ3XfPSyyzat7DOB6ymICnb0CQSuK0MQAY/m imA6oUHZL9OMSnNtVuB/+/u3FSEbDAPt1hfSmVRJc4H3NLS9Asfcur2nhGl38hIt dCaNlTXt3kt9kMJaD0RAbL7dpvSUY5XtuWEKyVmsvnt4LZ/9UXapHG/xYyH2b8uI GPjz+uKxQvs03N22k9H69j2o3YMOCe5f0NNc+tuoaWUmg2HmW/Vapg+q/RSHcHTe VrzlGVWNdYpTedxvewcv9dVGGOmaXl/Tr7ap07MrD5FuLy4nghM= =UF4R -----END PGP SIGNATURE----- --jo3orqfnivhqnbvw-- From owner-freebsd-hackers@freebsd.org Mon May 27 15:24:00 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96CD915A3258 for ; Mon, 27 May 2019 15:24:00 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 527CE719AF for ; Mon, 27 May 2019 15:23:59 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f53.google.com with SMTP id h13so12356202lfc.7 for ; Mon, 27 May 2019 08:23:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=3/mKIfrUuqobHFvIPqURcWbEEMupwCDx5nPj8F/qEhU=; b=ijl9wxr9cDBpUkBWKr5nKobAYhZk+2r35Iexn22VH0CClYVgYhEAhWtcZi9WT0Hn8+ HmSUJ+alkAdyVLBd7tnlL2PU1HF9A/ykk/ZaUUpsrjk7JLWYY+uuy4g4nGMvqwF8SMUb 2iVIgN8sykEkzl7RCSG/XUJP9266iJg8ZMTPqDL8l4aBoLqV7ETKMjWFhATZ7ixIPa/K cfkblfdU1wtxoJ13R+xI4VsWB+8S4rNR86kGXa8G4dzyb+2XHKk2ka8uvIKLo/qogmb1 rZ8+2dlcVcIH5sX0/PvPf6I3SRGTn82ftVF32ZQbwbfwl4LQKqKKenjtGvi7ur8tNpy6 50pw== X-Gm-Message-State: APjAAAVcG3+I7j2U4lcCX+tz3fBdQn2mwIcJoMAu4ia9xQzXucj53M+4 J6En9cj80G+R4kenUxbxdUxXmIIX X-Google-Smtp-Source: APXvYqxzV8qlBpa0FDKhhURcqaGOCUsKCDDv9lvNlAuIUdqKODrOUBjIrKVXUJQ3qIicge4lD0fOXg== X-Received: by 2002:a19:d1cb:: with SMTP id i194mr58655622lfg.13.1558970267329; Mon, 27 May 2019 08:17:47 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id c10sm2334412lfh.79.2019.05.27.08.17.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 08:17:46 -0700 (PDT) To: FreeBSD Hackers From: Andriy Gapon Subject: gpio interrupt on x86 Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> Date: Mon, 27 May 2019 18:17:45 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 527CE719AF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.93)[-0.934,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.26)[ip: (-0.56), ipnet: 209.85.128.0/17(-3.40), asn: 15169(-2.29), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[53.167.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 15:24:00 -0000 I would like to run some code when an input pin changes its state. A GPIO controller that handles that pin is capable of generating an interrupt. I can configure the type of a signal change that would trigger the interrupt. The GPIO controller would generate the interrupt on that change. I would be able to query the controller for a specific pin (if interrupts for multiple pins are enabled). All is good. Now, the question is how to _properly_ hook my code to the gpiobus hanging off the controller. I see that embedded (or not so embedded) platforms typically define a "slave" interrupt controller. I guess that it defines a new interrupt number (and interrupt source, etc) for each interrupt capable pin. And then hooking to that pin is a matter of just installing an interrupt handler for a specific interrupt and enabling it. But I am not sure if the same approach would work on x86. Is there any other alternative approach? Perhaps even a more light-weight one? Any code examples? Thank you. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon May 27 16:25:14 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB2EA15A4B2F; Mon, 27 May 2019 16:25:14 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56E9A73882; Mon, 27 May 2019 16:25:14 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.92 (FreeBSD)) (envelope-from ) id 1hVIR1-000Feb-KY; Mon, 27 May 2019 18:25:15 +0200 Date: Mon, 27 May 2019 18:25:15 +0200 From: Kurt Jaeger To: Eric McCorkle Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD and Coreboot Message-ID: <20190527162515.GH72200@home.opsec.eu> References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 16:25:15 -0000 Hi! > * The PC Engines boards evidently use coreboot, and I've heard multiple > reports of them running FreeBSD systems without a problem. I have approx. 130 of the PC Engines APUs in varius versions up until the most recent, running with FreeBSD just fine. No special setup, just the generic coreboot firmware. Well, they had some issues with 12.0-REL booting from USB sticks Booting 11.2 sticks, installing and upgrading works fine. Did not test more recent firmware. This worked to reflash the BIOS to their most recent versions: Source of the BIOS: https://pcengines.github.io/ I used flashrom -w apu4_v4.9.0.5.rom --programmer internal to upgrade: Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. /usr/local/bin/flashrom was installed by package flashrom-1.0_1 -- pi@opsec.eu +49 171 3101372 One year to go ! From owner-freebsd-hackers@freebsd.org Mon May 27 17:19:48 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E063115A61A8; Mon, 27 May 2019 17:19:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from smh-06.1blu.de (smh-06.1blu.de [178.254.0.206]) (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 7EFDC75C58; Mon, 27 May 2019 17:19:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [172.16.29.5] (helo=sh4-5.1blu.de) by smh-06.1blu.de with esmtp (Exim 4.86_2) (envelope-from ) id 1hVJHd-0000wn-VN; Mon, 27 May 2019 19:19:38 +0200 Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.86_2) (envelope-from ) id 1hVJHd-0007UO-R4; Mon, 27 May 2019 19:19:37 +0200 Date: Mon, 27 May 2019 19:19:37 +0200 From: Matthias Apitz To: Eric McCorkle Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD and Coreboot Message-ID: <20190527171937.GA27133@sh4-5.1blu.de> Reply-To: Matthias Apitz Mail-Followup-To: Eric McCorkle , FreeBSD Current , "freebsd-hackers@freebsd.org" References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 7EFDC75C58 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 17:19:49 -0000 El día Monday, May 27, 2019 a las 11:13:46AM -0400, Eric McCorkle escribió: > Hello everyone, > > I'm through enough of my job change that I can start working on FreeBSD > again. One thing I've had on my list to examine is using FreeBSD with > coreboot, so I wanted to put out a call for anyone who has done work on > this, or knows anything about it. Hello Eric, I don't know if this is something which has to do with your project. Since 2015 I use an Acer C720 Chromebook with FreeBSD (CURRENT) this has AFAIK coreboot with SeaBIOS and works just fine. Just to let you know. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators! From owner-freebsd-hackers@freebsd.org Mon May 27 22:01:25 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECFC915AC577; Mon, 27 May 2019 22:01:24 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89DE5886B5; Mon, 27 May 2019 22:01:24 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id t24so15910049otl.12; Mon, 27 May 2019 15:01:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qXMSqqMbSE2mwi/e2dY2kunlogGixg4YbG4sZipczio=; b=BAkvVmhi5ZKCN+Ace3vL/JCIiS/iwSXmMBNIBDkoruWrGc5vUF6ON7PdvpV1NsrNOw 9ZrgMDpsDvG2R2q/RAsnQJqZEqJxPFxjWOJeUkQm3QN3k+p8ueQylh/Lqn7MOFVlsPam EW+rLis5eJM5Os2hFm7iOcWIRXezazKhukWCFLI8RrAjcZs+cXWO1D1MHxnEIYr3OEeL q6zl74gmXIomufEB0fDZBYSR3ilejX3mzBfLI9v9fRaF3N0lVD/FSY6Z2QfP/WJeek79 9LkW4eVJDxi6yXe5gPupD3RbbXLa9m9vlMrA8AOAuM+lTley57elejLC39PPIdmyGBZC kHig== X-Gm-Message-State: APjAAAXHVA6MYrm3OAIrDGZfCTUgteK7bcyhxqq+UVH5ysU5Hx+FJE1s K9hdtg7seh6XQyQ+4PqkPNstxPwlp94TChWZgkI= X-Google-Smtp-Source: APXvYqwg/8pzPsFcTF1ZTXhOGkhcNtJdaGFLRymLlUYYqigcdVw1lMgQW+QQjYB4KKxv+TpKHgmpKN21Cr+eie9ItS4= X-Received: by 2002:a9d:7d9a:: with SMTP id j26mr14776408otn.102.1558994034336; Mon, 27 May 2019 14:53:54 -0700 (PDT) MIME-Version: 1.0 References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> From: Edward Napierala Date: Mon, 27 May 2019 22:53:42 +0100 Message-ID: Subject: Re: FreeBSD and Coreboot To: Eric McCorkle Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 89DE5886B5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 22:01:25 -0000 On Mon, 27 May 2019 at 16:14, Eric McCorkle wrote: [..] > My plan is roughly this: > > * Refurbish the GRUB port, get it working again in QEMU (possibly on one > of my machines), also possibly push a patch to GRUB to use the keybufs > mechanism to pass in GELI keys. > > * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > > * Possibly create a coreboot port (uncertain how this would work, since > Coreboot has its own extensive config menu) > > * Hold my breath and test it out on real hardware (I have a Librem 13 r1 > for this purpose) > > * Possibly try getting the FreeBSD kernel to work as a coreboot payload. Out of curiosity - why the kernel and not loader(8)? From owner-freebsd-hackers@freebsd.org Mon May 27 22:50:51 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 592E015AD6B6; Mon, 27 May 2019 22:50:51 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (static-108-31-38-18.washdc.fios.verizon.net [108.31.38.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE468A437; Mon, 27 May 2019 22:50:50 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 2BB70128F; Mon, 27 May 2019 22:50:49 +0000 (UTC) To: Edward Napierala Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXMXabRYJKwYBBAHaRw8BAQdAJ2yzSUUR7u7H/bLAFOzhPII7vvJ45zQeB60TxyCoio20 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiWBBMWCAA+FiEEG/v8wt9b D9+AxsV/6Y4m2LfgVbIFAlzF2m0CGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ6Y4m2LfgVbJ9mwD/YpSeQ5F9gpvKFS5Bs5w1Bw7zTOfO7zJQrh9NzDbWtd0BAOSGr/i5 zJer2pAjwambsyU0bhgHNy9IDQ7AGnidIyMHuDgEXMXabRIKKwYBBAGXVQEFAQEHQEBwYuBK iJPJEDtS6hbLgcDSUSbfUNA2rGp3TJ1G+7EqAwEIB4h+BBgWCAAmFiEEG/v8wt9bD9+AxsV/ 6Y4m2LfgVbIFAlzF2m0CGwwFCQHhM4AACgkQ6Y4m2LfgVbJ2kwEAlJj1z3zRJm3mmi6N81by nuwAxk3qcKa67WX2/F3C4soA/iwVuPMnx5RWaoX3i2eKXVNzNwzvTFfeGKxfQBOzMocM Subject: Re: FreeBSD and Coreboot Message-ID: <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> Date: Mon, 27 May 2019 18:50:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9ECAOtpg9rw2jdh2m5vI63HP0iDzOZsig" X-Rspamd-Queue-Id: 6EE468A437 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-1.79 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.94)[0.940,0]; NEURAL_HAM_LONG(-0.87)[-0.874,0]; IP_SCORE(0.25)[asn: 701(1.29), country: US(-0.06)]; MX_GOOD(-0.01)[mail.metricspace.net]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:701, ipnet:108.31.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 22:50:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9ECAOtpg9rw2jdh2m5vI63HP0iDzOZsig Content-Type: multipart/mixed; boundary="V8N54xAkborfrU9cp4VGzVm42fljY09MH"; protected-headers="v1" From: Eric McCorkle To: Edward Napierala Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Message-ID: <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> Subject: Re: FreeBSD and Coreboot References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> In-Reply-To: --V8N54xAkborfrU9cp4VGzVm42fljY09MH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/27/19 5:53 PM, Edward Napierala wrote: > On Mon, 27 May 2019 at 16:14, Eric McCorkle wrot= e: >=20 > [..] >=20 >> My plan is roughly this: >> >> * Refurbish the GRUB port, get it working again in QEMU (possibly on o= ne >> of my machines), also possibly push a patch to GRUB to use the keybufs= >> mechanism to pass in GELI keys. >> >> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU >> >> * Possibly create a coreboot port (uncertain how this would work, sinc= e >> Coreboot has its own extensive config menu) >> >> * Hold my breath and test it out on real hardware (I have a Librem 13 = r1 >> for this purpose) >> >> * Possibly try getting the FreeBSD kernel to work as a coreboot payloa= d. >=20 > Out of curiosity - why the kernel and not loader(8)? >=20 If I understand coreboot correctly, loader would have to directly manipulate devices _without a BIOS_. That is, it would have to have an entire device detection/interface layer, which I don't believe is the case today. At least in the EFI case, loader is talking through the system's EFI implementation, which takes care of all that for you. BIOS works in a similar way. My sense is getting loader to the point where it could be a coreboot (without Seabios/GRUB/Tianocore) would be quite an undertaking= =2E --V8N54xAkborfrU9cp4VGzVm42fljY09MH-- --9ECAOtpg9rw2jdh2m5vI63HP0iDzOZsig Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQb+/zC31sP34DGxX/pjibYt+BVsgUCXOxpxQAKCRDpjibYt+BV smxvAQC8YAcRUOedMVulJbiCdYNJzUWUBzCU6CBBxPYrn1R7VAEAgGBE64FIU0Wk WDMkEUWLlnfktDk+bFSVQWk1KtFVqQQ= =jtPc -----END PGP SIGNATURE----- --9ECAOtpg9rw2jdh2m5vI63HP0iDzOZsig-- From owner-freebsd-hackers@freebsd.org Tue May 28 00:53:53 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C595215AFF9F; Tue, 28 May 2019 00:53:53 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 133E88E24D; Tue, 28 May 2019 00:53:53 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7A60012C0; Tue, 28 May 2019 00:53:52 +0000 (UTC) Subject: Re: FreeBSD and Coreboot To: freebsd-hackers@freebsd.org, freebsd-current References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXMXabRYJKwYBBAHaRw8BAQdAJ2yzSUUR7u7H/bLAFOzhPII7vvJ45zQeB60TxyCoio20 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiWBBMWCAA+FiEEG/v8wt9b D9+AxsV/6Y4m2LfgVbIFAlzF2m0CGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ6Y4m2LfgVbJ9mwD/YpSeQ5F9gpvKFS5Bs5w1Bw7zTOfO7zJQrh9NzDbWtd0BAOSGr/i5 zJer2pAjwambsyU0bhgHNy9IDQ7AGnidIyMHuDgEXMXabRIKKwYBBAGXVQEFAQEHQEBwYuBK iJPJEDtS6hbLgcDSUSbfUNA2rGp3TJ1G+7EqAwEIB4h+BBgWCAAmFiEEG/v8wt9bD9+AxsV/ 6Y4m2LfgVbIFAlzF2m0CGwwFCQHhM4AACgkQ6Y4m2LfgVbJ2kwEAlJj1z3zRJm3mmi6N81by nuwAxk3qcKa67WX2/F3C4soA/iwVuPMnx5RWaoX3i2eKXVNzNwzvTFfeGKxfQBOzMocM Message-ID: <0c236dad-391f-5bb8-11d3-92ab532323ee@metricspace.net> Date: Mon, 27 May 2019 20:53:44 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zaA7IYSmNSVX1QCopAjLEvf3SHPyp39uU" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 00:53:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zaA7IYSmNSVX1QCopAjLEvf3SHPyp39uU Content-Type: multipart/mixed; boundary="7pfumWsctv7bbhOyH8GEFEgikWGFTrvQH"; protected-headers="v1" From: Eric McCorkle To: freebsd-hackers@freebsd.org, freebsd-current Message-ID: <0c236dad-391f-5bb8-11d3-92ab532323ee@metricspace.net> Subject: Re: FreeBSD and Coreboot References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> In-Reply-To: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> --7pfumWsctv7bbhOyH8GEFEgikWGFTrvQH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/27/19 11:13 AM, Eric McCorkle wrote: > My plan is roughly this: >=20 > * Refurbish the GRUB port, get it working again in QEMU (possibly on on= e > of my machines), also possibly push a patch to GRUB to use the keybufs > mechanism to pass in GELI keys. I managed to get the grub2 port compiling against 2.02 (latest release) in an afternoon's worth of work. Note: the --force-label flag on grub-install isn't presently implemented; I'll need to dig deeper into the code to get that working. I haven't tried to see if it works yet. You can follow my work on the grub2 branch of my freebsd-ports fork: https://github.com/emc2/freebsd-ports/tree/grub2 Also, I am potentially willing to take over maintenance of the port, assuming the volume of work isn't too high. --7pfumWsctv7bbhOyH8GEFEgikWGFTrvQH-- --zaA7IYSmNSVX1QCopAjLEvf3SHPyp39uU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQb+/zC31sP34DGxX/pjibYt+BVsgUCXOyGmAAKCRDpjibYt+BV slglAP90iSkN0gWDBEL7X9OvZSMK0YIJVLJ1KQRtlqJ+YVLaDQEAyCbyASc1KfiY Ik+B1/Poti0L5GzvE8GQ0kAAKKw9RQY= =iHgG -----END PGP SIGNATURE----- --zaA7IYSmNSVX1QCopAjLEvf3SHPyp39uU-- From owner-freebsd-hackers@freebsd.org Tue May 28 01:16:41 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C84315B0B49; Tue, 28 May 2019 01:16:41 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 CF9938EEDC; Tue, 28 May 2019 01:16:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-45-49-150-87.socal.res.rr.com [45.49.150.87]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id x4S15lUU009826 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 May 2019 18:05:47 -0700 Subject: Re: FreeBSD and Coreboot To: Eric McCorkle , Edward Napierala Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> From: Nathan Whitehorn Openpgp: preference=signencrypt Autocrypt: addr=nwhitehorn@freebsd.org; keydata= mQINBFuARN8BEADLKYsG3l1aq/M21R59I/5EsEfvtvd15ZJ9lDHcWPuxzIfGnu2LMpe5PrFP e/Y4bcsPrlB4S3I3ooIUDvoEEsDeqgqlZod3QevOK/RjLqiqx1i/4mKnobJ++3ppyVVIccgN sUrj786OYCFCI/W+uWw7cbKewNeaL//Z/TDKlHLkssiy6qmZbNQ0ZjcMLJKUesk4eVg2TtTD HNe42ZuxbUC9iLYieO4c7kQB4qiFhagDRiObXrLzvm2MQYeAaNVRqID+mfI75TWrQ+t98iVu mHvFu461eeteq59jg6H/IL07ACxL+HzEVM+D6tPtPrz7ppr3wiZL5Cu17yu0nAx0nhJTV8ZB qza1rOVun0x65S14L41XD2HkmBDxTaRlTg8ypnkLFo8kh+MEq4k67apL/DUGcaUjKy2TVUC7 3igLO/DwQHrkWx2RrOmS3xS0TgGXVmB47nq2Zveo3fcjporQK63n2sbLkS70cfAJAJ9KHEIx u9am44iW5Ku3+mVLgQYybtcUxlk/Jw/BA5V6KUcDQMd5kTm0MyagziqMaT+57ceYxwRBK4HC DCLRpSOHV81/YzyL5vnwfHsxADm3091rd0uwr8uRCQn7wLvlcFyp/JKSFkVnE1oo7UE4QQJZ GbSJyvj7GdXu0LdghALcMj/thdb+js4D3UuCaAMecgVSscxEIQARAQABtClOYXRoYW4gV2hp dGVob3JuIDxud2hpdGVob3JuQGZyZWVic2Qub3JnPokCTgQTAQgAOBYhBD1kIPqoIUk+gL8N YTi2TZRmhOh3BQJbgFJIAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEDi2TZRmhOh3 M6YP/RHkgLWCPGGBSKZ3an3GhRMO2B5qd+g5QGUt4gvvdMMgUqwvmUva4obvgS5qXbYOmFGM cP5myo1mcJ45Q06Qdy8pnFEBBm4dKlNZT8LHAz/lr0/I8FINJcIdwmyxHJzELW7nlBy+ZO0z rCJ4CK//MMCAlomj6s9ydaGF0Dnbj9LmE+CS/ZZaYqil5KgsXO2rbN1wa0QOpZjAc8I1NyDN 10nWTZSLeFcbfTWItc8bxVC8NOerG25OVMxjyvqp15ZSExL5NfxIMsrTAjk5AsLr0bCW3tGA A0eM2cwLBhAfdh3fdj+/8tzakafFwR8XrA6YWrvgFmIjCgXfbVGp058595SDHGM1BeCJ94Bm TJMbCTsGPTUbRsWXJ4ytjziqMPPYkXif+NdWNLX3/TTu4oGPGsPQjbTA2xTfLLjNFKLv0ieT XTMg3vMhiOsZnfKt65fwoJWh+mfBe9S4ImNiI2C6H/gr9rpjZZQ3f85+AUAQrVjZJwaOctTC wOr8o8odS5WrpwZVEQhJj8TdOiHKPsAS8+zsjdGucfkXBHnSctMS1uv9QMTTrMvWhuihzYlw 2pC3LHEvxUpv1lk+jH42uRqbMF0FfSPkundHalWXY/HZKWdukc5lhIcGYR9bcm+Eq5/P0Qyv 3q8Q6hIjx6pN4828q8aA0lDnQ1LOtGZjToGZUrcmuQINBFuARRkBEAC9SmeRBQpprN52L+js v29No0eITfSrXTbNhqLB4ikDcnGFDih9yunAQyKk+y++unxYute4NH70qnKpvHOzHENKrSNg uDgs0ga7/4iQMs2rWqTgSQ97JfmW6ilqJXbtKyKvLvK2Jt1lJo7I2uB3Sg3pupHc0WMElIyg EHm/goNnZA401BPGmkgwl9vD4UHxn4+om3CrqpcNWFIrJ/bHKjtg/CcINz3DA7KuyKTlg+jO IgH1Xf5cmCW8e4LeQoMqkXu5y9E+4/M+o6YKiLLplSk5pc0pep/+9S+5fVW2YTDjNXVIY1KK E5IqWZ5HsjxcsfEVEVgm/auR7iVreIi2dkJVrKczMMV0KBOqqwg3eXwfaUZo1NWL6FaHruYK tHkSblUWKSR2sLfDUnrFTj8/fRTHba6fDUhoxHPVnptEjCsSvUxCEVWZN9V64XjlFCO3cF72 e75ikbGp2R1PRPWgDFmmX0pHTGPKUImqKuF4krGrY64pf8iRUTyQvbNF49i6e4ycGwlAHhSq FBZkVBwvUZeDp9DFfL2Rht/QtjYH0yfcT5zRL0aI3oX6I7luCYvm4K4HG461BvTkvxZ2xmo3 dACzmwEyAClpseEaMOsbgwosnTFhehd4Qz1Kl4Yiry8/yqISEodt6vRjs5jAsT2okDBCc6qx +dww3ymXNvEGrf+AvQARAQABiQRsBBgBCAAgFiEEPWQg+qghST6Avw1hOLZNlGaE6HcFAluA RRkCGwICQAkQOLZNlGaE6HfBdCAEGQEIAB0WIQTTpX+yMt35tfRft49NUswkCJ+wagUCW4BF GQAKCRBNUswkCJ+waqoWEACAWq6YgCh4H+JPNxM33ENOmKZ+WmIfr7jgoy1UAhUz0OshLPHM dy4oyaPefNaio5jcp8rvuT7qxA19s1VOyA6NIvCBnMzs+x9bTkQdZ31mcBcESNltKShYO3mq JE8Iz665xUlY2U45x8oGO+pYvWXvZv1C4pXtqczzQQldRuYJ+zfHyGmJoDP6exj0ALVfApH1 RKrCHt51ZottN0gcy4fkmBF+D13hUWAEtq0TBXw+2m6Qwq5xQmWkItzw4x9CF+wE78hNodY5 TXoifJvMB78O/ltPUqUiiPn6FAmi7ErDA3Ue+b4dSBWCx/i+jhh08blrbTQeMr6yswQJzx3M m6BDvYsKZKC9WNI9YKJxopd/udikmcPSoBTyWgMhjm0FPMb3c9Ay9nlbV04LlaqT7DsG8WbL X6O8CZUEpsB8r2kptm4wjjkIywT5eyXbcoNMV449KRzobWDCLOzA50cqTCPwa+YaHUamcoXs 7f3g0AllZVg3J48tq3orQrbmd80/n6AK158fURHR4pPf1m7Z8LGvmfN5vSpw81IgJ0KQEg7P mBsrOZKXGRNvtiHipWvdC9+ex1OSHRNtKTL7bbBYV01atsw74pspBLwXbH/lWnUtFucwav41 wbtHYdfbhxpXZRL0YLcrJq6+oatJlUxzAjO3wz/EuU/5OAwMGJVptO80308ID/4jEYmXl0Ux PEXv2/FjHser/OdhzQNhLft9bBlMiSGwui5Rv0tWPZ7dB7gxsuJIBzvb/FoJXbFysmm+o4Bt go0xQqXqFBX4pD9KYKTDo9q4Bh+0k+NGKvBMJI9pwFu+Ix+u1dbrFnpi/q2nFRfYEKeZiKOD HOxMMcSeYEFaHqiiy5A7QDuW7i7e4uGY0Ls7vnxrNQTWpEIe9E6kIjIHtNWAOIypL8+tiuxr CckPYFEDEmJmp1XIIoFXOIgGceky7huMvtyWHAuE1RjrZpN34nuntpoPlYv0PpPNAIg20HBA eX+reoTCRquUz5F2yZuZRL4o2/sSbDwu4m1As4G0QNaWB7j3grTn6AEVhMbjLgA+QkPpvpN8 s3iEVlEyzuypuGhRR9sMMB/8itWKtCV4/TGoAGJkoK+LsVllfIuu2m9ekV9HAOg3583ame9L NQD0nD35egjdIv7PhbZDYVgPq1NS27b8wz8RqvYWlw+1kUSD62byWu/oFLLifHfUh66ImLCk kbJJBZ5XgGKb/mVpBRiyw7zJUJZgIyTB1NcCWr09n7X+44KuocAYM/hE7NKv8To/5PFmsWFu Y8m1Qh/j7U8/gOdAT7+Q4tLczRRU/ngcW8b/1ajWMY6UuZhrp/WfLoKHS79VYK39OClHRLSU hr911kye7XJLUdGr4S2k+enQb7kCDQRbgEVBARAA4soW2Dq6zQAsDsu2+PEiyQiCoUmMfDaR r9S10njfY/2S+YGrvPi/T6b+CTEI44bTIOLYK/8AsmhuzJvnq1tToxTRJGNOKjflLaOK3fr0 HUEMLZMs0XffuxSq5THSXjCQRcQF5+8tFii4XwFFuSCO96DuwDg2OyJ25DH3a88mcGhofY5b GoNuvlfqQXlzH2M+spQnhmof+toT9JIOG2jDhoo7SdZu15UZyTXlbVf9LwrOI9cprPEJDyqm tBFMB6Gx0b9tJtYP3mGndMCURuXg3hSqpLufiMJm6cJ6KLZMNkdW/H+WkUBPZ7PHrjqnY9SY fmGmJUyBtjm4dzJqHA1/54047uCi2c1iiJ6gvDh9R5Ng6r6zcg2KwIHiKi9Bxk4JhLObBGiV BGCBfS0FJ6dHo+CnfxiNUiRa8weHFtWJ8C6yO9Vub8ZB4DYxoK2SiDncjJ+juuL0N42lW5Fz /jsHEeLwm13LIaAs7XcCNzBzpXsot4ObD9JckAyyy5ZCVfOzw6Cyk2+3KYGHmurhOXEBjrkv di//KHSLMTO04k7c5v3LeAuuntN4MjQQ71LIa4VduBZj81eUPBYdaC4yA7sNYz8rF5oxjId+ d98h5Dq6EzbXLjYjs1XXWZbDJy/9cmQgPd93sZYF5xqR1idgj/sVgwMeaxRA+ZIyRuoKphxl 7jsAEQEAAYkCNgQYAQgAIBYhBD1kIPqoIUk+gL8NYTi2TZRmhOh3BQJbgEVBAhsMAAoJEDi2 TZRmhOh3ZFsQAJtDZvAnf75u+pyUStt6R/sFdiNrfv8fEYTrurf3F/byF6fy9Ya1fCrhtaZl PkfxsGpeKADhtRTic3hffEQN9PKqRAy4NOefBPtjrUHhASqGLhqrhp1/8o/SXVQKDgInQpL3 fUdqf5VuK5Rxtp27VlffsR/qD+Eb6a3n0V5cMxTSt6uzYGmvzMHzLCiMCxUL3aS84cuwJC10 Kw/ML5HoHVtjr9F72yUzU0F37aTgFRWFi7wVvwivfs6Y3RoZDNi5FzN+uZH85Xn/X6Dld5hI Vur/RDcqQVYsd+KZ9/yVv0ZFat285SljIaW6/j1v8bmj2VLE/BfIF9qhWL9YMN8n9cnD0f3R crrxNjE98RCR64sQTOD4HPdl527KjZnHhLlqkuoBu/RHN25eAgZhlU+7xHjJrydBYd5Smi3X uW3xIvvIWQwloBeTbtCpQBrGOqcYEufvRgxZcUbJJ++OBpHUW279L8dIqofubxoVhl+2qztm iNc12oYdkpGsjHqFFRi5lAzy7EcPB4XiMX5AjBghSa2vLmHyK2JKO30oeOmQfdbPmjWaTpxs U037CCkemUOX+JkxmMWyRMAl8SxgdVJKbbXNxi++iCtupi9yIxO3Lrn7QDwbP20xtw3H149o agz72N4V6GvNON1qJOIL66ZJ39jb0MJbg4EyvVV+59VUpt8B Message-ID: <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> Date: Mon, 27 May 2019 18:05:45 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LyIxkKby04YEpGsH5AeydSISyWGbOKjgf" X-Sonic-CAuth: UmFuZG9tSVbWyOWmqredkSUqPpij1VbraeWHougpD8h9Z6qsrQNCJ+9AdyDr/Yz5MzLx47cuU1rvT4D0x5U6GCMM4KZnYztkPRUm2Z3mOm4= X-Sonic-ID: C;+u7oueSA6RG6gccSXokrVQ== M;4EsouuSA6RG6gccSXokrVQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Rspamd-Queue-Id: CF9938EEDC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:7065, ipnet:64.142.96.0/19, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 01:16:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LyIxkKby04YEpGsH5AeydSISyWGbOKjgf Content-Type: multipart/mixed; boundary="q6PuLJAQ2dVeKq7lQ0j4emexr8iAFIqQL"; protected-headers="v1" From: Nathan Whitehorn To: Eric McCorkle , Edward Napierala Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current Message-ID: <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> Subject: Re: FreeBSD and Coreboot References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> In-Reply-To: <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> --q6PuLJAQ2dVeKq7lQ0j4emexr8iAFIqQL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2019-05-27 15:50, Eric McCorkle wrote: > On 5/27/19 5:53 PM, Edward Napierala wrote: >> On Mon, 27 May 2019 at 16:14, Eric McCorkle wro= te: >> >> [..] >> >>> My plan is roughly this: >>> >>> * Refurbish the GRUB port, get it working again in QEMU (possibly on = one >>> of my machines), also possibly push a patch to GRUB to use the keybuf= s >>> mechanism to pass in GELI keys. >>> >>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU >>> >>> * Possibly create a coreboot port (uncertain how this would work, sin= ce >>> Coreboot has its own extensive config menu) >>> >>> * Hold my breath and test it out on real hardware (I have a Librem 13= r1 >>> for this purpose) >>> >>> * Possibly try getting the FreeBSD kernel to work as a coreboot paylo= ad. >> Out of curiosity - why the kernel and not loader(8)? >> > If I understand coreboot correctly, loader would have to directly > manipulate devices _without a BIOS_. That is, it would have to have an= > entire device detection/interface layer, which I don't believe is the > case today. > > At least in the EFI case, loader is talking through the system's EFI > implementation, which takes care of all that for you. BIOS works in a > similar way. My sense is getting loader to the point where it could be= > a coreboot (without Seabios/GRUB/Tianocore) would be quite an undertaki= ng. > On IBM PowerNV systems, which also don't provide interfaces to a second-stage loader, we just abandoned loader(8). It's way too much work.= -Nathan --q6PuLJAQ2dVeKq7lQ0j4emexr8iAFIqQL-- --LyIxkKby04YEpGsH5AeydSISyWGbOKjgf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE06V/sjLd+bX0X7ePTVLMJAifsGoFAlzsiWoACgkQTVLMJAif sGrKyxAAnhNhQhSx91G/JcTnIdvrvcQLJCOhlX6TZhQdWOXNeB0/Eb7CjeEWns3a Cxoi4abJmHYV82oerBSnszEuj5rZFo0H8wy0PCaPYsg4UhBUI0GtrfGCxSzewbfq NAgPnYA9hENLk0YX1QjI3gASSKv10+Ab6MiLIvrwwIgaB1iAEPy3GjI+OlvhqBak 3VeQyyM8PpQOhMirhND21oGiAV5uknLJdtNQCXqlFAGZa9l1KDeviKlNm7Hnur9N Xa5xzNF8fHtPs8kmWdd2gof8hthdFESHV3E6+3l2RHeVTrJBtv8NfnwmM/xwdjbA xQDS3Qs7kvjY034KvALgIDamhNScN6Lg+51rpAyfkgwXmPpgWLk2S/Wl41rKDuNH V6AYd2ceNe7fdKwz6cMgraQOsqMAG3jO4r9Cy9bPrIGX28oPet2jee0NsJv+f5qV HP+Qc4GZNCMM7cQbLaX5qeNVtAri0Tc02jz7m3wfqejzJDCx2XAbfQYWpYU2t3qk YH0o7RgrVtxUi0tMawe1BSlCcvBYqRUEqB7wLxWRAYUDCI4HUs1DJhaRjNMfBj5C MlwhU3cNxhS+/tzl16kRPePCNJnvP7nZzz6y7ceiPBfBeAbc0pdX4SqNoD/Dm1Gv vy3A2rOUa2oT5OZjlYgR2p3cWa5FLo6/x40WnvWFz4XpyMRjp5c= =O/BF -----END PGP SIGNATURE----- --LyIxkKby04YEpGsH5AeydSISyWGbOKjgf-- From owner-freebsd-hackers@freebsd.org Tue May 28 02:14:43 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4447A15B256F for ; Tue, 28 May 2019 02:14:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4481C90D4D for ; Tue, 28 May 2019 02:14:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x741.google.com with SMTP id g18so1795773qkl.3 for ; Mon, 27 May 2019 19:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N2rtnLbCwk7TtmdmCjx8VrdshvnAH4bHJEsr2f55FwA=; b=SqI5uRV4z8ocZGZ6ceiS7XRI6CYQir19gDC4Vq+/eZj9pcIA8EDFiS2H91VZuamDQw zyIYubokPVcwrFJl5e0FFIDUbLgvaE3EVWxQTQ55gPSuJttUHePtPu5g/sFAZe2mAvJa QGZoI5jfL6cCLU3R9+0rWU04wP8TieB7BVlcN5lU4b7yF4G9AfyV/c22BujQMltzKBIB scM0YdNbkRNezO5pE8pK5lkl5Ij842D7ttlFwIUxGA2O9XIUMxjBYOQtP0V3hbV9UN/w 3bOsdgTRYck/0wWLO/bFlrthhhvtat1V0sS74hpBmievIrSHgcnNkzVQtbm2CpnWqMOY OdtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N2rtnLbCwk7TtmdmCjx8VrdshvnAH4bHJEsr2f55FwA=; b=OBItdhj9oLkoNmlLgXWUZZ/C3tI6p+xec1eH/Btzqnhm5pflUCryfrJ2eRlHFbpo7Z n8SXQKUShaLL3vVeiPq5kwzpZITMW2iv98ukOXlzybwsL4oHKLaR/Gtr+LmRUQoZUkI2 N3u72INpGqPbq9k9bAAZBjXTfq5X+3qoufzAJLoBfLGurx8+s62h++BOVYWN2Rg6p6KQ HYW8Dl8EaHGQwforAEvgkG3UXXP2rLYhxLAET+Do1VKSU7cW1OAw7vKPddaA4X4KQFcD A162kSNazJnzjhgqOFLpxSn/2aFrgkaWEyEBb/TUsi69l+4x9ks+MCoov0oNWRVnVw6I ep1g== X-Gm-Message-State: APjAAAX3eckYEqhNAfhnn5S/QsSkmuvnYmus7EfD4lvqg1kDW0TmpKPc 3+Aj/OR1YGfsBwUvOpmNi1YYX8eTrPk9gvqCVAB+OA== X-Google-Smtp-Source: APXvYqwAxlyEvgG/U4YCp2h6XVM4s/8L3g36g1HgFjfxSP8N0ahyLjZGmFbkdqOPBxucqrkfg0+lUiywYqn8f/O/CPQ= X-Received: by 2002:a05:620a:1384:: with SMTP id k4mr37539684qki.69.1559009681728; Mon, 27 May 2019 19:14:41 -0700 (PDT) MIME-Version: 1.0 References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> In-Reply-To: <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> From: Warner Losh Date: Mon, 27 May 2019 20:14:29 -0600 Message-ID: Subject: Re: FreeBSD and Coreboot To: Nathan Whitehorn Cc: Eric McCorkle , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , "freebsd-hackers@freebsd.org" , FreeBSD Current X-Rspamd-Queue-Id: 4481C90D4D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=SqI5uRV4 X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[1.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.80)[-0.803,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-0.74)[ip: (1.95), ipnet: 2607:f8b0::/32(-3.29), asn: 15169(-2.28), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 02:14:43 -0000 On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn wrote: > > > On 2019-05-27 15:50, Eric McCorkle wrote: > > On 5/27/19 5:53 PM, Edward Napierala wrote: > >> On Mon, 27 May 2019 at 16:14, Eric McCorkle > wrote: > >> > >> [..] > >> > >>> My plan is roughly this: > >>> > >>> * Refurbish the GRUB port, get it working again in QEMU (possibly on > one > >>> of my machines), also possibly push a patch to GRUB to use the keybufs > >>> mechanism to pass in GELI keys. > >>> > >>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > >>> > >>> * Possibly create a coreboot port (uncertain how this would work, since > >>> Coreboot has its own extensive config menu) > >>> > >>> * Hold my breath and test it out on real hardware (I have a Librem 13 > r1 > >>> for this purpose) > >>> > >>> * Possibly try getting the FreeBSD kernel to work as a coreboot > payload. > >> Out of curiosity - why the kernel and not loader(8)? > >> > > If I understand coreboot correctly, loader would have to directly > > manipulate devices _without a BIOS_. That is, it would have to have an > > entire device detection/interface layer, which I don't believe is the > > case today. > > > > At least in the EFI case, loader is talking through the system's EFI > > implementation, which takes care of all that for you. BIOS works in a > > similar way. My sense is getting loader to the point where it could be > > a coreboot (without Seabios/GRUB/Tianocore) would be quite an > undertaking. > > > > On IBM PowerNV systems, which also don't provide interfaces to a > second-stage loader, we just abandoned loader(8). It's way too much work. > How do you use tunables and loadable modules? Warner > From owner-freebsd-hackers@freebsd.org Tue May 28 04:44:09 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8014815B5C2C; Tue, 28 May 2019 04:44:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 9950395622; Tue, 28 May 2019 04:44:08 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-45-49-150-87.socal.res.rr.com [45.49.150.87]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id x4S4i4ve009608 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 May 2019 21:44:04 -0700 Subject: Re: FreeBSD and Coreboot To: Warner Losh Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> From: Nathan Whitehorn Openpgp: preference=signencrypt Autocrypt: addr=nwhitehorn@freebsd.org; keydata= mQINBFuARN8BEADLKYsG3l1aq/M21R59I/5EsEfvtvd15ZJ9lDHcWPuxzIfGnu2LMpe5PrFP e/Y4bcsPrlB4S3I3ooIUDvoEEsDeqgqlZod3QevOK/RjLqiqx1i/4mKnobJ++3ppyVVIccgN sUrj786OYCFCI/W+uWw7cbKewNeaL//Z/TDKlHLkssiy6qmZbNQ0ZjcMLJKUesk4eVg2TtTD HNe42ZuxbUC9iLYieO4c7kQB4qiFhagDRiObXrLzvm2MQYeAaNVRqID+mfI75TWrQ+t98iVu mHvFu461eeteq59jg6H/IL07ACxL+HzEVM+D6tPtPrz7ppr3wiZL5Cu17yu0nAx0nhJTV8ZB qza1rOVun0x65S14L41XD2HkmBDxTaRlTg8ypnkLFo8kh+MEq4k67apL/DUGcaUjKy2TVUC7 3igLO/DwQHrkWx2RrOmS3xS0TgGXVmB47nq2Zveo3fcjporQK63n2sbLkS70cfAJAJ9KHEIx u9am44iW5Ku3+mVLgQYybtcUxlk/Jw/BA5V6KUcDQMd5kTm0MyagziqMaT+57ceYxwRBK4HC DCLRpSOHV81/YzyL5vnwfHsxADm3091rd0uwr8uRCQn7wLvlcFyp/JKSFkVnE1oo7UE4QQJZ GbSJyvj7GdXu0LdghALcMj/thdb+js4D3UuCaAMecgVSscxEIQARAQABtClOYXRoYW4gV2hp dGVob3JuIDxud2hpdGVob3JuQGZyZWVic2Qub3JnPokCTgQTAQgAOBYhBD1kIPqoIUk+gL8N YTi2TZRmhOh3BQJbgFJIAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEDi2TZRmhOh3 M6YP/RHkgLWCPGGBSKZ3an3GhRMO2B5qd+g5QGUt4gvvdMMgUqwvmUva4obvgS5qXbYOmFGM cP5myo1mcJ45Q06Qdy8pnFEBBm4dKlNZT8LHAz/lr0/I8FINJcIdwmyxHJzELW7nlBy+ZO0z rCJ4CK//MMCAlomj6s9ydaGF0Dnbj9LmE+CS/ZZaYqil5KgsXO2rbN1wa0QOpZjAc8I1NyDN 10nWTZSLeFcbfTWItc8bxVC8NOerG25OVMxjyvqp15ZSExL5NfxIMsrTAjk5AsLr0bCW3tGA A0eM2cwLBhAfdh3fdj+/8tzakafFwR8XrA6YWrvgFmIjCgXfbVGp058595SDHGM1BeCJ94Bm TJMbCTsGPTUbRsWXJ4ytjziqMPPYkXif+NdWNLX3/TTu4oGPGsPQjbTA2xTfLLjNFKLv0ieT XTMg3vMhiOsZnfKt65fwoJWh+mfBe9S4ImNiI2C6H/gr9rpjZZQ3f85+AUAQrVjZJwaOctTC wOr8o8odS5WrpwZVEQhJj8TdOiHKPsAS8+zsjdGucfkXBHnSctMS1uv9QMTTrMvWhuihzYlw 2pC3LHEvxUpv1lk+jH42uRqbMF0FfSPkundHalWXY/HZKWdukc5lhIcGYR9bcm+Eq5/P0Qyv 3q8Q6hIjx6pN4828q8aA0lDnQ1LOtGZjToGZUrcmuQINBFuARRkBEAC9SmeRBQpprN52L+js v29No0eITfSrXTbNhqLB4ikDcnGFDih9yunAQyKk+y++unxYute4NH70qnKpvHOzHENKrSNg uDgs0ga7/4iQMs2rWqTgSQ97JfmW6ilqJXbtKyKvLvK2Jt1lJo7I2uB3Sg3pupHc0WMElIyg EHm/goNnZA401BPGmkgwl9vD4UHxn4+om3CrqpcNWFIrJ/bHKjtg/CcINz3DA7KuyKTlg+jO IgH1Xf5cmCW8e4LeQoMqkXu5y9E+4/M+o6YKiLLplSk5pc0pep/+9S+5fVW2YTDjNXVIY1KK E5IqWZ5HsjxcsfEVEVgm/auR7iVreIi2dkJVrKczMMV0KBOqqwg3eXwfaUZo1NWL6FaHruYK tHkSblUWKSR2sLfDUnrFTj8/fRTHba6fDUhoxHPVnptEjCsSvUxCEVWZN9V64XjlFCO3cF72 e75ikbGp2R1PRPWgDFmmX0pHTGPKUImqKuF4krGrY64pf8iRUTyQvbNF49i6e4ycGwlAHhSq FBZkVBwvUZeDp9DFfL2Rht/QtjYH0yfcT5zRL0aI3oX6I7luCYvm4K4HG461BvTkvxZ2xmo3 dACzmwEyAClpseEaMOsbgwosnTFhehd4Qz1Kl4Yiry8/yqISEodt6vRjs5jAsT2okDBCc6qx +dww3ymXNvEGrf+AvQARAQABiQRsBBgBCAAgFiEEPWQg+qghST6Avw1hOLZNlGaE6HcFAluA RRkCGwICQAkQOLZNlGaE6HfBdCAEGQEIAB0WIQTTpX+yMt35tfRft49NUswkCJ+wagUCW4BF GQAKCRBNUswkCJ+waqoWEACAWq6YgCh4H+JPNxM33ENOmKZ+WmIfr7jgoy1UAhUz0OshLPHM dy4oyaPefNaio5jcp8rvuT7qxA19s1VOyA6NIvCBnMzs+x9bTkQdZ31mcBcESNltKShYO3mq JE8Iz665xUlY2U45x8oGO+pYvWXvZv1C4pXtqczzQQldRuYJ+zfHyGmJoDP6exj0ALVfApH1 RKrCHt51ZottN0gcy4fkmBF+D13hUWAEtq0TBXw+2m6Qwq5xQmWkItzw4x9CF+wE78hNodY5 TXoifJvMB78O/ltPUqUiiPn6FAmi7ErDA3Ue+b4dSBWCx/i+jhh08blrbTQeMr6yswQJzx3M m6BDvYsKZKC9WNI9YKJxopd/udikmcPSoBTyWgMhjm0FPMb3c9Ay9nlbV04LlaqT7DsG8WbL X6O8CZUEpsB8r2kptm4wjjkIywT5eyXbcoNMV449KRzobWDCLOzA50cqTCPwa+YaHUamcoXs 7f3g0AllZVg3J48tq3orQrbmd80/n6AK158fURHR4pPf1m7Z8LGvmfN5vSpw81IgJ0KQEg7P mBsrOZKXGRNvtiHipWvdC9+ex1OSHRNtKTL7bbBYV01atsw74pspBLwXbH/lWnUtFucwav41 wbtHYdfbhxpXZRL0YLcrJq6+oatJlUxzAjO3wz/EuU/5OAwMGJVptO80308ID/4jEYmXl0Ux PEXv2/FjHser/OdhzQNhLft9bBlMiSGwui5Rv0tWPZ7dB7gxsuJIBzvb/FoJXbFysmm+o4Bt go0xQqXqFBX4pD9KYKTDo9q4Bh+0k+NGKvBMJI9pwFu+Ix+u1dbrFnpi/q2nFRfYEKeZiKOD HOxMMcSeYEFaHqiiy5A7QDuW7i7e4uGY0Ls7vnxrNQTWpEIe9E6kIjIHtNWAOIypL8+tiuxr CckPYFEDEmJmp1XIIoFXOIgGceky7huMvtyWHAuE1RjrZpN34nuntpoPlYv0PpPNAIg20HBA eX+reoTCRquUz5F2yZuZRL4o2/sSbDwu4m1As4G0QNaWB7j3grTn6AEVhMbjLgA+QkPpvpN8 s3iEVlEyzuypuGhRR9sMMB/8itWKtCV4/TGoAGJkoK+LsVllfIuu2m9ekV9HAOg3583ame9L NQD0nD35egjdIv7PhbZDYVgPq1NS27b8wz8RqvYWlw+1kUSD62byWu/oFLLifHfUh66ImLCk kbJJBZ5XgGKb/mVpBRiyw7zJUJZgIyTB1NcCWr09n7X+44KuocAYM/hE7NKv8To/5PFmsWFu Y8m1Qh/j7U8/gOdAT7+Q4tLczRRU/ngcW8b/1ajWMY6UuZhrp/WfLoKHS79VYK39OClHRLSU hr911kye7XJLUdGr4S2k+enQb7kCDQRbgEVBARAA4soW2Dq6zQAsDsu2+PEiyQiCoUmMfDaR r9S10njfY/2S+YGrvPi/T6b+CTEI44bTIOLYK/8AsmhuzJvnq1tToxTRJGNOKjflLaOK3fr0 HUEMLZMs0XffuxSq5THSXjCQRcQF5+8tFii4XwFFuSCO96DuwDg2OyJ25DH3a88mcGhofY5b GoNuvlfqQXlzH2M+spQnhmof+toT9JIOG2jDhoo7SdZu15UZyTXlbVf9LwrOI9cprPEJDyqm tBFMB6Gx0b9tJtYP3mGndMCURuXg3hSqpLufiMJm6cJ6KLZMNkdW/H+WkUBPZ7PHrjqnY9SY fmGmJUyBtjm4dzJqHA1/54047uCi2c1iiJ6gvDh9R5Ng6r6zcg2KwIHiKi9Bxk4JhLObBGiV BGCBfS0FJ6dHo+CnfxiNUiRa8weHFtWJ8C6yO9Vub8ZB4DYxoK2SiDncjJ+juuL0N42lW5Fz /jsHEeLwm13LIaAs7XcCNzBzpXsot4ObD9JckAyyy5ZCVfOzw6Cyk2+3KYGHmurhOXEBjrkv di//KHSLMTO04k7c5v3LeAuuntN4MjQQ71LIa4VduBZj81eUPBYdaC4yA7sNYz8rF5oxjId+ d98h5Dq6EzbXLjYjs1XXWZbDJy/9cmQgPd93sZYF5xqR1idgj/sVgwMeaxRA+ZIyRuoKphxl 7jsAEQEAAYkCNgQYAQgAIBYhBD1kIPqoIUk+gL8NYTi2TZRmhOh3BQJbgEVBAhsMAAoJEDi2 TZRmhOh3ZFsQAJtDZvAnf75u+pyUStt6R/sFdiNrfv8fEYTrurf3F/byF6fy9Ya1fCrhtaZl PkfxsGpeKADhtRTic3hffEQN9PKqRAy4NOefBPtjrUHhASqGLhqrhp1/8o/SXVQKDgInQpL3 fUdqf5VuK5Rxtp27VlffsR/qD+Eb6a3n0V5cMxTSt6uzYGmvzMHzLCiMCxUL3aS84cuwJC10 Kw/ML5HoHVtjr9F72yUzU0F37aTgFRWFi7wVvwivfs6Y3RoZDNi5FzN+uZH85Xn/X6Dld5hI Vur/RDcqQVYsd+KZ9/yVv0ZFat285SljIaW6/j1v8bmj2VLE/BfIF9qhWL9YMN8n9cnD0f3R crrxNjE98RCR64sQTOD4HPdl527KjZnHhLlqkuoBu/RHN25eAgZhlU+7xHjJrydBYd5Smi3X uW3xIvvIWQwloBeTbtCpQBrGOqcYEufvRgxZcUbJJ++OBpHUW279L8dIqofubxoVhl+2qztm iNc12oYdkpGsjHqFFRi5lAzy7EcPB4XiMX5AjBghSa2vLmHyK2JKO30oeOmQfdbPmjWaTpxs U037CCkemUOX+JkxmMWyRMAl8SxgdVJKbbXNxi++iCtupi9yIxO3Lrn7QDwbP20xtw3H149o agz72N4V6GvNON1qJOIL66ZJ39jb0MJbg4EyvVV+59VUpt8B Message-ID: <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> Date: Mon, 27 May 2019 21:44:03 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYrlsBa+UkOuWqmMbK/TSh8BJnjxuZwdiuMPjZQNMzdvfNHyBrjL+3xnQE/FCJLTcP6nIHpLVCAA9okt8M9G/bkQ8573ve5cPw= X-Sonic-ID: C;TL12OAOB6RGdcj30OgXfLQ== M;0B7IOAOB6RGdcj30OgXfLQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Rspamd-Queue-Id: 9950395622 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.93 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.935,0]; ASN(0.00)[asn:7065, ipnet:64.142.96.0/19, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 04:44:09 -0000 On 2019-05-27 19:14, Warner Losh wrote: > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > wrote: > >> >> On 2019-05-27 15:50, Eric McCorkle wrote: >>> On 5/27/19 5:53 PM, Edward Napierala wrote: >>>> On Mon, 27 May 2019 at 16:14, Eric McCorkle >> wrote: >>>> [..] >>>> >>>>> My plan is roughly this: >>>>> >>>>> * Refurbish the GRUB port, get it working again in QEMU (possibly on >> one >>>>> of my machines), also possibly push a patch to GRUB to use the keybufs >>>>> mechanism to pass in GELI keys. >>>>> >>>>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU >>>>> >>>>> * Possibly create a coreboot port (uncertain how this would work, since >>>>> Coreboot has its own extensive config menu) >>>>> >>>>> * Hold my breath and test it out on real hardware (I have a Librem 13 >> r1 >>>>> for this purpose) >>>>> >>>>> * Possibly try getting the FreeBSD kernel to work as a coreboot >> payload. >>>> Out of curiosity - why the kernel and not loader(8)? >>>> >>> If I understand coreboot correctly, loader would have to directly >>> manipulate devices _without a BIOS_. That is, it would have to have an >>> entire device detection/interface layer, which I don't believe is the >>> case today. >>> >>> At least in the EFI case, loader is talking through the system's EFI >>> implementation, which takes care of all that for you. BIOS works in a >>> similar way. My sense is getting loader to the point where it could be >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an >> undertaking. >> On IBM PowerNV systems, which also don't provide interfaces to a >> second-stage loader, we just abandoned loader(8). It's way too much work. >> > How do you use tunables and loadable modules? > > Warner > The firmware on PowerNV has a way to write tunables to the device-tree, which we rehydrate into something that looks like it came from loader. We don't usefully support loadable modules at the moment. The firmware can optionally load exactly one file from the boot filesystem and pass it to the kernel (for Linux, the initrd). There are a couple of ways to imagine exploiting this for kernel modules, but all of them are kind of crummy. -Nathan From owner-freebsd-hackers@freebsd.org Tue May 28 04:46:27 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CBA215B5DCB for ; Tue, 28 May 2019 04:46:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 542EA9581C for ; Tue, 28 May 2019 04:46:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x742.google.com with SMTP id d10so20571621qko.4 for ; Mon, 27 May 2019 21:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LYTziAV32kqbAD06fdIn2YevrGVoLtxN68LH5exHUCQ=; b=tyVZ3eFHM5Vls1QAIMqD2BdbHoW6w0nom18sLynoHunuj4BWJ+qhiUhBf7ZUsPrjCa wslD47sVjadlN9CJdRQ7hln0BeK4FpEarxzSl/9ZgD80ujSBJNB09DOQjEZzkkfIqZbp VMbF4Z6TZRzwDVaGBVwqhkQajYB2rAW6KlXgL9hd00z4rOiF4cug4uVwItSFKqZxvsMg BlmCxQ0aZCcdjcmn75Hu0oIuFsq7Bl9edm5eqKHYj8/8LaI3c5MYMo138sXc5Njzp0qS vaU+n1s6V9PYmCwGE1pLPgHZsbmIh+q+STVILmQ/PvDnvqO2zvogezL6XMOUCIh3LDVd tkiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LYTziAV32kqbAD06fdIn2YevrGVoLtxN68LH5exHUCQ=; b=GOthc6Py70isO1ije5LysnGafwHRv2YUsoSyb1skdmMJsa1gNIbakFZ3qcJMAb21Zu q0Ruwdmf9VIvXUFVf69/LnUQaoroNNhUi6lS+ZrOnw9D2IS0slBlaU6+32yjstxirWDT 8Sk2Y0vQmP/0/lJgna2w8wgOT6wVKkbWt1CsvUD70U1lbibwQ7Os8TACLbY5AWtcLKEy LHQ7vujZUlbuxH4vi+PWpDoHhCKo9I4XXuiXyLxetb57f/X2GNg27O4DNIK9h6lFhZ8g KQEyy/KQX/D14VQurUMQwa+fyYOw0Eh4Lz5boFmuiZt0xLDkHBjd9hiifvoSwNiQ5/Zb h8uA== X-Gm-Message-State: APjAAAU3qcrA3lSM4yNB+1Wlq1zwqVjE6OpCu5qd4I4Gzu0GNpYNW+zW VcL+qYccQILeU+6vqGxbmcDe/3qihzUnfW+fifZrSQ== X-Google-Smtp-Source: APXvYqzf0il/NzHYHZFC6Shon9+uBIWylF3xebTDL0ITjGG6W0Xb9J2NvLxq1929KbODY7xSdyk7CEts6DxUI0aSYyw= X-Received: by 2002:a37:4b48:: with SMTP id y69mr86077271qka.77.1559018785613; Mon, 27 May 2019 21:46:25 -0700 (PDT) MIME-Version: 1.0 References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> In-Reply-To: <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> From: Warner Losh Date: Mon, 27 May 2019 22:46:13 -0600 Message-ID: Subject: Re: FreeBSD and Coreboot To: Nathan Whitehorn Cc: Eric McCorkle , FreeBSD Hackers , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Rspamd-Queue-Id: 542EA9581C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=tyVZ3eFH X-Spamd-Result: default: False [-2.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.36)[-0.364,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-0.54)[ip: (2.93), ipnet: 2607:f8b0::/32(-3.29), asn: 15169(-2.28), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 04:46:27 -0000 On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn wrote: > > > On 2019-05-27 19:14, Warner Losh wrote: > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > > wrote: > > > >> > >> On 2019-05-27 15:50, Eric McCorkle wrote: > >>> On 5/27/19 5:53 PM, Edward Napierala wrote: > >>>> On Mon, 27 May 2019 at 16:14, Eric McCorkle > >> wrote: > >>>> [..] > >>>> > >>>>> My plan is roughly this: > >>>>> > >>>>> * Refurbish the GRUB port, get it working again in QEMU (possibly on > >> one > >>>>> of my machines), also possibly push a patch to GRUB to use the > keybufs > >>>>> mechanism to pass in GELI keys. > >>>>> > >>>>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > >>>>> > >>>>> * Possibly create a coreboot port (uncertain how this would work, > since > >>>>> Coreboot has its own extensive config menu) > >>>>> > >>>>> * Hold my breath and test it out on real hardware (I have a Librem 13 > >> r1 > >>>>> for this purpose) > >>>>> > >>>>> * Possibly try getting the FreeBSD kernel to work as a coreboot > >> payload. > >>>> Out of curiosity - why the kernel and not loader(8)? > >>>> > >>> If I understand coreboot correctly, loader would have to directly > >>> manipulate devices _without a BIOS_. That is, it would have to have an > >>> entire device detection/interface layer, which I don't believe is the > >>> case today. > >>> > >>> At least in the EFI case, loader is talking through the system's EFI > >>> implementation, which takes care of all that for you. BIOS works in a > >>> similar way. My sense is getting loader to the point where it could be > >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an > >> undertaking. > >> On IBM PowerNV systems, which also don't provide interfaces to a > >> second-stage loader, we just abandoned loader(8). It's way too much > work. > >> > > How do you use tunables and loadable modules? > > > > Warner > > > > The firmware on PowerNV has a way to write tunables to the device-tree, > which we rehydrate into something that looks like it came from loader. > > We don't usefully support loadable modules at the moment. The firmware > can optionally load exactly one file from the boot filesystem and pass > it to the kernel (for Linux, the initrd). There are a couple of ways to > imagine exploiting this for kernel modules, but all of them are kind of > crummy. > Now that the loader supports a ram disk, we are almost to something useful... but yea, almost and crummy often go hand in hand. Warner > From owner-freebsd-hackers@freebsd.org Tue May 28 11:17:29 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 948DC15BE997; Tue, 28 May 2019 11:17:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id B3B897480B; Tue, 28 May 2019 11:17:28 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4B4F313AC; Tue, 28 May 2019 11:17:28 +0000 (UTC) To: Warner Losh , Nathan Whitehorn Cc: FreeBSD Hackers , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXMXabRYJKwYBBAHaRw8BAQdAJ2yzSUUR7u7H/bLAFOzhPII7vvJ45zQeB60TxyCoio20 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiWBBMWCAA+FiEEG/v8wt9b D9+AxsV/6Y4m2LfgVbIFAlzF2m0CGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ6Y4m2LfgVbJ9mwD/YpSeQ5F9gpvKFS5Bs5w1Bw7zTOfO7zJQrh9NzDbWtd0BAOSGr/i5 zJer2pAjwambsyU0bhgHNy9IDQ7AGnidIyMHuDgEXMXabRIKKwYBBAGXVQEFAQEHQEBwYuBK iJPJEDtS6hbLgcDSUSbfUNA2rGp3TJ1G+7EqAwEIB4h+BBgWCAAmFiEEG/v8wt9bD9+AxsV/ 6Y4m2LfgVbIFAlzF2m0CGwwFCQHhM4AACgkQ6Y4m2LfgVbJ2kwEAlJj1z3zRJm3mmi6N81by nuwAxk3qcKa67WX2/F3C4soA/iwVuPMnx5RWaoX3i2eKXVNzNwzvTFfeGKxfQBOzMocM Subject: Re: FreeBSD and Coreboot Message-ID: Date: Tue, 28 May 2019 07:17:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 11:17:29 -0000 On 5/28/19 12:46 AM, Warner Losh wrote: > > > On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn > wrote: > > > > On 2019-05-27 19:14, Warner Losh wrote: > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > > > > wrote: > > > >> > >> On 2019-05-27 15:50, Eric McCorkle wrote: > >>> On 5/27/19 5:53 PM, Edward Napierala wrote: > >>>> On Mon, 27 May 2019 at 16:14, Eric McCorkle > > > >> wrote: > >>>> [..] > >>>> > >>>>> My plan is roughly this: > >>>>> > >>>>> * Refurbish the GRUB port, get it working again in QEMU > (possibly on > >> one > >>>>> of my machines), also possibly push a patch to GRUB to use the > keybufs > >>>>> mechanism to pass in GELI keys. > >>>>> > >>>>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > >>>>> > >>>>> * Possibly create a coreboot port (uncertain how this would > work, since > >>>>> Coreboot has its own extensive config menu) > >>>>> > >>>>> * Hold my breath and test it out on real hardware (I have a > Librem 13 > >> r1 > >>>>> for this purpose) > >>>>> > >>>>> * Possibly try getting the FreeBSD kernel to work as a coreboot > >> payload. > >>>> Out of curiosity - why the kernel and not loader(8)? > >>>> > >>> If I understand coreboot correctly, loader would have to directly > >>> manipulate devices _without a BIOS_.  That is, it would have to > have an > >>> entire device detection/interface layer, which I don't believe > is the > >>> case today. > >>> > >>> At least in the EFI case, loader is talking through the system's EFI > >>> implementation, which takes care of all that for you.  BIOS > works in a > >>> similar way.  My sense is getting loader to the point where it > could be > >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an > >> undertaking. > >> On IBM PowerNV systems, which also don't provide interfaces to a > >> second-stage loader, we just abandoned loader(8). It's way too > much work. > >> > > How do you use tunables and loadable modules? > > > > Warner > > > > The firmware on PowerNV has a way to write tunables to the device-tree, > which we rehydrate into something that looks like it came from loader. > > We don't usefully support loadable modules at the moment. The firmware > can optionally load exactly one file from the boot filesystem and pass > it to the kernel (for Linux, the initrd). There are a couple of ways to > imagine exploiting this for kernel modules, but all of them are kind of > crummy. > > > Now that the loader supports a ram disk, we are almost to something > useful... but yea, almost and crummy often go hand in hand. This is looking out ahead of my current roadmap, but if you were to do a kernel as the coreboot payload, there'd need to be some kind of trick to support ZFS-only systems. ZFS requires modules, which are typically pre-loaded (and linked) by loader (or GRUB). Coreboot has no disk or filesystem or even device access facilities, however. It's just "pull an image out of flash, do the bare essential hardware initialization to get to a C runtime environment, then jump into the image". One way around it might be to concatenate the modules and a kernel together with a kind of mezzanine level that does all the module linking, then jumps into the kernel. I suppose you could also build that functionality into the kernel itself, or perhaps even coreboot. I suspect there might be some license issues that kept us from being able to build these modules into the kernel in the first place, though, and that might affect the choice as well. From owner-freebsd-hackers@freebsd.org Tue May 28 12:52:17 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A28015C122C for ; Tue, 28 May 2019 12:52:17 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BA877B34; Tue, 28 May 2019 12:52:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f68.google.com with SMTP id m14so1288313lfp.12; Tue, 28 May 2019 05:52:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Vq8xG+BoH/WJLQc6Vg/2yKmwrYga6rfuQ5p0GC0Ko2g=; b=PjK3UGnvUXnfOtnX3/3+kAlUmvIAySQdsjN1U641kN/5ucEW1piAXiPd7Gb5FIV7kk zjQwmOxfRUI/X7E2OHwUyJhxEeOIRCihtZ3IlvIvSezcjQRhg1j8+3QB6L90LSG5j9rd djaDktozdlqdv7uswRzkhEGBIJOQ6wbCPo7ZuGchT+I4M8ATJSc/SCfS6FVE9dznoOSH U2+DdAULgWD7U68a2uOaQz+G2D6utKUz89gMqpGl4BDoWkjpoY39KpJavSd0F+l6oxZO 4bZYwnsh+IE1uQ7vRB7EkMql9gVfjrnHSa9b9UWvBDsPje1SnyEnyDzt9V7CrfckImIb Bm9w== X-Gm-Message-State: APjAAAU08gbGYekGb9nI0jhBfIvOR4ljfXyAARHj1iHpMRVV1JD8JJm1 T9qpqGwGx0Hr+U/QgZtU+1YTrp5z X-Google-Smtp-Source: APXvYqyh0okJ6g5DZEFidpZUBYHYxDvGvUOqLY3Qjm+XovpisFbvI8+qsmsUFtGzfp+GUsaIhO50hA== X-Received: by 2002:a19:5044:: with SMTP id z4mr8700446lfj.80.1559047933862; Tue, 28 May 2019 05:52:13 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id w11sm2882599lfe.32.2019.05.28.05.52.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 05:52:12 -0700 (PDT) Subject: Re: Amazon AMIs To: Warner Losh , Matthew Seaman Cc: "freebsd-hackers@freebsd.org" , Colin Percival , Alex Dupre , Jonathan Anderson References: <8a139c9c-b98b-4a54-1d7c-0ea1e3dc7a72@freebsd.org> <53a0bd68-a6ba-e8ad-4af2-abeb22e92c03@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <74ed9ad5-58d9-db02-2e20-b053ba5eeb87@FreeBSD.org> Date: Tue, 28 May 2019 15:52:11 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BA877B34 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.68 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.09 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.93)[-0.931,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.15)[ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.28), country: US(-0.06)]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.167.85.209.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 12:52:17 -0000 On 21/02/2019 18:17, Warner Losh wrote: > On Thu, Feb 21, 2019 at 1:02 AM Matthew Seaman wrote: > >> On 20/02/2019 22:32, Jonathan Anderson wrote: >>> On 20 Feb 2019, at 18:50, Alex Dupre wrote: >>> >>>> Colin Percival wrote: >>>>> Last time I looked at this, we weren't handling hotplug/hotunplug of >>>>> "NVMe" >>>>> disks properly on the m5/c5/etc. instances. I opted to recommend the >>>>> instance >>>>> which completely works rather than the one with slightly better >>>>> performance... >>>> >>>> It does happen only on a few instances, but I get some freezes on new t3 >>>> machines: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235856 >>>> >>>> They are indeed cheaper and more performant, but not 100% reliable in >>>> every workload. >>> >>> https://www.xkcd.com/937 ? >>> >> >> Yes, indeed. That's a very good reason not to recommend the newest and >> shiniest. I haven't seen any problems so far, but then again it's only >> been a day or so and we haven't got into the full testing regime quite >> yet. I'll let you know if we do run into problems. >> >> Is there work on hot-plug NVMe going on? ISTR jmg@ mentioning hotplug >> PCI at the dev summit at Stockholm EuroBSDCon, but not much since then. >> > > It's hot-unplug that doesn't work quite right. Hotplug works, I believe, if > you have PCI_HP in your kernel, I believe. > > What's needed is about a solid week of cleanup and testing in this area, > however. I am not sure about the context of the latest question... whether it was about NVMe hot-plug on real modern hardware or whether it was still about AWS. In the latter case, as Colin pointed out earlier[*], PCI_HP would not help at all, because the emulated bridge is not a PCIe bridge. It seems that they use a mechanism based on an older specification, PCI Standard Hot-Plug Controller and Subsystem Specification. I believe that FreeBSD never implemented it. [*] http://www.daemonology.net/blog/2017-11-17-FreeBSD-EC2-C5-instances.html -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue May 28 14:22:13 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AED44159E260; Tue, 28 May 2019 14:22:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2154F83557; Tue, 28 May 2019 14:22:12 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4SEM2wH015969; Tue, 28 May 2019 07:22:02 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4SEM2fR015968; Tue, 28 May 2019 07:22:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905281422.x4SEM2fR015968@gndrsh.dnsmgr.net> Subject: Re: FreeBSD and Coreboot In-Reply-To: To: Eric McCorkle Date: Tue, 28 May 2019 07:22:02 -0700 (PDT) CC: Warner Losh , Nathan Whitehorn , FreeBSD Hackers , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2154F83557 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.92)[-0.923,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 14:22:13 -0000 > On 5/28/19 12:46 AM, Warner Losh wrote: > > > > > > On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn > > wrote: > > > > > > > > On 2019-05-27 19:14, Warner Losh wrote: > > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > > > > > > wrote: > > > > > >> > > >> On 2019-05-27 15:50, Eric McCorkle wrote: > > >>> On 5/27/19 5:53 PM, Edward Napierala wrote: > > >>>> On Mon, 27 May 2019 at 16:14, Eric McCorkle > > > > > >> wrote: > > >>>> [..] > > >>>> > > >>>>> My plan is roughly this: > > >>>>> > > >>>>> * Refurbish the GRUB port, get it working again in QEMU > > (possibly on > > >> one > > >>>>> of my machines), also possibly push a patch to GRUB to use the > > keybufs > > >>>>> mechanism to pass in GELI keys. > > >>>>> > > >>>>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU > > >>>>> > > >>>>> * Possibly create a coreboot port (uncertain how this would > > work, since > > >>>>> Coreboot has its own extensive config menu) > > >>>>> > > >>>>> * Hold my breath and test it out on real hardware (I have a > > Librem 13 > > >> r1 > > >>>>> for this purpose) > > >>>>> > > >>>>> * Possibly try getting the FreeBSD kernel to work as a coreboot > > >> payload. > > >>>> Out of curiosity - why the kernel and not loader(8)? > > >>>> > > >>> If I understand coreboot correctly, loader would have to directly > > >>> manipulate devices _without a BIOS_.? That is, it would have to > > have an > > >>> entire device detection/interface layer, which I don't believe > > is the > > >>> case today. > > >>> > > >>> At least in the EFI case, loader is talking through the system's EFI > > >>> implementation, which takes care of all that for you.? BIOS > > works in a > > >>> similar way.? My sense is getting loader to the point where it > > could be > > >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an > > >> undertaking. > > >> On IBM PowerNV systems, which also don't provide interfaces to a > > >> second-stage loader, we just abandoned loader(8). It's way too > > much work. > > >> > > > How do you use tunables and loadable modules? > > > > > > Warner > > > > > > > The firmware on PowerNV has a way to write tunables to the device-tree, > > which we rehydrate into something that looks like it came from loader. > > > > We don't usefully support loadable modules at the moment. The firmware > > can optionally load exactly one file from the boot filesystem and pass > > it to the kernel (for Linux, the initrd). There are a couple of ways to > > imagine exploiting this for kernel modules, but all of them are kind of > > crummy. > > > > > > Now that the loader supports a ram disk, we are almost to something > > useful... but yea, almost and crummy often go hand in hand. > > This is looking out ahead of my current roadmap, but if you were to do a > kernel as the coreboot payload, there'd need to be some kind of trick to > support ZFS-only systems. > > ZFS requires modules, which are typically pre-loaded (and linked) by > loader (or GRUB). Coreboot has no disk or filesystem or even device > access facilities, however. It's just "pull an image out of flash, do > the bare essential hardware initialization to get to a C runtime > environment, then jump into the image". ZFS does not "require" modules, you can statically compile both opensolaris and zfs into your kernel. > > One way around it might be to concatenate the modules and a kernel > together with a kind of mezzanine level that does all the module > linking, then jumps into the kernel. I suppose you could also build > that functionality into the kernel itself, or perhaps even coreboot. It is called a statically linked kernel, no modules at all. > I suspect there might be some license issues that kept us from being > able to build these modules into the kernel in the first place, though, > and that might affect the choice as well. I do not know of a license issue for US, linux has one due to incompatibility of a GPL kernel with a CDDL ZFS module, thankfully we do not have that issue. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue May 28 15:41:28 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81ABC15A3876; Tue, 28 May 2019 15:41:28 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2428185C89; Tue, 28 May 2019 15:41:28 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id g18so18155991otj.11; Tue, 28 May 2019 08:41:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7mFP629XXHkvIS9PRfhZv6JcHIF8FHaKF/7IJ1tg37g=; b=b6Q3I1qtmGy6PfPg8jM5XdU345bW5MtZQ34ixNBMWL5yG+CHpuISC6q3BQu75s2PL7 QT0n72kKV93Kc583fMRB1xhDx1yD4NOGjQ5/ySDhJSSFC9gQby6c/ZwcI/axF2ZwyKdc 1cKTNs4wHO6CedtIVvNhLXpCtOajevPk64lqUxkFa7YFxYfbTQoSNtxkqc8/d5T+7r7V 5vaBfyqqlrwYy4S3gh2cGWeMZmFftmuJ43AZH2+4L7OYZIQA4sb/5t5CPXmhHBjXXjRf jBQ9NREdtwIXkiLOAbEtiCmbbNCoRq191ZxyDLblA5din4OBnj37OAy7uzceFrumv4Zk dEUg== X-Gm-Message-State: APjAAAUidJxsiHRhil6Gaa2oYRbSKy+juOfTFVaN3qY8tKahQap3KAht S1PqCziTeSw9SFrJ4crxMgrrlwLg/teAIZ5qtyU= X-Google-Smtp-Source: APXvYqxdKlgQDAZd0rVz1kTCKAKz67KchoSC71iAsPkm5jnJvEjgH/isLw5WMmMNY34d+EOxbXv+L6gEn7PFmzsPuX0= X-Received: by 2002:a9d:469b:: with SMTP id z27mr3200209ote.11.1559058086922; Tue, 28 May 2019 08:41:26 -0700 (PDT) MIME-Version: 1.0 References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> In-Reply-To: From: Edward Napierala Date: Tue, 28 May 2019 16:41:15 +0100 Message-ID: Subject: Re: FreeBSD and Coreboot To: Eric McCorkle Cc: Warner Losh , Nathan Whitehorn , FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2428185C89 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.90)[-0.903,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 15:41:28 -0000 On Tue, 28 May 2019 at 12:17, Eric McCorkle wrote: [..] > > Now that the loader supports a ram disk, we are almost to something > > useful... but yea, almost and crummy often go hand in hand. > > This is looking out ahead of my current roadmap, but if you were to do a > kernel as the coreboot payload, there'd need to be some kind of trick to > support ZFS-only systems. > > ZFS requires modules, which are typically pre-loaded (and linked) by > loader (or GRUB). Coreboot has no disk or filesystem or even device > access facilities, however. It's just "pull an image out of flash, do > the bare essential hardware initialization to get to a C runtime > environment, then jump into the image". A ramdisk could help with that - boot with UFS-formatted ramdisk image as rootfs, have init(8) execute a script that loads zfs.ko and whatever other kernel module that's neccessary, and reroot into ZFS. From owner-freebsd-hackers@freebsd.org Tue May 28 18:17:38 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1628415A7AE4 for ; Tue, 28 May 2019 18:17:38 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with ESMTP id 783AE8B785 for ; Tue, 28 May 2019 18:17:37 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 15625 invoked from network); 28 May 2019 18:21:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 28 May 2019 18:21:02 -0000 Subject: Re: Amazon AMIs To: Andriy Gapon , Warner Losh , Matthew Seaman Cc: "freebsd-hackers@freebsd.org" , Alex Dupre , Jonathan Anderson References: <8a139c9c-b98b-4a54-1d7c-0ea1e3dc7a72@freebsd.org> <53a0bd68-a6ba-e8ad-4af2-abeb22e92c03@FreeBSD.org> <74ed9ad5-58d9-db02-2e20-b053ba5eeb87@FreeBSD.org> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@freebsd.org; prefer-encrypt=mutual; keydata= mQGhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgStCVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+iGEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEuQINBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFiEkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <79d5cdad-3a95-de88-25ee-0dd8d27a442e@freebsd.org> Date: Tue, 28 May 2019 11:19:07 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <74ed9ad5-58d9-db02-2e20-b053ba5eeb87@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 783AE8B785 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 18:17:38 -0000 On 5/28/19 5:52 AM, Andriy Gapon wrote: > On 21/02/2019 18:17, Warner Losh wrote: >> It's hot-unplug that doesn't work quite right. Hotplug works, I believe, if >> you have PCI_HP in your kernel, I believe. >> >> What's needed is about a solid week of cleanup and testing in this area, >> however. > > I am not sure about the context of the latest question... whether it was about > NVMe hot-plug on real modern hardware or whether it was still about AWS. > In the latter case, as Colin pointed out earlier[*], PCI_HP would not help at > all, because the emulated bridge is not a PCIe bridge. > It seems that they use a mechanism based on an older specification, PCI Standard > Hot-Plug Controller and Subsystem Specification. Right, these EC2 instances look like they have NVMe devices being hotplugged on a legacy PCI bus attached to an Intel 440FX chipset. There is no real hardware which behaves the same way as these VMs. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Tue May 28 20:16:34 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8E9415AB0BF for ; Tue, 28 May 2019 20:16:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D33FE68203; Tue, 28 May 2019 20:16:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f65.google.com with SMTP id b11so55206lfa.5; Tue, 28 May 2019 13:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BtiFdOav59k9+BkDATjDBJCAUqs7v5YuqIuKPioe+LY=; b=NvhEMX4BiLRzQpOSkJetaz7+7XyNw9VGZoeMh1cARkm7C1BNNNcw7H1zrRXmOqMHha Aqp+1I/QTFqycUJEasGCUOD+F62ihmAdOWSQb3LYWpdVChwZvRHlmp4F+X2zXBY6em4R U3Ryp4OSz543grL8Uld6j4lJ7WZlqV9ISTu4j+V46MEbmVEE83/dgPBRAdnyAhL4WDpe p+XgC2VJlIWtquNz7rhva+vDjvIrDG/mvV1a5p0JRhUNCOfZWkHaFM1MGmNPPYXQFXqq OMMxJCHSrqK74Qx2Lmqo1BdJBUCcqbZnkc4n5CBUph++2Yb/7m5TOxn/1/iZNw1VxrFZ DFPQ== X-Gm-Message-State: APjAAAUS/QS7C60Dj/JyEKtwNlZzzojZgVX5rUrz6Un+LQQvclwE0tp7 7rUW1EiiBNCAUEiotss0zMt8uMTG X-Google-Smtp-Source: APXvYqycEvV/XMoqdhS9CcRkja/zOGXGCRH/agcRleRW3G2SKTsdBtpmGy8e0+ovPCxDNadXLEEsUA== X-Received: by 2002:ac2:5449:: with SMTP id d9mr22048944lfn.126.1559074590719; Tue, 28 May 2019 13:16:30 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q23sm3149240ljg.35.2019.05.28.13.16.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 13:16:29 -0700 (PDT) Subject: Re: Amazon AMIs To: Colin Percival , Warner Losh , Matthew Seaman Cc: "freebsd-hackers@freebsd.org" , Alex Dupre , Jonathan Anderson References: <8a139c9c-b98b-4a54-1d7c-0ea1e3dc7a72@freebsd.org> <53a0bd68-a6ba-e8ad-4af2-abeb22e92c03@FreeBSD.org> <74ed9ad5-58d9-db02-2e20-b053ba5eeb87@FreeBSD.org> <79d5cdad-3a95-de88-25ee-0dd8d27a442e@freebsd.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <2fd62a3f-4490-235f-5aab-e09b21dc14d7@FreeBSD.org> Date: Tue, 28 May 2019 23:16:27 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <79d5cdad-3a95-de88-25ee-0dd8d27a442e@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D33FE68203 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.65 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.81)[-0.810,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; IP_SCORE(-1.15)[ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.29), country: US(-0.06)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[65.167.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[65.167.85.209.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 20:16:34 -0000 On 28/05/2019 21:19, Colin Percival wrote: > On 5/28/19 5:52 AM, Andriy Gapon wrote: >> On 21/02/2019 18:17, Warner Losh wrote: >>> It's hot-unplug that doesn't work quite right. Hotplug works, I believe, if >>> you have PCI_HP in your kernel, I believe. >>> >>> What's needed is about a solid week of cleanup and testing in this area, >>> however. >> >> I am not sure about the context of the latest question... whether it was about >> NVMe hot-plug on real modern hardware or whether it was still about AWS. >> In the latter case, as Colin pointed out earlier[*], PCI_HP would not help at >> all, because the emulated bridge is not a PCIe bridge. >> It seems that they use a mechanism based on an older specification, PCI Standard >> Hot-Plug Controller and Subsystem Specification. > > Right, these EC2 instances look like they have NVMe devices being hotplugged > on a legacy PCI bus attached to an Intel 440FX chipset. There is no real > hardware which behaves the same way as these VMs. I guess so, but I believe that it still conforms to the mentioned specification, at least to a degree (google key words are SHPC+PCI). But I must admit that I haven't actually read it, just skimmed a couple of sections. It looks like Linux has support for that kind of the hot-plug. Just found some additional interesting details: https://github.com/intel/nemu/wiki/ACPI-PCI-discovery-hotplug -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue May 28 22:51:16 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EFC015AEFC2; Tue, 28 May 2019 22:51:16 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B5096EB2B; Tue, 28 May 2019 22:51:12 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-pl1-x634.google.com with SMTP id g9so148474plm.6; Tue, 28 May 2019 15:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=PewRgrcLsE1Pkei/lgF1JJ6vDiNsSrMmPO1yiU/aQjs=; b=iL0T2W8s1kjtUXURJb66Q7K/MGTKczXDzrRiRBwUrvsjmq8XoFV54gslV8yj/XmSet Ipv+W6h4Zy1zNZAMYYDAZfBG4Wma7+P89B9zx4D/728QzfKc7vtlFOrFAV65dBAUJ27m h30rEvicRBPOf0hPoSqYc6oXjkhSYN5/pQBxc3/8gP/3qZ0z6r0NFTc7Tgnt0VqKFB8w vEq1PHKqI9ZGYhjZpAxlY2ruBT0HeK/Jaf0CorlYUHfH5xT8DfQpOhLFG1ppN9mIdHDg Wi1SOpDUx8A2F6L/5U0qXZfbQzeRKpYK70S0Z0zvJtPj7xUimsLn3zOZTcm01zyMgO1p 27Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:cc:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=PewRgrcLsE1Pkei/lgF1JJ6vDiNsSrMmPO1yiU/aQjs=; b=owFFWQY2gb/1GcsrGVQp8regk79ML2SYMfjNMAwdvDUzONsmncvpkMmHvUiwW9L5ls Bi8N0WFu93xtel+R1Gc00Bnd9yapnmNJu+NDQkn8+E7LIO9/zcBOJa+14C7n36iDJFON qK6sF3p9Obbje5OGxzLlneiLJIFy8+dZjKqQzCGE382seIDT+gyFBlHgX/UK72lAt3gz fabfRtJ9MjjqHyBAd1NPrtXO+WnFp6y22Lht2B7untssYbFAA4OU4rCD72qb9bxz2g6P glykeTmzdoCM3a2YTj1mdbHkPxzKiyEuAWbHd5ebt3tlHi20anYfytYLzFQRJkotHCXr DPng== X-Gm-Message-State: APjAAAVMHCaqRvMAJi/r+Yjn3/jZ0Pg94JbhqF8Bqr95AJeZKJzatmGS 7V5w0q8NCgmY0Rdc6x4KAVAI2ulGGXM= X-Google-Smtp-Source: APXvYqwn8/j5XXByWa5wXFvKsJh4WMM/WIM4ldI04smmGtg/PygW9S3pqFqy0J+K6AVk2ZJZKcSfMg== X-Received: by 2002:a17:902:9a9:: with SMTP id 38mr95809372pln.10.1559083870762; Tue, 28 May 2019 15:51:10 -0700 (PDT) Received: from [192.168.1.25] (c-73-170-47-221.hsd1.ca.comcast.net. [73.170.47.221]) by smtp.gmail.com with ESMTPSA id t25sm29608488pfq.91.2019.05.28.15.51.09 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 15:51:10 -0700 (PDT) Sender: Theron Tarigo From: Theron To: soc-status@freebsd.org Subject: GSoC: Separation of Ports Build Process from Local Installation Cc: freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org, Bakul Shah Message-ID: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> Date: Tue, 28 May 2019 18:51:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 0B5096EB2B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iL0T2W8s; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of therontarigo@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=therontarigo@gmail.com X-Spamd-Result: default: False [-6.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.90)[ip: (-8.88), ipnet: 2607:f8b0::/32(-3.30), asn: 15169(-2.29), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 22:51:16 -0000 Hello All, For Google Summer of Code 2019 I am working on FreeBSD's ports tree makefiles towards eliminating the dependency of the ports building process on the local system's installed packages.  Currently this level of separation can only be accomplished in practice through chroot or Jail.  The project will eliminate the need for cooperation of the root user since /usr/local will not need to be touched. The major technical obstacle to be overcome is that ports expect to find files of their dependencies installed in /usr/local.  To support this without touching that location on the installed system, file accesses will be redirected to a location controlled by the ports build process through use of a library to intercept file accesses. Once I have that working (well enough to build one port at a time) I will move on to modify bsd.port.mk itself (and related files) to utilize this mechanism for virtual installation of port dependencies during builds. The full project proposal can be seen at https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit . My goal is that this work can be integrated well enough into /usr/ports/Mk so that unlike Jail, no set up work should be required for using ports tree to build a set of installable packages. Please let me know if you are interested in this project; feedback is appreciated.  If someone would like to provide ongoing feedback or mentorship that would be especially helpful.  Bakul Shah is my mentor officially for GSoC but I would be happy to have additional support from someone who is experienced with internals of the port infrastructure makefiles. Theron Tarigo From owner-freebsd-hackers@freebsd.org Wed May 29 03:28:55 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6807615B4D35; Wed, 29 May 2019 03:28:55 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC62F7713D; Wed, 29 May 2019 03:28:54 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4T3SgeG018874; Tue, 28 May 2019 20:28:42 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4T3Sfep018873; Tue, 28 May 2019 20:28:41 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905290328.x4T3Sfep018873@gndrsh.dnsmgr.net> Subject: Re: GSoC: Separation of Ports Build Process from Local Installation In-Reply-To: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> To: Theron Date: Tue, 28 May 2019 20:28:41 -0700 (PDT) CC: soc-status@freebsd.org, Bakul Shah , freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: CC62F7713D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:28:55 -0000 [ Charset UTF-8 unsupported, converting... ] > Hello All, > > For Google Summer of Code 2019 I am working on FreeBSD's ports tree > makefiles towards eliminating the dependency of the ports building > process on the local system's installed packages.? Currently this level > of separation can only be accomplished in practice through chroot or > Jail.? The project will eliminate the need for cooperation of the root > user since /usr/local will not need to be touched. > > The major technical obstacle to be overcome is that ports expect to find > files of their dependencies installed in /usr/local.? To support this > without touching that location on the installed system, file accesses > will be redirected to a location controlled by the ports build process > through use of a library to intercept file accesses. Assumption of /usr/local was considered wrong long long ago and it should always be ${PREFIX}. Any place that actually assumes this value to be /usr/local should be fixed. Had this policy been properly maintained it would simply be a mater of changing ${PREFIX} to a new and empty place before starting a ports build and things should of just worked. Restoration to this ancient and functional behavior is desirable at least on my part. > Once I have that working (well enough to build one port at a time) I > will move on to modify bsd.port.mk itself (and related files) to utilize > this mechanism for virtual installation of port dependencies during builds. > > The full project proposal can be seen at > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit > . > > My goal is that this work can be integrated well enough into > /usr/ports/Mk so that unlike Jail, no set up work should be required for > using ports tree to build a set of installable packages. > > Please let me know if you are interested in this project; feedback is > appreciated.? If someone would like to provide ongoing feedback or > mentorship that would be especially helpful.? Bakul Shah is my mentor > officially for GSoC but I would be happy to have additional support from > someone who is experienced with internals of the port infrastructure > makefiles. > > Theron Tarigo Regards, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed May 29 06:57:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62AFB15B971B for ; Wed, 29 May 2019 06:57:05 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496B184B56; Wed, 29 May 2019 06:57:04 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f173.google.com with SMTP id m22so1081047ljc.3; Tue, 28 May 2019 23:57:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HCKRu6897mgPCMH6Obja36q9U2ja1oozgvxFMDaGVhc=; b=TJ9rQ5ww+ZMG/1h88pgBGHS+X8tJpEsCGp2T+r4/0O/n5ryAARLxJcCwhsSH7vHCc0 Rp156/toO0zprJbkUFgdxlr1Jcgeotk2NXn6VJXP4puy6fgyD0QZ7sHqWL9B4YIJQjuI TGvP65/NkbY6rvfDrQJgJuakHNA+1dCMa/RhR2vrrgQbbdMjIhgkPEPahqbOdgxhcPyQ SrW/SRZnGr+eZzoIGVA9RM+efJ4ek7TSrow5gCmuCH/LtTcfgR/TMLiZFN6xzhqel+oX 3GD10yPkm5Z+Bligt21405HKV/LnYxwgTP+ng5n74jo4uJmjOJLsCYDbS4YrUKIW5y0X nApQ== X-Gm-Message-State: APjAAAWAZoSfNqvvjNzPwlXUAEmR1kObxYUmfJzzgd2gQqH+7povsVcc qkIBxyGNUUuD3iz8UQijylnodhlA X-Google-Smtp-Source: APXvYqy7O7VidWJpOJwOI80iWhACHRAIfOdS5+DSEazt4CNjJmYEgVLgcstEaSvuB2rn51jmgDVf+Q== X-Received: by 2002:a2e:860a:: with SMTP id a10mr10681736lji.158.1559113022283; Tue, 28 May 2019 23:57:02 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id z24sm3299871lfh.63.2019.05.28.23.57.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 23:57:01 -0700 (PDT) Subject: Re: completely broken IICBUS_IVAR_NOSTOP From: Andriy Gapon To: Ian Lepore , FreeBSD Hackers , Konstantin Belousov References: <1521383420.99081.87.camel@freebsd.org> <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <4de0ed33-47bb-3452-4563-adee8c5070de@FreeBSD.org> Date: Wed, 29 May 2019 09:57:00 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 496B184B56 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.83)[-0.834,0]; RCVD_IN_DNSWL_NONE(0.00)[173.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.26)[ip: (-0.57), ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.29), country: US(-0.06)]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 06:57:05 -0000 On 24/05/2019 20:43, Andriy Gapon wrote: > > A lot of time has passed but the problem is still there. > The "nostop" thing is completely broken. > I have recently thought about this issue a little bit again and now I think that > IVARs are not suitable for nostop property. Simply put, there is no bus (in the > "newbus" sense) where such an IVAR could be configured for a child. > > I see two possible solutions. > > 1. Make "nostop" a property of an iicbus instance. We can keep the current > getter and setter, but they won't be IVAR accessors any more. Also, target > devices for the calls to the functions would need to be adjusted. > > 2. Since this property hasn't found a wider use and remains specific to the > intel drm driver, we could just subclass iicbb and put the quirk into the > subclassed driver. Actually, the only consumer of this feature, drm2, has already been removed from the tree. And the out-of-tree drm driver uses linux i2c implementation in linuxkpi. So, it does not use FreeBSD i2c code at all. Thus, we can completely remove the broken code. And, if we decide to revisit the original problem later, we can design a new solution. Like making NOSTOP a default and, perhaps, adding an explicit STOP flag. > On 23/03/2018 11:56, Andriy Gapon wrote: >> On 18/03/2018 16:30, Ian Lepore wrote: >>> Now for the bad news:  don't use it.  It doesn't work.  It's 100% a bug >>> in the code that maybe kinda-sorta seemed to work for whoever added it, >>> because accidentally the right garbage was on the stack in the local >>> nostop var.  The generic transfer code doesn't check that the accessor >>> failed so it ends up using stack garbage for nostop.  The reason >>> there's g'teed to be no such ivar is because the code is asking the >>> wrong device, and it doesn't even have a handle to the right child >>> device to get the info it wants. >> >> >> Oh, indeed. >> I think that there never was an intention to make "nostop" a property of an i2c >> slave, a child of an iicbus device. I think that instead it was supposed to be >> a property of the iicbus's parent device, an actual i2c adapter driver. >> I guess that the reason that "nostop" became an ivar in iicbus was an incorrect >> understanding of how a "bit-banger" device (something implementing iicbb_if), >> iicbb device and iicbus device are connected. I think that I was among the >> reviewers and I probably had a bit of confusion back then. >> >> >> It seems that the only place where iicbus_get_nostop() is used is >> iicbus_transfer_gen(). iicbus_transfer_gen is used in several i2c drivers as an >> iicbus_transfer method. it's also used in iicbb, thinly wrapped by >> iicbb_transfer(). >> So, iicbus_get_nostop() actually translates to a call to BUS_READ_IVAR(parent, >> device, 1, &v) where I already substituted one for IICBUS_IVAR_NOSTOP. >> Here we can see that while the accessor functions lok quite nice they get >> expanded to generic calls without much context. So, whether that >> BUS_READ_IVAR() call succeeds and what value it gets depends on whether the >> parent bus defines an ivar with a value of 1 and what value that ivar might have >> for the driver device. Many buses define at least a couple of ivars. >> So, a return value of iicbus_get_nostop() could be consistent for a particular >> driver while still being arbitrary. But it can be a piece of stack garbage too, >> just as you said. >> >> The only place where iicbus_set_nostop() is used is intel_iicbb_attach(). >> In that case the ivar is "set" on a wrong device at all (the bit-banger, not iicbb). >> >> >> This definitely needs to be fixed / reworked. >> Perhaps nostop should become a new interface in iicbus_if and iicbb_if... >> > > -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed May 29 09:57:06 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5003815BD70C for ; Wed, 29 May 2019 09:57:06 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from nimbus.fccf.net (nimbus.fccf.net [185.117.82.79]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C052F8B4C1 for ; Wed, 29 May 2019 09:57:05 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from straylight.m.ringlet.net (office.storpool.com [185.117.80.129]) by nimbus.fccf.net (Postfix) with ESMTPSA id 2F55E3CE for ; Wed, 29 May 2019 12:56:55 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 6213d7 by straylight.m.ringlet.net (DragonFly Mail Agent v0.11); Wed, 29 May 2019 12:56:54 +0300 Date: Wed, 29 May 2019 12:56:53 +0300 From: Peter Pentchev To: "Rodney W. Grimes" Cc: Theron , Bakul Shah , freebsd-hackers@freebsd.org, soc-status@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GSoC: Separation of Ports Build Process from Local Installation Message-ID: <20190529095653.GN18665@straylight.m.ringlet.net> Mail-Followup-To: "Rodney W. Grimes" , Theron , Bakul Shah , freebsd-hackers@freebsd.org, soc-status@freebsd.org, freebsd-ports@freebsd.org References: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> <201905290328.x4T3Sfep018873@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="citGix+cyBYE+lqp" Content-Disposition: inline In-Reply-To: <201905290328.x4T3Sfep018873@gndrsh.dnsmgr.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: C052F8B4C1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.988,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 09:57:06 -0000 --citGix+cyBYE+lqp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 28, 2019 at 08:28:41PM -0700, Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] > > Hello All, > >=20 > > For Google Summer of Code 2019 I am working on FreeBSD's ports tree=20 > > makefiles towards eliminating the dependency of the ports building=20 > > process on the local system's installed packages.? Currently this level= =20 > > of separation can only be accomplished in practice through chroot or=20 > > Jail.? The project will eliminate the need for cooperation of the root= =20 > > user since /usr/local will not need to be touched. > >=20 > > The major technical obstacle to be overcome is that ports expect to fin= d=20 > > files of their dependencies installed in /usr/local.? To support this= =20 > > without touching that location on the installed system, file accesses= =20 > > will be redirected to a location controlled by the ports build process= =20 > > through use of a library to intercept file accesses. >=20 > Assumption of /usr/local was considered wrong long long ago and it > should always be ${PREFIX}. Any place that actually assumes this > value to be /usr/local should be fixed. >=20 > Had this policy been properly maintained it would simply be a mater > of changing ${PREFIX} to a new and empty place before starting > a ports build and things should of just worked. >=20 > Restoration to this ancient and functional behavior is desirable > at least on my part. Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where ports find stuff *during the build*, and ${PREFIX} where they install the built files? Of course, I haven't actually touched a FreeBSD ports build in years, so I might very likely be wrong. I also seem to remember a series of test port builds done a long time ago with a different value for LOCALBASE, specifically to catch ports that do not honor the policy in this regard. > > Once I have that working (well enough to build one port at a time) I=20 > > will move on to modify bsd.port.mk itself (and related files) to utiliz= e=20 > > this mechanism for virtual installation of port dependencies during bui= lds. > >=20 > > The full project proposal can be seen at=20 > > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04Or= YAUpdIZs/edit=20 > > . > >=20 > > My goal is that this work can be integrated well enough into=20 > > /usr/ports/Mk so that unlike Jail, no set up work should be required fo= r=20 > > using ports tree to build a set of installable packages. > >=20 > > Please let me know if you are interested in this project; feedback is= =20 > > appreciated.? If someone would like to provide ongoing feedback or=20 > > mentorship that would be especially helpful.? Bakul Shah is my mentor= =20 > > officially for GSoC but I would be happy to have additional support fro= m=20 > > someone who is experienced with internals of the port infrastructure=20 > > makefiles. G'luck, Peter --=20 Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --citGix+cyBYE+lqp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAlzuV2AACgkQZR7vsCUn 3xOGrA/5AZxeLDyWUBJaBzzZZqXkZ4bl4jOLlFqyTQIu9/ABsHQnhrTZxP13nijI gfO2YYHi56+Ubeh6uPay91EqgOf7AaSzWUFDzJvoonrYvCnjcZNIPjG88clKq2nW 3if3JS+XEArUoTisoHFeSpcjVvbmhFxArRAYBrTUfFIx7BvtbcSjsrXaEd3hpePJ 7Gx77gZrS0mOyIsXpRJOgfvtvw4rmtD/+dJnTx/zCXGNI5cyVW6e9BepFCYcu8Ko fuaBIsEVum+ihruO52R3SrcmlpW+ZctaMnijpyrTBUXkGheDNg3SnoVp9mugbtn+ dvFB+lmR4eEOce8BrEnLPpZkV2EpzP6EVrfZ2a3uNOSpXX+oOxcQ4+3culGTtwf9 ctiIWFK1iT+VYKbOr9Oe/7FihgDZW6LFBdVt6FZPCRpcnDyt4YGCYpKB+OYE8qDU COHlc7z6EvzwGJpozZweRHvu6bPnsLC0jU+ktISzj2a9GYsGJWGT99MJcEihuJdO F11VZCem9x9ZfdzqiVviitgpur4CGKgbIPLuT9NEVDxnIdkBxAnGdmxuRs36sAuK QYj9W80p6acaWGyktFhT4MRKTcYT33IZ0DJ0CY6+yiat4N3YkQ7SoSixFnRFA2u3 PBUwA+cNyngvgomx+oVJNhXNvC1ap2xtGC/q5tRN8HpYzZQEP84= =UFym -----END PGP SIGNATURE----- --citGix+cyBYE+lqp-- From owner-freebsd-hackers@freebsd.org Wed May 29 10:16:36 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E5DA15BDFCF for ; Wed, 29 May 2019 10:16:36 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BD878C09E for ; Wed, 29 May 2019 10:16:35 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f178.google.com with SMTP id m22so1636836ljc.3 for ; Wed, 29 May 2019 03:16:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=PCEvXA+YtNih+Wrts+PorgXIX3zHD5VltPkoGvPkwq0=; b=EW1bnn8TRM0g9UEUK+wd5gd7J9tKUtmy+mbt+mvbfysNQoIhtkxIsZbZB9wBb7yP+5 B5s2/Z4FFnzcc4da1OjSaT2k0C+0pcGDTXW0EYVbR93+qgmkGkSHdb5V4lVIhv0kIuzY 2SIO3Yp8vYYpoH59MZocfnfSNgJgpjcsX0OSwxR5loqfgd8VpIJ2wyNAbeaAYaIzNa6m 6FxdYEsdm30ljOr9CFljVZUu2kwWoGGmlyl+WLEDJqGa5APl06d5FIuyeU8kHEgO/tCV hDPnJJ6XNpI2szHrUxZNW1gkO6Dipb592RTYAGluFEVFvqo7Q+DdENKr37vJ3elW8XYF rXgA== X-Gm-Message-State: APjAAAXEIJHwIxXLG/okeDy4m7njSHnyv3aqk1lBxr8OjofX0pKrGxgC LB901cmw+tH2Z7Z+X8zYhYEwESbf X-Google-Smtp-Source: APXvYqxd33jYoiqriOMD68hH3dRDQlyk4wBLbe2+GDpGF6mzjKILUgkeFnAe9m8vCbPXwEmCFJWjqw== X-Received: by 2002:a2e:85c4:: with SMTP id h4mr14011551ljj.217.1559124491647; Wed, 29 May 2019 03:08:11 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 21sm382759ljv.56.2019.05.29.03.08.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 03:08:10 -0700 (PDT) From: Andriy Gapon Subject: setting driver properties for a particular device To: FreeBSD Hackers References: <201905231115.x4NBFMSu037564@repo.freebsd.org> Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> Date: Wed, 29 May 2019 13:08:09 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201905231115.x4NBFMSu037564@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2BD878C09E X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.87)[-0.874,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.24)[ip: (-0.45), ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.29), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[178.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 10:16:36 -0000 On 23/05/2019 14:15, Andriy Gapon wrote: > Author: avg > Date: Thu May 23 11:15:22 2019 > New Revision: 348153 > URL: https://svnweb.freebsd.org/changeset/base/348153 > > Log: > gpioled: add a new hint for initial state > > hint.gpioled.%d.state determines the initial state of the LED when the > driver takes control over it: > 0 - the LED is off > 1 - the LED is on > -1 - the LED is kept as it was By the way, can anyone suggest a mechanism to set device properties like this one _programmatically_ ? I am thinking of a case where I know exactly how everything is wired on a platform. And there is no FDT or alike support for it. And hints are not possible to set up correctly (e.g., bus numbers may float). So, I want to create a gpioled child on a specific bus and I want to set some properties for the device. Of course, I can probably do something like kern_setenv("hints.foo.X.bar", ...) using the child's name and unit number. But that feels a bit cumbersome. And this question is not about gpioled specifically. IVARs is definitely not the right mechanism, because it is about bus-specific properties of devices on the bus. So, it is not aware of properties specific to a driver that attaches to a child device. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed May 29 10:30:07 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC8A15BE7E4 for ; Wed, 29 May 2019 10:30:07 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 221388C9C5; Wed, 29 May 2019 10:30:06 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-ua1-x936.google.com with SMTP id 7so704267uah.1; Wed, 29 May 2019 03:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5g89VnQP8VmIwtIeDZwYqvxmZURHD/YG/FUxm0hI8QA=; b=WKyqTUBUW9p8TMGA9KrnslIvr58d9WGY6PNsoBfigfQsU7CUcdA3AyVjcRLFi1p7AB iofy8bzdjadLqeBrNsqw6L48QIWyNPHLs0Z+N9uruVD2Ha1Ol0b/8ZXny/mMXNtAqdYu YDIJcCjXj9/YWAdKy8s8c1y9bmIwf/QdPGPFvjas8XwCST1OyAWr7rwjYuyPgekkm+e0 MW6g8fsURmb4D8aR9Wqpc4BHm717rh4XWXMHFFfDrIpe9cblVbnGXv5P8EOpQrokvtlT YzKOxTAqQ3UWTBGK5VfIDJ/NYbIeXQqaaiBdEjVHqNry8R7ABEytZG2kzrF1H32mWue8 ttcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5g89VnQP8VmIwtIeDZwYqvxmZURHD/YG/FUxm0hI8QA=; b=X8SF7vOIDJalECB7TpZ7mlI9s2Gdr9l1XtMH0aRRNpvtorv83P1vvXQ6tlEBwHZfL7 CCF6B+5y9sblShtO9u3wZ2LiME1vN3R7uet/snknorgSk+lD9bfsniJmeB/2ycU6fdu6 tR+QLuQfYq32ZLcLjncko23cdShxkpRIoEYhPhIIZ2JsUoNB8GgRhEMnp3PlX6eOqpLZ Z3Ig7ZNXgYbJzoMYqccpzS/VUPY/wD/iCor1XEXFnL2XOOPRESKRijOrZaYVn2CSEUVn OlI/VruFbEXvtrwqY0FUoria+bPS9+5IWTG6EIsHiY/RM+P3ppa0c2TSjDwLCQXyekvc FGrQ== X-Gm-Message-State: APjAAAWAJ2OwUy40hEPfAGsLXJRJSD5IZJJfZarlq/+k1hWvS6nA06hX TDwdDVTSgMlrSWEK1/eyJQ+YAZJ/IjXDVVEDTizNCgMr X-Google-Smtp-Source: APXvYqwvGGgShtxOLjb/MvKVqip4P2+TdjkgQ1KnZV1bIt75eTJGtzJIvQ8YycFnqwhqEmwzLfIZJCHL7Cr9m7LwRtA= X-Received: by 2002:ab0:5a07:: with SMTP id l7mr27845431uad.78.1559125805191; Wed, 29 May 2019 03:30:05 -0700 (PDT) MIME-Version: 1.0 References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> In-Reply-To: <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> From: Michael Zhilin Date: Wed, 29 May 2019 13:29:54 +0300 Message-ID: Subject: Re: setting driver properties for a particular device To: Andriy Gapon Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 221388C9C5 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=WKyqTUBU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mizhka@gmail.com designates 2607:f8b0:4864:20::936 as permitted sender) smtp.mailfrom=mizhka@gmail.com X-Spamd-Result: default: False [-7.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[6.3.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.08)[ip: (-9.77), ipnet: 2607:f8b0::/32(-3.30), asn: 15169(-2.29), country: US(-0.06)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 10:30:07 -0000 Hi, There are kenv and sysctl. Is it far from what you are looking for? Thanks! On Wed, May 29, 2019 at 1:19 PM Andriy Gapon wrote: > On 23/05/2019 14:15, Andriy Gapon wrote: > > Author: avg > > Date: Thu May 23 11:15:22 2019 > > New Revision: 348153 > > URL: https://svnweb.freebsd.org/changeset/base/348153 > > > > Log: > > gpioled: add a new hint for initial state > > > > hint.gpioled.%d.state determines the initial state of the LED when the > > driver takes control over it: > > 0 - the LED is off > > 1 - the LED is on > > -1 - the LED is kept as it was > > By the way, can anyone suggest a mechanism to set device properties like > this > one _programmatically_ ? > > I am thinking of a case where I know exactly how everything is wired on a > platform. And there is no FDT or alike support for it. And hints are not > possible to set up correctly (e.g., bus numbers may float). So, I want to > create a gpioled child on a specific bus and I want to set some properties > for > the device. > Of course, I can probably do something like kern_setenv("hints.foo.X.bar", > ...) > using the child's name and unit number. But that feels a bit cumbersome. > > And this question is not about gpioled specifically. > > IVARs is definitely not the right mechanism, because it is about > bus-specific > properties of devices on the bus. So, it is not aware of properties > specific to > a driver that attaches to a child device. > > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed May 29 10:32:09 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4863A15BEA87 for ; Wed, 29 May 2019 10:32:09 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 581358CC4C for ; Wed, 29 May 2019 10:32:08 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f68.google.com with SMTP id m14so1581329lfp.12 for ; Wed, 29 May 2019 03:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=y7hcdp4QgZXcHoAWgwbTNg0Yy8wfmrFQTN1qpdnbCI0=; b=Wg33NQjOYDiRhA0dAEIpALVFtEjSFAtNo+IdTSeckj/HjqDD/k+vC0cosuLqgQSoaq K4fNfDE4GrOLfQ6Y0Dvi7xuvhObEoQ5B1ajZI8gepAAd0tYMvNI9YCnF8TDFzHjGtZbf 6CD4Ff3E0xzS8L8488RyzBam0atcdM2XAx4q8xgNchfvgkS0noJX7AQOeQtJYaNNvrom sFJs2ObhNFYalR5ZhInXlom2tMhCaYN1yiXcuj3TpTjDJXWEX6+K5WtKzWwbYFE8D695 xb7kZOSKAFXEvHOdzpoNNsznjl+PrqSILZ87HuH4XyUF0/+qVvFTyyK3zy4w6pGFY9O2 N5FQ== X-Gm-Message-State: APjAAAVe9oo/75r03JPq3hC6iChVtqDGfuUsk/DYqPnUdC4OyLRx6RKQ xu/3L0T95GaPCdiq2Fudl5WsoNhy X-Google-Smtp-Source: APXvYqwTJWY4zZUbDcnCzItpfkxF54AS+vXeH0ECoTNKG6zwuxHa8Hc8LJrVSrx/0r6sUvl3ydPvuw== X-Received: by 2002:ac2:518d:: with SMTP id u13mr11965077lfi.40.1559125920952; Wed, 29 May 2019 03:32:00 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id m11sm1668698lfp.10.2019.05.29.03.31.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 03:31:59 -0700 (PDT) Subject: Re: setting driver properties for a particular device To: Michael Zhilin Cc: FreeBSD Hackers References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> Date: Wed, 29 May 2019 13:31:58 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 581358CC4C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.68 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; IP_SCORE(-1.14)[ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.29), country: US(-0.06)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.167.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.167.85.209.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 10:32:09 -0000 On 29/05/2019 13:29, Michael Zhilin wrote: > Hi, > > There are kenv and sysctl. Is it far from what you are looking for? No. When I said programmatically, I meant programmatically from within the kernel. > On Wed, May 29, 2019 at 1:19 PM Andriy Gapon > wrote: > > On 23/05/2019 14:15, Andriy Gapon wrote: > > Author: avg > > Date: Thu May 23 11:15:22 2019 > > New Revision: 348153 > > URL: https://svnweb.freebsd.org/changeset/base/348153 > > > > Log: > >   gpioled: add a new hint for initial state > >    > >   hint.gpioled.%d.state determines the initial state of the LED when the > >   driver takes control over it: > >     0 - the LED is off > >     1 - the LED is on > >    -1 - the LED is kept as it was > > By the way, can anyone suggest a mechanism to set device properties like this > one _programmatically_ ? > > I am thinking of a case where I know exactly how everything is wired on a > platform.  And there is no FDT or alike support for it.  And hints are not > possible to set up correctly (e.g., bus numbers may float).  So, I want to > create a gpioled child on a specific bus and I want to set some properties for > the device. > Of course, I can probably do something like kern_setenv("hints.foo.X.bar", ...) > using the child's name and unit number.  But that feels a bit cumbersome. > > And this question is not about gpioled specifically. > > IVARs is definitely not the right mechanism, because it is about bus-specific > properties of devices on the bus.  So, it is not aware of properties specific to > a driver that attaches to a child device. > > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed May 29 11:31:47 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6ED015BFCD7; Wed, 29 May 2019 11:31:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36C9C8EA79; Wed, 29 May 2019 11:31:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4TBVaLP020569; Wed, 29 May 2019 04:31:36 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4TBVaVD020568; Wed, 29 May 2019 04:31:36 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905291131.x4TBVaVD020568@gndrsh.dnsmgr.net> Subject: Re: GSoC: Separation of Ports Build Process from Local Installation In-Reply-To: <20190529095653.GN18665@straylight.m.ringlet.net> To: Peter Pentchev Date: Wed, 29 May 2019 04:31:36 -0700 (PDT) CC: "Rodney W. Grimes" , Theron , Bakul Shah , freebsd-hackers@freebsd.org, soc-status@freebsd.org, freebsd-ports@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 36C9C8EA79 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 11:31:47 -0000 -- Start of PGP signed section. > On Tue, May 28, 2019 at 08:28:41PM -0700, Rodney W. Grimes wrote: > > [ Charset UTF-8 unsupported, converting... ] > > > Hello All, > > > > > > For Google Summer of Code 2019 I am working on FreeBSD's ports tree > > > makefiles towards eliminating the dependency of the ports building > > > process on the local system's installed packages.? Currently this level > > > of separation can only be accomplished in practice through chroot or > > > Jail.? The project will eliminate the need for cooperation of the root > > > user since /usr/local will not need to be touched. > > > > > > The major technical obstacle to be overcome is that ports expect to find > > > files of their dependencies installed in /usr/local.? To support this > > > without touching that location on the installed system, file accesses > > > will be redirected to a location controlled by the ports build process > > > through use of a library to intercept file accesses. > > > > Assumption of /usr/local was considered wrong long long ago and it > > should always be ${PREFIX}. Any place that actually assumes this > > value to be /usr/local should be fixed. > > > > Had this policy been properly maintained it would simply be a mater > > of changing ${PREFIX} to a new and empty place before starting > > a ports build and things should of just worked. > > > > Restoration to this ancient and functional behavior is desirable > > at least on my part. > > Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where > ports find stuff *during the build*, and ${PREFIX} where they > install the built files? Of course, I haven't actually touched > a FreeBSD ports build in years, so I might very likely be wrong. > I also seem to remember a series of test port builds done a long > time ago with a different value for LOCALBASE, specifically to catch > ports that do not honor the policy in this regard. ${LOCALBASE} came along after the time frame I am speaking of, but yes, that is the present place that ports can find stuff. I think the default is that LOCALBASE=PREFIX=/usr/local which is fine, but there are things that just assume these values to be /usr/local and that is broken. For a list, with a lot of false positives: find /usr/src -type f | xargs grep "/usr/local" I have no idea how to do the same for all of ports, but given prior and not to long ago history, we have ports that break if you are not installing in /usr/local/ > > > Once I have that working (well enough to build one port at a time) I > > > will move on to modify bsd.port.mk itself (and related files) to utilize > > > this mechanism for virtual installation of port dependencies during builds. > > > > > > The full project proposal can be seen at > > > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit > > > . > > > > > > My goal is that this work can be integrated well enough into > > > /usr/ports/Mk so that unlike Jail, no set up work should be required for > > > using ports tree to build a set of installable packages. > > > > > > Please let me know if you are interested in this project; feedback is > > > appreciated.? If someone would like to provide ongoing feedback or > > > mentorship that would be especially helpful.? Bakul Shah is my mentor > > > officially for GSoC but I would be happy to have additional support from > > > someone who is experienced with internals of the port infrastructure > > > makefiles. > > G'luck, > Peter > > -- > Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -- End of PGP section, PGP failed! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed May 29 14:32:29 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE9E215C4817; Wed, 29 May 2019 14:32:28 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 819306F2CD; Wed, 29 May 2019 14:32:28 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-402.fritz.box (p200300CD5F0B620098C1EFFA06128F6D.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:6200:98c1:effa:612:8f6d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "st_esser@t-online.de", Issuer "WISeKey CertifyID Standard Services CA 2" (verified OK)) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8BC321E01A; Wed, 29 May 2019 14:32:27 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: GSoC: Separation of Ports Build Process from Local Installation To: Theron , soc-status@freebsd.org Cc: Bakul Shah , freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org References: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: Date: Wed, 29 May 2019 16:32:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 819306F2CD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 14:32:29 -0000 Am 29.05.19 um 00:51 schrieb Theron: > Hello All, > > For Google Summer of Code 2019 I am working on FreeBSD's ports tree makefiles > towards eliminating the dependency of the ports building process on the local > system's installed packages. Currently this level of separation can only be > accomplished in practice through chroot or Jail. The project will eliminate > the need for cooperation of the root user since /usr/local will not need to be > touched. > > The major technical obstacle to be overcome is that ports expect to find files > of their dependencies installed in /usr/local. To support this without > touching that location on the installed system, file accesses will be > redirected to a location controlled by the ports build process through use of > a library to intercept file accesses. > > Once I have that working (well enough to build one port at a time) I will move > on to modify bsd.port.mk itself (and related files) to utilize this mechanism > for virtual installation of port dependencies during builds. > > The full project proposal can be seen at > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit > . What's wrong with using chroot to provide a clean build environment? That is what synth does, and I have been using my re-implementation of portmaster for this purpose for some time, which uses a chroot jail with read-only null-mounts of all relevant file systems and a clean copy of some files and directories in /etc and /var that can be written without root privileges. The jail is set up in not measurable time (irrelevant compared to the time required to build the port). The only problem with this approach is that it requires extra disk space for the build environment (e.g., the specific C compiler required by some port) plus the work space for the actual port build process. I'm using tmpfs file systems within the jail for the work directory and the copies of parts of /etc and /var that need to be written to. Is there a risk of mis-use of the interception library to attack the system, BTW? [Its use is not restricted to root and it might be used to re-map file system paths for commands that check e.g. policy files to decide whether some operation is authorized ... SUID programs should not be vulnerable to such an attack (since they do not allow the library pre-load required to intercept the file operations), but there might be application programs that are restricted by non-writable files in hard-coded directories that could be subverted this way ... (such a command would be ill-designed, since any user could compile her own interception library, but providing such a library with the system and possibly having hooks for it in libc might simplify such an attack, especially if there is no compiler and easy way to install such a library on a host).] > My goal is that this work can be integrated well enough into /usr/ports/Mk so > that unlike Jail, no set up work should be required for using ports tree to > build a set of installable packages. Yes, this might be beneficial. But there will be huge differences compared to the current build process. And in the end you'll probably have to put the logic used by, e.g., portmaster to track dependencies and determine the availability of up-to-date packages (to use as build dependencies) into the ports system. > Please let me know if you are interested in this project; feedback is > appreciated. If someone would like to provide ongoing feedback or mentorship > that would be especially helpful. Bakul Shah is my mentor officially for GSoC > but I would be happy to have additional support from someone who is > experienced with internals of the port infrastructure makefiles. I'd be interested to get further information about your approach and the progress you make and my experience working on a somewhat similar project with portmaster might allow me to answer questions or provide some help ... Regards, STefan From owner-freebsd-hackers@freebsd.org Wed May 29 16:01:35 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A52FC15A5F68; Wed, 29 May 2019 16:01:35 +0000 (UTC) (envelope-from shivankgarg98@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 776AD72C56; Wed, 29 May 2019 16:01:34 +0000 (UTC) (envelope-from shivankgarg98@gmail.com) Received: by mail-ed1-x52b.google.com with SMTP id m4so4548157edd.8; Wed, 29 May 2019 09:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=KV1XjMcpQSdjFAtWqYlehBgHXhAVRGjX22KBjbzIdUc=; b=g0pPYRvvcVSV9QhhBrqgK2JI4B7Bh1mzUJc6xVKnncRDQT6Zy4lNYS52BOZ7nEDm8+ MYXOnWuRYXVH1y77xqgjO74d9eJEqc+mO7JvZNfDGhtMxgVrsdVbfF24msQZVzAWgXZJ CIHpeEVORUxPb9JfoK8blu39dnUrPcixWR59YDh6ae7IYBArDTSVw6cX+aAzgmVA9Vop c4j+k3FHrC/RdROZ4o4v6K37OzJ9nBlLV4ICimiRylRR/V5DCPv7VWi7CFHm5Ones6OY hKCOJ6Nddx848+hQeWvZWPIUSyM/XqcovLUh31THocsRNrUm7zXu3wMdaz/26BQ5JPz5 vCvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KV1XjMcpQSdjFAtWqYlehBgHXhAVRGjX22KBjbzIdUc=; b=YkEYyX07rtaBcfBn+3YCADY91wsr6QYTK+g/H7i2di7Qejm4iF2P7Lnha3MPtQCM7Z QQjIVk08CFMO8ydgvz0ur7I1e4r3+uC6gcbFqIuR+D/q91AfzOUtSY239y8yD6RAUZ2I Y5giOKHuAJWe7jnH1KOZPI3W3w9i3F5o0jnFdbiZmd6O8vS8+H6peb+6Tf+YG4QPbph2 64g8v4/lbr0f+buUBbTOZjDu8QOEXwzSt+SpdxE3wDS3ICdRvQy9QHQteyGit4Wi83eG kS0ZGCqkwJ6abAZ+M+z+x4eN005wBaiZf//rW/3NnSk8zRzjZXH3SgdEzRZFdlTByCH2 ZhUA== X-Gm-Message-State: APjAAAV6qSPeRTg5EusNCH78kf8k6d5+1UKKb8uUIMty7H3Ef302FGNz QSnN9c/jA9Ycn273pIpfr9aPZgFfwt8J4nNEBPv/pMLXCRI= X-Google-Smtp-Source: APXvYqzwPZpQ+E4b9JtOTHNYC7f/1lZ5F+NOVzbv8xmOe3/1H+SOlY4dm5Y6AIJWGQmFv8TyVNCujBEvUKhvXS4OzSg= X-Received: by 2002:a50:add7:: with SMTP id b23mr136708524edd.215.1559145693041; Wed, 29 May 2019 09:01:33 -0700 (PDT) MIME-Version: 1.0 From: Shivank Garg Date: Wed, 29 May 2019 21:31:22 +0530 Message-ID: Subject: [GSoC'19 Introduction] MAC policy on IP addresses in Jail To: soc-status@freebsd.org, freebsd-hackers@freebsd.org Cc: "Bjoern A. Zeeb" X-Rspamd-Queue-Id: 776AD72C56 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=g0pPYRvv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shivankgarg98@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=shivankgarg98@gmail.com X-Spamd-Result: default: False [-6.60 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[b.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-2.70)[ip: (-8.97), ipnet: 2a00:1450::/32(-2.18), asn: 15169(-2.29), country: US(-0.06)]; NEURAL_HAM_SHORT(-0.89)[-0.891,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 16:01:36 -0000 Hi, This project is aimed at developing a loadable MAC module with the "The TrustedBSD MAC Framework" to limit the set of IP addresses a VNET-enabled Jail can choose from. I am a fourth-year undergraduate student in the Department of EE at IIT Kanpur, India. I am an open-source enthusiast and interested in Operating Systems, Computer Networks, and system security. My mentor for the project is Bjoern A. Zeeb (bz@FreeBSD.org) *About the project:* Using VNET in FreeBSD jails, the root of the jail can set IP addresses of their will, however, sysadmins may need to limit these privileges for different purposes. With a MAC framework, the root of the host can restrict root of the jail to set the desired IP address. Currently, there is no MAC policy module for such restriction, implying these rules are written in the kernel itself. The project is focused on writing a MAC module for "The TrustedBSD MAC framework " to enable easy management of privilege(configuring the network stack) restriction of jail. Features this new MAC policy module should include are- Host be able to define the list(multiple lists) of IP(both IPv4 and IPv6) addresses/subnets for the jail to choose from. Host be able to restrict the jail from setting the certain IP addresses(both IPv4 and IPv6) or prefixes(subnets). Nested Jails should also follow the access control policy. *Approach:* Currently, my approach is to write a loadable kernel module which has checks on IP addresses using various syscalls. Using SIOCAIFADDR(for IPv4) and SIOCAIFADDR_IN6(for IPv6) code and ioctl system call, these checks can be implemented to allow/disallow a particular IP address. *Test Plan:* For testing this module, I will write simple test cases for checking the validity of the module. For generating a test report, I will use Kyua Testing framework. Do Check this project on Github: https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/sys/security/mac_ipacl FreeBSD wiki: https://wiki.freebsd.org/SummerOfCode2019Projects/MACPolicyIPAddressJail Please feel free to share your ideas and feedback on this project. Regards, Shivank Garg From owner-freebsd-hackers@freebsd.org Wed May 29 20:24:22 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE89F15AC488; Wed, 29 May 2019 20:24:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ED3E8562D; Wed, 29 May 2019 20:24:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id W57Lh1r5lGusjW57MhIWeJ; Wed, 29 May 2019 14:24:13 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=E5NmQfObTbMA:10 a=pGLkceISAAAA:8 a=B6KMzFptAAAA:20 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=GO1jMW3m-7Bypqi-ZcwA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 2A4E8684; Wed, 29 May 2019 13:24:10 -0700 (PDT) Date: Tue, 28 May 2019 21:01:58 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> References: <5cdb1c0b-a2dd-c754-daa3-187330ad9ad6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: GSoC: Separation of Ports Build Process from Local Installation To: freebsd-hackers@freebsd.org, Theron , soc-status@freebsd.org CC: Bakul Shah ,freebsd-ports@freebsd.org From: Cy Schubert Message-ID: X-CMAE-Envelope: MS4wfD+zeNXpfJYG7N80YyKmFssDsZPSfFf5YwQHDnX3KW+8t+JdlPw14HOtAtL6HQGotyE2CZrqQBQcBeE/FWYKyJRt9hMywpieTe2q762fPpyZJ7IMRa+j 0iOyuCCJK6W9AvP45aZXeR/UH58y/qEMardwp4MM+KmAwOW6ZF3e8o3+WN47VSvM1dcN64LD0DFwp/uSTnKTf3ysQRiogqwLuLYP+HDwCC+TLh56LGovqQR4 Qku7zLUzQGFNxdr6xeFyg0DvzLEQJOrYUjblcfFUjzJe9UFEW0e4pSWb9fGBDqsTTluNJs35qCYmaP/eMSnxp7u4aFZrpAss3+/8YR5Fgns= X-Rspamd-Queue-Id: 4ED3E8562D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.952,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 20:24:22 -0000 On May 28, 2019 3:51:08 PM PDT, Theron wrote: >Hello All, > >For Google Summer of Code 2019 I am working on FreeBSD's ports tree=20 >makefiles towards eliminating the dependency of the ports building=20 >process on the local system's installed packages=2E=C2=A0 Currently this = level > >of separation can only be accomplished in practice through chroot or=20 >Jail=2E=C2=A0 The project will eliminate the need for cooperation of the = root=20 >user since /usr/local will not need to be touched=2E > >The major technical obstacle to be overcome is that ports expect to >find=20 >files of their dependencies installed in /usr/local=2E=C2=A0 To support t= his=20 >without touching that location on the installed system, file accesses=20 >will be redirected to a location controlled by the ports build process=20 >through use of a library to intercept file accesses=2E > >Once I have that working (well enough to build one port at a time) I=20 >will move on to modify bsd=2Eport=2Emk itself (and related files) to >utilize=20 >this mechanism for virtual installation of port dependencies during >builds=2E > >The full project proposal can be seen at=20 >https://docs=2Egoogle=2Ecom/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04= OrYAUpdIZs/edit > >=2E > >My goal is that this work can be integrated well enough into=20 >/usr/ports/Mk so that unlike Jail, no set up work should be required >for=20 >using ports tree to build a set of installable packages=2E > >Please let me know if you are interested in this project; feedback is=20 >appreciated=2E=C2=A0 If someone would like to provide ongoing feedback or= =20 >mentorship that would be especially helpful=2E=C2=A0 Bakul Shah is my men= tor=20 >officially for GSoC but I would be happy to have additional support >from=20 >someone who is experienced with internals of the port infrastructure=20 >makefiles=2E > >Theron Tarigo >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" How is this different from what poudriiere already does? --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Wed May 29 21:02:08 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6047115ADAA4 for ; Wed, 29 May 2019 21:02:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 3BF858796A for ; Wed, 29 May 2019 21:02:06 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559163720; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=G2az5quBB6kLXUA2p40xHUro9qgrMhnU7WD0GPE7yXHodNsye+r0jTnxdUq2EgFR5n3EEnucKWH0O ogQFFo1pPPzB0i+/nwUn/AoPicFCRm5EQ2Szq4bUoyQmW6Xp0OnIyVhaT6yBFgkCwAHNIITjgN69uN x41Ou4lCl3m8lc+KN4wvhzwTtSE7LNdx6nh7ocy4u/ryUzIpQYleletwRhs18yq2P71y9YleLT+wAg OKgR2pQo2i5N1oYslWOCXuTEaWChpyL4U3EwBCk35HVSf/yiG4jp6RqEr3JYcBW94nfn4WEsGtx3I6 J/V42slLqJdSLdMi/ugFKGB/rN73eiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=jR3ch9wkGYgVZvp7J45LxnmJD20sit1qLaByl18htKM=; b=AB0lqthLhufs+Vw1ko+sKHl++81/b6336BYlTSLiPIWJf1COcgQmOZdhq4r+gtZK+BkmQGqes8nKb Yv9IfVDq961JsJ+Vfa8IPTR0Fc7iQguHXlnGHokgVMkceZo0ZuHaeYRk6n/v2O//CUCbvTbRrK3Jhg GG7lvg7Kf0NuM90wU5l1qhoZJXlxG3BaPWfTR2UmBMTqY0nP9ozeZDxyz8Gr2kIb14HIRW53Wlkiri kXivY5A9Rw8lAecnlgV2yvu8iFZmP4lXZGSjzQV9hSLUGdBbllL7K+x0SvLx4+sN2IlrFGJXtzIfFp 3+RYweVbec+MVQaA4Fln/+UkOMjvvDw== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=jR3ch9wkGYgVZvp7J45LxnmJD20sit1qLaByl18htKM=; b=jI1xApvlRTPL3R/oHzpWgxrjwaJE2mtZ8u9QnLQv17wGUq8VY/Wg5TRJ01K/JAsQL1yhDlynt07YQ QL+DX0Uoaxl8s3NLliBrveOu8GDuzJiq9HnZsZejtcWGwIvpb9udSnPF9jOdh1sP9uVdYBKuTTYZce qC92Bn0hZa43r61qrpsMzNEIvXXOldohUfI5uD5lvS/hGpG2jlbOwluFmB8aAXqeX52+/y+4j/YUH5 DubJexj+nto4XfzjvBUy9o5LCuoBpz897XG1gpBWIRdINZslwUk5P7bxdImAQsizpV1k8SUxPWaSPf 19fbGGXGrErFTqEBfCnO37eGmRKZqig== X-MHO-RoutePath: aGlwcGll X-MHO-User: fdac9a4d-8254-11e9-91aa-b56e4e6b5865 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id fdac9a4d-8254-11e9-91aa-b56e4e6b5865; Wed, 29 May 2019 21:01:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4TL1tDA036094; Wed, 29 May 2019 15:01:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: completely broken IICBUS_IVAR_NOSTOP [Was: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined?] From: Ian Lepore To: Andriy Gapon , FreeBSD Hackers , Konstantin Belousov Date: Wed, 29 May 2019 15:01:55 -0600 In-Reply-To: References: <1521383420.99081.87.camel@freebsd.org> <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3BF858796A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 21:02:08 -0000 On Fri, 2019-05-24 at 20:43 +0300, Andriy Gapon wrote: > A lot of time has passed but the problem is still there. > The "nostop" thing is completely broken. > I have recently thought about this issue a little bit again and now I > think that > IVARs are not suitable for nostop property. Simply put, there is no > bus (in the > "newbus" sense) where such an IVAR could be configured for a child. > > I see two possible solutions. > > 1. Make "nostop" a property of an iicbus instance. We can keep the > current > getter and setter, but they won't be IVAR accessors any more. Also, > target > devices for the calls to the functions would need to be adjusted. > > 2. Since this property hasn't found a wider use and remains specific > to the > intel drm driver, we could just subclass iicbb and put the quirk into > the > subclassed driver. > Sorry for the delay in responding to this, I got busy with $work for a few days. I think the right thing to do would be to implement iicbus_transfer directly in the intel_iicbb_driver, then it could do whatever it wants in terms of ignoring STOP without perturbing other drivers. But I'm not sure it's practical to do so unless someone notices a problem, because I'm not sure how we'd test it otherwise. -- Ian > > On 23/03/2018 11:56, Andriy Gapon wrote: > > On 18/03/2018 16:30, Ian Lepore wrote: > > > Now for the bad news: don't use it. It doesn't work. It's 100% > > > a bug > > > in the code that maybe kinda-sorta seemed to work for whoever > > > added it, > > > because accidentally the right garbage was on the stack in the > > > local > > > nostop var. The generic transfer code doesn't check that the > > > accessor > > > failed so it ends up using stack garbage for nostop. The reason > > > there's g'teed to be no such ivar is because the code is asking > > > the > > > wrong device, and it doesn't even have a handle to the right > > > child > > > device to get the info it wants. > > > > > > Oh, indeed. > > I think that there never was an intention to make "nostop" a > > property of an i2c > > slave, a child of an iicbus device. I think that instead it was > > supposed to be > > a property of the iicbus's parent device, an actual i2c adapter > > driver. > > I guess that the reason that "nostop" became an ivar in iicbus was > > an incorrect > > understanding of how a "bit-banger" device (something implementing > > iicbb_if), > > iicbb device and iicbus device are connected. I think that I was > > among the > > reviewers and I probably had a bit of confusion back then. > > > > > > It seems that the only place where iicbus_get_nostop() is used is > > iicbus_transfer_gen(). iicbus_transfer_gen is used in several i2c > > drivers as an > > iicbus_transfer method. it's also used in iicbb, thinly wrapped by > > iicbb_transfer(). > > So, iicbus_get_nostop() actually translates to a call to > > BUS_READ_IVAR(parent, > > device, 1, &v) where I already substituted one for > > IICBUS_IVAR_NOSTOP. > > Here we can see that while the accessor functions lok quite nice > > they get > > expanded to generic calls without much context. So, whether that > > BUS_READ_IVAR() call succeeds and what value it gets depends on > > whether the > > parent bus defines an ivar with a value of 1 and what value that > > ivar might have > > for the driver device. Many buses define at least a couple of > > ivars. > > So, a return value of iicbus_get_nostop() could be consistent for a > > particular > > driver while still being arbitrary. But it can be a piece of stack > > garbage too, > > just as you said. > > > > The only place where iicbus_set_nostop() is used is > > intel_iicbb_attach(). > > In that case the ivar is "set" on a wrong device at all (the bit- > > banger, not iicbb). > > > > > > This definitely needs to be fixed / reworked. > > Perhaps nostop should become a new interface in iicbus_if and > > iicbb_if... > > > > From owner-freebsd-hackers@freebsd.org Wed May 29 21:40:48 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAB2C15AE58E for ; Wed, 29 May 2019 21:40:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 433D489057 for ; Wed, 29 May 2019 21:40:47 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559166044; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=mUTv5IobotbDiAWHZoi0R4jtcenD36MW8/C2FE7TtERKeRvuJ5V3m6FaTPjDqT4uroEEUTELdWjA3 slO14iRrIigSofKlr/Xtb/l2/POpiiVwk7lik3GAyVZKgT1LUQhFj11ak3+2LsO9koUEOEK0car1Jo 8qNhAM67yBfLPeSIRtDBQ2PljBy4pf/NaYk1vtk72c6vHzw9ndQmKCmnXYY7o26IPcMgV6Pb+KcKVU /Un1BmmivCtaKrXmcF/L0nyzyCWJi1luc2V/au49yQi/HToB91MFsD8nQIT1aerGVHNYHT2T9piu4B 7p4Qh6EK93zEQMr0enbxLKbqjR66ibA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=hLDQqBgWzAzL7dhKzjgo464SUvMRrIRi2SwwhOHhD1k=; b=WJb+tH8/iTfYwdsk/+xCjRjnPWWsXCKex5iBapwL8FuLsu+CCtsAmsS9m7QXYF3VWpsAdaREUQ0jz 7P1I+OTWeyhkfe5BYlYRgMNmHnKjU3kbv6W/6EVSVhap/uXGnmI1Htkv6X2zHPbw/Fqthywu+sDMc7 8PHufiZh0A07viNnjC+qvkK4osRsWJ0utfJduU6M8e5Qx116dO+CaIXwCSpJk1pLpSDxbSwLlrMS/H 3p3iijuzowGIkg/lYhwD5Jy8TkfZuLDyC2uuuR96lkXaOo9c6t6fiDW3Isn3CVFMveq4ekOvVAFz2V JGyFM/oTmIIgiqLabym11/103LzDPkw== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=hLDQqBgWzAzL7dhKzjgo464SUvMRrIRi2SwwhOHhD1k=; b=HTPPfMuKst7kGUs4dYrAUjcPFTqurR6mk0e1c9Bja/61wgSoOCUTyM9q/OMtPqpcgkSJarSzD4N2T 6erQfxoEjYmcB4zfn4VBBWyLp49tTNoXpzCAFnId6rQ3SS8/geL/pPmBHNMIX44uDlS1JANWxZZLz5 kJEW1V1t53/aBVRAeb43UDgxIk0tLxlJfQ2jGvdaYWrOHnEriuntp8TNtGnk8xwGZJ3s0KzjNOxVyJ 6YKhFYBN4q8c1YgegIPlM6wrOwiK8h6v9jH6dr4qhwJZjuL6GdGcu5m5+fAE7103UlvEi/TtaAbM+/ wEzKKAYLt9XkGPAjtzOxQ9w9AlKBm0g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 6742ac49-825a-11e9-91aa-b56e4e6b5865 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 6742ac49-825a-11e9-91aa-b56e4e6b5865; Wed, 29 May 2019 21:40:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4TLedSN036276; Wed, 29 May 2019 15:40:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: setting driver properties for a particular device From: Ian Lepore To: Andriy Gapon , Michael Zhilin Cc: FreeBSD Hackers Date: Wed, 29 May 2019 15:40:39 -0600 In-Reply-To: <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 433D489057 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 21:40:48 -0000 On Wed, 2019-05-29 at 13:31 +0300, Andriy Gapon wrote: > On 29/05/2019 13:29, Michael Zhilin wrote: > > Hi, > > > > There are kenv and sysctl. Is it far from what you are looking for? > > No. When I said programmatically, I meant programmatically from > within the kernel. > Hmmm. Whatever you do, it's going to amount to a conspiracy of agreement between the driver that wants to set this info and the driver that is expected to act on it. So if you don't use the existing hints mechanism, then you'll have to invent something new, and the gpioled driver will have to be updated to also check that new mechanism to see if there is any config info there that affects it. I'm not sure that's a big win over the slight inelegance of crafting a hint string at runtime. -- Ian > > On Wed, May 29, 2019 at 1:19 PM Andriy Gapon > > wrote: > > > > On 23/05/2019 14:15, Andriy Gapon wrote: > > > Author: avg > > > Date: Thu May 23 11:15:22 2019 > > > New Revision: 348153 > > > URL: https://svnweb.freebsd.org/changeset/base/348153 > > > > > > Log: > > > gpioled: add a new hint for initial state > > > > > > hint.gpioled.%d.state determines the initial state of the > > LED when the > > > driver takes control over it: > > > 0 - the LED is off > > > 1 - the LED is on > > > -1 - the LED is kept as it was > > > > By the way, can anyone suggest a mechanism to set device > > properties like this > > one _programmatically_ ? > > > > I am thinking of a case where I know exactly how everything is > > wired on a > > platform. And there is no FDT or alike support for it. And > > hints are not > > possible to set up correctly (e.g., bus numbers may float). > > So, I want to > > create a gpioled child on a specific bus and I want to set some > > properties for > > the device. > > Of course, I can probably do something like > > kern_setenv("hints.foo.X.bar", ...) > > using the child's name and unit number. But that feels a bit > > cumbersome. > > > > And this question is not about gpioled specifically. > > > > IVARs is definitely not the right mechanism, because it is > > about bus-specific > > properties of devices on the bus. So, it is not aware of > > properties specific to > > a driver that attaches to a child device. > > > > > > -- > > Andriy Gapon > > _______________________________________________ > > freebsd-hackers@freebsd.org > > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org > > " > > > > From owner-freebsd-hackers@freebsd.org Thu May 30 15:35:55 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC03D15C59E2 for ; Thu, 30 May 2019 15:35:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 046729107D for ; Thu, 30 May 2019 15:35:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559230552; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=VDb/nbPgNJzofDHjnRLrYNRcw8MEv/pESpTWnjZ/oejSJ4J/n/vCngonv/pE7FMXlwe1juyEzq2R9 MljPYDYcyexwQaGxboVIq48XerldimZyIwvOnvZnkiLA0PlwZBTwlFgBAqNHMyuMD0yYXDxFksOqWB 3Kq1Kl2ij4HXPyu7IqyNHUjfLbcDTRuwaRW6aK377tqYWUvMnQySLGyb7dmEMID6s6Rb5VNDZ6Y9P/ iAnrpDzimh79vgy2x0yef0Xa7OoLsOL9r4in4N1nEHivwY2dAjU43pbiOFPioZBDEG8ESi+iqB7SiQ JLYwWGomTBJyC+1UE2SvfgSntObjHrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=KK2g/kryEA0Q0e/a9iE1JzDgLoQ2DTlz414B3QXWOO0=; b=px4GEWna6/d43z2/SrLhZMK94cpZACVfFT3LCE3cEd3BvXt/1w+Kanzz1JbvpGkI7J+EYc7uZbKCV wF+ygKkW+WsUAHhGjeuKIMwE3d+qd/S8OyO5cKSqxUKb4j7CHiD6EKMk5NFr7b3tGvJtd6wA+vx8s2 nTBRg7aISHV24pOV8CMSsFerFfi6znxR+p0OHGkcFLh3pt9gyOV/aln2yrfH7CDvdE1b31iTjiio8N 5GUA9PCcW/mA/BXz0HLpl2lrNwrbelaW4FVBl9E0tVltVDDwxB/lDAu3+iyM0c/LTSONuIV7DUCljR OFbHOvqgIPXkr6rs6XBJtXJa+OZMvOQ== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=KK2g/kryEA0Q0e/a9iE1JzDgLoQ2DTlz414B3QXWOO0=; b=gOsi7hK3qEmAGj0SlsAcfZSelHMZhaD4DfB1tGJBKxG8k7l2lo5SoFYBSwiCUbLt5DHuSMkjFejX/ k1MFSuhnzodaF33i4IGtszmslSsdCtDzPN9d3p6NF10iZvlUXF7LnSn02q/+BzfG5D4SHe3fedPKiG ai5Vhq6hXbhxk0pgh7QLS5fvaYb8l7PDtV+T6ubyKgJM61WahJlFNA66lVHUS72OVONcLrDuVYQ5c2 u1uMbezXXJWKqEWcqJp8S8o7J0sepkWH0B3PE1Xh2ByTRba1XVi4yxAxDE4ZX+VJC8JybupvcPTyuk +BboYr5zRc9zQAoO6l+PPTY/6QG3S4g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 997b1ff7-82f0-11e9-85c6-c97e5c048ed3 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 997b1ff7-82f0-11e9-85c6-c97e5c048ed3; Thu, 30 May 2019 15:35:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4UFZm5k039379; Thu, 30 May 2019 09:35:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: gpio interrupt on x86 From: Ian Lepore To: Andriy Gapon , FreeBSD Hackers Date: Thu, 30 May 2019 09:35:48 -0600 In-Reply-To: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> References: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 046729107D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 15:35:56 -0000 On Mon, 2019-05-27 at 18:17 +0300, Andriy Gapon wrote: > I would like to run some code when an input pin changes its state. > A GPIO controller that handles that pin is capable of generating an interrupt. > I can configure the type of a signal change that would trigger the interrupt. > The GPIO controller would generate the interrupt on that change. > I would be able to query the controller for a specific pin (if interrupts for > multiple pins are enabled). > All is good. > > Now, the question is how to _properly_ hook my code to the gpiobus hanging off > the controller. > I see that embedded (or not so embedded) platforms typically define a "slave" > interrupt controller. I guess that it defines a new interrupt number (and > interrupt source, etc) for each interrupt capable pin. And then hooking to that > pin is a matter of just installing an interrupt handler for a specific interrupt > and enabling it. > > But I am not sure if the same approach would work on x86. > Is there any other alternative approach? > Perhaps even a more light-weight one? > Any code examples? > > Thank you. The way this works on modern embedded systems is via INTRNG, a framework that allows any number of interrupt controllers of differing types and capabilities to coexist. A gpio hardware driver registers itself as an interrupt controller, then the interrupts it provides (each gpio pin) are accessible as resources just like interrupts on the primary controller, and so drivers just use interrupts that originate from a gpio pin the same as they would any other interrupt. Of course, one required piece of magic to make all this work is metadata: something needs to make the connection between the gpio controller and pin, and the driver that wants to use changes on that pin as an interrupt indication. In the embedded world it's FDT data that describes those connections, so that when a driver asks for interrupt resource index N it reads the FDT data to find a cross- reference to which gpio device and pin to use for that. The connections between the gpiopin interrupt source and the resources allocated by other drivers are made in nexus. This is because typically there isn't a parent-child relationship between the device that manages the gpio pins and the devices that want to use those pins as a source of interrupts; nexus is the common ancestor of both. The x86 world doesn't use INTRNG (but it must have something similar, since all modern x86 hardware has multiple interrupt controllers). So I'm not sure how a gpio driver for x86 might be an interrupt source, but there should be a way for that to happen. The harder part, I think, will be coming up with the metadata to allow another driver which is not a [grand]child of the gpio controller to use those interrupts. -- Ian From owner-freebsd-hackers@freebsd.org Fri May 31 15:12:15 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F194015BF78B; Fri, 31 May 2019 15:12:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 691DD7074E; Fri, 31 May 2019 15:12:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1hWjCM-000I1A-A0; Fri, 31 May 2019 18:12:02 +0300 Date: Fri, 31 May 2019 18:12:02 +0300 From: Slawa Olhovchenkov To: Ian Lepore Cc: lev@FreeBSD.org, freebsd-fs@freebsd.org, freebsd-hackers@FreeBSD.org, Alexander Motin Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me. Message-ID: <20190531151202.GG47119@zxy.spb.ru> References: <55989579-a228-498e-2842-453cad6f315f@FreeBSD.org> <174f71126ca39907370a8904c07546b712ad91b9.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <174f71126ca39907370a8904c07546b712ad91b9.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 691DD7074E X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.61 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.83)[0.827,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.93)[0.928,0]; IP_SCORE(0.00)[country: RU(0.01)]; MX_GOOD(-0.01)[zxy.spb.ru]; NEURAL_SPAM_LONG(0.96)[0.961,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 15:12:15 -0000 On Mon, May 20, 2019 at 10:10:16AM -0600, Ian Lepore wrote: > On Mon, 2019-05-20 at 18:38 +0300, Lev Serebryakov wrote: > > I'm looking at last commit to > > 'sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c' (r345200) and > > have one question. > > > > Is it Ok for two threads to communicate via simple global variable? > > Now > > new code has (line 315): > > > > static boolean_t arc_adjust_needed = B_FALSE; > > > > And after that some threads run code like this: > > > > mutex_enter(&arc_adjust_lock); > > arc_adjust_needed = B_TRUE; > > mutex_exit(&arc_adjust_lock); > > zthr_wakeup(arc_adjust_zthr); > > > > And thread `arc_adjust_zthr` has code like this (line 4874): > > > > return (arc_adjust_needed); > > > > This variable is not atomic. It is not updated and/or read in atomic > > way. What code gives guarantees that `arc_adjust_zthr` will detect > > this > > change? I don't see any. Am I wrong? > > The arc_adjust_needed variable is the gating condition associated with > a condition variable and lock. It is only read or changed while > holding a lock, and the acquiring and releasing of that lock provides > the needed memory barriers. In this case, the association with the > condition variable and lock is somewhat obscured by the way the zthread > timer stuff works. The arc_adjust_cb_check() function is called from > line 193 of contrib/opensolaris/uts/common/fs/zfs/zthr.c, and that's > where you'll find the code that makes it clear this is an idiomatic > condition variable pattern. What about arc_no_grow, for example? arc_no_grow set in arc_reap_cb_check(), called from arc_reap_zthr thread and in arc_lowmem(). arc_no_grow test in arc_adapt(), called from arc_read()/arc_get_data_impl() called from many unsynced thread. How synced visibility of this varibale?