Date: Tue, 30 May 2000 08:50:50 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Bob Kot <bobkat@azstarnet.com> Cc: freebsd-hackers@freebsd.org Subject: Re: subr_bus.c | kldload | kldunload Message-ID: <Pine.BSF.4.21.0005300845580.2947-100000@salmon.nlsystems.com> In-Reply-To: <00052914152202.00450@full.planing.jibe>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 May 2000, Bob Kot wrote: > > > 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. The devclass will live forever. This is not a problem since the second time the driver is loaded, it will use the devclass which was created the first time. > > 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. Without seeing the code, it appears that you are creating a new device instance each time the module is loaded. Probably you should try to only do this the first time (e.g. by looking to see if device msm0 exists). This part of the interface could use some improvement. > > 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. Warner Losh might be able to help you out here. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 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?Pine.BSF.4.21.0005300845580.2947-100000>