From owner-freebsd-current Wed May 14 08:28:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA14928 for current-outgoing; Wed, 14 May 1997 08:28:27 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA14907; Wed, 14 May 1997 08:28:18 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id QAA22196; Wed, 14 May 1997 16:27:38 +0100 (BST) Date: Wed, 14 May 1997 16:27:37 +0100 (BST) From: Doug Rabson Reply-To: Doug Rabson To: Stefan Esser cc: Michael Smith , current@freebsd.org Subject: Re: Backwards compatibiliy for isa_driver In-Reply-To: <19970513114307.17799@x14.mi.uni-koeln.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 May 1997, Stefan Esser wrote: > On May 13, Michael Smith wrote: > > Before you go any further with this, you should check with the > > Alpha people, and have a look at the NetBSD code for the > > same thing. > > Yes, I'm willing to do that ... > > > Whilst I found the documentation for the NetBSD approach to > > be pathetic (read: nonexistent), it was relatively easy to > > find enough examples to get something going. > > > The NetBSD approach blurs the distinction between "bus" and > > "device", which I think is _the_ critical point. A nested > > bus is a "device" on its parent bus, but a "bus" to devices > > below it. > > Yes, I fully agree. That's exactly what I was planning. > I have seperated the data into several data structures: > > 1) Structure common to all devices, values private per > device instance: > > - Unit number > - Operational state OK. > > 2) Structure depends on bus type, values private per > device instance, maintained by the "device" above, > which happens to be a "bus device": > > - "wired position" (e.g. "at pci1 slot 4") > - probemessage() > - resources While I was daydreaming about this stuff, I imagined that the resources could be stored in a database (sysctl?). This would be filled in from various sources, isa static device data, isapnp device data, pci etc. Since the location of the data is hidden, instead of in explicit memory structures, it can be read into the kernel from a config file. The kernel could then load the appropriate drivers and call the probe routines. For instance: dev Root of all device resources dev.isa All isa devices dev.isa.ed All resources for ed devices dev.isa.ed.0 Resources for ed0 device dev.isa.ed.0.port Integer for first ioport dev.isa.ed.0.portsize Integer for ioport range dev.isa.ed.0.mem Memory region dev.isa.ed.0.memsize Memory region size dev.isa.ed.0.irq etc. The probe (and attach) routine would get a handle to the node containing its resources: edprobe(..., sysctl_node_t resources) { ... port = sysctl_read_integer(resources, "port"); sysctl_write_integer(resources, "portsize", ED_PORT_RANGE); } Actually, now that I think about it, the resources should be more uniform: dev.isa.ed.0.port.type = io dev.isa.ed.0.port.start = 0x3d0 dev.isa.ed.0.port.size = 0x10 dev.isa.ed.0.mem.type = mem dev.isa.ed.0.mem.start = 0xd0000 dev.isa.ed.0.mem.size = 0x1000 dev.isa.ed.0.irq.type = irq dev.isa.ed.0.irq.start = 5 dev.isa.ed.0.irq.size = 1 Then one could write code like: ports = sysctl_get_handle(resources, "port"); sc->sc_port = sysctl_read_integer(ports, "start"); sysctl_write_integer(ports, "size", real_port_range); if (error = resource_check(ports)) giveup; The resource_check function would figure out the type of the resource and act appropriately. > > 3) Driver specific data structure, values private per > device instance: > > - xxx_softc > > 4) Common data structure, values private per driver but > shared by all instances of this device type: > > - drvname > - numunits > - maxunits > - probe() > - attach() > - shutdown() > > Of course, the struct components are not meant to be a > complete list, just a few typical examples ... I would add detach() to that list. I want all drivers to be loadable *and* unloadable. The detach() routine would be called when the driver is unloaded. > > > Hmm, Doug R. and I are just opening a discussion on a "resource manager" > > (someone just threw a PnP card at me, heh) which might well be relevant > > in this context. > > I found a $15 PnP sound card, which I bought just for > playing with ISA PnP ... :) > > My implementation of resource management uses the > following functions: > > devdata *resource_check (unsigned type, unsigned flags, > addr_t low, addr_t high); > > int resource_claim (devdata *dev, unsigned type, unsigned flags, > addr_t low, addr_t high); > > void resource_free (devdata *dev); > > The following resource types are currently defined: > > #define REST_NONE 0x00 > #define REST_MEM 0x01 > #define REST_PORT 0x02 > #define REST_INT 0x03 > #define REST_DMA 0x04 > #define REST_MAX 0x04 > > And these are the only valid "flags" values, currently: > > #define RESF_NONE 0x00 > #define RESF_SHARED 0x01 > > Simplified example: > > if ((otherdev = resource_check(REST_IRQ, RESF_SHARED, irq, irq) != NULL) > { > printf("irq conflict with device: %s", devname(otherdev)); > return -1; > } > > The actual resource check can be either a function of the > "bus device" operating on data from section 2) above, or > (in my current implementation) is a common function, which > maintains its own resource database (and needs the function > resource_claim() to add resources to this database). > > > There was mention of a NetBSD "extent allocator" which I need to follow > > through. > > > > Jason T., are you reading this? A few quick words in summary would > > be handy... > > I'd be very interested in pointers to further information, > too ... I just read through NetBSD's extent allocator (sys/kern/subr_extent.c) and it looks pretty useful. You could certainly use it as the implementation of your resource functions. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891