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>