From owner-freebsd-hackers Wed May 31 12:45:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by hub.freebsd.org (Postfix) with ESMTP id A83EC37B515 for ; Wed, 31 May 2000 12:45:38 -0700 (PDT) (envelope-from bobkat@azstarnet.com) Received: from full.planing.jibe (dialup10ip085.tus.azstarnet.com [169.197.34.213]) by cepheus.azstarnet.com (8.9.3/8.9.3) with SMTP id MAA10894; Wed, 31 May 2000 12:44:59 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ From: Bob Kot To: Warner Losh Subject: Re: subr_bus.c | kldload | kldunload Date: Wed, 31 May 2000 11:52:55 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200005301805.MAA17843@harmony.village.org> In-Reply-To: <200005301805.MAA17843@harmony.village.org> Cc: Doug Rabson , freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Message-Id: <00053112445700.00521@full.planing.jibe> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 May 2000, you wrote: > There is my iopener led driver that might be a good stard. I'm > writing some articles about this now, but have been so swamped that > I'm not sure when I'll get them done :-(. You can download the led > driver from: > http://people.freebsd.org/~imp/led.tar.gz > Please let me know if you have problems with this, or comments on > this. This was the example I was looking for. I compiled it as a module with a few changes to led_identify (driver_t *driver, device_t parent) { devclass_t dc; device_t child; dc = devclass_find("led"); if (devclass_get_device(dc, 0) == NULL) { child = BUS_ADD_CHILD(parent, 0, "led", -1); device_set_desc(child, "MrLED"); bus_set_resource(child, SYS_RES_IOPORT, 0, LED_IOADDR, 1); } print_devclass_list(); } For driver hacking in 4.0 I have options DDB and BUS_DEBUG in the kernel I use. I strongly recommend any follow up documentation to encourage the use of both of those. The ability to use all of those print_XXX()'s in subr_bus.c was very illuminating to *this* novice 4.0 hacker. I kldloaded / kldunloaded this several times and then went and studied the message log. I am reasonably confident that things are behaving. At least there is no overt evidence of leaks or panics. My aberrant code was very close to this. I had determined I needed a msm_identify() and within it I was calling BUS_ADD_CHILD. At 1st with no conditional and then I had a problem with arguments. BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, "msm", 0) definitely gave me grief. Also I had DEVMETHOD(device_detach, bus_generic_detach) in my msm_methods. I added an msm_detach instead, that is currently stubbed out to only the return 0 statement. Making only those changes allows me to now kldload & unload my driver with results equivalent to the LED driver. Thank you...Sluething out the right example always makes life so easy. Conceptually I'm not sure I clearly understand what gets left behind in the kernel after a kldunload, but I'll ponder on that and in the mean time continue to whup the driver into shape. 1 3 0 1 3 13013 BOB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message