Ok. That is normally user space policy so it isn't easy to do. User space
programs set a flag to indicate a file will be closed. You could set this
yourself but a malicious application could then reset it. That would depend
if the item is one of security or avoiding accidents.
> I'm using fds opened on my driver to track and communicate with
> participating processes, and am *relying* on a close() on that
> fd to indicate that that process has died.
2.2.x will call the flush() handler when any task using the handle closes
a copy of it, and the release handler on the final close.
> The problem is that when a process forks and exits, the child
> will still have the fd open, so my module won't know that the
> original process that opened the fd is dead, and it needs to
> know so that it can unblock any processes that have blocked
> on a Send() or Receive() to it.
I wonder whether you should simply allow the user to shoot themselves like
this. There must be cases where one day it will be useful for your API
to allow file handles to be passed on to other tasks. Making your API
unUnixlike is perhaps dangerous too ?
If you are simply trying to avoid accidentally passing the handle on then
the fcntl F_SETFL interface is designed to allow you to set FD_CLOEXEC in
these cases as user space policy. Many security programs make heavy use of
this when running unpriviledged subtasks for example.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/