From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:41:33 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 8BF98106566B for ; Mon, 15 Sep 2008 16:41:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 79AD38FC1C for ; Mon, 15 Sep 2008 16:41:33 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7800F79X181540@asmtp015.mac.com> for freebsd-current@freebsd.org; Mon, 15 Sep 2008 09:41:33 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48CE8D2D.4020400@icyb.net.ua> Date: Mon, 15 Sep 2008 09:41:32 -0700 References: <48CE59C2.9060307@icyb.net.ua> <48CE8D2D.4020400@icyb.net.ua> X-Mailer: Apple Mail (2.928.1) Cc: 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: Mon, 15 Sep 2008 16:41:33 -0000 On Sep 15, 2008, at 9:28 AM, Andriy Gapon wrote: > on 15/09/2008 18:58 Marcel Moolenaar said the following: >> On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: >>> >>> This is a fairly standard and old machine with 2 COM ports. >>> Recently (last Friday) I decided to update my RELENG_7 system and >>> also to transition from sio to uart. >>> >>> This what I had before the upgrade: >>> kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 >>> flags 0x10 on acpi0 >>> kernel: sio0: type 16550A >>> kernel: sio0: [FILTER] >>> kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 >>> on acpi0 >>> kernel: sio1: type 16550A >>> kernel: sio1: [FILTER] >>> >>> This is what I have now: >>> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 >>> on isa0 >>> uart0: [FILTER] >>> >>> This is what I have in device.hints for uart: >>> hint.uart.0.at="isa" >>> hint.uart.0.port="0x3F8" >>> hint.uart.0.flags="0x10" >>> hint.uart.0.irq="4" >>> hint.uart.1.at="isa" >>> hint.uart.1.port="0x2F8" >>> hint.uart.1.irq="3" >>> hint.uart.2.at="isa" >>> >>> Precisely the same hints (s/uart/sio/) I had for sio. >> The hints are bogus. As you can see, sio(4) attached to acpi(4), >> whereas uart(4) attaches to isa(4). > > Yes and yes. > >> Don't compile ACPI as a kernel module and all is fine. > > What is the alternative? > Building it into a kernel? Yes. > Is this maybe too much of a requirement? It's how our modules work. You can safely compile leaf drivers as modules (leaf drivers are drivers that have no other drivers depending on it), but we don't deal well with non-leaf drivers. acpi(4) is a non-leaf driver, with sio(4) and uart(4) depending on it. If you compile acpi(4) as a module, you should do the same for sio(4), uart(4), etc. We don't enforce that, which is the problem. sio(4) added a kluge to work around the design/implementation flaw, whereas uart(4) does not. The reason uart(4) does not is that you don't want to compile-in code that you don't need. It bloats the kernel and we need to keep our embedded platforms in mind. 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... > From /sys/i386/conf/NOTES (RELENG_7): > # Note that building ACPI into the kernel is deprecated; the module is > # normally loaded automatically by the loader. Just another bogus note. Compiling ACPI into the kernel is not deprecated, because it's required for at least ia64 and I think for amd64 as well. -- Marcel Moolenaar xcllnt@mac.com