From owner-freebsd-new-bus Wed Jan 26 0:40:54 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id 3F4E115167 for ; Wed, 26 Jan 2000 00:40:51 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.103]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA649C for ; Wed, 26 Jan 2000 09:40:45 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id JAA09497 for new-bus@freebsd.org; Wed, 26 Jan 2000 09:40:20 +0100 (CET) (envelope-from asmodai) Date: Wed, 26 Jan 2000 09:40:20 +0100 From: Jeroen Ruigrok/Asmodai To: new-bus@freebsd.org Subject: newbus from a documentation view Message-ID: <20000126094020.G290@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi guys, most of you know I am working on the documentation for newbus/busspace and consequently device drivers. (Heaven knows how Bill Paul, Poul-Henning, Peter and Matthew already have grey hairs by now *g*.) What I haven't been able to define is a discription for newbus. Sure, it is the new bus structure, but how is it best to be described? ``As a system that allows for a very structured device and bus architecture by means of interconnecting busses and devices in a logical way.'' Also, did I miss important files functions in this list: machine/bus.h I see that this one is basically an empty header, deprecated in usage? machine/bus_pio.h I see that this one is also an empty header, also deprecated in usage? machine/resource.h sys/bus.h sys/bus_private.h sys/module.h The function houdeholding is for later today. =) -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project How the gods kill... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Jan 26 0:45:15 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 1B59414CF2 for ; Wed, 26 Jan 2000 00:45:13 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id DAA83993; Wed, 26 Jan 2000 03:45:11 -0500 (EST) Date: Wed, 26 Jan 2000 03:45:10 -0500 (EST) From: "Matthew N. Dodd" To: Jeroen Ruigrok/Asmodai Cc: new-bus@FreeBSD.ORG Subject: Re: newbus from a documentation view In-Reply-To: <20000126094020.G290@daemon.ninth-circle.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Jan 2000, Jeroen Ruigrok/Asmodai wrote: > ``As a system that allows for a very structured device and bus > architecture by means of interconnecting busses and devices in a logical > way.'' Object Oriented Dynamic Attachment Bus Abstraction Layer would be 'catch phrases' I would try to use. :) > Also, did I miss important files functions in this list: > > machine/bus.h sys/i386/include/bus.h depending on which hardware we run) > > machine/bus_memio.h > I see that this one is basically an empty header, deprecated in > usage? > > machine/bus_pio.h > I see that this one is also an empty header, also deprecated in > usage? > > machine/resource.h > > sys/bus.h > > sys/bus_private.h > > sys/module.h > > The function houdeholding is for later today. =) So long as you make it clear that the newbus, bus-space, bus-dma and the resource manager are different things though in some cases more or less related to eachother I think you'll be ok. (Since it wasn't very clear where one stopped and another began when I started looking at things.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Jan 26 9:23:26 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id 1CF82154A9 for ; Wed, 26 Jan 2000 09:23:23 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.166]) by smtp04.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA3B2F; Wed, 26 Jan 2000 18:23:19 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id SAA14417; Wed, 26 Jan 2000 18:23:10 +0100 (CET) (envelope-from asmodai) Date: Wed, 26 Jan 2000 18:23:10 +0100 From: Jeroen Ruigrok/Asmodai To: "Matthew N. Dodd" Cc: new-bus@FreeBSD.ORG Subject: Re: newbus from a documentation view Message-ID: <20000126182309.H290@daemon.ninth-circle.org> References: <20000126094020.G290@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from winter@jurai.net on Wed, Jan 26, 2000 at 03:45:10AM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000126 09:59], Matthew N. Dodd (winter@jurai.net) wrote: >On Wed, 26 Jan 2000, Jeroen Ruigrok/Asmodai wrote: >> ``As a system that allows for a very structured device and bus >> architecture by means of interconnecting busses and devices in a logical >> way.'' > >Object Oriented >Dynamic Attachment >Bus Abstraction Layer *cough* ``Newbus is the new bus abstraction layer architecture which saw its introduction in FreeBSD 4.0. Its goals are to provide a more object oriented means of interconnecting the various busses and devices which a host system provides to the Operating System. Its main features include amongst others: dynamic attaching, easy modularisation of drivers, and pseudo-busses.'' I probably still missed some things. Feel free to point them out and I'll try to rewrite it within the boundaries of english. ;) >> machine/bus_memio.h >> I see that this one is basically an empty header, deprecated in >> usage? I see we #define bus_memio_h in machine/bus.h, so basically all drivers including machine/bus_memio.h and bus_pio.h are kinda out of synch with newbus/busspace? >> machine/bus_pio.h >> I see that this one is also an empty header, also deprecated in >> usage? See above. -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project How the gods kill... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Jan 26 13:39: 8 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A9A68154A3 for ; Wed, 26 Jan 2000 13:39:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA01265; Wed, 26 Jan 2000 14:39:00 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA02463; Wed, 26 Jan 2000 14:38:36 -0700 (MST) Message-Id: <200001262138.OAA02463@harmony.village.org> To: Jeroen Ruigrok/Asmodai Subject: Re: newbus from a documentation view Cc: "Matthew N. Dodd" , new-bus@FreeBSD.ORG In-reply-to: Your message of "Wed, 26 Jan 2000 18:23:10 +0100." <20000126182309.H290@daemon.ninth-circle.org> References: <20000126182309.H290@daemon.ninth-circle.org> <20000126094020.G290@daemon.ninth-circle.org> Date: Wed, 26 Jan 2000 14:38:36 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000126182309.H290@daemon.ninth-circle.org> Jeroen Ruigrok/Asmodai writes: : >> machine/bus_memio.h : >> I see that this one is basically an empty header, deprecated in : >> usage? : : I see we #define bus_memio_h in machine/bus.h, so basically all drivers : including machine/bus_memio.h and bus_pio.h are kinda out of synch with : newbus/busspace? : : >> machine/bus_pio.h : >> I see that this one is also an empty header, also deprecated in : >> usage? : : See above. The way that Justin had intended it is as follows. If the device hardware supported I/O mapping, then you'd include in your driver. It would do what was needed to bring in support for progammed I/O. Likewise with . This would allow the bus_space_read_1, et al, to be highly optimized for devices that could optimize them. He told me in private conversations that this made a big difference in the performance he was seeing in the ahc driver at the time. I don't know how big big is, however. I know there was also optimizations in the api to bus_space_dma to allow things to work better on specialized hardware. I changed this a little to default to using both memory and progammed I/O if neither was included to be more compatible with NetBSD and newconfig. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Thu Jan 27 3:28: 2 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1793F155C4 for ; Thu, 27 Jan 2000 03:28:00 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p06-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.135]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA06408; Thu, 27 Jan 2000 20:27:48 +0900 (JST) Message-ID: <388FBC62.C06BEB9B@newsguy.com> Date: Thu, 27 Jan 2000 12:32:50 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: "Matthew N. Dodd" , new-bus@FreeBSD.ORG Subject: Re: newbus from a documentation view References: <20000126094020.G290@daemon.ninth-circle.org> <20000126182309.H290@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok/Asmodai wrote: > > *cough* > > ``Newbus is the new bus abstraction layer architecture which saw its > introduction in FreeBSD 4.0. Its goals are to provide a more object > oriented means of interconnecting the various busses and devices which > a host system provides to the Operating System. Its main features > include amongst others: dynamic attaching, easy modularisation of > drivers, and pseudo-busses.'' Please, see to it that the above appears on the back of 4.0-RELEASE's cds. Not even Brett Glass could fault it. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "2 b or not to b" meaning varies depending on whether one uses the 79 or the 83 standard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Jan 28 11:40:55 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from mass.cdrom.com (castles561.castles.com [208.214.165.125]) by hub.freebsd.org (Postfix) with ESMTP id 1671515C0E for ; Fri, 28 Jan 2000 11:40:50 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA02604 for ; Fri, 28 Jan 2000 11:49:32 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001281949.LAA02604@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: new-bus@freebsd.org Subject: Some serious problems with ISA and PnP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 11:49:31 -0800 From: Mike Smith Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I ran into something last night that I think needs some fairly urgent attention, relating to the handling of resources for ISA PnP devices. /* * Finally assign resource to pnp devices and probe them. */ if (bootverbose) printf("isa_probe_children: probing PnP devices\n"); for (i = 0; i < nchildren; i++) { device_t child = children[i]; struct isa_device* idev = DEVTOISA(child); if (!TAILQ_FIRST(&idev->id_configs)) continue; if (isa_assign_resources(child)) { struct resource_list *rl = &idev->id_resources; struct resource_list_entry *rle; device_probe_and_attach(child); The problem here is that isa_assign_resources() doesn't just find a viable set of resources for the child, it actually allocates _and_activates_ them. This is bad in a couple of cases. If we don't have a driver for the device, we never throw the resources away and deconfigure the device, so we can't reuse them for something else. That's not so good. In my case, and making it much worse, I ran into a problem with how this interacts with the sorts of things that are typically attached to the PNP0c02 identifier on the i386. When a memory resource is activated, it's mapped into the kernel's address space by calling pmap_mapdev. Typically, this is just wasteful if the device isn't going to use the memory. Unfortunately, it's not uncommon to attach a set of resources to a PNP0c02 identifier that describe all of the physical memory in a system. This isn't fatal until you try it on a system with enough memory to exhaust the kernel's virtual address space, but it does result in blowing out the kernel's pagetables. I think that the only remedy here is to handle ISA PnP resources the same way that other busses do; make the information on the resources available to the driver and let _it_ decide how to allocate them. It's definitely not appropriate for the bus code to be doing it - it simply can't tell what is the "right" thing to do. Interestingly, it seems that many, if not all, of the ISA drivers already allocate their own resources. How is it that this can work at all if they're already allocated in the PnP case? If this is the case, how much would it hurt to simply not reserve/allocate them at all in the ISA bus code? Is there anything else I'm missing here? Thanks. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sat Jan 29 3: 0:32 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 21D6D14F88; Sat, 29 Jan 2000 03:00:19 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12EVby-000G72-0B; Sat, 29 Jan 2000 11:00:15 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA67033; Sat, 29 Jan 2000 11:03:15 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 29 Jan 2000 10:58:53 +0000 (GMT) From: Doug Rabson To: Mike Smith Cc: new-bus@freebsd.org Subject: Re: Some serious problems with ISA and PnP In-Reply-To: <200001281949.LAA02604@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Jan 2000, Mike Smith wrote: > > I ran into something last night that I think needs some fairly urgent > attention, relating to the handling of resources for ISA PnP devices. > > > /* > * Finally assign resource to pnp devices and probe them. > */ > if (bootverbose) > printf("isa_probe_children: probing PnP devices\n"); > for (i = 0; i < nchildren; i++) { > device_t child = children[i]; > struct isa_device* idev = DEVTOISA(child); > > if (!TAILQ_FIRST(&idev->id_configs)) > continue; > > if (isa_assign_resources(child)) { > struct resource_list *rl = &idev->id_resources; > struct resource_list_entry *rle; > > device_probe_and_attach(child); > > The problem here is that isa_assign_resources() doesn't just find a > viable set of resources for the child, it actually allocates > _and_activates_ them. > > This is bad in a couple of cases. If we don't have a driver for the > device, we never throw the resources away and deconfigure the device, so > we can't reuse them for something else. That's not so good. > > In my case, and making it much worse, I ran into a problem with how this > interacts with the sorts of things that are typically attached to the > PNP0c02 identifier on the i386. When a memory resource is activated, it's > mapped into the kernel's address space by calling pmap_mapdev. > Typically, this is just wasteful if the device isn't going to use the > memory. Unfortunately, it's not uncommon to attach a set of resources to > a PNP0c02 identifier that describe all of the physical memory in a > system. This isn't fatal until you try it on a system with enough memory > to exhaust the kernel's virtual address space, but it does result in > blowing out the kernel's pagetables. > > I think that the only remedy here is to handle ISA PnP resources the same > way that other busses do; make the information on the resources available > to the driver and let _it_ decide how to allocate them. It's definitely > not appropriate for the bus code to be doing it - it simply can't tell > what is the "right" thing to do. > > Interestingly, it seems that many, if not all, of the ISA drivers already > allocate their own resources. How is it that this can work at all if > they're already allocated in the PnP case? If this is the case, how much > would it hurt to simply not reserve/allocate them at all in the ISA bus > code? > > Is there anything else I'm missing here? This code needs to find out where to map the resources for a given PnP device. The only way to decide whether a given range is available is to attempt to allocate that range so that is how the code is written. It does release the resources which it allocated after it finds a place for them and the driver will later allocate them itself using the locations found for them. The simplest fix here is probably to just remove the RF_ACTIVE flag from the calls to bus_alloc_resource(). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message