On Mon, 2008-08-18 at 10:29 -0700, david@xxxxxxx wrote:On Mon, 18 Aug 2008, Eric Paris wrote:
******************************
Great, how to build this interface. THIS IS WHAT I ACTUALLY CARE ABOUT
The communication with userspace has a very specific need. The scanning
process needs to get 'something' that will give it access to the
original file/inode/data being worked on. My previous patch set does
this with a special securityfs file. Scanners would block on 'read.'
This block was waiting for something to be scanned and when available a
dentry_open() was called in the context of the scanner for the inode in
question. This means that the fd in the scanner had to be the same data
as the fd in the original process.
having scanners access a file blocking on read won't work for multiple
scanners (unless you are going to create multiple files for them to read)
WHAT?