From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:19:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073511065679 for ; Tue, 16 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0B08FC1A for ; Tue, 16 Sep 2008 20:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8GKJUDR097041; Tue, 16 Sep 2008 16:19:30 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Peter Wemm" Date: Tue, 16 Sep 2008 15:53:01 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <200809151808.33400.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809161553.02028.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 16 Sep 2008 16:19:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8265/Tue Sep 16 15:26:49 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:19:37 -0000 On Tuesday 16 September 2008 03:26:00 pm Peter Wemm wrote: > On Mon, Sep 15, 2008 at 3:08 PM, John Baldwin wrote: > > On Monday 15 September 2008 04:11:14 pm Marcel Moolenaar wrote: > >> > >> On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote: > >> > >> > --- a/sys/conf/files > >> > +++ b/sys/conf/files > >> > @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe > >> > dev/twe/twe_freebsd.c optional twe > >> > dev/tx/if_tx.c optional tx > >> > dev/txp/if_txp.c optional txp > >> > -dev/uart/uart_bus_acpi.c optional uart acpi > >> > +dev/uart/uart_bus_acpi.c optional uart > >> > #dev/uart/uart_bus_cbus.c optional uart cbus > >> > dev/uart/uart_bus_ebus.c optional uart ebus > >> > dev/uart/uart_bus_isa.c optional uart isa > >> > >> This is exactly the thing we shouldn't be doing. > >> > >> You now compile the acpi bus attachment on platforms > >> that don't even have acpi. This is not a fix, it's > >> a breakage... > > > > You can change it in sys/conf/files.i386 instead. (It's ok to have duplicate > > lines across files*, the file gets compiled in if any one of the conditions > > matches). > > I agree. If uart is representing itself as a sio replacement, then it > needs to be a sio replacement. And on i386, that presently means > compiling the acpi attachment always. ie: add a second > "dev/uart/uart_bus_acpi.c optional uart" to files.i386. > > On the other hand, we shouldn't be compiling acpi.ko as a module > anyway. It really is an integral part of any recent x86 machines. > The PC2001 spec requires ACPI. You can't get a 'Designed for Windows > XXX' logo unless you're compliant with >= PC2001 these days. Having > it as a module just adds memory overhead (admittedly small, but it is > there). Having a crash involving acpi means that you suddenly have > more moving parts to keep track of for kgdb, and more things to go > wrong in getting decent dump info. (Granted, kgdb handles modules > much better now, but it is still something to go wrong if the on-disk > acpi.ko gets out of sync with the kernel.debug or the vmcore) > > I prefer what happens on amd64. It is compiled into the kernel, but > on the rare occasion where it is a problem there is a hint to shut it > down at boot. i386 has the same hint already. And if somebody really > wants to build a custom kernel without it, that can be done too. And > they get the acpi bus attachments compiled out at the same time. > > We're at least two full machine upgrade life cycles beyond the point > where ACPI was effectively mandatory in PC's. We really should be > optimizing for the case where it is there rather than not. > > As for soekris boxes without acpi - we already have compile-time > options that are compelling for building a custom kernel for use on a > soekris. Booting GENERIC with embedded acpi is harmless though, > except for the non-trivial kernel bloat in GENERIC. I agree with just adding acpi to GENERIC on i386 and have that be the real solution. -- John Baldwin