From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 10:34:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE3B716A4CE for ; Wed, 19 Nov 2003 10:34:50 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF88543F3F for ; Wed, 19 Nov 2003 10:34:49 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAJIYiEs066187; Wed, 19 Nov 2003 19:34:44 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Wilko Bulte From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 19 Nov 2003 19:24:58 +0100." <20031119182458.GA4703@freebie.xs4all.nl> Message-ID: <66186.1069266884@critter.freebsd.dk> cc: Sam Leffler cc: Steve Kargl cc: freebsd-arch@FreeBSD.ORG Subject: Re: adding crypto support to GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 19 Nov 2003 18:34:51 -0000 X-Original-Date: Wed, 19 Nov 2003 19:34:44 +0100 X-List-Received-Date: Wed, 19 Nov 2003 18:34:51 -0000 In message <20031119182458.GA4703@freebie.xs4all.nl>, Wilko Bulte writes: >> >What are the implications for individuals >> >who live in countries that restrict access >> >to crypto? >> >> Are there any of those left ? > >France? And just what is the nature of restriction ? As far as I know there is no restriction on tools with which to encrypt, that would be against several EU regulations. The only restrictions I'm aware of are restrictions on _use_ and rules about key disclosure. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 17:06:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D2F416A4CE for ; Mon, 26 Jan 2004 17:06:33 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id AC35243D8D for ; Mon, 26 Jan 2004 17:05:18 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 30513 invoked by uid 1000); 27 Jan 2004 01:03:58 -0000 Date: Mon, 26 Jan 2004 17:03:58 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.151728.133912536.imp@bsdimp.com> Message-ID: <20040126165523.W30461@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 01:06:33 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126140100.T29680@root.org> > Nate Lawson writes: > : I have a driver that knows the IO port it wants. It's not set up by a > : parent bus, so I can't use bus_set_resource(). This call returns NULL. > : Any idea how to debug why newbus is rejecting this request? The io port > : is not in use and the rid is unique. > : > : bus_alloc_resource(dev, SYS_RES_IOPORT, rid, 0x101c, 0x101c, 1, > : RF_ACTIVE); > > Ummm, you can use bus_set_resource() in the driver to do this (I've > done it before). bus_set_resource() should return 0 to indicate > success. bus_alloc_resource should then succeed. There may be one > other step to do as well to make this work, but I'm not sure if it is > an internal convention or actually required. The pci bus code does a > resource_list_add for each of the resources the child uses, but I > think that's an internal thing to the pci bus (that other busses do > also). Ok, I'm doing the set/alloc and it works. However, one weird thing. If I allocate all ports at boot time, it succeeds. My driver goes through multiple release/allocate cycles and it all works as expected. However if I boot and attach to only one of the registers, subsequent attempts to attach the second one fail. The resources are 2 IO ports, 0x101c and 0x101d. Both are 1 byte. -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 17:20:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 535EB16A4CE for ; Mon, 26 Jan 2004 17:20:15 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D10B243D80 for ; Mon, 26 Jan 2004 17:19:27 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0R1HQET084680; Mon, 26 Jan 2004 18:17:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jan 2004 18:17:20 -0700 (MST) Message-Id: <20040126.181720.15264443.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040126165523.W30461@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> <20040126165523.W30461@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 01:20:15 -0000 In message: <20040126165523.W30461@root.org> Nate Lawson writes: : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I : allocate all ports at boot time, it succeeds. My driver goes through : multiple release/allocate cycles and it all works as expected. However if : I boot and attach to only one of the registers, subsequent attempts to : attach the second one fail. The resources are 2 IO ports, 0x101c and : 0x101d. Both are 1 byte. Deos devinfo -r show any cause for the problem? Maybe you aren't releasing them properly? Also, why not allocate them as a block of 2? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 17:25:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9582316A4CE for ; Mon, 26 Jan 2004 17:25:00 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4627343D99 for ; Mon, 26 Jan 2004 17:24:05 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 30645 invoked by uid 1000); 27 Jan 2004 01:23:46 -0000 Date: Mon, 26 Jan 2004 17:23:46 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.181720.15264443.imp@bsdimp.com> Message-ID: <20040126172211.J30603@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> <20040126.181720.15264443.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 01:25:00 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126165523.W30461@root.org> > Nate Lawson writes: > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I > : allocate all ports at boot time, it succeeds. My driver goes through > : multiple release/allocate cycles and it all works as expected. However if > : I boot and attach to only one of the registers, subsequent attempts to > : attach the second one fail. The resources are 2 IO ports, 0x101c and > : 0x101d. Both are 1 byte. > > Deos devinfo -r show any cause for the problem? Maybe you aren't > releasing them properly? Also, why not allocate them as a block of 2? I'll look into that. I can't allocate them in one block as they come and go, based on system state. In one state, one is available and in another, both are available. If I boot while only one is available and then you plug in the AC adapter, new ones appear. This is acpi, btw. -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 17:35:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF06216A4CE for ; Mon, 26 Jan 2004 17:35:41 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8575F43D9D for ; Mon, 26 Jan 2004 17:34:08 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0R1WMET084762; Mon, 26 Jan 2004 18:32:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jan 2004 18:32:15 -0700 (MST) Message-Id: <20040126.183215.26531948.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040126172211.J30603@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126172211.J30603@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 01:35:41 -0000 In message: <20040126172211.J30603@root.org> Nate Lawson writes: : On Mon, 26 Jan 2004, M. Warner Losh wrote: : > In message: <20040126165523.W30461@root.org> : > Nate Lawson writes: : > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I : > : allocate all ports at boot time, it succeeds. My driver goes through : > : multiple release/allocate cycles and it all works as expected. However if : > : I boot and attach to only one of the registers, subsequent attempts to : > : attach the second one fail. The resources are 2 IO ports, 0x101c and : > : 0x101d. Both are 1 byte. : > : > Deos devinfo -r show any cause for the problem? Maybe you aren't : > releasing them properly? Also, why not allocate them as a block of 2? : : I'll look into that. I can't allocate them in one block as they come and : go, based on system state. In one state, one is available and in another, : both are available. If I boot while only one is available and then you : plug in the AC adapter, new ones appear. This is acpi, btw. Ummm, wouldn't they both always be allocated to the driver, even if you could only talk to one of them at any given time? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 17:44:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A47DF16A4CE for ; Mon, 26 Jan 2004 17:44:38 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 74FBD43D46 for ; Mon, 26 Jan 2004 17:44:37 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 30778 invoked by uid 1000); 27 Jan 2004 01:44:39 -0000 Date: Mon, 26 Jan 2004 17:44:39 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.183215.26531948.imp@bsdimp.com> Message-ID: <20040126174103.R30729@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126.183215.26531948.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 01:44:38 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126172211.J30603@root.org> > Nate Lawson writes: > : On Mon, 26 Jan 2004, M. Warner Losh wrote: > : > In message: <20040126165523.W30461@root.org> > : > Nate Lawson writes: > : > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I > : > : allocate all ports at boot time, it succeeds. My driver goes through > : > : multiple release/allocate cycles and it all works as expected. However if > : > : I boot and attach to only one of the registers, subsequent attempts to > : > : attach the second one fail. The resources are 2 IO ports, 0x101c and > : > : 0x101d. Both are 1 byte. > : > > : > Deos devinfo -r show any cause for the problem? Maybe you aren't > : > releasing them properly? Also, why not allocate them as a block of 2? > : > : I'll look into that. I can't allocate them in one block as they come and > : go, based on system state. In one state, one is available and in another, > : both are available. If I boot while only one is available and then you > : plug in the AC adapter, new ones appear. This is acpi, btw. > > Ummm, wouldn't they both always be allocated to the driver, even if > you could only talk to one of them at any given time? No, the object you evaluate for a list of registers changes dynamically at runtime. The _CST method returns one of the below objects, depending on AC adapter state. If you evaluate it at boot and get CST1, you have no info about CST2, which you might get later. Name (CST1, Package (0x02) { Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x08, 0x00, 0x0000000000000000) }, } }) Name (CST2, Package (0x03) { Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x08, 0x00, 0x0000000000000000) }, }, Package (0x04) { ResourceTemplate () { Register (SystemIO, 0x08, 0x00, 0x0000000000001014) }, } }) -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 21:47:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93EB016A543 for ; Mon, 26 Jan 2004 21:47:57 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1711044066 for ; Mon, 26 Jan 2004 19:49:10 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 31137 invoked by uid 1000); 27 Jan 2004 03:22:30 -0000 Date: Mon, 26 Jan 2004 19:22:30 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.181720.15264443.imp@bsdimp.com> Message-ID: <20040126191657.B31071@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> <20040126.181720.15264443.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 05:47:59 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126165523.W30461@root.org> > Nate Lawson writes: > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I > : allocate all ports at boot time, it succeeds. My driver goes through > : multiple release/allocate cycles and it all works as expected. However if > : I boot and attach to only one of the registers, subsequent attempts to > : attach the second one fail. The resources are 2 IO ports, 0x101c and > : 0x101d. Both are 1 byte. > > Deos devinfo -r show any cause for the problem? Maybe you aren't > releasing them properly? Also, why not allocate them as a block of 2? Ok, I've found what's going on. Apparently my acpi_sysresource0 pseudo-device is claiming all resources in its _CRS method. If I don't boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. But if I boot attaching them, it reserves less of the range. acpi_cpu0 I/O ports: 0x101c 0x101d acpi_sysresource0 I/O ports: 0x10-0x1f 0x24-0x25 0x28-0x29 0x2c-0x2d 0x2e-0x2f 0x30-0x31 0x34-0x35 0x38-0x39 0x3c-0x3d 0x50-0x53 0x72-0x77 0x90-0x9f 0xa4-0xa5 0xa8-0xa9 0xac-0xad 0xb0-0xb5 0xb8-0xb9 0xbc-0xbd 0x101e-0x109d 0x1180-0x11bf 0x15e0-0x15ef 0x1600-0x167f I'm not sure of a way around this. All ASL I've seen keeps these registers contiguous so I could whack out a block of 8 of them, although that doesn't seem correct. Perhaps acpi_cpu should be able to override the acpi_sysresource0 allocations, maybe by asking it for the resource if bus_resource_alloc returns NULL. Thoughts? -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 21:48:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61DD616A7C0 for ; Mon, 26 Jan 2004 21:48:41 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34ECF43EC3 for ; Mon, 26 Jan 2004 19:40:52 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0R3QfET085891; Mon, 26 Jan 2004 20:26:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jan 2004 20:26:28 -0700 (MST) Message-Id: <20040126.202628.39465078.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040126191657.B31071@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 05:48:44 -0000 In message: <20040126191657.B31071@root.org> Nate Lawson writes: : On Mon, 26 Jan 2004, M. Warner Losh wrote: : > In message: <20040126165523.W30461@root.org> : > Nate Lawson writes: : > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I : > : allocate all ports at boot time, it succeeds. My driver goes through : > : multiple release/allocate cycles and it all works as expected. However if : > : I boot and attach to only one of the registers, subsequent attempts to : > : attach the second one fail. The resources are 2 IO ports, 0x101c and : > : 0x101d. Both are 1 byte. : > : > Deos devinfo -r show any cause for the problem? Maybe you aren't : > releasing them properly? Also, why not allocate them as a block of 2? : : Ok, I've found what's going on. Apparently my acpi_sysresource0 : pseudo-device is claiming all resources in its _CRS method. If I don't : boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. But : if I boot attaching them, it reserves less of the range. : : acpi_cpu0 : I/O ports: : 0x101c : 0x101d : : acpi_sysresource0 : I/O ports: : 0x10-0x1f : 0x24-0x25 : 0x28-0x29 : 0x2c-0x2d : 0x2e-0x2f : 0x30-0x31 : 0x34-0x35 : 0x38-0x39 : 0x3c-0x3d : 0x50-0x53 : 0x72-0x77 : 0x90-0x9f : 0xa4-0xa5 : 0xa8-0xa9 : 0xac-0xad : 0xb0-0xb5 : 0xb8-0xb9 : 0xbc-0xbd : 0x101e-0x109d : 0x1180-0x11bf : 0x15e0-0x15ef : 0x1600-0x167f : : I'm not sure of a way around this. All ASL I've seen keeps these : registers contiguous so I could whack out a block of 8 of them, although : that doesn't seem correct. Perhaps acpi_cpu should be able to override : the acpi_sysresource0 allocations, maybe by asking it for the resource if : bus_resource_alloc returns NULL. Thoughts? Have acpi bus own the resources that acpi_sysresource0 uses. Allow children to get at parts of that as they see fit. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:16:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4720216A4D1 for ; Mon, 26 Jan 2004 22:16:26 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8675243D68 for ; Mon, 26 Jan 2004 22:15:46 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 31971 invoked by uid 1000); 27 Jan 2004 06:15:09 -0000 Date: Mon, 26 Jan 2004 22:15:09 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.202628.39465078.imp@bsdimp.com> Message-ID: <20040126221305.P31969@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126.202628.39465078.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:16:26 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126191657.B31071@root.org> > Nate Lawson writes: > : On Mon, 26 Jan 2004, M. Warner Losh wrote: > : > In message: <20040126165523.W30461@root.org> > : > Nate Lawson writes: > : > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I > : > : allocate all ports at boot time, it succeeds. My driver goes through > : > : multiple release/allocate cycles and it all works as expected. However if > : > : I boot and attach to only one of the registers, subsequent attempts to > : > : attach the second one fail. The resources are 2 IO ports, 0x101c and > : > : 0x101d. Both are 1 byte. > : > > : > Deos devinfo -r show any cause for the problem? Maybe you aren't > : > releasing them properly? Also, why not allocate them as a block of 2? > : > : Ok, I've found what's going on. Apparently my acpi_sysresource0 > : pseudo-device is claiming all resources in its _CRS method. If I don't > : boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. But > : if I boot attaching them, it reserves less of the range. > : > : acpi_cpu0 > : I/O ports: > : 0x101c > : 0x101d > : > : acpi_sysresource0 > : I/O ports: > : 0x10-0x1f > : 0x24-0x25 > : 0x28-0x29 > : 0x2c-0x2d > : 0x2e-0x2f > : 0x30-0x31 > : 0x34-0x35 > : 0x38-0x39 > : 0x3c-0x3d > : 0x50-0x53 > : 0x72-0x77 > : 0x90-0x9f > : 0xa4-0xa5 > : 0xa8-0xa9 > : 0xac-0xad > : 0xb0-0xb5 > : 0xb8-0xb9 > : 0xbc-0xbd > : 0x101e-0x109d > : 0x1180-0x11bf > : 0x15e0-0x15ef > : 0x1600-0x167f > : > : I'm not sure of a way around this. All ASL I've seen keeps these > : registers contiguous so I could whack out a block of 8 of them, although > : that doesn't seem correct. Perhaps acpi_cpu should be able to override > : the acpi_sysresource0 allocations, maybe by asking it for the resource if > : bus_resource_alloc returns NULL. Thoughts? > > Have acpi bus own the resources that acpi_sysresource0 uses. bus_set_resource(device_get_parent(dev), ...) ? > Allow children to get at parts of that as they see fit. Sounds good, but no idea how to implement this. Would I have to implement new parts to acpi_alloc_resource()? -Nate From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:29:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 953B016A4CE; Mon, 26 Jan 2004 22:29:30 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9000943D66; Mon, 26 Jan 2004 22:29:06 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0R6RRuO088291; Tue, 27 Jan 2004 07:27:27 +0100 (CET) (envelope-from phk@phk.freebsd.dk) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 28 Sep 2003 23:22:07 +0200." <653.1064784127@critter.freebsd.dk> Date: Tue, 27 Jan 2004 07:27:27 +0100 Message-ID: <88290.1075184847@critter.freebsd.dk> cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:29:30 -0000 In message <653.1064784127@critter.freebsd.dk>, Poul-Henning Kamp writes: > >I am in the process of adding ref-counting and locking to dev_t, >and would very much prefer if we could get this step completed >soon before 5-STABLE gets branched. Sure I did write this, several months ago. Could whoever has a mailloop fix it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:36:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F83216A4CE for ; Mon, 26 Jan 2004 22:36:06 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C518443D5E for ; Mon, 26 Jan 2004 22:35:49 -0800 (PST) (envelope-from msmith@freebsd.org) Received: from [192.168.1.101] (c-24-7-68-232.client.comcast.net [24.7.68.232]) by elvis.mu.org (Postfix) with ESMTP id 456B25C7E4; Mon, 26 Jan 2004 22:34:46 -0800 (PST) In-Reply-To: <20040126191657.B31071@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mike Smith Date: Mon, 26 Jan 2004 22:34:43 -0800 To: Nate Lawson X-Mailer: Apple Mail (2.609) cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:36:06 -0000 > Ok, I've found what's going on. Apparently my acpi_sysresource0 > pseudo-device is claiming all resources in its _CRS method. If I don't > boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. > But > if I boot attaching them, it reserves less of the range. It just comes along later, I think. > I'm not sure of a way around this. All ASL I've seen keeps these > registers contiguous so I could whack out a block of 8 of them, > although > that doesn't seem correct. Perhaps acpi_cpu should be able to override > the acpi_sysresource0 allocations, maybe by asking it for the resource > if > bus_resource_alloc returns NULL. Thoughts? You probably need the concept of a "may be considered system device" device, which can steal resource ranges from the sysresource placeholder. The whole reason for the sysresource device was to have something sitting on resources that the AML said had "something" behind them so that they didn't get handed out to devices on eg. PCI. If you're in the same sort of scope as the sysresource device, it's fair to say that you know more than eg. the PCI bus resource code does about whether you can use the resource in question. = Mike From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:36:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0299316A4CE for ; Mon, 26 Jan 2004 22:36:59 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F8BB43D4C for ; Mon, 26 Jan 2004 22:36:58 -0800 (PST) (envelope-from msmith@mu.org) Received: from [192.168.1.101] (c-24-7-68-232.client.comcast.net [24.7.68.232]) by elvis.mu.org (Postfix) with ESMTP id 7AF355C7CF; Mon, 26 Jan 2004 22:36:16 -0800 (PST) In-Reply-To: <20040126221305.P31969@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> <20040126.202628.39465078.imp@bsdimp.com> <20040126221305.P31969@root.org> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1A5AC87C-5093-11D8-8DD8-000393C72BD6@mu.org> Content-Transfer-Encoding: 7bit From: Mike Smith Date: Mon, 26 Jan 2004 22:36:13 -0800 To: Nate Lawson X-Mailer: Apple Mail (2.609) cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:36:59 -0000 On Jan 26, 2004, at 10:15 PM, Nate Lawson wrote: >> Allow children to get at parts of that as they see fit. > > Sounds good, but no idea how to implement this. Would I have to > implement > new parts to acpi_alloc_resource()? Probably, yes. Something like a 'hog' flag on acpi_sysresource and a new bus/device method that lets you ask it for a range back. = Mike From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 02:21:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DACE16A4CE; Tue, 27 Jan 2004 02:21:46 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 882AD43D5D; Tue, 27 Jan 2004 02:21:42 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0RALfET090037; Tue, 27 Jan 2004 03:21:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 03:21:19 -0700 (MST) Message-Id: <20040127.032119.28084825.imp@bsdimp.com> To: msmith@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: nate@root.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 10:21:46 -0000 In message: Mike Smith writes: : The whole reason for the sysresource device was to have something : sitting on resources that the AML said had "something" behind them : so that they didn't get handed out to devices on eg. PCI. If you're : in the same sort of scope as the sysresource device, it's fair to : say that you know more than eg. the PCI bus resource code does about : whether you can use the resource in question. Yes. It is a form of resource enumeration that belongs to ACPI. Therefore, ACPI should manage it and dole it out to its children which are based on the AML. That's what it is there for. It is akin to the PCI code assigning resources based on the BARs that a child has. However, only akin, because the entire resource space is enumerated in the bus, not the children, for ACPI. The sysresource stuff was a means to an end, not the only way to that end. I'm starting to think that the right way to go is to reserve EVERYTHING up front, and then have all the acpi_foo devices allocate out of that reserveation. In this way it is similar to a BAR that has been assigned by the BIOS, but isn't allocated by a child device on pci. In the code I'm working on, those resources are reserved at the bus level and given to the child if it asks for it later. Well, it is a little more complex than that because the child device actually owns the resource, but the bus is who assigns ownership. In ACPI, since the resource maps aren't child specific, the ownership should resided in the bus layer. So instead of belonging to acpi_sysresource0, it would belong to acpi0. This may also help some downstream resource allocations, since they would now be happening a little earlier in the game. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 02:56:56 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0733916A4CE; Tue, 27 Jan 2004 02:56:56 -0800 (PST) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7C4243D5A; Tue, 27 Jan 2004 02:56:52 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 80E5041; Tue, 27 Jan 2004 11:56:35 +0100 (CET) Date: Tue, 27 Jan 2004 11:56:35 +0100 From: Guido van Rooij To: Poul-Henning Kamp Message-ID: <20040127105635.GA85742@gvr.gvr.org> References: <653.1064784127@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <653.1064784127@critter.freebsd.dk> cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 10:56:56 -0000 On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: > Can I see some volounteers and/or maintainers please ? > > ./alpha/osf1/osf1_misc.c > badly named local macro ? > > ./compat/linux/linux_stats.c > ./compat/svr4/svr4_types.h > compat code, not sure that this is correct now. > Must be supported by new "finddev" semantics. > > ./dev/ata/atapi-cd.c > cloning related to root mount. > gets fixed when phk GEOMify the driver. > > ./dev/sound/midi/midi.h > Not sure. > > ./dev/nmdm/nmdm.c > pseudo-cloning. Should do real cloning. > > ./dev/syscons/syscons.c > Related to console initialization. Maybe tricky. > > ./dev/sound/pcm/dsp.c > ./dev/sound/pcm/mixer.c > ./dev/usb/ugen.c > ./dev/usb/uscanner.c > Failure to cache result of make_dev() > > ./dev/vinum > Failure to cache result of make_dev() ? Please don't forget the vmware modules and the rtc one. -Guido From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 08:06:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C5216A4CE; Tue, 27 Jan 2004 08:06:15 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0655F43D81; Tue, 27 Jan 2004 08:05:55 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0RG3bUd041081; Tue, 27 Jan 2004 11:03:37 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0RG3aZD041078; Tue, 27 Jan 2004 11:03:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 27 Jan 2004 11:03:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Guido van Rooij In-Reply-To: <20040127105635.GA85742@gvr.gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 16:06:15 -0000 On Tue, 27 Jan 2004, Guido van Rooij wrote: > On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: Time warp! > Please don't forget the vmware modules and the rtc one. I believe Silby is working on this. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 09:32:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3371C16A4CE; Tue, 27 Jan 2004 09:32:01 -0800 (PST) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBB543D46; Tue, 27 Jan 2004 09:31:48 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id C495345; Tue, 27 Jan 2004 18:30:39 +0100 (CET) Date: Tue, 27 Jan 2004 18:30:39 +0100 From: Guido van Rooij To: Robert Watson Message-ID: <20040127173039.GA92177@gvr.gvr.org> References: <20040127105635.GA85742@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: arch@freebsd.org cc: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: HEADSUP: Change of makedev() semantics. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 17:32:01 -0000 On Tue, Jan 27, 2004 at 11:03:36AM -0500, Robert Watson wrote: > > On Tue, 27 Jan 2004, Guido van Rooij wrote: > > > On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: > > Time warp! Yep..better late than never though ;-) -Guido From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 10:11:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6701816A4CE for ; Tue, 27 Jan 2004 10:11:08 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A15B943D55 for ; Tue, 27 Jan 2004 10:11:05 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 29788 invoked from network); 27 Jan 2004 18:10:38 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Jan 2004 18:10:38 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 27 Jan 2004 12:10:36 -0600 (CST) From: Mike Silbersack To: Bruce Evans In-Reply-To: <20040126212725.E1244@gamplex.bde.org> Message-ID: <20040127120826.V4636@odysseus.silby.com> References: <20040125230314.S730@odysseus.silby.com> <20040126212725.E1244@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 18:11:08 -0000 On Mon, 26 Jan 2004, Bruce Evans wrote: > Many callers don't worry much about efficiency and do calculations like > (hz / 10) to get the timeout. This is still more efficient than the > 64-bit divisions and other complications needed to handle general > conversions of times to timeouts. (Look at tvtohz(). Note that the > complications in it have very little to do with struct timeval not > being a scalar type. They are to handle representation problems.) > > Bruce I've thought more about this, and although I could debate some points, you've convinced me that changing the interface without changing the implementation is totally pointless. So, if I ever get around to implementation changes, then I'll come back and we can rediscuss some of these issues. Mike "Silby" Silbersack From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 13:07:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8481616A4CE for ; Tue, 27 Jan 2004 13:07:49 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3882443D2F for ; Tue, 27 Jan 2004 13:06:59 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 74877 invoked by uid 1000); 27 Jan 2004 21:05:08 -0000 Date: Tue, 27 Jan 2004 13:05:08 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.032119.28084825.imp@bsdimp.com> Message-ID: <20040127125547.G74774@root.org> References: <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> <20040127.032119.28084825.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 21:07:49 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: > Mike Smith writes: > : The whole reason for the sysresource device was to have something > : sitting on resources that the AML said had "something" behind them > : so that they didn't get handed out to devices on eg. PCI. If you're > : in the same sort of scope as the sysresource device, it's fair to > : say that you know more than eg. the PCI bus resource code does about > : whether you can use the resource in question. > > Yes. It is a form of resource enumeration that belongs to ACPI. > Therefore, ACPI should manage it and dole it out to its children which > are based on the AML. That's what it is there for. It is akin to the > PCI code assigning resources based on the BARs that a child has. > However, only akin, because the entire resource space is enumerated in > the bus, not the children, for ACPI. The sysresource stuff was a > means to an end, not the only way to that end. I'm starting to think > that the right way to go is to reserve EVERYTHING up front, and then > have all the acpi_foo devices allocate out of that reserveation. > > In this way it is similar to a BAR that has been assigned by the BIOS, > but isn't allocated by a child device on pci. In the code I'm working > on, those resources are reserved at the bus level and given to the > child if it asks for it later. Well, it is a little more complex than > that because the child device actually owns the resource, but the bus > is who assigns ownership. In ACPI, since the resource maps aren't > child specific, the ownership should resided in the bus layer. So > instead of belonging to acpi_sysresource0, it would belong to acpi0. > This may also help some downstream resource allocations, since they > would now be happening a little earlier in the game. Ok, let me propose a design and I'd appreciate your comments. The probe routine for acpi_sysresource will stay the same. The attach will allocate the resources to its parent device (acpi0). acpi0 will make this set of resources available to its children via a flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If acpi_resource_alloc finds a range already has that flag set, it will refuse the request. Otherwise, it will release that range and then immediately allocate it to the child. -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 13:21:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5676016A4CF; Tue, 27 Jan 2004 13:21:19 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7699043D7C; Tue, 27 Jan 2004 13:20:38 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0RLJgET097585; Tue, 27 Jan 2004 14:19:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 14:19:37 -0700 (MST) Message-Id: <20040127.141937.45155991.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127125547.G74774@root.org> References: <20040127.032119.28084825.imp@bsdimp.com> <20040127125547.G74774@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 21:21:19 -0000 In message: <20040127125547.G74774@root.org> Nate Lawson writes: : On Tue, 27 Jan 2004, M. Warner Losh wrote: : > In message: : > Mike Smith writes: : > : The whole reason for the sysresource device was to have something : > : sitting on resources that the AML said had "something" behind them : > : so that they didn't get handed out to devices on eg. PCI. If you're : > : in the same sort of scope as the sysresource device, it's fair to : > : say that you know more than eg. the PCI bus resource code does about : > : whether you can use the resource in question. : > : > Yes. It is a form of resource enumeration that belongs to ACPI. : > Therefore, ACPI should manage it and dole it out to its children which : > are based on the AML. That's what it is there for. It is akin to the : > PCI code assigning resources based on the BARs that a child has. : > However, only akin, because the entire resource space is enumerated in : > the bus, not the children, for ACPI. The sysresource stuff was a : > means to an end, not the only way to that end. I'm starting to think : > that the right way to go is to reserve EVERYTHING up front, and then : > have all the acpi_foo devices allocate out of that reserveation. : > : > In this way it is similar to a BAR that has been assigned by the BIOS, : > but isn't allocated by a child device on pci. In the code I'm working : > on, those resources are reserved at the bus level and given to the : > child if it asks for it later. Well, it is a little more complex than : > that because the child device actually owns the resource, but the bus : > is who assigns ownership. In ACPI, since the resource maps aren't : > child specific, the ownership should resided in the bus layer. So : > instead of belonging to acpi_sysresource0, it would belong to acpi0. : > This may also help some downstream resource allocations, since they : > would now be happening a little earlier in the game. : : Ok, let me propose a design and I'd appreciate your comments. The probe : routine for acpi_sysresource will stay the same. The attach will allocate : the resources to its parent device (acpi0). : : acpi0 will make this set of resources available to its children via a : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If : acpi_resource_alloc finds a range already has that flag set, it will : refuse the request. Otherwise, it will release that range and then : immediately allocate it to the child. That seems overly convoluted. Why not just allocate it in acpi0? If a driver requests something that acpi0 has allocated, it assigns it to the child and takes it out of its resource manager. If not, then it passes things up a level in the tree. No special flags needed, although acpi does get a little more complicated. This will ensure that the resources are owned by someone, and can easily be delegated. These resource ranges are there to be used by acpi, and only acpi. There's nothing magical about the acpi_sysresource device, and it can be relegated to the scrap-heap of history if needed. This is similar to how pci bridges should be working, but aren't, right now. They have a range they decode, and they should own those resources, but given them out to their children as they request them. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 13:41:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B49516A4CE for ; Tue, 27 Jan 2004 13:41:30 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B5A9243D5D for ; Tue, 27 Jan 2004 13:41:28 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 75131 invoked by uid 1000); 27 Jan 2004 21:40:18 -0000 Date: Tue, 27 Jan 2004 13:40:18 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.141937.45155991.imp@bsdimp.com> Message-ID: <20040127133251.W75080@root.org> References: <20040127.032119.28084825.imp@bsdimp.com> <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 21:41:30 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: <20040127125547.G74774@root.org> > Nate Lawson writes: > : Ok, let me propose a design and I'd appreciate your comments. The probe > : routine for acpi_sysresource will stay the same. The attach will allocate > : the resources to its parent device (acpi0). > : > : acpi0 will make this set of resources available to its children via a > : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If > : acpi_resource_alloc finds a range already has that flag set, it will > : refuse the request. Otherwise, it will release that range and then > : immediately allocate it to the child. > > That seems overly convoluted. Why not just allocate it in acpi0? If > a driver requests something that acpi0 has allocated, it assigns it to > the child and takes it out of its resource manager. If not, then it > passes things up a level in the tree. No special flags needed, > although acpi does get a little more complicated. This will ensure > that the resources are owned by someone, and can easily be delegated. > These resource ranges are there to be used by acpi, and only acpi. So acpi0 would do a resource_list_delete for the given resource if it's in the list and then perform the alloc request. This would then succeed since no one owns the resource at that point. Once it succeeds, the child owns the range and it can't be stolen. And I guess when the child releases the range, acpi0 can reclaim all such resources. I wouldn't want a pccard device plugged in later to grab the IO ports after a child temporarily releases them (say while the ACPI Performance cpufreq driver is unloaded and then reloaded). > There's nothing magical about the acpi_sysresource device, and it can > be relegated to the scrap-heap of history if needed. Well, the way we find out about the resources is through a pseudo-device with a PNPID. So it makes sense to use the normal device discovery method to find these resources. This leads me to do the allocation for the parent by the acpi_sysresource0 attach method. -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 14:10:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C8A516A4CE; Tue, 27 Jan 2004 14:10:31 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8018743D5A; Tue, 27 Jan 2004 14:09:43 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0RM9gET098264; Tue, 27 Jan 2004 15:09:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 15:09:36 -0700 (MST) Message-Id: <20040127.150936.73380598.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127133251.W75080@root.org> References: <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> <20040127133251.W75080@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 22:10:31 -0000 In message: <20040127133251.W75080@root.org> Nate Lawson writes: : On Tue, 27 Jan 2004, M. Warner Losh wrote: : > In message: <20040127125547.G74774@root.org> : > Nate Lawson writes: : > : Ok, let me propose a design and I'd appreciate your comments. The probe : > : routine for acpi_sysresource will stay the same. The attach will allocate : > : the resources to its parent device (acpi0). : > : : > : acpi0 will make this set of resources available to its children via a : > : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If : > : acpi_resource_alloc finds a range already has that flag set, it will : > : refuse the request. Otherwise, it will release that range and then : > : immediately allocate it to the child. : > : > That seems overly convoluted. Why not just allocate it in acpi0? If : > a driver requests something that acpi0 has allocated, it assigns it to : > the child and takes it out of its resource manager. If not, then it : > passes things up a level in the tree. No special flags needed, : > although acpi does get a little more complicated. This will ensure : > that the resources are owned by someone, and can easily be delegated. : > These resource ranges are there to be used by acpi, and only acpi. : : So acpi0 would do a resource_list_delete for the given resource if it's in : the list and then perform the alloc request. This would then succeed : since no one owns the resource at that point. Once it succeeds, the child : owns the range and it can't be stolen. And I guess when the child : releases the range, acpi0 can reclaim all such resources. I wouldn't want : a pccard device plugged in later to grab the IO ports after a child : temporarily releases them (say while the ACPI Performance cpufreq driver : is unloaded and then reloaded). Right, that's why it would delegate the resource. This implies that when the delegation is released, it would go back to being owned by acpi0. : > There's nothing magical about the acpi_sysresource device, and it can : > be relegated to the scrap-heap of history if needed. : : Well, the way we find out about the resources is through a pseudo-device : with a PNPID. So it makes sense to use the normal device discovery method : to find these resources. This leads me to do the allocation for the : parent by the acpi_sysresource0 attach method. This gets ugly. The reason that I suggested not doing the discovery this way is because you want to allocate *ALL* resources up front before giving any to any children. pci has issues with this right now that I'm working to fix. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 14:25:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F84516A4CE for ; Tue, 27 Jan 2004 14:25:15 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D00643D4C for ; Tue, 27 Jan 2004 14:24:52 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 75367 invoked by uid 1000); 27 Jan 2004 22:23:15 -0000 Date: Tue, 27 Jan 2004 14:23:15 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.150936.73380598.imp@bsdimp.com> Message-ID: <20040127141708.O75272@root.org> References: <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> <20040127.150936.73380598.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 22:25:15 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: <20040127133251.W75080@root.org> > Nate Lawson writes: > : > There's nothing magical about the acpi_sysresource device, and it can > : > be relegated to the scrap-heap of history if needed. > : > : Well, the way we find out about the resources is through a pseudo-device > : with a PNPID. So it makes sense to use the normal device discovery method > : to find these resources. This leads me to do the allocation for the > : parent by the acpi_sysresource0 attach method. > > This gets ugly. The reason that I suggested not doing the discovery > this way is because you want to allocate *ALL* resources up front > before giving any to any children. pci has issues with this right now > that I'm working to fix. I'm pretty sure there is no other way to know what resources acpi devices will be using without evaluating the resource pseudo-device. The other way (which we currently do) is assume everything is available and let each driver grab whatever is free and then attach the resource pseudo-device last to claim all remaining acpi resources. Unless you have a better idea, the short-term approach will not change any of the above. It will just add the ability for acpi devices to later reclaim resources from acpi0 (by having acpi_sysresource0 attach remaining resources to its parent). Allocating all resources up front would require multiple passes of the namespace and I'm not ready to make that drastic of a change without some more design work about how this fits in with the rest of FreeBSD (in particular, PCI). -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 14:33:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67BFA16A4CE; Tue, 27 Jan 2004 14:33:23 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6690443D5D; Tue, 27 Jan 2004 14:32:38 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0RMVQET098658; Tue, 27 Jan 2004 15:31:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 15:31:20 -0700 (MST) Message-Id: <20040127.153120.67922084.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127141708.O75272@root.org> References: <20040127133251.W75080@root.org> <20040127.150936.73380598.imp@bsdimp.com> <20040127141708.O75272@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 22:33:23 -0000 In message: <20040127141708.O75272@root.org> Nate Lawson writes: : On Tue, 27 Jan 2004, M. Warner Losh wrote: : > In message: <20040127133251.W75080@root.org> : > Nate Lawson writes: : > : > There's nothing magical about the acpi_sysresource device, and it can : > : > be relegated to the scrap-heap of history if needed. : > : : > : Well, the way we find out about the resources is through a pseudo-device : > : with a PNPID. So it makes sense to use the normal device discovery method : > : to find these resources. This leads me to do the allocation for the : > : parent by the acpi_sysresource0 attach method. : > : > This gets ugly. The reason that I suggested not doing the discovery : > this way is because you want to allocate *ALL* resources up front : > before giving any to any children. pci has issues with this right now : > that I'm working to fix. : : I'm pretty sure there is no other way to know what resources acpi devices : will be using without evaluating the resource pseudo-device. The other : way (which we currently do) is assume everything is available and let each : driver grab whatever is free and then attach the resource pseudo-device : last to claim all remaining acpi resources. Unless you have a better : idea, the short-term approach will not change any of the above. It will : just add the ability for acpi devices to later reclaim resources from : acpi0 (by having acpi_sysresource0 attach remaining resources to its : parent). You could add acpi_sysresource as the first child, which would get around the issues. It could then call a private method on its parent to give it the resources. But why couldn't that code be moved up into parent? I guess I'm not understanding the difficulty here, because right now there's only one sysresource, and it does: static int acpi_sysresource_probe(device_t dev) { if (!acpi_disabled("sysresource") && acpi_MatchHid(dev, "PNP0C02")) device_set_desc(dev, "System Resource"); else return (ENXIO); device_quiet(dev); return (-100); } static int acpi_sysresource_attach(device_t dev) { struct resource *res; int i, rid; /* * Suck up all the resources that might have been assigned to us. * Note that it's impossible to tell the difference between a * resource that someone else has claimed, and one that doesn't * exist. */ for (i = 0; i < 100; i++) { rid = i; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, 0); rid = i; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, 0); rid = i; res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE); } return (0); } I'm not sure that I see. : Allocating all resources up front would require multiple passes of the : namespace and I'm not ready to make that drastic of a change without some : more design work about how this fits in with the rest of FreeBSD (in : particular, PCI). Yes. We do need to redesign the probe/attach code to have multiple passes. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 23:13:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A98016A4CE for ; Tue, 27 Jan 2004 23:13:49 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D21843D55 for ; Tue, 27 Jan 2004 23:13:39 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 77898 invoked by uid 1000); 28 Jan 2004 07:13:41 -0000 Date: Tue, 27 Jan 2004 23:13:41 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.153120.67922084.imp@bsdimp.com> Message-ID: <20040127225912.A77804@root.org> References: <20040127133251.W75080@root.org> <20040127.150936.73380598.imp@bsdimp.com> <20040127.153120.67922084.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 07:13:49 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: <20040127141708.O75272@root.org> > Nate Lawson writes: > : > : Well, the way we find out about the resources is through a pseudo-device > : > : with a PNPID. So it makes sense to use the normal device discovery method > : > : to find these resources. This leads me to do the allocation for the > : > : parent by the acpi_sysresource0 attach method. > : > > : > This gets ugly. The reason that I suggested not doing the discovery > : > this way is because you want to allocate *ALL* resources up front > : > before giving any to any children. pci has issues with this right now > : > that I'm working to fix. > : > : I'm pretty sure there is no other way to know what resources acpi devices > : will be using without evaluating the resource pseudo-device. The other > : way (which we currently do) is assume everything is available and let each > : driver grab whatever is free and then attach the resource pseudo-device > : last to claim all remaining acpi resources. Unless you have a better > : idea, the short-term approach will not change any of the above. It will > : just add the ability for acpi devices to later reclaim resources from > : acpi0 (by having acpi_sysresource0 attach remaining resources to its > : parent). > > You could add acpi_sysresource as the first child, which would get > around the issues. It could then call a private method on its parent > to give it the resources. But why couldn't that code be moved up into > parent? I guess I'm not understanding the difficulty here, because > right now there's only one sysresource, and it does: As usual, the devil is in the details. If we want to attach the resources first, we must add another namespace walk first. (And while we're at that, I'd add another pass to hook up the embedded controller after the resources so all other devices if they ignore _REG will still work. I think this is needed for some Gateways.) Instead, let's assume we keep the current approach to keep this simpler. The first step is to move the resource attach code into acpi0. As we walk the tree, when we hit a resource object, set the resources and then attach them immediately: @@ -1035,7 +1040,10 @@ * device. Ignore the return value here; it's OK for the * device not to have any resources. */ acpi_parse_resources(child, handle, &acpi_res_parse_set); if (!acpi_disabled("sysresource") && acpi_MatchHid(dev, "PNP0C02")) { acpi_parse_resources(bus, acpi_get_handle(bus), &acpi_res_parse_set); device_probe_and_attach(bus); continue; } else acpi_parse_resources(child, handle, &acpi_res_parse_set); /* If we're debugging, probe/attach now rather than later */ ACPI_DEBUG_EXEC(device_probe_and_attach(child)); Now acpi0 owns the resources. In acpi_alloc_resource, I call resource_list_alloc(). If it returns NULL, then loop through all rids, calling resource_list_find() on each. For each that it finds, check if rl->start + rl->count overlaps the requested address. If so, free this resource via resource_list_free(), call BUS_ALLOC_RESOURCE() for the caller's resource, then generate a new resource_list_alloc() for the truncated range. This would be unnecessary if we had a way to free a partial range of a resource, but it appears this is the only way. Thoughts? -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 23:34:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8691116A4CE; Tue, 27 Jan 2004 23:34:50 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFE0243D6B; Tue, 27 Jan 2004 23:34:45 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0S7YjET006514; Wed, 28 Jan 2004 00:34:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jan 2004 00:34:40 -0700 (MST) Message-Id: <20040128.003440.73380546.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127225912.A77804@root.org> References: <20040127141708.O75272@root.org> <20040127.153120.67922084.imp@bsdimp.com> <20040127225912.A77804@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: msmith@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 07:34:50 -0000 In message: <20040127225912.A77804@root.org> Nate Lawson writes: : Now acpi0 owns the resources. In acpi_alloc_resource, I : call resource_list_alloc(). If it returns NULL, then loop through all : rids, calling resource_list_find() on each. For each that it finds, check : if rl->start + rl->count overlaps the requested address. If so, free this : resource via resource_list_free(), call BUS_ALLOC_RESOURCE() for the : caller's resource, then generate a new resource_list_alloc() for the : truncated range. This would be unnecessary if we had a way to free a : partial range of a resource, but it appears this is the only way. : : Thoughts? I'd be tempted to create your own resource manager, and use the rman code to deal. Once you allocate the resources from the upstream manager (using BUS_ALLOC_RESOURCE), you can then search the resource manager to dole out the resources. Since these resources aren't associated in a 1-1 manner with how the devices will use it, unlike pci or pc card busses, this may be the easiest way to cope. The resource manager does the stuff that you talk about. The resource manager is how you deal with partial ranges. Be aware that jhb believes that there might be some bugs in the dark corners of rman that would account for some weird behavior that we've seen from time to time, but I'm less sure. You'd need to rman_init() things, and then rman_manage_region the appropriate regions. The code would look a lot like what is in nexus. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 16:06:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2698416A4CE for ; Wed, 28 Jan 2004 16:06:13 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B897E43D4C for ; Wed, 28 Jan 2004 16:06:05 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (rwcrmhc12) with ESMTP id <20040129000600014004rl3ke>; Thu, 29 Jan 2004 00:06:04 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i0T065Nb054474; Wed, 28 Jan 2004 19:06:05 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i0T05xuv054472; Wed, 28 Jan 2004 19:05:59 -0500 (EST) (envelope-from rodrigc) Date: Wed, 28 Jan 2004 19:05:59 -0500 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20040129000559.GA54451@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: ULE testing with "late" tool? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 00:06:13 -0000 Hi, I was reading the following paper about ULE: http://www.chesapeake.net/~jroberson/ULE.pdf This paper mentions a tool called "late" for measuring performance of a scheduler. Anyone know where I can obtain this tool? Thanks. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 09:03:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BFFF16A4CE for ; Fri, 30 Jan 2004 09:03:12 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DEF43D60 for ; Fri, 30 Jan 2004 09:02:41 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id DC717530A; Fri, 30 Jan 2004 18:02:22 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id DFD425308 for ; Fri, 30 Jan 2004 18:02:04 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id CB34733C6A; Fri, 30 Jan 2004 18:02:04 +0100 (CET) To: arch@freebsd.org From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 30 Jan 2004 18:02:04 +0100 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 Subject: init(8) in jails X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2004 17:03:12 -0000 Currently, the preferred mechanism to set up a virtual server in a jail is 'jail /path/to/jail jail.host.name 1.2.3.4 /etc/rc'. How about modifying init instead and teach it how to run a jail? The advantages of that approach would include the ability to send a signal to a jailed init to have it run /etc/rc.shutdown inside the jail and terminate the jail cleanly; currently, there is no clean method of terminating a jail. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 10:20:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0815716A4CE for ; Fri, 30 Jan 2004 10:20:49 -0800 (PST) Received: from 82-41-27-158.cable.ubr04.edin.blueyonder.co.uk (82-41-27-158.cable.ubr04.edin.blueyonder.co.uk [82.41.27.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF3243D1F for ; Fri, 30 Jan 2004 10:20:44 -0800 (PST) (envelope-from andrew@mux.org.uk) Received: from mux.org.uk (spatula.flat [192.168.0.2]) by myriad.flat (Postfix) with ESMTP id A9E5EBA; Fri, 30 Jan 2004 17:12:08 +0000 (GMT) Message-ID: <401AA096.9080406@mux.org.uk> Date: Fri, 30 Jan 2004 18:21:10 +0000 From: Andrew Boothman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: arch@freebsd.org Subject: Re: init(8) in jails X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2004 18:20:49 -0000 Dag-Erling Smørgrav wrote: > Currently, the preferred mechanism to set up a virtual server in a > jail is 'jail /path/to/jail jail.host.name 1.2.3.4 /etc/rc'. > > How about modifying init instead and teach it how to run a jail? The > advantages of that approach would include the ability to send a signal > to a jailed init to have it run /etc/rc.shutdown inside the jail and > terminate the jail cleanly; currently, there is no clean method of > terminating a jail. This seems to be similar to the jailer command developed by Nate Nielsen. http://memberwebs.com/nielsen/freebsd/jails/jailer/ or sysutils/jailer Andrew From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 12:31:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F0F216A4CE for ; Fri, 30 Jan 2004 12:31:28 -0800 (PST) Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4CB43D5A for ; Fri, 30 Jan 2004 12:31:24 -0800 (PST) (envelope-from dodell@sitetronics.com) Received: from sitetronics.com ([62.163.150.222]) by amsfep14-int.chello.nl ESMTP <20040130203122.UVDA18174.amsfep14-int.chello.nl@sitetronics.com>; Fri, 30 Jan 2004 21:31:22 +0100 Message-ID: <401ABEC9.1060206@sitetronics.com> Date: Fri, 30 Jan 2004 21:30:01 +0100 From: "Devon H. O'Dell" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Boothman References: <401AA096.9080406@mux.org.uk> In-Reply-To: <401AA096.9080406@mux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: init(8) in jails X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2004 20:31:28 -0000 Andrew Boothman wrote: > This seems to be similar to the jailer command developed by Nate Nielsen. > > http://memberwebs.com/nielsen/freebsd/jails/jailer/ > or sysutils/jailer > > Andrew I've found jailer to be adequate for managing my jails. To shut a jail down, I have to jexec [jid] /bin/kill -9 -1, though, otherwise it stays in the jls list. --Devon From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 14:44:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A8716A4CE for ; Fri, 30 Jan 2004 14:44:27 -0800 (PST) Received: from mta08-svc.ntlworld.com (mta08-svc.ntlworld.com [62.253.162.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41CCB43D2D for ; Fri, 30 Jan 2004 14:44:26 -0800 (PST) (envelope-from antony.t.curtis@ntlworld.com) Received: from [10.10.10.100] ([81.98.110.96]) by mta08-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040130224414.SXQL26804.mta08-svc.ntlworld.com@[10.10.10.100]>; Fri, 30 Jan 2004 22:44:14 +0000 From: Antony T Curtis To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1075502641.51737.34.camel@pcgem.rdg.cyberkinetica.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 30 Jan 2004 22:44:01 +0000 Content-Transfer-Encoding: 8bit cc: arch@freebsd.org Subject: Re: init(8) in jails X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2004 22:44:27 -0000 On Fri, 2004-01-30 at 17:02, Dag-Erling Smørgrav wrote: > Currently, the preferred mechanism to set up a virtual server in a > jail is 'jail /path/to/jail jail.host.name 1.2.3.4 /etc/rc'. > > How about modifying init instead and teach it how to run a jail? The > advantages of that approach would include the ability to send a signal > to a jailed init to have it run /etc/rc.shutdown inside the jail and > terminate the jail cleanly; currently, there is no clean method of > terminating a jail. Funnily enough, a couple of years ago, I modified init to run inside a jail... and then some terminals accessed different jails. All you need to do is to modify init to store it's pid in /var/run/init.pid and make tools which send signals to init read that file instead of assuming that init is pid=1. a quick and simple script to start/shutdown jails... and you can do fun stuff like all the console terminals are actually talking to a jailed session - gives an additional tier of confusion when someone tries to fiddle via the console. :D The 'root' non-jailed system can then run with practically no services running - just managing the jailed 'virtual servers'. I even went as far as using nmdm to be able to talk to the non-jailed system from one of the jailed instances (since the non-jail had no network service running at all) To reduplicate all the work is perhaps 2-4 hours. I don't have the source anymore because the box it was done on was wiped by my brother and he installed RedHat on it. Now, all someone needs to do is combine it with the vimage patch and you can have a nearly full virtual server system. -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 00:05:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53AF516A4CE for ; Sat, 31 Jan 2004 00:05:33 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B694243D2D for ; Sat, 31 Jan 2004 00:05:06 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.66.238] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 35573425; Sat, 31 Jan 2004 10:59:24 +0300 Received: from mobile.acsolutions.com (localhost [127.0.0.1]) ESMTP id i0V84c3U001187; Sat, 31 Jan 2004 11:04:44 +0300 (EAT) (envelope-from mtm@mobile.acsolutions.com) Received: (from mtm@localhost) by mobile.acsolutions.com (8.12.10/8.12.10/Submit) id i0V84bS2001186; Sat, 31 Jan 2004 11:04:37 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jan 2004 11:04:35 +0300 From: Mike Makonnen To: Dag-Erling Sm?rgrav Message-ID: <20040131080435.GA1172@mobile.acsolutions.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: arch@FreeBSD.org Subject: Re: init(8) in jails X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2004 08:05:33 -0000 On Fri, Jan 30, 2004 at 06:02:04PM +0100, Dag-Erling Sm?rgrav wrote: > Currently, the preferred mechanism to set up a virtual server in a > jail is 'jail /path/to/jail jail.host.name 1.2.3.4 /etc/rc'. > > How about modifying init instead and teach it how to run a jail? The > advantages of that approach would include the ability to send a signal > to a jailed init to have it run /etc/rc.shutdown inside the jail and > terminate the jail cleanly; currently, there is no clean method of > terminating a jail. I'm about to commit a patch submitted by someone else that will allow people to shutdown individual jails from /etc/rc.d/jail. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 00:33:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD4F016A4E8 for ; Tue, 3 Feb 2004 00:33:05 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id F345943D41 for ; Tue, 3 Feb 2004 00:33:03 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 93A213ABB72; Tue, 3 Feb 2004 09:34:44 +0100 (CET) Date: Tue, 3 Feb 2004 09:34:44 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@freebsd.org Message-ID: <20040203083444.GM4200@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1hVIwB4NpNcOOTEe" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i Subject: Size-independent byte order swapping functions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 08:33:06 -0000 --1hVIwB4NpNcOOTEe Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. I'm planning to commit this patch: http://garage.freebsd.pl/patches/endian.h.patch Any comments/objections? PS. It breaks build currently, because ATA stuff use function named 'bswap', but I'm planing to talk with sos@ first about renaming it. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --1hVIwB4NpNcOOTEe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQFAH10kForvXbEpPzQRAl7wAKCtTI5ThnOA0177xxi0jlyixD5duACfZaK7 1qcViU/XuCcaT0OpHcpqBcA= =v0l7 -----END PGP SIGNATURE----- --1hVIwB4NpNcOOTEe-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 01:48:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 509DF16A4CE; Tue, 3 Feb 2004 01:48:02 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id D299C43D6A; Tue, 3 Feb 2004 01:47:45 -0800 (PST) (envelope-from ru@FreeBSD.org.ua) Received: from phantom.cris.net (ru@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i139mNem083406; Tue, 3 Feb 2004 11:48:23 +0200 (EET) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i139mMmk083401; Tue, 3 Feb 2004 11:48:22 +0200 (EET) (envelope-from ru) Date: Tue, 3 Feb 2004 11:48:22 +0200 From: Ruslan Ermilov To: Pawel Jakub Dawidek Message-ID: <20040203094822.GA82507@FreeBSD.org.ua> References: <20040203083444.GM4200@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20040203083444.GM4200@garage.freebsd.pl> User-Agent: Mutt/1.5.5.1i cc: freebsd-arch@freebsd.org Subject: Re: Size-independent byte order swapping functions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 09:48:02 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 03, 2004 at 09:34:44AM +0100, Pawel Jakub Dawidek wrote: > Hello. >=20 > I'm planning to commit this patch: >=20 > http://garage.freebsd.pl/patches/endian.h.patch >=20 > Any comments/objections? >=20 A question: what would be their application? Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAH25mUkv4P6juNwoRAt0eAJ9rVfJA4fDlgf2HUV0JTyUxaiYUggCdGVJ/ Mw7ZWm9FKZBh/3WQ56h4ML0= =j1l0 -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 02:01:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 565C916A4CE; Tue, 3 Feb 2004 02:01:59 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD66743D45; Tue, 3 Feb 2004 02:01:57 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i13A1tDF006924; Tue, 3 Feb 2004 11:01:56 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 03 Feb 2004 09:34:44 +0100." <20040203083444.GM4200@garage.freebsd.pl> Date: Tue, 03 Feb 2004 11:01:55 +0100 Message-ID: <6923.1075802515@critter.freebsd.dk> cc: freebsd-arch@freebsd.org Subject: Re: Size-independent byte order swapping functions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 10:01:59 -0000 In message <20040203083444.GM4200@garage.freebsd.pl>, Pawel Jakub Dawidek write s: >I'm planning to commit this patch: > > http://garage.freebsd.pl/patches/endian.h.patch I have a hard time seeing a sensible use for these. Endianess conversion is almost exclusively used in communications (even if the "transmission media" is a disk), and I can't possibly see how it can make sense to be lax about wordsize but strict about byteordering. Could you please tell us what you need these for and why you could not use the explicitly sized families of endian functions ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 02:36:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E206216A4CE for ; Tue, 3 Feb 2004 02:36:25 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id A882043D1D for ; Tue, 3 Feb 2004 02:36:23 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 1776C3ABB5D; Tue, 3 Feb 2004 11:38:05 +0100 (CET) Date: Tue, 3 Feb 2004 11:38:04 +0100 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20040203103804.GP4200@garage.freebsd.pl> References: <20040203083444.GM4200@garage.freebsd.pl> <6923.1075802515@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+NfgObvpQT1Q9Yq" Content-Disposition: inline In-Reply-To: <6923.1075802515@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-arch@freebsd.org Subject: Re: Size-independent byte order swapping functions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 10:36:26 -0000 --U+NfgObvpQT1Q9Yq Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 03, 2004 at 11:01:55AM +0100, Poul-Henning Kamp wrote: +> >I'm planning to commit this patch: +> > +> > http://garage.freebsd.pl/patches/endian.h.patch +>=20 +> I have a hard time seeing a sensible use for these. +>=20 +> Endianess conversion is almost exclusively used in communications +> (even if the "transmission media" is a disk), and I can't possibly +> see how it can make sense to be lax about wordsize but strict about +> byteordering. +>=20 +> Could you please tell us what you need these for and why you could +> not use the explicitly sized families of endian functions ? I found them very useful while doing many such translations. It protect from problems when you need to manage many such transformations. For example, you have some structure: struct mystruct { uint16_t ms_foo; uint32_t ms_bar; uint64_t ms_foobar; }; and many places where you translate those fields. Suddenly, you need to change size of one of those fields. If you were using size-independent functions you don't need to change anything else, in other case diff will be much bigger with much mistake probability. Of course if only I found them useful, I'll stop right here. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --U+NfgObvpQT1Q9Yq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQFAH3oMForvXbEpPzQRAkgSAJ9rg3kBVfmhUickNVTBzmjVr/JuXACePni+ +mRCAQGmosK4MC8Em204nxI= =xx5e -----END PGP SIGNATURE----- --U+NfgObvpQT1Q9Yq-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 02:48:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14CCA16A4CE; Tue, 3 Feb 2004 02:48:47 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 443FB43D46; Tue, 3 Feb 2004 02:48:45 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i13AmiAF059915; Tue, 3 Feb 2004 02:48:44 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i13AmiS6059914; Tue, 3 Feb 2004 02:48:44 -0800 (PST) (envelope-from rizzo) Date: Tue, 3 Feb 2004 02:48:44 -0800 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20040203024844.A59792@xorpc.icir.org> References: <20040203083444.GM4200@garage.freebsd.pl> <6923.1075802515@critter.freebsd.dk> <20040203103804.GP4200@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040203103804.GP4200@garage.freebsd.pl>; from pjd@freebsd.org on Tue, Feb 03, 2004 at 11:38:04AM +0100 cc: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: Size-independent byte order swapping functions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 10:48:47 -0000 On Tue, Feb 03, 2004 at 11:38:04AM +0100, Pawel Jakub Dawidek wrote: ... > +> I have a hard time seeing a sensible use for these. > +> > +> Endianess conversion is almost exclusively used in communications > +> (even if the "transmission media" is a disk), and I can't possibly > +> see how it can make sense to be lax about wordsize but strict about > +> byteordering. in fact, i'd rather have some types that prevent you from making mistakes and carelessly copy values between incompatible types. I am exploring ways to do this -- e.g. at the moment i am using this: #define N(x) ((x).__x) #define H16(x) (ntohs(N(x))) #define H32(x) (ntohl(N(x))) #define N16(x) (htons(x)) #define N32(x) (htonl(x)) struct _n32_t { uint32_t __x; }; struct _n16_t { uint16_t __x; }; typedef struct _n32_t n32_t; /* network format */ typedef struct _n16_t n16_t; /* network format */ so that the compiler prevents me from assigning between host and network representations. uint32_t a, b; n32_t c, d; c = d; /* ok */ a = b; /* ok */ c = b; /* compiler complains */ N(c) = N32(b); /* ok */ b = H32(c); /* ok */ c == b; /* unfortunately does not work */ N(c) == N(b); /* ok, saves conversion */ H32(c) == H32(b); /* ok, requires conversion */ of course, the use of custom macros probably makes the code less readable once one is used to the ntoh*() stuff... cheers luigi From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 11:15:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C9F16A4CF for ; Tue, 3 Feb 2004 11:15:04 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 31FAB43D5A for ; Tue, 3 Feb 2004 11:14:59 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 32215 invoked by uid 1000); 3 Feb 2004 19:14:59 -0000 Date: Tue, 3 Feb 2004 11:14:59 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.032119.28084825.imp@bsdimp.com> Message-ID: <20040203111312.Q32201@root.org> References: <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> <20040127.032119.28084825.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 19:15:04 -0000 I'm trying to get a basic version working, using rman. Currently, I attempt to allocate resources from the parent first, via BUS_ALLOC_RESOURCE. If that succeeds, I add the resource to my rman pool via rman_manage_region and return it. If it fails, I look up the default values for the resource with resource_list_find and then attempt to reserve it with rman_reserve_resource. If that succeeds, I activate the resource and return it. The release function just deactivates it and always returns it to the local pool via rman_release_resource. I set up the initial resources by calling bus_set_resource on the acpi0 device whenever I run into the system resources object. This has the effect that early allocations will come from nexus0 and later allocations (after sysresource has been detected) come from acpi0. I think that should be ok for now. A few questions: 1. Do I have to do all the bus_set_handle gyrations found in nexus? I thought that they could be dispensed with since nexus should do all those when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE. I can certainly leave out the PC98 ifdefs since I'm relatively certain there are no PC98 ACPI machines, right? 2. Do I have to make acpi_alloc_resource/release_resource machdep now since there are so many MD things like i386 bus handles and the like? It seems that nexus on all 3 archs (ia32, ia64, amd64) is exactly the same. 3. After I have gotten a resource from nexus via BUS_ALLOC_RESOURCE and added it to the local pool through rman_manage_region, do I have to then rman_reserve_resource before returning it to the user? In the future, I'll make two passes, first to detect system resource objects (PNP0C01 and PNP0C02) and reserve resources and the second to actually probe acpi devices. I'd rather wait for newbus to do this multi-pass approach than attempt it myself with hacks to try to localize it. -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 12:17:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F5D16A4CE for ; Tue, 3 Feb 2004 12:17:19 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95F7B43D41 for ; Tue, 3 Feb 2004 12:17:17 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i13KHFHT087664; Tue, 3 Feb 2004 13:17:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 03 Feb 2004 13:16:41 -0700 (MST) Message-Id: <20040203.131641.26968129.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040203111312.Q32201@root.org> References: <20040127.032119.28084825.imp@bsdimp.com> <20040203111312.Q32201@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 20:17:19 -0000 [[ I'll draft a longer reply this evening ]] In message: <20040203111312.Q32201@root.org> Nate Lawson writes: : 1. Do I have to do all the bus_set_handle gyrations found in nexus? I think so. I'd have to look at the code. You may be able to copy the bus_handle from the BUS_ALLOC_RESOURCE resource. : I : thought that they could be dispensed with since nexus should do all those : when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE. It all depends on the details (eg, I'd have to look at the code you are writing). : I can : certainly leave out the PC98 ifdefs since I'm relatively certain there are : no PC98 ACPI machines, right? There never was or will be a ACPI implementation for pc98. : In the future, I'll make two passes, first to detect system resource : objects (PNP0C01 and PNP0C02) and reserve resources and the second to : actually probe acpi devices. I'd rather wait for newbus to do this : multi-pass approach than attempt it myself with hacks to try to localize : it. Yes. We need a better discovery phase followed by an attach phase. I don't know if this is a newbus API change yet or not. I can see it being done with most of the APIs that are in place now, but a few tweaks might be in order. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 13:43:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB0D416A4CE for ; Tue, 3 Feb 2004 13:43:48 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9168843D39 for ; Tue, 3 Feb 2004 13:43:43 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 7AE973ABB5D; Tue, 3 Feb 2004 22:45:30 +0100 (CET) Date: Tue, 3 Feb 2004 22:45:30 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@freebsd.org Message-ID: <20040203214530.GB14639@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i Subject: Non-standard ;; and SYSINIT(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 21:43:49 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. It looks like SYSINIT() macro is defined with trailing ;. Maybe there was some reason to do so, but I assume that this is a bug. There are many, many calls where an extra ; is added after SYSINIT(). SYSUNINIT() is defined without trailing ; ... This will be ok, but ;; is not supported by ICO C (gcc -pedantic tell me that). Here is a patch that fix this issue at least for SYSINIT(): http://garage.freebsd.pl/patches/SYSINIT.patch The most important part is a change in sys/kernel.h, that removes trailing ; from SYSINIT() definition: - DATA_SET(sysinit_set,uniquifier ## _sys_init); + DATA_SET(sysinit_set,uniquifier ## _sys_init) AND REMEMBER! I'm not going to commit it (without strong approvals)!:) --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQFAIBZ6ForvXbEpPzQRAsN7AKDrvbOnySBlqZVk6OOOG6iOeF4FnQCfRtwj CElZwVYZIqj0PAc+CrzKfA4= =VOMk -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 14:35:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD44A16A50D for ; Tue, 3 Feb 2004 14:35:28 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4148843D2F for ; Tue, 3 Feb 2004 14:35:16 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 3473 invoked from network); 3 Feb 2004 22:35:15 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Feb 2004 22:35:15 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i13MZ9M0002617; Tue, 3 Feb 2004 17:35:10 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: Pawel Jakub Dawidek , freebsd-arch@freebsd.org Date: Tue, 3 Feb 2004 17:20:20 -0500 User-Agent: KMail/1.5.4 References: <20040203214530.GB14639@garage.freebsd.pl> In-Reply-To: <20040203214530.GB14639@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402031720.20211.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: Non-standard ;; and SYSINIT(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 22:35:28 -0000 On Tuesday 03 February 2004 04:45 pm, Pawel Jakub Dawidek wrote: > Hello. > > It looks like SYSINIT() macro is defined with trailing ;. > Maybe there was some reason to do so, but I assume that this is a bug. > There are many, many calls where an extra ; is added after SYSINIT(). > SYSUNINIT() is defined without trailing ; ... > > This will be ok, but ;; is not supported by ICO C (gcc -pedantic > tell me that). > > Here is a patch that fix this issue at least for SYSINIT(): > > http://garage.freebsd.pl/patches/SYSINIT.patch > > The most important part is a change in sys/kernel.h, that removes > trailing ; from SYSINIT() definition: > > - DATA_SET(sysinit_set,uniquifier ## _sys_init); > + DATA_SET(sysinit_set,uniquifier ## _sys_init) > > AND REMEMBER! I'm not going to commit it (without strong approvals)!:) Yes, please. SYSINIT() without ;'s confuse "smart" editors that try to do autoindent. -- John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 15:04:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B6AB16A4CE for ; Tue, 3 Feb 2004 15:04:01 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BC2843D2D for ; Tue, 3 Feb 2004 15:03:57 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 33691 invoked by uid 1000); 3 Feb 2004 23:03:58 -0000 Date: Tue, 3 Feb 2004 15:03:58 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040203.131641.26968129.imp@bsdimp.com> Message-ID: <20040203145412.P33636@root.org> References: <20040127.032119.28084825.imp@bsdimp.com> <20040203111312.Q32201@root.org> <20040203.131641.26968129.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 23:04:01 -0000 On Tue, 3 Feb 2004, M. Warner Losh wrote: > [[ I'll draft a longer reply this evening ]] Great. > In message: <20040203111312.Q32201@root.org> > Nate Lawson writes: > : 1. Do I have to do all the bus_set_handle gyrations found in nexus? > > I think so. I'd have to look at the code. You may be able to copy > the bus_handle from the BUS_ALLOC_RESOURCE resource. I'm not quite sure how things work but I think I shouldn't have to do any post-processing of resources retrieved from BUS_ALLOC_RESOURCE. The nexus should do all the original setup and then I am just storing it in an rman pool with rman_manage_region. The handle may need to be regenerated when allocating a resource out of the rman pool (later), especially if the range changes. For example, if I BUS_ALLOC_RESOURCE 4 I/O ports and manage the whole region in rman, a later rman_release_resource and then rman_reserve_resource of 1 of them should re-set the bus handle. I can post the code if it would help. It makes my laptop hard reset a little ways into the boot. ;-) But for now, I think all I need to know is what I need to do differently in acpi than in the nexus. The differences as I see it are: 1. No previous knowledge of start/end for my rman pools. Call rman_manage_region for each resource retrieved from nexus. 2. Try a BUS_ALLOC_RESOURCE first instead of going straight to the rman pool. 3. Always release to the local rman pool, not the parent. 4. Skip most bus handle initialization that is already done in nexus. I'm sure there are problems with these assumptions. > : I > : thought that they could be dispensed with since nexus should do all those > : when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE. > > It all depends on the details (eg, I'd have to look at the code you > are writing). > > : In the future, I'll make two passes, first to detect system resource > : objects (PNP0C01 and PNP0C02) and reserve resources and the second to > : actually probe acpi devices. I'd rather wait for newbus to do this > : multi-pass approach than attempt it myself with hacks to try to localize > : it. > > Yes. We need a better discovery phase followed by an attach phase. I > don't know if this is a newbus API change yet or not. I can see it > being done with most of the APIs that are in place now, but a few > tweaks might be in order. I could implement this in acpi since we already make two attach passes for busses like PCI. Perhaps the general case could be a flags argument that is passed through to the attach handler that says what pass this is. -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 23:03:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D284C16A4CE; Tue, 3 Feb 2004 23:03:14 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87ABD43D1F; Tue, 3 Feb 2004 23:03:11 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i1472mLE020971; Wed, 4 Feb 2004 18:02:48 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1472jt4029521; Wed, 4 Feb 2004 18:02:46 +1100 Date: Wed, 4 Feb 2004 18:02:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: <200402031720.20211.john@baldwin.cx> Message-ID: <20040204172838.L1097@gamplex.bde.org> References: <20040203214530.GB14639@garage.freebsd.pl> <200402031720.20211.john@baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Pawel Jakub Dawidek cc: freebsd-arch@freebsd.org Subject: Re: Non-standard ;; and SYSINIT(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 07:03:15 -0000 On Tue, 3 Feb 2004, John Baldwin wrote: > On Tuesday 03 February 2004 04:45 pm, Pawel Jakub Dawidek wrote: > > Hello. > > > > It looks like SYSINIT() macro is defined with trailing ;. > > Maybe there was some reason to do so, but I assume that this is a bug. > > There are many, many calls where an extra ; is added after SYSINIT(). > > SYSUNINIT() is defined without trailing ; ... > > > > This will be ok, but ;; is not supported by ICO C (gcc -pedantic > > tell me that). This is a bug in the calls with the extra semicolon. All calls in the original SYSINIT() mistake^W commit didn't have it, and I fixed all the extra semicolons that were there many years ago. Unfortunately, the kernel is not usually compiled with C compilers so bugs like this keep coming back. An extra "," at the end of enum lists and types smaller than int in bitfields are other favorites (the former is pedantic and is only required for C90, but the latter is serious since it gives unportabilities at both compile and runtime). > > Here is a patch that fix this issue at least for SYSINIT(): > > > > http://garage.freebsd.pl/patches/SYSINIT.patch This seems to be missing a few. A quick grep shows 111 lines matching "^-SYSINIT" in it, but there are 244 lines matching "^SYSINIT" in .c files in the kernel; among the latter there are 144 currently correct lines without the semicolon and 71 lines with it. I prefer not to make cosmetic changes in large amounts of non-broken code when it outweighs the broken code and was sort of waiting for the broken code to outweigh the non-broken code (or better, for SYSINIT to mostly go away) before changing this. Unfortunately, SYSINIT is not going away; RELENG_3: 112 lines without semicolon 20 with it RELENG_4: 80 lines without semicolon 46 with it -current: 144 lines without semicolon 71 with it > > The most important part is a change in sys/kernel.h, that removes > > trailing ; from SYSINIT() definition: > > > > - DATA_SET(sysinit_set,uniquifier ## _sys_init); > > + DATA_SET(sysinit_set,uniquifier ## _sys_init) > > > > AND REMEMBER! I'm not going to commit it (without strong approvals)!:) > > Yes, please. SYSINIT() without ;'s confuse "smart" editors that try to do > autoindent. There is a PR or two about this (mostly from the point of view of editors, starting with one for gtags IIRC). The queue FOREACH macros are similar mistakes at the level of editors. You have to add {} to make short loops even uglier to get indent(1) to accidentally understand them. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 23:30:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2D2F16A4CE for ; Tue, 3 Feb 2004 23:30:01 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C98943D2F for ; Tue, 3 Feb 2004 23:29:59 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id D11C83ABB5D; Wed, 4 Feb 2004 08:31:48 +0100 (CET) Date: Wed, 4 Feb 2004 08:31:48 +0100 From: Pawel Jakub Dawidek To: Bruce Evans Message-ID: <20040204073148.GD14639@garage.freebsd.pl> References: <20040203214530.GB14639@garage.freebsd.pl> <200402031720.20211.john@baldwin.cx> <20040204172838.L1097@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MAH+hnPXVZWQ5cD/" Content-Disposition: inline In-Reply-To: <20040204172838.L1097@gamplex.bde.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: John Baldwin cc: freebsd-arch@freebsd.org Subject: Re: Non-standard ;; and SYSINIT(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 07:30:02 -0000 --MAH+hnPXVZWQ5cD/ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2004 at 06:02:45PM +1100, Bruce Evans wrote: +> > > It looks like SYSINIT() macro is defined with trailing ;. +> > > Maybe there was some reason to do so, but I assume that this is a bu= g. +> > > There are many, many calls where an extra ; is added after SYSINIT(). +> > > SYSUNINIT() is defined without trailing ; ... +> > > +> > > This will be ok, but ;; is not supported by ICO C (gcc -pedantic +> > > tell me that). +>=20 +> This is a bug in the calls with the extra semicolon. All calls in the +> original SYSINIT() mistake^W commit didn't have it, and I fixed all +> the extra semicolons that were there many years ago. Unfortunately, +> the kernel is not usually compiled with C compilers so bugs like this +> keep coming back. An extra "," at the end of enum lists and types +> smaller than int in bitfields are other favorites (the former is pedantic +> and is only required for C90, but the latter is serious since it gives +> unportabilities at both compile and runtime). +>=20 +> > > Here is a patch that fix this issue at least for SYSINIT(): +> > > +> > > http://garage.freebsd.pl/patches/SYSINIT.patch +>=20 +> This seems to be missing a few. A quick grep shows 111 lines matching +> "^-SYSINIT" in it, but there are 244 lines matching "^SYSINIT" in .c +> files in the kernel; among the latter there are 144 currently correct +> lines without the semicolon and 71 lines with it. I prefer not to +> make cosmetic changes in large amounts of non-broken code when it +> outweighs the broken code and was sort of waiting for the broken code +> to outweigh the non-broken code (or better, for SYSINIT to mostly go +> away) before changing this. Unfortunately, SYSINIT is not going away; +> RELENG_3: 112 lines without semicolon 20 with it +> RELENG_4: 80 lines without semicolon 46 with it +> -current: 144 lines without semicolon 71 with it Have you count: SYSINIT(..., ..., ...); ? Or SYSINITs in other macros? They don't start with line start sometimes. Anyway, I am able to compile LINT with my patch and SYSINIT() without semicolon is treated as a bug. +> > > The most important part is a change in sys/kernel.h, that removes +> > > trailing ; from SYSINIT() definition: +> > > +> > > - DATA_SET(sysinit_set,uniquifier ## _sys_init); +> > > + DATA_SET(sysinit_set,uniquifier ## _sys_init) +> > > +> > > AND REMEMBER! I'm not going to commit it (without strong approvals)!= :) +> > +> > Yes, please. SYSINIT() without ;'s confuse "smart" editors that try t= o do +> > autoindent. +>=20 +> There is a PR or two about this (mostly from the point of view of editor= s, +> starting with one for gtags IIRC). +>=20 +> The queue FOREACH macros are similar mistakes at the level of editors. +> You have to add {} to make short loops even uglier to get indent(1) to +> accidentally understand them. So maybe this is good time to start such little, but big cleanups. Now we have SYSINIT() which doesn't require semicol and SYSUNINIT() which needs it. If you will decide to do this, feel free to use my patch. IMHO this is worth it, if we want to support other compilers in the future. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --MAH+hnPXVZWQ5cD/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQFAIJ/kForvXbEpPzQRAs+HAKCYpHCDTTA0QdSrQbSMyLNbg/eZYwCglMtj F8N3Sxb8wxRRfvU8pOHVdR0= =5hfK -----END PGP SIGNATURE----- --MAH+hnPXVZWQ5cD/-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 04:47:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 333D016A4CE for ; Wed, 4 Feb 2004 04:47:46 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C4843D53 for ; Wed, 4 Feb 2004 04:47:43 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i14ClfDF029980 for ; Wed, 4 Feb 2004 13:47:41 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 04 Feb 2004 13:47:41 +0100 Message-ID: <29979.1075898861@critter.freebsd.dk> Subject: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 12:47:46 -0000 I'm just using Rijndael/AES for illustration, the same issues apply to various other algorithms. Right now we have identical (apart from some trivial details) of the AES algorithms in the kernel: [1] src/sys/crypto/rijndael/* [ipsec, random and geom_bde options] [2] arc/sys/opencrypto/rijndael.? [crypto] As far as I can see, the src/crypto stuff which is slightly better organized, originally arrived with KAME, and the sys/opencrypto stuff of came in with sam@'s HW-crypto support work. The HW-crypto support code only needs a software implementation as a fall-back if hardware does not offer it. I would like to propose that we try to eliminate the private copies of crypto functions in sys/opencrypto and instead focus on the copies in src/crypto as our "generic" implementations. Are there any technical or political reasons why we should not do this ? Next problem is that there currently is no way to detect if opencrypto is present in the kernel or not, or for that matter if we have the rijndael code in there or not. This makes life for GBDE as a KLD sort of interesting. Were are we going with our kernel modularization ? Do we want to use multi-level module dependencies ? "gbde depends on opencrypto _or_ rijndael" "opencrypto depends on rijndael and [...]" "random depends on rijndael" If not, how else do we want to manage this "creepy maze of dependencies, all tangled" ? For reference: a rijndael implementation is about 14kB in .o files GBDE is about 15kB in .o files Opencrypto framework is about 25kB in .o files Sw-crypto engines an additional 40kB (incl rijndael) One obvious and tempting solution is to make opencrypt non-optional since that solves all the dependency issues. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 06:01:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B479E16A4DF for ; Wed, 4 Feb 2004 06:01:40 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA3A43D1D for ; Wed, 4 Feb 2004 06:01:38 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id A357F5308; Wed, 4 Feb 2004 15:01:37 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 746CB5310; Wed, 4 Feb 2004 15:01:31 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 572D633C6A; Wed, 4 Feb 2004 15:01:31 +0100 (CET) To: Poul-Henning Kamp References: <29979.1075898861@critter.freebsd.dk> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 04 Feb 2004 15:01:31 +0100 In-Reply-To: <29979.1075898861@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 04 Feb 2004 13:47:41 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 14:01:42 -0000 Poul-Henning Kamp writes: > I would like to propose that we try to eliminate the private copies > of crypto functions in sys/opencrypto and instead focus on the > copies in src/crypto as our "generic" implementations. > > Are there any technical or political reasons why we should not do this ? I'm not sure how well-tested the KAME code is. For instance, until recently, src/sys/crypto/md5.c used a static buffer as temporary storage on big-endian systems, making it non-reentrant. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 06:13:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44BC716A4CE for ; Wed, 4 Feb 2004 06:13:37 -0800 (PST) Received: from cheer.mahoroba.org (flets20-024.kamome.or.jp [218.45.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F3F943D46 for ; Wed, 4 Feb 2004 06:13:33 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:g8fp8BiZ9qlLWMLK3R6LgK0uy+oKkDFCsnOaDQXulEYmyFsygRNxFfJ5xWp+UmiN@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i14EDDZS042362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2004 23:13:20 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Wed, 04 Feb 2004 23:13:13 +0900 Message-ID: From: Hajimu UMEMOTO To: des@des.no (Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?=) In-Reply-To: References: <29979.1075898861@critter.freebsd.dk> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.2-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cheer.mahoroba.org cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 14:13:37 -0000 Hi, >>>>> On Wed, 04 Feb 2004 15:01:31 +0100 >>>>> Dag-Erling Sm=F8rgrav said: des> I'm not sure how well-tested the KAME code is. For instance, until des> recently, src/sys/crypto/md5.c used a static buffer as temporary des> storage on big-endian systems, making it non-reentrant. src/sys/crypto/md5.c is not derived from KAME, and KAME doesn't use it at all. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 10:21:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3D5116A4CE for ; Wed, 4 Feb 2004 10:21:14 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EAA43D1D for ; Wed, 4 Feb 2004 10:21:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 24334 invoked from network); 4 Feb 2004 18:21:11 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Feb 2004 18:21:11 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i14IL5M0007692; Wed, 4 Feb 2004 13:21:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson , "M. Warner Losh" Date: Wed, 4 Feb 2004 10:47:17 -0500 User-Agent: KMail/1.5.4 References: <20040203.131641.26968129.imp@bsdimp.com> <20040203145412.P33636@root.org> In-Reply-To: <20040203145412.P33636@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402041047.17902.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 18:21:14 -0000 On Tuesday 03 February 2004 06:03 pm, Nate Lawson wrote: > On Tue, 3 Feb 2004, M. Warner Losh wrote: > > : In the future, I'll make two passes, first to detect system resource > > : objects (PNP0C01 and PNP0C02) and reserve resources and the second to > > : actually probe acpi devices. I'd rather wait for newbus to do this > > : multi-pass approach than attempt it myself with hacks to try to > > : localize it. > > > > Yes. We need a better discovery phase followed by an attach phase. I > > don't know if this is a newbus API change yet or not. I can see it > > being done with most of the APIs that are in place now, but a few > > tweaks might be in order. > > I could implement this in acpi since we already make two attach passes for > busses like PCI. Perhaps the general case could be a flags argument that > is passed through to the attach handler that says what pass this is. We need to allow something that allows legacy drivers to work out of the box at the last pass and it needs to be more flexible than just special casing PCI/ACPI resource allocation. I want more than just 2 passes btw: pass 1: enumerate busses including bridges to further busses - this would possibly include some rough resource allocation where each bus would allocate space from its parent that it hands out to children - this pass might also include things like pnpbios and acpi system resource drivers pass 2: enumerate interrupt source providers (i.e. PICs) - after this, interrupt handlers should be able to run, though perhaps not safe to rely on yet due to lack of working timeouts pass 3: let all the previously probed devices attach interrupt handlers if needed (like acpi0 needing the SCI) pass 4: enumerate clock devices - this lets us get timeouts working. We can now start scheduling ithreads and allowing interrupt handlers to run. ... pass 0 (done last): everything else Now most devices will always probe/attach with interrupts and timeouts fully up and running like they are when a driver is kldloaded after boot, meaning that all the config intr hook crap can die, etc. I think that a driver with a legacy foo_probe/foo_attach should only be called during the last pass. One possible way to accomplish this with minimal damage is to add a pass number field to the driver structure after the softc field and have pass 0 be the magic pass that happens at the end. That would get legacy drivers working w/ just a recompile. The other thing you want to do though would be to add a pass number to foo_attach(), and once a driver is probed, it's attach routine would get called for every subsequent pass with the pass number passed in as the argument. This would require an API/ABI change for foo_attach though. The reason for this is that some devices might need to do different things for different passes. For example, acpi0 would want to parse the madt to enumerate PICs during pass 2 even though it would be a pass 1 driver. The same for legacy0 and using the mptable in pass2. I'm not sure if this is the best approach for that case. You might be able to do it w/o changing foo_attach() by having an apic pass 2 driver that is a child of acpi0 whose identify routine parses the MADT and similarly for legacy0 by having the apic driver parse mptable for its identify routine. That would allow us to keep API compatiblity and only adjust the driver struct ABI. Doing this would allow us to finally kick things like CPUs, PICs, clocks and other system devices under new-bus properly. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 16:07:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FED416A4CE for ; Wed, 4 Feb 2004 16:07:08 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF20943D54 for ; Wed, 4 Feb 2004 16:07:06 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id AE7AF72DC7; Wed, 4 Feb 2004 16:07:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id AC6C572DBF; Wed, 4 Feb 2004 16:07:06 -0800 (PST) Date: Wed, 4 Feb 2004 16:07:06 -0800 (PST) From: Doug White To: Poul-Henning Kamp In-Reply-To: <29979.1075898861@critter.freebsd.dk> Message-ID: <20040204160446.F96240@carver.gumbysoft.com> References: <29979.1075898861@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 00:07:08 -0000 On Wed, 4 Feb 2004, Poul-Henning Kamp wrote: > > I'm just using Rijndael/AES for illustration, the same issues apply > to various other algorithms. > > Right now we have identical (apart from some trivial details) of the > AES algorithms in the kernel: > > [1] src/sys/crypto/rijndael/* > [ipsec, random and geom_bde options] > > [2] arc/sys/opencrypto/rijndael.? > [crypto] You'd have to go back to the original discussion, but I though that we decided to go with this to avoid complicating KAME imports. Just trying to inject some history into the discussion :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 23:19:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C232F16A4CE for ; Wed, 4 Feb 2004 23:19:20 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E99D43D1F for ; Wed, 4 Feb 2004 23:19:19 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id i157JHHQ060655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 Feb 2004 23:19:18 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Poul-Henning Kamp , arch@freebsd.org Date: Wed, 4 Feb 2004 23:24:18 -0800 User-Agent: KMail/1.5.3 References: <29979.1075898861@critter.freebsd.dk> In-Reply-To: <29979.1075898861@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402042324.18434.sam@errno.com> Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 07:19:20 -0000 On Wednesday 04 February 2004 04:47 am, Poul-Henning Kamp wrote: > I'm just using Rijndael/AES for illustration, the same issues apply > to various other algorithms. > > Right now we have identical (apart from some trivial details) of the > AES algorithms in the kernel: > > [1] src/sys/crypto/rijndael/* > [ipsec, random and geom_bde options] > > [2] arc/sys/opencrypto/rijndael.? > [crypto] > > As far as I can see, the src/crypto stuff which is slightly better > organized, originally arrived with KAME, and the sys/opencrypto > stuff of came in with sam@'s HW-crypto support work. > > The HW-crypto support code only needs a software implementation as > a fall-back if hardware does not offer it. > > I would like to propose that we try to eliminate the private copies > of crypto functions in sys/opencrypto and instead focus on the > copies in src/crypto as our "generic" implementations. > > Are there any technical or political reasons why we should not do this ? > All the cipher code in opencrypto is there for a reason; either because it ran substantially faster than the KAME code at the time I imported the crypto framework or because there were API incompatbilities that made using the KAME versions difficult. In general the one overriding rule I had was that I could not remove any code in crypto so anything new had to go in opencrypto. Where there are no longer reasons to keep duplicate copies I'm fine with removing code from opencrypto. But before you do this you might also compare the code to the current work in openbsd (from which this stuff came) to see if there are changes there that might change your decision. > > Next problem is that there currently is no way to detect if opencrypto > is present in the kernel or not, or for that matter if we have the > rijndael code in there or not. This makes life for GBDE as a KLD > sort of interesting. > > Were are we going with our kernel modularization ? > > Do we want to use multi-level module dependencies ? > > "gbde depends on opencrypto _or_ rijndael" > "opencrypto depends on rijndael and [...]" > "random depends on rijndael" > > If not, how else do we want to manage this "creepy maze of dependencies, > all tangled" ? > > For reference: > a rijndael implementation is about 14kB in .o files > > GBDE is about 15kB in .o files > > Opencrypto framework is about 25kB in .o files > Sw-crypto engines an additional 40kB (incl rijndael) > > One obvious and tempting solution is to make opencrypt non-optional > since that solves all the dependency issues. I tried to get opencrypto included in GENERIC for 5.2 but was too late. I think making it part of the base system is too costly for embedded environments but could be persuaded otherwise. I think with your recent mods that gbde depends on opencrypto so I'm not sure why you're worried about an explicit rijndael dependency unless you can build gbde w/ and w/o the opencrypto usage. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 23:30:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D8A816A4CE for ; Wed, 4 Feb 2004 23:30:24 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD6043D41 for ; Wed, 4 Feb 2004 23:30:22 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i157UGDF038922; Thu, 5 Feb 2004 08:30:16 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Sam Leffler From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 04 Feb 2004 23:24:18 PST." <200402042324.18434.sam@errno.com> Date: Thu, 05 Feb 2004 08:30:16 +0100 Message-ID: <38921.1075966216@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 07:30:24 -0000 In message <200402042324.18434.sam@errno.com>, Sam Leffler writes: >All the cipher code in opencrypto is there for a reason; either because it ran >substantially faster than the KAME code at the time I imported the crypto >framework or because there were API incompatbilities that made using the KAME >versions difficult. In general the one overriding rule I had was that I could >not remove any code in crypto so anything new had to go in opencrypto. If we collapse the two, we should of course keep the best version. I guess my suggestion/question could also be put this way: "Is it about time we stop having a 'KAME crypto' and a 'OpenCrypto' code set, and instead get us a 'FreeBSD crypto' code set. >I tried to get opencrypto included in GENERIC for 5.2 but was too late. I >think making it part of the base system is too costly for embedded >environments but could be persuaded otherwise. > >I think with your recent mods that gbde depends on opencrypto so I'm not sure >why you're worried about an explicit rijndael dependency unless you can build >gbde w/ and w/o the opencrypto usage. Well, my problem is that either I need a compiletime #ifdef to decide to pull in opencrypto support, or we need to add failing stub-functions when we do not have opencrypto in the kernel. I would really like to avoid the situation where I have to have two different gbde kld's: one with and one without opencrypto. But as I said, it may be time to discuss the overall issue of kld dependencies, rather than just scratch my own little itch... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 00:46:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 304BB16A4CE for ; Thu, 5 Feb 2004 00:46:04 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8864343D31 for ; Thu, 5 Feb 2004 00:46:02 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i158k0DF039613; Thu, 5 Feb 2004 09:46:00 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Doug White From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 04 Feb 2004 16:07:06 PST." <20040204160446.F96240@carver.gumbysoft.com> Date: Thu, 05 Feb 2004 09:46:00 +0100 Message-ID: <39612.1075970760@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 08:46:04 -0000 In message <20040204160446.F96240@carver.gumbysoft.com>, Doug White writes: >On Wed, 4 Feb 2004, Poul-Henning Kamp wrote: > >> >> I'm just using Rijndael/AES for illustration, the same issues apply >> to various other algorithms. >> >> Right now we have identical (apart from some trivial details) of the >> AES algorithms in the kernel: >> >> [1] src/sys/crypto/rijndael/* >> [ipsec, random and geom_bde options] >> >> [2] arc/sys/opencrypto/rijndael.? >> [crypto] > >You'd have to go back to the original discussion, but I though that we >decided to go with this to avoid complicating KAME imports. > >Just trying to inject some history into the discussion :) I realize that, but for something as generic as specific cryptographic algorithms, I do not think that is a valid argument for having two implementations in the kernel, particularly not for a case like the AES implementation which is line-for-line identical. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 06:46:07 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D8416A4CE for ; Thu, 5 Feb 2004 06:46:07 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1680543D1F for ; Thu, 5 Feb 2004 06:46:05 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i15Ek0nJ026353; Thu, 5 Feb 2004 07:46:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 05 Feb 2004 07:45:49 -0700 (MST) Message-Id: <20040205.074549.128866887.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <38921.1075966216@critter.freebsd.dk> References: <200402042324.18434.sam@errno.com> <38921.1075966216@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@errno.com cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 14:46:07 -0000 In message: <38921.1075966216@critter.freebsd.dk> "Poul-Henning Kamp" writes: : But as I said, it may be time to discuss the overall issue of kld : dependencies, rather than just scratch my own little itch... Typically people just put the module dependency into their kld and get on with their lives. There's really little to discuss except maybe making an opencrypto module... At least as far as the dependency issue with klds. I have no comment on the code duplication aspects. I've been using something similar to share code between a couple of different drivers I work on. There's a few other drivers in the tree that depend on various things (wlan, elink, md5, etc). The md5 depend could easily be a more generic crypto depend. It was convenient at the time to do what I did. If there's any kind of kld issues, it is that the core part of the kernel is too large and needs to be a little more modular. However, breaking things down further than they are can be hard. The problem as I see it is that there are too many 10k-100k chunks that are non-optional. This makes it hard to subset below a certain point. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 08:46:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D85FC16A4CE for ; Thu, 5 Feb 2004 08:46:43 -0800 (PST) Received: from laika.ifs.tuwien.ac.at (laika.ifs.tuwien.ac.at [128.131.167.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0A7443D1F for ; Thu, 5 Feb 2004 08:46:42 -0800 (PST) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by laika.ifs.tuwien.ac.at (Postfix) with ESMTP id 2D07D2087 for ; Thu, 5 Feb 2004 17:48:33 +0100 (CET) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id EE7DA40ED for ; Thu, 5 Feb 2004 17:46:40 +0100 (CET) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id C21DB1D4; Thu, 5 Feb 2004 17:46:40 +0100 (CET) Date: Thu, 5 Feb 2004 17:46:40 +0100 From: Stefan Farfeleder To: arch@freebsd.org Message-ID: <20040205164639.GC602@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i Subject: C99 variadic macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 16:46:44 -0000 Hi, I went through the source tree and converted all occurrences of GNU-style variadic macros to C99 compliant ones in !contrib code. For macros that (ab)use string concatenation like #define foo(fmt, args...) printf("%s: " fmt "\n", __func__, ##args) three printf's must be used. As almost all variadic macros are used for debugging, this shouldn't matter much. Two occurrences (src/lib/libypclnt/ypclnt.h and src/sys/dev/ichsmb/ichsmb.c) remain since they can't be converted easily and are already protected by defined(__GNUC__). http://www.ten15.org/~stefanf/FreeBSD/vamacro.diff Cheers, Stefan Farfeleder From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 11:30:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D988F16A542 for ; Thu, 5 Feb 2004 11:30:29 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02DAA43D53 for ; Thu, 5 Feb 2004 11:30:00 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 29617 invoked from network); 5 Feb 2004 19:28:48 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Feb 2004 19:28:48 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i15JSXM4014155; Thu, 5 Feb 2004 14:28:42 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: Stefan Farfeleder , arch@freebsd.org Date: Thu, 5 Feb 2004 14:05:59 -0500 User-Agent: KMail/1.5.4 References: <20040205164639.GC602@wombat.fafoe.narf.at> In-Reply-To: <20040205164639.GC602@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402051405.59533.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: C99 variadic macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 19:30:33 -0000 On Thursday 05 February 2004 11:46 am, Stefan Farfeleder wrote: > Hi, > > I went through the source tree and converted all occurrences of > GNU-style variadic macros to C99 compliant ones in !contrib code. > For macros that (ab)use string concatenation like > > #define foo(fmt, args...) printf("%s: " fmt "\n", __func__, ##args) > > three printf's must be used. As almost all variadic macros are used for > debugging, this shouldn't matter much. Two occurrences > (src/lib/libypclnt/ypclnt.h and src/sys/dev/ichsmb/ichsmb.c) remain > since they can't be converted easily and are already protected by > defined(__GNUC__). > > http://www.ten15.org/~stefanf/FreeBSD/vamacro.diff C99 macros don't work when args is 0. I.e., if I did: foo("test"); The C99 _VA_ARGS_ think doesn't delete the , whereas the GCC way does. -- John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 12:06:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58AA816A4CE for ; Thu, 5 Feb 2004 12:06:13 -0800 (PST) Received: from laika.ifs.tuwien.ac.at (laika.ifs.tuwien.ac.at [128.131.167.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C0043D68 for ; Thu, 5 Feb 2004 12:05:49 -0800 (PST) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by laika.ifs.tuwien.ac.at (Postfix) with ESMTP id 509E3209E; Thu, 5 Feb 2004 21:06:49 +0100 (CET) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 1108840ED; Thu, 5 Feb 2004 21:04:57 +0100 (CET) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 845E21D4; Thu, 5 Feb 2004 21:04:56 +0100 (CET) Date: Thu, 5 Feb 2004 21:04:56 +0100 From: Stefan Farfeleder To: John Baldwin Message-ID: <20040205200454.GD602@wombat.fafoe.narf.at> References: <20040205164639.GC602@wombat.fafoe.narf.at> <200402051405.59533.john@baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402051405.59533.john@baldwin.cx> User-Agent: Mutt/1.5.5.1i cc: arch@freebsd.org Subject: Re: C99 variadic macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 20:06:15 -0000 On Thu, Feb 05, 2004 at 02:05:59PM -0500, John Baldwin wrote: > On Thursday 05 February 2004 11:46 am, Stefan Farfeleder wrote: > > #define foo(fmt, args...) printf("%s: " fmt "\n", __func__, ##args) > C99 macros don't work when args is 0. I.e., if I did: > > foo("test"); > > The C99 _VA_ARGS_ think doesn't delete the , whereas the GCC way does. While it's true that the ellipsis must match a positive number of arguments, this isn't necessarily a problem. You just use "..." for both the format string and its arguments. Cheers, Stefan Farfeleder From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 12:44:18 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0A4416A4CE for ; Thu, 5 Feb 2004 12:44:18 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C373143D55 for ; Thu, 5 Feb 2004 12:43:54 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 21325 invoked from network); 5 Feb 2004 20:43:49 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Feb 2004 20:43:49 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i15KhiM0014557; Thu, 5 Feb 2004 15:43:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Stefan Farfeleder Date: Thu, 5 Feb 2004 15:44:48 -0500 User-Agent: KMail/1.5.4 References: <20040205164639.GC602@wombat.fafoe.narf.at> <200402051405.59533.john@baldwin.cx> <20040205200454.GD602@wombat.fafoe.narf.at> In-Reply-To: <20040205200454.GD602@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402051544.48349.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: C99 variadic macros X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 20:44:19 -0000 On Thursday 05 February 2004 03:04 pm, Stefan Farfeleder wrote: > On Thu, Feb 05, 2004 at 02:05:59PM -0500, John Baldwin wrote: > > On Thursday 05 February 2004 11:46 am, Stefan Farfeleder wrote: > > > #define foo(fmt, args...) printf("%s: " fmt "\n", __func__, ##args) > > > > C99 macros don't work when args is 0. I.e., if I did: > > > > foo("test"); > > > > The C99 _VA_ARGS_ think doesn't delete the , whereas the GCC way does. > > While it's true that the ellipsis must match a positive number of > arguments, this isn't necessarily a problem. You just use "..." for > both the format string and its arguments. Not always easily done in my experience, though the 3 printf thing (ugh) might serve as a workaround as I didn't try that before when I've tried to use the C99 way. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 14:31:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E1416A4CE for ; Thu, 5 Feb 2004 14:31:08 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5875443D39 for ; Thu, 5 Feb 2004 14:31:07 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i15MUqN4003145; Thu, 5 Feb 2004 23:30:57 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 05 Feb 2004 07:45:49 MST." <20040205.074549.128866887.imp@bsdimp.com> Date: Thu, 05 Feb 2004 23:30:52 +0100 Message-ID: <3144.1076020252@critter.freebsd.dk> cc: sam@errno.com cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 22:31:08 -0000 In message <20040205.074549.128866887.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <38921.1075966216@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: But as I said, it may be time to discuss the overall issue of kld >: dependencies, rather than just scratch my own little itch... > >Typically people just put the module dependency into their kld and get >on with their lives. There's really little to discuss except maybe >making an opencrypto module... At least as far as the dependency >issue with klds. I have no comment on the code duplication aspects. And that means that "optional dependencies" are not in the picture ? I want gbde to use opencrypto if it is there, but I do not want to require it (since it is optional from GBDE's point of view). Is there any sane way to do that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 5 15:12:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F90816A4CE for ; Thu, 5 Feb 2004 15:12:08 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A37BF43D55 for ; Thu, 5 Feb 2004 15:12:05 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i15NC1nJ032221; Thu, 5 Feb 2004 16:12:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 05 Feb 2004 16:11:58 -0700 (MST) Message-Id: <20040205.161158.71089474.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <3144.1076020252@critter.freebsd.dk> References: <20040205.074549.128866887.imp@bsdimp.com> <3144.1076020252@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@errno.com cc: arch@freebsd.org Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 23:12:08 -0000 In message: <3144.1076020252@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040205.074549.128866887.imp@bsdimp.com>, "M. Warner Losh" writes: : >In message: <38921.1075966216@critter.freebsd.dk> : > "Poul-Henning Kamp" writes: : >: But as I said, it may be time to discuss the overall issue of kld : >: dependencies, rather than just scratch my own little itch... : > : >Typically people just put the module dependency into their kld and get : >on with their lives. There's really little to discuss except maybe : >making an opencrypto module... At least as far as the dependency : >issue with klds. I have no comment on the code duplication aspects. : : And that means that "optional dependencies" are not in the picture ? : : I want gbde to use opencrypto if it is there, but I do not want to : require it (since it is optional from GBDE's point of view). : : Is there any sane way to do that ? Ah. I see. Yes, there's a way to do it, but it requires lots of cooperation on the part the optional module. Warner