From owner-freebsd-hackers Wed Nov 8 10: 5:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from linus.dvart.com (linus.dvart.com [64.79.2.3]) by hub.freebsd.org (Postfix) with ESMTP id AE9B937B4D7 for ; Wed, 8 Nov 2000 10:05:14 -0800 (PST) Received: from dvart.com ([192.168.100.141]) by linus.dvart.com (8.9.3/8.9.3) with ESMTP id KAA02791; Wed, 8 Nov 2000 10:05:13 -0800 Message-ID: <3A0995D9.61AD357F@dvart.com> Date: Wed, 08 Nov 2000 10:05:13 -0800 From: bruno schwander X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: close call in a device ? References: <200011080736.XAA02080@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Luigi Rizzo wrote: > you could do something like this: > + open allocates a descriptor which stores the PID of the process requesting > access to the "device" > doing that now > + each I/O operation uses the descriptor matching the PID passed to the > read/write/ioctl that too > > + you could implement an ioctl() to dispose the storage, a "well behaved" > process would have to invoke this ioctl before terminating; I could, but my problem is that the process is not under my control. I can't modify the program to have it do something more. Maybe I can have a module that captures the close call and make it issue my special cleanup ioctl ? Or maybe that call won't be intercepted precisely because of the so far observed behavior ? back to studying the kernel module stuff.... > > + and a timeout as you suggested could be used to purge entries that have > been idle for some time, or you could also purge them basing on usage > patterns assumning there are clearly identifiable ones. > yes, but that is the problem again, there may not be clearly identifiable patterns. At least, in the worst case, I could just check the process table and when a process goes away, I clean its associated resources. And I have to hope that a given process does not reopen and close the device several times. > > > Did I miss something in your suggestion ? Or were you suggesting that I can > > create same name device entries, differing only by their minor number ? But then > > you cannot use the same name unless the entries are in different > directories. My suggestion was to use /dev/foo.00 /dev/foo.01 /dev/foo.02 > and so on. > yep, I tried and tested that now :-) well there may not be a simple solution, but I think the idea of trapping "close" calls may work if I can trap the actual call before the kernel does its job of deciding where to route the call (which driver) and if the driver "close" should be called. Thanks for the idea. Any comments anyone ? bruno ########################################################################### Bruno Schwander Senior Software Engineer Worldgate Communications, Inc email: bschwand@dvart.com ############################################################################ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message