On Thu, Feb 03, 2000 at 10:05:22AM -0700, Kenneth D. Merry wrote: > > The reference counting should be handled by PHK's disk layer (which sits > above CAM), and the da driver's close routine should only get called on > final close. ok. > > I don't know about the vn device, though. > That was the reason fro the posting. vnconfig -u goes directly to the vn device but that device has no track of open count. I don't see any code to notify the upper layer that the device is gove. That is wrong of course. In fact, one can vnconfig -u a device, while the device is used in a mount. The ufs layer doesn't even know that the device is gone and accessing the mount is still possible. Unmounting is not. So in this case, I guess vnconfig -u should fail. I think this is best achieved by using a ref counter in the vn device code. There is another bug in the vn code as well, which has tom do with modules. The following will panic on a page fault in vnsetcred (in the VOP_UNLOCK call): kldload vn vnconfig -c something vnconfig -u something kldunload vn kldload vn vnconfig -c something <--- instant panic I have not been able to debug this further, because it seems (but I have to recheck to be sure), that add-symbol-file /modules/vn <correct address> does not allow one to look at variables delcared inside the vn module. Is there an easy way btw to determine <address>? I looked inside the debugger in the linker_files queue and then use the load address there, plus the start address of .text as found by objdump of the vn module. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
