From owner-freebsd-current@FreeBSD.ORG Sat Jul 5 15:44:58 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 9676F106566C; Sat, 5 Jul 2008 15:44:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFD48FC0C; Sat, 5 Jul 2008 15:44:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtp016-bge351000.mac.com (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id m65Fiw5H002452; Sat, 5 Jul 2008 08:44:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.102] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K3J00NQOIEW4340@asmtp016.mac.com>; Sat, 05 Jul 2008 08:44:58 -0700 (PDT) Message-id: <13CE46CD-EF60-448D-BDC7-CBE274D22FE3@mac.com> From: Marcel Moolenaar To: John Baldwin In-reply-to: <200807042108.25355.jhb@freebsd.org> Date: Sat, 05 Jul 2008 08:44:56 -0700 References: <20080701181358.GA93601@wep4017.physik.uni-wuerzburg.de> <200807041832.40605.jhb@freebsd.org> <0D68D063-6654-4E55-ACA9-A0B58C7AA45C@mac.com> <200807042108.25355.jhb@freebsd.org> X-Mailer: Apple Mail (2.926) Cc: Alexey Shuvaev , freebsd-current@freebsd.org, Dmitry Morozovsky Subject: Re: puc(4) man page update? 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: Sat, 05 Jul 2008 15:44:58 -0000 On Jul 4, 2008, at 6:08 PM, John Baldwin wrote: >>> The >>> attachments get bound at runtime. This is actually an important >>> feature. >> >> It's an important feature of KOBJ, yes. The point of compiling >> drivers into the kernel is to get just what you need. Not a >> bunch of bus attachments you don't want. Modules have pretty >> much all bus attachments because they need to work with >> whatever kernel they're loaded in. >> >> So, sio(4) is not following the rules in the strictest sense. >> That's why sio(4) is a bad example, why the problem is not >> adequately acknowledged and people keep running into the same >> old problems of things not working "as expected". > > This is because acpi is a module. One way this could be fixed is to > not put > ISA devices enumerated by ACPI on acpi0, but instead of an ACPI- > aware ISA bus > driver for devices on ISA/LPC that ACPI enumerates. Agreed. For this to work on ia64, we also have to clean up the ISA related code and some drivers. We have to remove the assumption of having (legacy) PC hardware from it. The legacy PC code must be moved under a different option. Think about syscons, PnP, ISA DMA and option ROM. Those options could be put under an option LPC or something. For example: we could have an option LPC that is what option ISA is now, but excludes the isa(4) bus driver. The ISA option would change to mean the isa(4) bus driver only. In a way acpi(4) is that new isa(4) bus driver, but we didn't change option ISA to exclude the current isa bus. In other words, we didn't add support for hints to acpi(4). The amount of work is to eliminate the isa bus. That gives exactly what you suggest, modulo naming. > Also, none of that will > fix any of the actual problems people have (i.e. COM1 being sio1 and > COM2 > being sio0 because the BIOS lists them backwards. This happens to > work in > the non-ACPI case with PNPBIOS due to far grosser hacks that cause > PNPBIOS > devices to not even be used if hints are present.) That's still a different issue and unrelated. -- Marcel Moolenaar xcllnt@mac.com