Date: Fri, 22 May 2020 08:56:50 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Mark Johnston <markj@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r361352 - in head/sys: amd64/amd64 i386/i386 Message-ID: <1e73eb03-a734-64df-f1c8-9fccc85a3bf0@FreeBSD.org> In-Reply-To: <20200522153743.GC2512@raichu> References: <202005220118.04M1ItwO032876@repo.freebsd.org> <20200522151059.GK64045@kib.kiev.ua> <20200522153743.GC2512@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/22/20 8:37 AM, Mark Johnston wrote: > On Fri, May 22, 2020 at 06:10:59PM +0300, Konstantin Belousov wrote: >> On Fri, May 22, 2020 at 01:18:55AM +0000, Mark Johnston wrote: >>> Author: markj >>> Date: Fri May 22 01:18:55 2020 >>> New Revision: 361352 >>> URL: https://svnweb.freebsd.org/changeset/base/361352 >>> >>> Log: >>> Fix the build after r361033 when ACPI is disabled. >> What is the sense in doing this for amd64 ? I doubt that we can boot >> with ACPI disabled. > > It is possible to boot in virtualized environments without ACPI. I'm > not sure why it is especially useful, but I wanted to avoid regressing a > stable branch since at least one person noticed the breakage fairly > quickly, and it is easy to fix. I agree it mostly seems dubious. I believe at one point that NetApp at least was using FreeBSD/amd64 on gear that didn't have a "real" BIOS and didn't have ACPI. That was probably 10 years ago though when I last heard that, so it may no longer be true. That said, even the !ACPI code we have now is a runtime check so it should still fallback if ACPI isn't detected at runtime or is disabled via a hint. I'm not sure how much we should go out of our way to permit compiling without ACPI. On any modern consumer hardware you are going to want ACPI. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e73eb03-a734-64df-f1c8-9fccc85a3bf0>