Date: Mon, 18 Feb 2008 11:18:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: Kostik Belousov <kostikbel@gmail.com>, Dag-Erling Smorgrav <des@des.no>, freebsd-current@freebsd.org, Giorgos Keramidas <keramida@freebsd.org> Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h Message-ID: <20080218111445.I35880@fledge.watson.org> In-Reply-To: <200802181513.42681.doconnor@gsoft.com.au> References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> <20080218040625.GA8141@kobe.laptop> <200802181513.42681.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Feb 2008, Daniel O'Connor wrote:
> On Mon, 18 Feb 2008, Giorgos Keramidas wrote:
>
>> But the first will probably fail when kdump tries to parse the output of
>> ls(1), and the second may fail in a similar manner when kdump tries to
>> parse an error message like a ktrace record.
>>
>> This sort of difficulty in separating the output of the traced process and
>> the ktrace records themselves is probably at least part of the reason why
>> nobody has done it yet.
>
> I did have a look at the source and the file opening etc is handled by the
> kernel but I am not sure who 'owns' that file descriptor.
>
> If, as you suggest, it is the process being traced then yes it would cause
> problems.
>
> I guess it couldn't be moved to ktrace without rearchitecting how ktracing
> works so the ktrace process sticks around writing stuff out to disk.
There are a lot of implicit design assumptions in the current design, such as:
(1) Stalling on I/O may sleep, but won't be indefinite.
(2) Ktrace I/O can happen from the following contexts without consequence:
process exit, thread return to userspace, system call entry, system call
exit, namei(), I/O input and output routines for file descriptors, and the
utrace() system call.
Direct vnode I/O generally meets these criteria, as disk waits, while long,
tend to be bounded, and performing arbitrary vnode I/O from, say, the socket
receive routine, while potentially slow, is safe. However, if you start using
a file descriptor instead of a vnode, you need to worry about things like
indefinite blocking, recursion, etc. I'm not saying these can't be addressed,
but it's not as simple as replacing references to struct vnode with references
to struct file.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080218111445.I35880>