From owner-freebsd-arch@freebsd.org Mon Jun 18 17:08:38 2018 Return-Path: Delivered-To: freebsd-arch@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 95DA910135BD for ; Mon, 18 Jun 2018 17:08:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D7C680B3 for ; Mon, 18 Jun 2018 17:08:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 2301D10AFD4; Mon, 18 Jun 2018 13:08:29 -0400 (EDT) Subject: Re: upstream for contrib/tzcode/stdtme? To: Eitan Adler References: <20a85a8f-29a7-0d8f-64d1-9ba005ffe79c@FreeBSD.org> Cc: "freebsd-arch@freebsd.org" From: John Baldwin Message-ID: <10e35d23-37d8-edf4-fa3b-9663bfdaa629@FreeBSD.org> Date: Mon, 18 Jun 2018 10:08:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 18 Jun 2018 13:08:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:08:38 -0000 On 6/15/18 4:09 PM, Eitan Adler wrote: > On 15 June 2018 at 11:31, John Baldwin wrote: > >> I think this second approach is actually a better plan and is not quite what you >> were suggesting. >> >> That is, import the vendor bits corresponding to our existing code first into >> the vendor area, > > > then svn cp our existing files from libc, zic, etc. into the >> contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only' >> merge to initialize the vendor mergeinfo. >> At that point you should be able to >> svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local >> changes we have and start to think about them. > > At this point both vendor and contrib have the same files, same > layout, but possibly different content? Yes. The different content would be our local changes. > How do we do the update itself then? "svn merge" from the vendor area > into contrib? Yes, just like a normal vendor update. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Jun 20 21:00:24 2018 Return-Path: Delivered-To: freebsd-arch@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 8D193100BC15 for ; Wed, 20 Jun 2018 21:00:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B4DC7450F; Wed, 20 Jun 2018 21:00:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C0F4319106; Wed, 20 Jun 2018 21:00:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id CE8661D0B; Wed, 20 Jun 2018 21:00:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id SNmmyzxFUg4u; Wed, 20 Jun 2018 21:00:20 +0000 (UTC) To: Sean Bruno , freebsd-arch DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com F3E331D04 References: From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8CGwwF AlrozigFCQpgez0ACgkQNddxu25Gl8+m5Af/R3VEdxNMAcDIes9ADhQyofj20SPV3eCJ3HYR OebTSuNdOudGt4AAyA8Ks94u9hiIp5IGsc6RDsT9W7O2vgXhd6eV3eiY5Oif5xLIYrIDVu1Y 1GyRxRrPEn/QOqDN6uFZCPwK1aOapGcYCrO9lB0gMuTVfgHanU61rgC9tMX0OoAOyRd+V3/M 8lDNhjJdF/IpO3SdYzKfkwduy4qamw4Gphcx/RfYQvYLq/eDkP8d50PphWdboqWBwNRHayro W/07OGzfxM5fJ5mBsXPQcO2QcRjkyHf6xCM6Hi1qQL4OnXMNE/ZTX0lnOj1/pH93TlzSHZMP TaiiA/MBD3vGsXBmBg== Organization: FreeBSD Subject: Re: Building and Iterating Message-ID: <686cb08d-5648-52f4-a95e-2faf3ea20bef@FreeBSD.org> Date: Wed, 20 Jun 2018 14:00:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cLS3T9X7IqLoQtZMLERtUmJsi9LnicwMk" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 21:00:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cLS3T9X7IqLoQtZMLERtUmJsi9LnicwMk Content-Type: multipart/mixed; boundary="8eBa8skDHXSIIPJNoKMIHyazfgNjOFlP0"; protected-headers="v1" From: Bryan Drewery To: Sean Bruno , freebsd-arch Message-ID: <686cb08d-5648-52f4-a95e-2faf3ea20bef@FreeBSD.org> Subject: Re: Building and Iterating References: In-Reply-To: --8eBa8skDHXSIIPJNoKMIHyazfgNjOFlP0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/1/2018 10:20 AM, Sean Bruno wrote: > Before I dive into the mk files of a buildworld, I'd like to describe > "what I want" so as to start a discussion of my goal. >=20 > 1. If I select no toolchain (WITHOUT_TOOLCHAIN), but clang needs to be= > built, only build a toolchain that targets the ARCH being requested. >=20 > 2. If I select no toolchain (WITHOUT_TOOLCHAIN), but clang needs to be= > built, give me a knob to turn that aborts the build with a meaningful > message that lets me know I need to update the toolchain on my buildbox= =2E >=20 https://reviews.freebsd.org/D11077 has this but I suspect it's wildly stale already. Also having a knob like this would ultimately lead to someone making their /usr/bin/cc less useful for optimizations like WITH_SYSTEM_COMPILER= =2E > 3. If the boostrap toolchain needs to be built in the normal case, onl= y > target the ARCH being requested. I understand that we "want" a CC > installed that targets all architectures and this is something I agree = with. >=20 Hm yes there is no real reason to have multi-arch support in the WORLDTMP compiler. Though I do have a pending patch to build clang *once* for universe that relies on this full-arch-support behavior but I'm sure it's trivial to continue using it for that piece. --=20 Regards, Bryan Drewery --8eBa8skDHXSIIPJNoKMIHyazfgNjOFlP0-- --cLS3T9X7IqLoQtZMLERtUmJsi9LnicwMk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJbKsBjAAoJEDXXcbtuRpfPC3oIAKnAa82pAv8SjYXWlXb6Hfte 6aHj8IgezMljoMHs+qtUVqJe+lKmqaY82ap1TNxtxUARxJQtRQAqldRlJKT238p1 8EMhcGvVWCZS0VQHrLnOpTme9FoAuyBmze68a1WeJCnSHpy56gFoJqWjlxuu1Jqo YtGeP5+GuxV6tOPOsdMgKQU1XvelESGe/+/iVCWl5OizRd8tF6I65YXJAGQYTRaB m7SkGugwcfOI93s7TjN3EXSGtcz66dpmRCHcrLiDnR3KEPHdyH0ZTD6qX0KCOhO4 KJ4X7LQU+ZkRNfATRFa16Uctm65Hy6wHQm7nIBPCNveOcJdA9akNWYnefNRPk9s= =U/J4 -----END PGP SIGNATURE----- --cLS3T9X7IqLoQtZMLERtUmJsi9LnicwMk-- From owner-freebsd-arch@freebsd.org Thu Jun 21 04:39:21 2018 Return-Path: Delivered-To: freebsd-arch@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 DA6231002A6D; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69DE9884F0; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 06C492B6E4; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f49.google.com with SMTP id m4-v6so1148995lfj.13; Wed, 20 Jun 2018 21:39:19 -0700 (PDT) X-Gm-Message-State: APt69E0xA39M2t4xcmpUxQPTmIrvRSD6+zjEYd9fsA3MIR+Jmdc3e1iN sNLpQ2jgAS9IzWHpi/9/5t2hIGb9PAWg+2VU7E4= X-Google-Smtp-Source: ADUXVKLZ4xqdn6UQAf6HxCynnF7/UvUU9omYVB8ssClncgbglAKmdEiTFSWOHH3OwDxp08v35aG8BzXp4ClOgC+Afmw= X-Received: by 2002:a2e:6506:: with SMTP id z6-v6mr6650919ljb.76.1529555958444; Wed, 20 Jun 2018 21:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 21:38:57 -0700 (PDT) From: Kyle Evans Date: Wed, 20 Jun 2018 23:38:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Proposal: envmode/hintmode rototill To: freebsd-arch@freebsd.org Cc: freebsd-embedded@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 04:39:21 -0000 Hello! The current situation with envmode/hintmode (see: config(5), `env` and `hints` respectively) is less than ideal, and conflicts with some future needs that I have. There will be a decent summary after the next couple paragraphs of background. The problem is that config(5) supplied env/hints are mutually exclusive with loader.conf(5)-driven kenv. The hints situation is slightly better as it can be altered with a sysctl that switches to the dynamic environment and thus pulls in any static hints supplied through config(5) along with whatever hints might have appeared in the chosen static kenv and those mixed in after the switch to dynamic environment. The way I need it to work is that config(5) supplied env is effectively a seed for the static environment. This would then get augmented with whatever MD environment (generally from loader(8)) has been specified. A poor example goal is to be able to have a kernconf with `options VERBOSE_SYSINIT` and debug.verbose_sysinit=0 set to quiet it by default, then have the ability to add in debug.verbose_sysinit=1 through loader(8) to make the VERBOSE_SYSINIT behavior verbose again. This is a bad example because this could be accomplished with `options VERBOSE_SYSINIT=0`, but I think it gets the point across- the kernconf environment is a set of reasonable defaults that may be overwritten by the loader. I had initially thought that maybe there were security considerations to be had here, but loader(8) static env can be switched to by including static_env.disabled=1 in said env- so it wasn't always ignored in the current world order. SUMMARY: I would like to: 1.) Eradicate envmode/hintmode 2.) Augment kernconf env with loader(8) supplied env 3.) Prior to the dynamic environment being setup, hint searches will be conducted across the two dfferent kinds of static environments (if applicable) as well as any static hints that were supplied, in order: loader(8) env, config(5) env, config(5) hints 4.) After the dynamic environment is provisioned (from loader(8) and config(5) environments), add in config(5) hints 5.) Once all of these environments have been merged into the dynamic environment, all hint searches should then just search the dynamic environment. This seems to be the common case for searches at the moment; the dynamic environment is completely merged by the end of SI_SUB_KMEM In the New World Order, there is no such thing as ignoring any of these environments. Each one is either provided or not, and the kernel will use them if they're provided. I have a pretty-close-to-finished patch implementing all of the above. Thoughts? Is there a reason this is a really bad idea? Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Thu Jun 21 15:40:48 2018 Return-Path: Delivered-To: freebsd-arch@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 5ABE910222D6; Thu, 21 Jun 2018 15:40:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BA3B81D9C; Thu, 21 Jun 2018 15:40:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9C59E2F9B5; Thu, 21 Jun 2018 15:40:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f46.google.com with SMTP id g21-v6so4987933lfb.4; Thu, 21 Jun 2018 08:40:47 -0700 (PDT) X-Gm-Message-State: APt69E3l5k0hIwR7JdNeqafTxkp2AS+ovVbN41rOGu9Nvh7rkvXkwyxH mmes/VEW3+Pg2BZn7Q33DMbnI6S9ahxml9HX+9M= X-Google-Smtp-Source: ADUXVKJ71KdHSGeK2egJTy28Wm/Ylelnl20f3mw7s88HThnV8pO22a+jD6U8KNAraeUvuu74oIl6KY8zXPqn2l8suOY= X-Received: by 2002:a19:d046:: with SMTP id h67-v6mr15635995lfg.52.1529595646097; Thu, 21 Jun 2018 08:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:40:25 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Thu, 21 Jun 2018 10:40:25 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Proposal: envmode/hintmode rototill To: freebsd-arch@freebsd.org Cc: freebsd-embedded@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:40:48 -0000 On Wed, Jun 20, 2018 at 11:38 PM, Kyle Evans wrote: > Hello! > > The current situation with envmode/hintmode (see: config(5), `env` and > `hints` respectively) is less than ideal, and conflicts with some > future needs that I have. There will be a decent summary after the > next couple paragraphs of background. > > The problem is that config(5) supplied env/hints are mutually > exclusive with loader.conf(5)-driven kenv. The hints situation is > slightly better as it can be altered with a sysctl that switches to > the dynamic environment and thus pulls in any static hints supplied > through config(5) along with whatever hints might have appeared in the > chosen static kenv and those mixed in after the switch to dynamic > environment. > > The way I need it to work is that config(5) supplied env is > effectively a seed for the static environment. This would then get > augmented with whatever MD environment (generally from loader(8)) has > been specified. > > A poor example goal is to be able to have a kernconf with `options > VERBOSE_SYSINIT` and debug.verbose_sysinit=0 set to quiet it by > default, then have the ability to add in debug.verbose_sysinit=1 > through loader(8) to make the VERBOSE_SYSINIT behavior verbose again. > This is a bad example because this could be accomplished with `options > VERBOSE_SYSINIT=0`, but I think it gets the point across- the kernconf > environment is a set of reasonable defaults that may be overwritten by > the loader. > > I had initially thought that maybe there were security considerations > to be had here, but loader(8) static env can be switched to by > including static_env.disabled=1 in said env- so it wasn't always > ignored in the current world order. > > SUMMARY: I would like to: > > 1.) Eradicate envmode/hintmode > 2.) Augment kernconf env with loader(8) supplied env > 3.) Prior to the dynamic environment being setup, hint searches will > be conducted across the two dfferent kinds of static environments (if > applicable) as well as any static hints that were supplied, in order: > loader(8) env, config(5) env, config(5) hints > 4.) After the dynamic environment is provisioned (from loader(8) and > config(5) environments), add in config(5) hints > 5.) Once all of these environments have been merged into the dynamic > environment, all hint searches should then just search the dynamic > environment. This seems to be the common case for searches at the > moment; the dynamic environment is completely merged by the end of > SI_SUB_KMEM > > In the New World Order, there is no such thing as ignoring any of > these environments. Each one is either provided or not, and the kernel > will use them if they're provided. I have a pretty-close-to-finished > patch implementing all of the above. > > Thoughts? Is there a reason this is a really bad idea? > > Thanks, > > Kyle Evans I've created a phabricator review for my proposed patch here: https://reviews.freebsd.org/D15953 -- this contains the actual rototill as well as associated config(5)/config(8) changes. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Fri Jun 22 15:47:18 2018 Return-Path: Delivered-To: freebsd-arch@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 E5A1A101F335 for ; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA4374F2D for ; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 29E77101F332; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) Delivered-To: arch@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 074BE101F330 for ; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CDFA74F2B for ; Fri, 22 Jun 2018 15:47:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id j135-v6so3528903itj.1 for ; Fri, 22 Jun 2018 08:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=T3gFL0RlTIfEW+Y5MO8jwMIGJBOFD6+KsQwbtoU5PC0=; b=kj/g2bnYhWAa1z3Xz5dVwD3wJE7CS3kje3LzCfiu40A1UVcS/DCve2Y1W08lYt46rw dWDznGh/cVoAt4sXysiPNRlUJtHvK9eZ3MkDMmRhTW8LKY4OjI8UZQDsC0s6i7znrbqI RC0pP4Jlb4bLPnCv5dZzbowyjPNsKyc/QEJHQwYdHmQiSivXQPQurOVx9WyuWWxD26m1 Y0L2yPP7DZMLQxV8q23QyVXfhDY7KcJTe+ohaBQb8nw0Y1I8Cg7vRoVA6Tad6T3u8uv0 w3psg7oBH5EF0Nv1YyrW1DW5X8XkyJEmJJUZwnooSSzPZvysi1LSZflZzYg6PYX9Nr+F jrKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=T3gFL0RlTIfEW+Y5MO8jwMIGJBOFD6+KsQwbtoU5PC0=; b=StpVN50TFFLZ7dOb1sldd1NOvc6hoXDoM/V/KmnNhnQ1l6LqyGJG8cTtlwStQgEjMC FyMxEIaWtONc+1O2aMoIpdfX+Kt/9fQOqV8RixoCrnXQk4e9rdXo9xnAsy17ryHKRTba N47Wr6CrwvQDhxuDDuff1OECnex15795vOpnhnquvg2Q/Z3zwrS83l8PKFpIFmbTRMXs uyTUOKy3AHI/Nn6jphHfV5qCcNL/EqPcpFTrzx1eKXMAcGCUWjWR+/LShtVt++A2qIeX Y6vsFK8UXWe8pT5PyS2gXNn3IB6UkIIanQi5MZXmfOxTJUXNgb/pZS+1buZvHiOMceNM 6W1g== X-Gm-Message-State: APt69E1qU1S7Zk8dgeU1QGYEsMA+iSLHyOUm+pDkfQALY5tb5h+IyYp5 dwvQvB9ECxfFlmr1ZPj0l3ad7Be9/aEuanI4IfwdjPlp X-Google-Smtp-Source: AAOMgpfIm8IXrsBS2P/vyY8ZygbPsIuypBHLOoMGDf1pTQacBvZ8BJ9gWwAJbMxEWNS+0U4Mf5FC77g1wlvHCnUNCOQ= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr1987733itc.36.1529682435411; Fri, 22 Jun 2018 08:47:15 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 08:47:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] From: Warner Losh Date: Fri, 22 Jun 2018 09:47:14 -0600 X-Google-Sender-Auth: NEg1erIF2ClqAys25ZRVeeMeQuY Message-ID: Subject: UEFI Plans / Shifts -- RFC To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:47:18 -0000 Greetings, As I've documented before, I'll be making some addition UEFI changes. To recap, the plan: 1. Remove boot1.efi 2. Enhance loader.efi so it can live on ESP 3. Enhance loader.efi so it can do ping-pong booting 1 is still the plan, but there's some bits left to do. Most of step 2 is done. However, there's some issues that I'd like to work through. 3 is my next task. There's other installer and installworld tasks that are needed before 1 can be done. In the past boot1.efi chose the /, read /boot/config or /boot.config and passed those args to /boot/loader.efi. This was always an imperfect match to UEFI, since we selected video/serial/both and other things for the kernel, but used the EFI conout function which sent the output to whatever the UEFI ConOut variable was set to. In fact, we totally ignored that variable and people had to manually hack together something to try to make things match the variable so the kernel messages would work. There is another vector to pass arguments to /boot/loader.efi, and that's efibootmgr can set args to use that are passed to main w/o needing to read boot.conf at all. So, now that loader.efi is starting up, and we'd like to have verbose output before we select the root filesystem from which we could get the boot.conf to know where to send this output, I'd like to shift things a little. Since we already have almost all the information we need from the uefi boot variable, I'd like to stop parsing boot.conf and shift to using that. I'd like to make the ConOut variable override the command args passed in. So, the new process will be: 1. Parse the args. Get a tentative howto. 2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and RB_SERIAL. If we find a video card in the list, we'll use it. If we find serial in the list, we'll use that and set RB_SERIAL. If we find both, we'll set RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll set comconsole_speed. 3. We'll parse loader.conf 4. Just before we boot, if we have the 'efi' console set and serial was set in the ConOut variable, we'll set hw.uart.console to reflect the speed and the value of comconsole_port[*]. This will result in serial consoles just working almost all the time w/o needing to do anything. The 'almost' part here is because to find the serial port, we have to walk the ACPI name space to find the _CRS that matches the _HID for the serial port. We're given the _UID, but that's just a number whose meaning varies to the point of it being random. While we know that _UID X will refer to the same port from boot to boot, we have no clue what that is on any given board. To work around this, people with non-standard console ports (which everybody with a BMC likely has), you'll need to set comconsole_port in loader.conf. Of course, you'll have had to do that today to make this setup work, so that's nothing new. In the fullness of time, but not for 12, we should just parse ACPI in the UEFI boot loader. This is somewhat non-trivial since we have to write the OS glue for the ACPICA code to have it work in the UEFI environment. I've not investigated doing that in any more detail than to see there's no quick, easy shortcuts. So here's my open questions: (1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the one that's on the ESP or the one in the / we hope to boot from. What if I don't find a /? I am leaning to a 'hard no' on this question because the efibootmgr provides a vector to get command line args to loader.efi that's much better. boot.conf was a hack around the fact you couldn't set command line args in the legacy bios. (2) Should the command line args passed in take precedence? Or should ConOut? Or should ConOut be used first with the command line args augmenting it? (3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have both video and serial? Or should we only set RB_MULTIPLE? Or should we check the command line args and only set RB_SERIAL in this case when -h is on the command line, like we do today. The downstream effect of this choses where THE console of the kernel goes until someone writes a some ttymux code to allow it to go to all the consoles requested by the boot loader. My current code is up at https://reviews.freebsd.org/D15917 if you want to look. As always, what to do comments should likely go here, while 'this code sucks, here's how to make it better' type comments should go on the review. Warner Warner From owner-freebsd-arch@freebsd.org Fri Jun 22 18:18:11 2018 Return-Path: Delivered-To: freebsd-arch@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 04B791023562 for ; Fri, 22 Jun 2018 18:18:11 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0577AB03 for ; Fri, 22 Jun 2018 18:18:10 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 46FF4102355F; Fri, 22 Jun 2018 18:18:10 +0000 (UTC) Delivered-To: arch@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 222B5102355E for ; Fri, 22 Jun 2018 18:18:10 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB30A7AB00; Fri, 22 Jun 2018 18:18:09 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [172.17.133.41] (unknown [12.202.168.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AC1511C65; Fri, 22 Jun 2018 18:18:09 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 22 Jun 2018 11:18:06 -0700 Subject: Re: UEFI Plans / Shifts -- RFC From: Ravi Pokala To: Warner Losh , "freebsd-arch@freebsd.org" Message-ID: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> Thread-Topic: UEFI Plans / Shifts -- RFC References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:18:11 -0000 > To work around this, people with non-standard console ports (which everyb= ody with a BMC likely has), What makes you say that? On most (all?) systems with IPMI that I've seen, the motherboard console po= rt is a normal UART. It just so happens that the UART isn't connected to a D= B9 header, but rather to the serial port on the BMC. The firmware on the BMC= (somehow -- reading the BIOS/UEFI settings directly?) knows the configurati= on of the motherboard console port, and configures its side to match. And th= ere you go: a serial connection between the motherboard console port and the= BMC. What the BMC then does with it -- reflect it over the network using Serial-= Over-LAN, expose it via a web interface, etc. -- is a separate matter entire= ly. -Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: on behalf of Warner Losh Date: 2018-06-22, Friday at 08:47 To: "freebsd-arch@freebsd.org" Subject: UEFI Plans / Shifts -- RFC > Greetings, >=20 > As I've documented before, I'll be making some addition UEFI changes. >=20 > To recap, the plan: > 1. Remove boot1.efi > 2. Enhance loader.efi so it can live on ESP > 3. Enhance loader.efi so it can do ping-pong booting >=20 > 1 is still the plan, but there's some bits left to do. Most of step 2 is > done. However, there's some issues that I'd like to work through. 3 is my > next task. There's other installer and installworld tasks that are needed > before 1 can be done. >=20 > In the past boot1.efi chose the /, read /boot/config or /boot.config and > passed those args to /boot/loader.efi. This was always an imperfect match > to UEFI, since we selected video/serial/both and other things for the > kernel, but used the EFI conout function which sent the output to whateve= r > the UEFI ConOut variable was set to. In fact, we totally ignored that > variable and people had to manually hack together something to try to mak= e > things match the variable so the kernel messages would work. There is > another vector to pass arguments to /boot/loader.efi, and that's efibootm= gr > can set args to use that are passed to main w/o needing to read boot.conf > at all. >=20 > So, now that loader.efi is starting up, and we'd like to have verbose > output before we select the root filesystem from which we could get the > boot.conf to know where to send this output, I'd like to shift things a > little. Since we already have almost all the information we need from the > uefi boot variable, I'd like to stop parsing boot.conf and shift to using > that. I'd like to make the ConOut variable override the command args pass= ed > in. >=20 > So, the new process will be: > 1. Parse the args. Get a tentative howto. > 2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and RB_SERIA= L. > If we find a video card in the list, we'll use it. If we find serial in t= he > list, we'll use that and set RB_SERIAL. If we find both, we'll set > RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll s= et > comconsole_speed. > 3. We'll parse loader.conf > 4. Just before we boot, if we have the 'efi' console set and serial was s= et > in the ConOut variable, we'll set hw.uart.console to reflect the speed an= d > the value of comconsole_port[*]. >=20 > This will result in serial consoles just working almost all the time w/o > needing to do anything. The 'almost' part here is because to find the > serial port, we have to walk the ACPI name space to find the _CRS that > matches the _HID for the serial port. We're given the _UID, but that's ju= st > a number whose meaning varies to the point of it being random. While we > know that _UID X will refer to the same port from boot to boot, we have n= o > clue what that is on any given board. To work around this, people with > non-standard console ports (which everybody with a BMC likely has), you'l= l > need to set comconsole_port in loader.conf. Of course, you'll have had to > do that today to make this setup work, so that's nothing new. In the > fullness of time, but not for 12, we should just parse ACPI in the UEFI > boot loader. This is somewhat non-trivial since we have to write the OS > glue for the ACPICA code to have it work in the UEFI environment. I've no= t > investigated doing that in any more detail than to see there's no quick, > easy shortcuts. >=20 > So here's my open questions: > (1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the > one that's on the ESP or the one in the / we hope to boot from. What if I > don't find a /? I am leaning to a 'hard no' on this question because the > efibootmgr provides a vector to get command line args to loader.efi that'= s > much better. boot.conf was a hack around the fact you couldn't set comman= d > line args in the legacy bios. > (2) Should the command line args passed in take precedence? Or should > ConOut? Or should ConOut be used first with the command line args > augmenting it? > (3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have bo= th > video and serial? Or should we only set RB_MULTIPLE? Or should we check t= he > command line args and only set RB_SERIAL in this case when -h is on the > command line, like we do today. The downstream effect of this choses wher= e > THE console of the kernel goes until someone writes a some ttymux code to > allow it to go to all the consoles requested by the boot loader. >=20 > My current code is up at https://reviews.freebsd.org/D15917 if you want t= o > look. As always, what to do comments should likely go here, while 'this > code sucks, here's how to make it better' type comments should go on the > review. >=20 > Warner >=20 > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jun 22 18:33:32 2018 Return-Path: Delivered-To: freebsd-arch@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 9517F1023F74 for ; Fri, 22 Jun 2018 18:33:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2589D7BCB1 for ; Fri, 22 Jun 2018 18:33:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id D89291023F73; Fri, 22 Jun 2018 18:33:31 +0000 (UTC) Delivered-To: arch@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 A2B501023F72 for ; Fri, 22 Jun 2018 18:33:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31B5A7BCAC for ; Fri, 22 Jun 2018 18:33:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id v83-v6so4198054itc.3 for ; Fri, 22 Jun 2018 11:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=n9Lx4LQGkk/W75KyYl+LbxXLn4dpTgTTn2TcWfyDJEc=; b=HZEvPg4Owgf0Kvm4ee3mNodu+i22R9LRPCtQ/rE3WNQMEwe/Pidawd2cFTzvIks+VR G0zDwQwOnFO8aCrhsbXOFf9zJtDJCxcvLIUW7H4MPsM0GjlWK9uYrclIy5O0IJIM3Tne XvTzpsu4Vjef1Obw0HnxklXtwBc3BxVq8XzgCPPWw0uJvAlV+6hK20ih9GzxP5GQM6vO j7nOtcTQlhoArS0rW79BOFz7autd3EcceYPYWtfn0T5Jw1zBDmr1ZC+MyxpUC1tCBtXa fcVQi+fWGeSPh08tHytlK4OuFavpdEDO2PJKWOodsTQLdkwZBCxak4LpoHhHuJmZI4/y vU0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=n9Lx4LQGkk/W75KyYl+LbxXLn4dpTgTTn2TcWfyDJEc=; b=JnYBLsia0ur/pFsHqGQxgJjMZ15o+rW2YyB+kTs3Alz8tsB0c8oY4N4lgHklORYL7r hPJR0v2LGPfBG66AFF0ljQ48It4OzkkMCicalRYMDUAxXDl5iYEe/x00cEgRKQ39NjW3 8lKgJt5iVHQ7uwhIOjHM0E/GqS8hlURrZoI423qI0dara3MnglpsEOqKW8oljiLarbXd NUg2NhK4ytRLWI9gfvA2Sv3rphTGRQSql5qwMPgVYvIijjSO0knqRDg2W/qDRhNCMiuV mpfXDnUExdKJxyPLD6SZFq0HT6wPEniUzhx1gIzi4Xxjnf+KoRZsUdtSGx5cgtuSwhgR Op9w== X-Gm-Message-State: APt69E050MJdMBhg0+tZFgcag1VYHlNNN3lxJ9nsyiOBX6kEH/MxAMO/ XxtdwwAeEiZBr5DBlG6XJQjL3iFRK3Aano9x5XSqPw== X-Google-Smtp-Source: AAOMgpf7uh9YmdL5rGDQ2mzj/nhefheY4e1tBsH1sQuEsKDNPWCWTGBFQpiWgqgXfnNxpMQAHcQiNfkvKKZk66tcP2g= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr2479965itc.36.1529692410506; Fri, 22 Jun 2018 11:33:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 11:33:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> References: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> From: Warner Losh Date: Fri, 22 Jun 2018 12:33:29 -0600 X-Google-Sender-Auth: pGP3WBhlgDrYSLOzvd2g6C_Covg Message-ID: Subject: Re: UEFI Plans / Shifts -- RFC To: Ravi Pokala Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:33:33 -0000 On Fri, Jun 22, 2018 at 12:18 PM, Ravi Pokala wrote: > > To work around this, people with non-standard console ports (which > everybody with a BMC likely has), > > What makes you say that? > > On most (all?) systems with IPMI that I've seen, the motherboard console > port is a normal UART. It just so happens that the UART isn't connected t= o > a DB9 header, but rather to the serial port on the BMC. The firmware on t= he > BMC (somehow -- reading the BIOS/UEFI settings directly?) knows the > configuration of the motherboard console port, and configures its side to > match. And there you go: a serial connection between the motherboard > console port and the BMC. > > What the BMC then does with it -- reflect it over the network using > Serial-Over-LAN, expose it via a web interface, etc. -- is a separate > matter entirely. > I mean that the BMC is almost never connected to COM1, at least for the sampling of motherboards I've had to deal with in the past 5 years. The standard port is COM1 for debugging. Everything else you have to set an address for. Warner > -Ravi (rpokala@) > > =EF=BB=BF-----Original Message----- > From: on behalf of Warner Losh < > imp@bsdimp.com> > Date: 2018-06-22, Friday at 08:47 > To: "freebsd-arch@freebsd.org" > Subject: UEFI Plans / Shifts -- RFC > > > Greetings, > > > > As I've documented before, I'll be making some addition UEFI changes. > > > > To recap, the plan: > > 1. Remove boot1.efi > > 2. Enhance loader.efi so it can live on ESP > > 3. Enhance loader.efi so it can do ping-pong booting > > > > 1 is still the plan, but there's some bits left to do. Most of step 2 i= s > > done. However, there's some issues that I'd like to work through. 3 is = my > > next task. There's other installer and installworld tasks that are need= ed > > before 1 can be done. > > > > In the past boot1.efi chose the /, read /boot/config or /boot.config an= d > > passed those args to /boot/loader.efi. This was always an imperfect mat= ch > > to UEFI, since we selected video/serial/both and other things for the > > kernel, but used the EFI conout function which sent the output to > whatever > > the UEFI ConOut variable was set to. In fact, we totally ignored that > > variable and people had to manually hack together something to try to > make > > things match the variable so the kernel messages would work. There is > > another vector to pass arguments to /boot/loader.efi, and that's > efibootmgr > > can set args to use that are passed to main w/o needing to read boot.co= nf > > at all. > > > > So, now that loader.efi is starting up, and we'd like to have verbose > > output before we select the root filesystem from which we could get the > > boot.conf to know where to send this output, I'd like to shift things a > > little. Since we already have almost all the information we need from t= he > > uefi boot variable, I'd like to stop parsing boot.conf and shift to usi= ng > > that. I'd like to make the ConOut variable override the command args > passed > > in. > > > > So, the new process will be: > > 1. Parse the args. Get a tentative howto. > > 2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and > RB_SERIAL. > > If we find a video card in the list, we'll use it. If we find serial in > the > > list, we'll use that and set RB_SERIAL. If we find both, we'll set > > RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll > set > > comconsole_speed. > > 3. We'll parse loader.conf > > 4. Just before we boot, if we have the 'efi' console set and serial was > set > > in the ConOut variable, we'll set hw.uart.console to reflect the speed > and > > the value of comconsole_port[*]. > > > > This will result in serial consoles just working almost all the time w/= o > > needing to do anything. The 'almost' part here is because to find the > > serial port, we have to walk the ACPI name space to find the _CRS that > > matches the _HID for the serial port. We're given the _UID, but that's > just > > a number whose meaning varies to the point of it being random. While we > > know that _UID X will refer to the same port from boot to boot, we have > no > > clue what that is on any given board. To work around this, people with > > non-standard console ports (which everybody with a BMC likely has), > you'll > > need to set comconsole_port in loader.conf. Of course, you'll have had = to > > do that today to make this setup work, so that's nothing new. In the > > fullness of time, but not for 12, we should just parse ACPI in the UEFI > > boot loader. This is somewhat non-trivial since we have to write the OS > > glue for the ACPICA code to have it work in the UEFI environment. I've > not > > investigated doing that in any more detail than to see there's no quick= , > > easy shortcuts. > > > > So here's my open questions: > > (1) Do I need to parse boot.conf? If so, do I violate POLA by parsing t= he > > one that's on the ESP or the one in the / we hope to boot from. What if= I > > don't find a /? I am leaning to a 'hard no' on this question because th= e > > efibootmgr provides a vector to get command line args to loader.efi > that's > > much better. boot.conf was a hack around the fact you couldn't set > command > > line args in the legacy bios. > > (2) Should the command line args passed in take precedence? Or should > > ConOut? Or should ConOut be used first with the command line args > > augmenting it? > > (3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have > both > > video and serial? Or should we only set RB_MULTIPLE? Or should we check > the > > command line args and only set RB_SERIAL in this case when -h is on the > > command line, like we do today. The downstream effect of this choses > where > > THE console of the kernel goes until someone writes a some ttymux code = to > > allow it to go to all the consoles requested by the boot loader. > > > > My current code is up at https://reviews.freebsd.org/D15917 if you want > to > > look. As always, what to do comments should likely go here, while 'this > > code sucks, here's how to make it better' type comments should go on th= e > > review. > > > > Warner > > > > Warner > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > >