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.
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
