Subject: typed copyin/copyout (was: Re: Show sysctl activity in ktrace)
To: None <email@example.com>
From: Emmanuel Dreyfus <firstname.lastname@example.org>
Date: 09/21/2006 08:32:03
> Wouldn't it be better to fix them all, by making ktracers find out
> about data the kernel reads from places pointed to by syscalls? Then
> kdump can juggle the formatting however it thinks appropriate for the
> call in question. Yes, this means a bit more work (syscalls that chase
> user-level pointers would have to use a routine that creates ktrace
> entries as well as reading the data), but it's really the right fix.
I had ideas about this, but it would be a bit intrusive.
Working at the syscall code level seems unworkable, because you don't
know if the argument given to the syscall will actually be used.
IMO the right place to trace things is at copyin/copyout level:
We can introduce a new copyin/coypout set of function, let's say
dcopyin(l, uaddr, kaddr, len, type)
struct lwp *;
const void *udaddr;
error = copyin(uaddr, kaddr, len);
if (!error && type && KTRPOINT(l->l_proc, type))
ktrgeneric(l, type, UIO_WRITE, kaddr, len);
ktrgeneric() would save in the ktrace record the type, the read/write
direction and the data. kdump would use the type to learn how to format
the data. There could even be a set of data displaying function shared
among kdump and kernel.
Then the next job would be to gradually replace every copyin/copyout in
the kernel by the typed version dcopyin/dcopyout