already does the initialization (though it didn't set pca_initialized, so
we always initialized twice) and since attach calls make_dev(), there's no
way that pcaopen() can be called before pcaattach().
files to use 5.x syntax (I hope..)
Note: I suppose one might need to hack the hints file as well?
Submitted by: Mike Barcroft <mike@FreeBSD.ORG>, Bruce Mah <bmah@FreeBSD.ORG>
Forgot to mention: creation of a full-fleged package archive requires some
changes in bsd.ports.mk, because currently it doesn't install some files
that are usually packed into the package archive (+MTREE_DIRS, +DISPLAY
and so on). Support for this will be committed later.
allows for an easy way to backup old version of port prior to installing
a new one;
- silence compiler warnings by killing some unused variables and adding
all includes necessary.
MFC after: 2 weeks
because the IN_RENAME flag only fixes a few of the huge number of race
conditions that can result in the source path becoming invalid even
prior to the VOP_RENAME() call. The panics created a serious security
issue whereby an attacker could fairly easily cause the panic to
occur, crashing the machine.
The correct solution requires a great deal of work in the namei
path cache code.
MFC after: 0 days
Until now, the ptrace syscall was implemented as a wrapper that called
various functions in procfs depending on which ptrace operation was
requested. Most of these functions were themselves wrappers around
procfs_{read,write}_{,db,fp}regs(), with only some extra error checks,
which weren't necessary in the ptrace case anyway.
This commit moves procfs_rwmem() from procfs_mem.c into sys_process.c
(renaming it to proc_rwmem() in the process), and implements ptrace()
directly in terms of procfs_{read,write}_{,db,fp}regs() instead of
having it fake up a struct uio and then call procfs_do{,db,fp}regs().
It also moves the prototypes for procfs_{read,write}_{,db,fp}regs()
and proc_rwmem() from proc.h to ptrace.h, and marks all procfs files
except procfs_machdep.c as "optional procfs" instead of "standard".
the target process was being held locked during the uiomove() call. If the
process calling readdir() was the same as the target process (for instance
'ls /proc/curproc/'), and uiomove() caused a page fault, the result would
be a proc lock recursion. I have no idea how long this has been broken -
possibly ever since pfind() was changed to lock the process it returns.
Also replace the one and only call to procfs_findtextvp() with a direct
test of td->td_proc->p_textvp.
