Date: Fri, 12 Jan 2001 23:06:13 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-current@freebsd.org Subject: Re: RE: Running Linux kernel modules. Message-ID: <14943.53910.930029.953797@grasshopper.cs.duke.edu> In-Reply-To: <200101130002.f0D02fk16650@earth.backplane.com> References: <01C07BF3.695D3780.ggross@symark.com> <14942.32188.899333.434988@grasshopper.cs.duke.edu> <200101130002.f0D02fk16650@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14943.53910.930029.953797>