From owner-freebsd-current Fri Jan 12 16: 3:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 3C38937B400 for ; Fri, 12 Jan 2001 16:03:19 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0D02fk16650; Fri, 12 Jan 2001 16:02:41 -0800 (PST) (envelope-from dillon) Date: Fri, 12 Jan 2001 16:02:41 -0800 (PST) From: Matt Dillon Message-Id: <200101130002.f0D02fk16650@earth.backplane.com> To: Andrew Gallatin Cc: freebsd-current@FreeBSD.ORG, "'Alfred Perlstein'" Subject: Re: RE: Running Linux kernel modules. References: <01C07BF3.695D3780.ggross@symark.com> <14942.32188.899333.434988@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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? Why not just track the opens independantly in the overloading code? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message