Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Paul Goyette wrote: The saga continues! :) Next, I'm going to have a look at fd_getfile2()/fclose() and see if that is a viable approach. Hmmm. The comments in kern/kern_descrip.c for fd_getfile2() require that the process is not allowed to fork or exit "across this

Re: In-kernel process exit hooks?

The saga continues! :) I previously posted one set of patches that changes filemon to use fd_{get,put}file() only when the activity-log file is actually being accessed. This works, but doesn't prevent or detect when the application program closes-and-reopens that fd. Attached to this

Re: Device driver attachment when using module(7)

thegl...@gmail.com ("T. Glass") writes: >So my question is: are module device drivers supposed to configure a real >device driver instance, or are they just a method of inserting the right >autoconf glue, before the whole autoconfiguration process take place? Apparently that depends on the

RE: In-kernel process exit hooks?

Will the hang occur if make dies due to a signal (control-C, or kill -9, for example)? --Terry > -Original Message- > From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On > Behalf Of Paul Goyette > Sent: Thursday, January 7, 2016 17:00 > To: Taylor R Campbell

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 09:00:03 +0800 (PHT) From:Paul Goyette Message-ID: | Any other suggestions would be appreciated. Another possibility would be to detach the logged-to file from the

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Robert Elz wrote: Another possibility would be to detach the logged-to file from the process when logging is enabled (making the ioctl that attaches it also be notionally a close from the process point of view). But keeping the reference in kernel. When logging is

Re: In-kernel process exit hooks?

OK, I now have a third way of handling the problem. To recap the three options (refer to the attachments) 1. fd_getfile This option calls fd_getfile() each time it needs to access the activity log, and calls fd_putfile() after each use. This way, the additional reference on the file

Re: In-kernel process exit hooks?

On 1/7/16, Paul Goyette wrote: > On Fri, 8 Jan 2016, Paul Goyette wrote: > >> The saga continues! :) >> >> >> >> Next, I'm going to have a look at fd_getfile2()/fclose() and see if that >> is a viable approach. > > Hmmm. The comments in kern/kern_descrip.c for fd_getfile2()

RE: In-kernel process exit hooks?

On Thu, 7 Jan 2016, Terry Moore wrote: Will the hang occur if make dies due to a signal (control-C, or kill -9, for example)? It depends on which fd is numerically lower. If the /dev/filemon fd is lower, it will get closed first, which removes the reference to the log-file fd. If the

Re: In-kernel process exit hooks?

On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote: > Based on internal implementation of filemon(4), there is an ordering > requirement imposed on the sequence of events that occur when a process > using /dev/filemon exits. In particular, the file descriptor on which the > device

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 11:22:28AM +0800, Paul Goyette wrote: > Yeah, I was trying to avoid the change in semantics. :) The fewer things > I touch, the fewer things will go wrong, and I definitely don't want to > break make, which would result in difficulties making[sic] a new version. > :)

Re: amd64 profiling kernel build failure

On Fri, Jan 08, 2016 at 02:33:58PM +0900, Kengo NAKAHARA wrote: > --- a/sys/kern/subr_prof.c > +++ b/sys/kern/subr_prof.c > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 2014/07/10 > 21:13:52 christos Exp > #include > #include > > +#ifdef MULTIPROCESSOR >

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) From:Paul Goyette Message-ID: | Is there a "supported" interface for detaching the file (or descriptor) | from the process without closing it?

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) From:Paul Goyette Message-ID: | Is there a "supported" interface for detaching the file (or descriptor) | from the process without closing it?

Re: In-kernel process exit hooks?

Hmmm, option #3 doesn't work so well, after all! I tried it when both the target and monitor processes were children of the same shell process. Thus all three of these share the same 'struct file' for their stdout, and the filemon_fd_close() callback cannot tell which one is being closed.

Re: amd64 profiling kernel build failure

Hi, On 2016/01/08 15:50, David Holland wrote: On Fri, Jan 08, 2016 at 02:33:58PM +0900, Kengo NAKAHARA wrote: > --- a/sys/kern/subr_prof.c > +++ b/sys/kern/subr_prof.c > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 2014/07/10 21:13:52 christos Exp > #include >

Re: amd64 profiling kernel build failure

On Fri, Jan 08, 2016 at 06:50:02AM +, David Holland wrote: > > --- a/sys/kern/subr_prof.c > > +++ b/sys/kern/subr_prof.c > > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 > 2014/07/10 21:13:52 christos Exp > > #include > > #include > > > > +#ifdef

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > For an example of the right way to do this kind of thing, look in > kern_acct.c. Better example: sys_fktrace, since that uses a file handle. And it does virtually the same thing that filemon's trying to do, except much more

Re: In-kernel process exit hooks?

On Thu, 7 Jan 2016, Taylor R Campbell wrote: > Another possibility would be to change filemon(4) to do fd_getfile > each it needs to use the file descriptor. This makes it a little more > brittle (fails if you close the descriptor), but would sidestep the > problem. Hmmm, perhaps.