Date: Fri, 5 Oct 2001 14:47:28 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Peter Wemm <peter@wemm.org>, <arch@FreeBSD.ORG> Subject: Re: Removing ptrace(2)'s dependency on procfs(5) Message-ID: <20011005141014.W12962-100000@delplex.bde.org> In-Reply-To: <xzpofnnatlh.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Oct 2001, Dag-Erling Smorgrav wrote:
> Peter Wemm <peter@wemm.org> writes:
> > Dag-Erling Smorgrav wrote:
> > > - move procfs_rwmem() from src/sys/fs/procfs/procfs_mem.c into
> > > src/sys/kern/sys_process.c or some other convenient location where
> > > both ptrace(2) and procfs(5) can access it (and also move its
> > > prototype to a convenient header file).
> > It seems to be mostly VM code, perhaps it should be somewhere in vm/*,
> > perhaps vm/vm_glue.c ?
>
> procfs_rwmem() was originally derived from code which still resides
> (#if 0'd out) in sys_process.c. That's why I felt it was the most
> logical place to move it to.
This may have happened before the dawn of history, but 4.4BSD-Lite has
a full procfs_rwmem() and only stubs in sys_process.c, so FreeBSD
certainly didn't derive procfs_rwmem() from sys_process.c. History
shows that sys_process.c once used pread(), but peter changed it to
use procfs in rev.1.21. It's more likely that pread() was derived
from procfs_rwmem() than vice versa.
> > Would it not make more sense to just make ptrace_{read|write}_*regs()
> > in machdep.c rather than have ptrace go via procfs functions and back to
> > machdep.c?
>
> That's exactly what I'm saying.
>
> In case you're confused, the PROCFS_ACTION() stuff in procfs_machdep.c
> has nothing to do with procfs, it's just a poorly-named macro that
> evaluates its arguments and does some error checking.
The error checking is bogus too. It checks that PHOLD() actually worked.
This is currently necessary because PHOLD() is broken.
In fact, all of procfs_machdep.c is bogus. The functions in it just
call functions in machdep.c, so procfs_machdep.c is MI, modulo the
functions in machdep.c not having gratuitously MD names. The functions
in machdep.c should have been inline in procfs_machdep.c, as in NetBSD.
This is not quite right in your reorganization. The functions are needed
by both procfs and ptrace, so they shouldn't be in procfs_machdep.c or
have names beginning with procfs.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011005141014.W12962-100000>