From owner-freebsd-current Fri Jan 12 20: 6:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 4E7D537B402 for ; Fri, 12 Jan 2001 20:06:15 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id XAA19786; Fri, 12 Jan 2001 23:06:14 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0D46Ds07966; Fri, 12 Jan 2001 23:06:13 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Jan 2001 23:06:13 -0500 (EST) To: Matt Dillon Cc: freebsd-current@freebsd.org Subject: Re: RE: Running Linux kernel modules. 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> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14943.53910.930029.953797@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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