Matt Dillon writes:
 > :To handle the multiple open problem, I'm overloading the open and
 > :close system calls.  Upon open, I call the native open, then I grovel
 > :around in the process' open file table looking for my special file.
 > :When I find it, I mark fp->f_nextread with a magic number, then store
 > :a pointer to the per-open private data in fp->f_offset.  On close, I
 > :go grovelling again.  I deallocate the private data, clear the magic
 > :number, and call the system close function.  I've also got an
 > :at_exit() hook that does much the same thing.
 >     Wait a sec... f_nextread and f_offset can be messed around with
 >     by the user process, what prevents the user process from screwing
 >     up your kernel data pointer?

Pure ignorance.  Since the device doesn't support reads/writes, I'm
hoping nobody will try to lseek on it ;) I could overload the syscalls
that touch these fields if I have to, but I'm hoping this will be just
an interum hack and don't want to waste time polishing it.

 >     Why not just track the opens independantly in the overloading code?

I'm not sure I know what you mean.  I don't just need to track
multiple open/closes, I need to be able to hang a pointer off of
something that I can get at durning an mmap() or ioctl() syscall so
that I can tell which instance I'm dealing with.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to