Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC

On Sun, Oct 27, 2002 at 01:24:19AM -0700, Juli Mallett wrote:
> * De: Maxim Sobolev <[email protected]> [ Data: 2002-10-27 ]
> 	[ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> > > * De: Maxim Sobolev <[email protected]> [ Data: 2002-10-27 ]
> > > 	[ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> > > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> > > > > > Please review the patch, which adds two new types of events -
> > > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> > > > > > notification when the image starts or stops executing. For example, it
> > > > > > could be used to monitor that a daemon is up and running and notify
> > > > > > administrator when for some reason in exits. I am running this code
> > > > > > for more than a year now without any problems.
> > > > > > 
> > > > > > Any comments and suggestions are welcome.
> > > > > 
> > > > > Couldn't this just be done by init(8) and /etc/ttys?  Or inetd?  If you
> > > > > want to write your own, couldn't you use waitpid()?  Or a kevent() of
> > > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK?  I'm not sure I see the need for
> > > > > this.
> > > > 
> > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> > > > vnodes - it is the main difference. Currently, you can't reliably
> > > > get a notification when kernes started executing some arbitrary
> > > > executable from your fs.
> > > 
> > > This is not a job for the kernel, I don't think.
> > 
> > Why not? Kernel now reports number of internal events via kqueue(2) interface,
> > there is nothing wrong in adding yet another one. BTW, linux and irix already
> > have similar functionality provided by /dev/imon.
> 
> If you implemented a kq interface, and an imon wrapper, I'd be much more
> impressed.  A less-divergant interface to do this would be nice, even if
> kq is the backing.  In fact, especially if kq is the backing, kq is strong,
> kq will make us smart.

Actually, the only user of /dev/imon I am aware of is SGI's fam package
(file alteration monitor). I've already implemented subset of it
using BSD kqueue as a backend instead of imon. Check bsdfam project
on sourceforge for details.

-Maxim

To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-audit" in the body of the message