Date: Wed, 31 May 2000 11:52:55 -0700 From: Bob Kot <bobkat@azstarnet.com> To: Warner Losh <imp@village.org> Cc: Doug Rabson <dfr@nlsystems.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: subr_bus.c | kldload | kldunload Message-ID: <00053112445700.00521@full.planing.jibe> In-Reply-To: <200005301805.MAA17843@harmony.village.org> References: <Pine.BSF.4.21.0005300845580.2947-100000@salmon.nlsystems.com> <200005301805.MAA17843@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00053112445700.00521>