Date: Mon, 29 May 2000 14:06:25 -0700 From: Bob Kot <bobkat@azstarnet.com> To: freebsd-hackers@FreeBSD.ORG Subject: subr_bus.c | kldload | kldunload Message-ID: <00052914152202.00450@full.planing.jibe>
next in thread | raw e-mail | index | archive | help
I am in the process of upgrading my Turtle Beach MultiSound Monterey soundcard device driver (msm) from the 3.x version available from http://www.treefort.org/~bobkat/msm_main.shtml to 4.0-RELEASE. While crawling over the learning curve of the new-bus system I've been bit by the following. In FreeBSD: src/sys/kern/subr_bus.c,v 1.54 2000/02/29 09:36:25 dfr line 312 devclass_find_internal(driver->name, TRUE); calls that function ignoring the return value but with arg2=TRUE If the classname is not found in the for loop at line 255 and create = TRUE, which it is by call value then a malloc is performed. The malloc is assigned to dc and dc is returned, but the calling function has summarily ignored the return value. How is this malloc'd memory ever freed? I looked at the head of the CVS tree and this same scenario still looks like it can happen. Please confirm or refute. -=-=-=-=-=-=-=-= What led me to uncover this is trying to get my driver which is compiled as a module to kldload / kldunload from a shell prompt as root with the system fully up running multi-user. The behavior under 3.x is that a kldload will attach my (msm) module to the kernel and execute my msm_probe() and msm_attach() functions. A subsequent kldunload will delete the module and free all resources allocated leaving no leaks or indications that it had ever been attached. I am attempting to accomplish the same behavior on 4.0-RELEASE. Also my 4.0 kernel will have no prior knowledge of this device meaning /sys/compile/SOMEKERNEL/ioconf.c will know nothing about this device. This souncard is a totally brain dead ISA board not PnP. So in modifications for newbus of 4.0 I used the joy driver as an example. It's source being at /sys/isa/joy.c. It has a module Makefile at /sys/modules/joy and also there is a joy.sh file that would indicate that this module can be kldload'd into a running kernel. Well I tried that and kldstat -v indeed showed the joy module was loaded but the joy_probe() function never got executed. I edited the /sys/isa/joy.c file and added a printf() as the 1st line of the joy_probe() function, recompiled the module and kldloaded it again, after first kldunload'ing it of course, and that printf() output was nowhere to be found (not in /var/log/messages or on any system console). Someone please confirm or refute this behavior. I went thru the execise of adding a joy option to a kernel config file and built a new kernel. Booting it caused the joy_probe() function to execute and the printf() output was in /var/log/messages as anticipated. My driver, patterned after the joy driver module, was exhibiting the same behavior my msm_probe() was not being executed on kldload. I did some things to surmount that hurdle and am at a point where my driver kldload's, executes my msm_probe() and msm_attach() functions and kldunload's, but that leak in subr_bus.c is leaving an instance of my msm_devclass behind when I kldunload and on each subsequent kldload I add another msm unit to the kernel. That is not an acceptable situation. Knowing that my in-experienced approach at getting my msm_probe() and msm_attach() to execute may not be the right way to do things, I will start by just asking for a referral to some other driver that is implemented as a module with the newbus architecture, that will kldload / kldunload with no side effects and that preferably is an ISA device. If no one responds to this request I will repost with actual code and a laundry list of observed symptoms. Bob Kot 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?00052914152202.00450>