link points to the process's current working directory, and the root
link points to the process's root directory. What else would you
expect?
For directories that are out of reach (caller is in a chroot, target
process is in a different chroot, etc), the links point to "/"
instead.
current directory in curproc. Fix from Pedro Martelletto:
We cannot call vgone() from procfs_inactive() if we are coming from
vclean(). that's what's probably causing the deadlock.
kernel and ran for a day or so. There are still some caddr_t types in
the arguments of some calls, I will do those separately (later) as
they touch a lot more of the system.
Approved by christos@NetBSD.org.
to have KFS or PFS differentiators. Further I have wrapped the enum in
procfs in "#ifdef _KERNEL" as it is done in kernfs.
To see the discussion go to http://mail-index.NetBSD.org/tech-kern/2003/09/
and look for "Mismatched enums in include files" in the list.
* Remove the "lwp *" argument that was added to vget(). Turns out
that nothing actually used it!
* Remove the "lwp *" arguments that were added to VFS_ROOT(), VFS_VGET(),
and VFS_FHTOVP(); all they did was pass it to vget() (which, as noted
above, didn't use it).
* Remove all of the "lwp *" arguments to internal functions that were added
just to appease the above.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
are vput()/vrele()d as necessary - some filesystems did use the wrong
one for some ops, and it's just safer to not take the chance
based on suggestion by Bill Studenmund
- Is it ok to convert DTYPE_PIPE to VFIFO and DTYPE_SOCKET to VSOCK?
- XXX: Avoid locking issue in ls -Rl /proc by avoiding curproc
- Does I/O to pipes work?
- XXX: Are there security implications?
(__HAVE_PTRACE_MACHDEP) and procfs (__HAVE_PROCFS_MACHDEP).
These changes will allow platforms like x86 (XMM) and PowerPC
(AltiVec) to export extended register sets in a sane manner.
* Use __HAVE_PTRACE_MACHDEP to export x86 XMM registers (standard
FP + SSE/SSE2) using PT_{GET,SET}XMMREGS (in the machdep
ptrace request space).
* Use __HAVE_PROCFS_MACHDEP to export x86 XMM registers via
/proc/N/xmmregs in procfs.
christos