From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 22:09:56 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 4AEB1106567F for ; Mon, 15 Sep 2008 22:09:56 +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 AAAE08FC0C for ; Mon, 15 Sep 2008 22:09:50 +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 m8FM9bCJ083996; Mon, 15 Sep 2008 18:09:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Mon, 15 Sep 2008 18:07:45 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> In-Reply-To: <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809151807.45844.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 15 Sep 2008 18:09:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8251/Mon Sep 15 16:23:40 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: freebsd-current@freebsd.org, Andriy Gapon 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: Mon, 15 Sep 2008 22:09:56 -0000 On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote: > > On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: > > > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: > >> > >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > >> > >>> on 15/09/2008 19:41 Marcel Moolenaar said the following: > >>>> So, if you compile acpi(4) as a module, you must compile all > >>>> it's depending drivers as modules as well. Or you compile acpi > >>>> into the kernel... > >>> > >>> I understand the logic, but OTOH uart can work without acpi too, so > >>> it's not a strict dependency. > >> > >> Well, yes. That's what's causing your "problem". You compile a > >> kernel without acpi but with uart. As such, uart will be built > >> without acpi support. uart does indeed work without acpi. > >> > >> The problem is that people then load the acpi module at runtime > >> and expect uart to work with acpi. That's not going to fly. If > >> one builds uart as a module, all possible support is included > >> and it works as expected. > >> > >>> Also, this (acpi dependency) doesn't seem to be documented. > >> > >> It's standard behaviour. > > > > The problem is that right now we ship with acpi.ko as a module by > > default and > > have the loader auto-load acpi.ko IFF the machine supports ACPI. > > Well, don't do that then. Just have the device probe check if acpi is > supported and attach if yes. It does that, the loader stuff is from someone trying to be fancy and save the memory of not having acpi.ko around if the system doesn't support it. This may in fact be dubious. :) -- John Baldwin