Date: Wed, 08 Nov 2000 10:05:13 -0800 From: bruno schwander <bschwand@dvart.com> To: Luigi Rizzo <rizzo@aciri.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: close call in a device ? Message-ID: <3A0995D9.61AD357F@dvart.com> References: <200011080736.XAA02080@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A0995D9.61AD357F>