Re: Return ESRCH instead of zero result for KERN_FILE sysctl

Alexander Bluhm wrote: > On Tue, May 03, 2016 at 12:20:34AM -0400, Ted Unangst wrote: > > Alexander Bluhm wrote: > > > > > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? > > > > I think this should be BYPID only. I'm not sure why. Maybe because a user > > exists even when

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

On Tue, May 03, 2016 at 12:20:34AM -0400, Ted Unangst wrote: > Alexander Bluhm wrote: > > > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? > > I think this should be BYPID only. I'm not sure why. Maybe because a user > exists even when the user isn't running any processes.

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

On Tue, May 03, 2016 at 10:47:51PM +0300, Vadim Zhukov wrote: > @@ -333,10 +336,12 @@ kvm_deadfile_byid(kvm_t *kd, int op, int > goto cleanup; > } > > - if (op == KERN_FILE_BYPID && arg > 0 && > - proc.p_pid != (pid_t)arg) { > -

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

> Date: Tue, 3 May 2016 22:47:51 +0300 (MSK) > Cc: tech@openbsd.org > > So, after initial input, here is improved version. Changelist: > > - Simplified handling of "matched" variable in sysctl_file(), > from kettenis@. > > - ERRORS section for kvm_getfiles.2 (to be committed

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

So, after initial input, here is improved version. Changelist: - Simplified handling of "matched" variable in sysctl_file(), from kettenis@. - ERRORS section for kvm_getfiles.2 (to be committed separately), requested by bluhm@. I also moved beginning of RETURN VALUES section a

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

Alexander Bluhm wrote: > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? I think this should be BYPID only. I'm not sure why. Maybe because a user exists even when the user isn't running any processes. But a process doesn't exist when it doesn't exist.

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

2016-05-03 1:19 GMT+03:00 Mark Kettenis : >> Date: Tue, 3 May 2016 00:04:13 +0200 >> From: Alexander Bluhm >> >> On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: >> > When matching by PID, we'd better return ESRCH expicitly rather >>

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

2016-05-03 1:04 GMT+03:00 Alexander Bluhm : > On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: >> When matching by PID, we'd better return ESRCH expicitly rather >> than zero entries. This makes, for example, fstat(1) behaviour >> more consistent and makes it

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

> Date: Tue, 3 May 2016 00:04:13 +0200 > From: Alexander Bluhm > > On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: > > When matching by PID, we'd better return ESRCH expicitly rather > > than zero entries. This makes, for example, fstat(1) behaviour > >

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: > When matching by PID, we'd better return ESRCH expicitly rather > than zero entries. This makes, for example, fstat(1) behaviour > more consistent and makes it easier to replace "if lsof -p ..." > checks in third-party code with "if

Return ESRCH instead of zero result for KERN_FILE sysctl

When matching by PID, we'd better return ESRCH expicitly rather than zero entries. This makes, for example, fstat(1) behaviour more consistent and makes it easier to replace "if lsof -p ..." checks in third-party code with "if fstat -p ...". For libkvm, I explicitly test for ESRCH to avoid going