Date: Fri, 10 Aug 2001 11:22:06 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Sansonetti Laurent <lorenzo@linuxbe.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Doing file operations on syscalls handler Message-ID: <Pine.NEB.3.96L.1010810111651.19412T-100000@fledge.watson.org> In-Reply-To: <003101c12195$3be399a0$0201a8c0@teledisnet.be>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Aug 2001, Sansonetti Laurent wrote:
> I'm new on FreeBSD modules programming, and I've a little question...
> How can I do file operations (like open(), read()..) on a syscall
> handler of a syscall module ? In fact I've met the problem since my
> module must open a file which contains some informations for the hacked
> syscall (in this case, it's getdirentries()).. I've tried to malloc a
> open_args struct, filled-it and use [sys] open, but it doesn't work...
> Is there a way to call user syscalls ?
There are a couple of things to keep in mind when doing module
programming:
(1) Generally, filenames are with respects to a particular process's root
directory or current working directory. As such, the system
name->vnode calls make assumptions about the availability of that
information.
(2) System call code in the kernel is generally structured so that any
pointers to additional data beyond the basic system call arguments are
assumed to be in userspace, and associated with a particular process
(generally, curproc).
When kernel code interacts with files, it normally does so by operating
directly on the file vnode, rather than using the indirection of the
system call interface. Also, the kernel code generally relies on a
userland process to initiate the name->vnode conversion, so that namei()
has a process to perform the lookup with respects to (remember the need
for root and working directories). Examples of file use from within
kernel include ktrace(), UFS quotes, UFS extended attributes, kernel
modules, and system accounting. Each of these does it a slightly
different way, but all are initiated by a system call which provides an
initial name to generate the vnode.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010810111651.19412T-100000>