fam
[Top] [All Lists]

Re: [fam] possible imon bug?

To: gasteb@xxxxxxxxxxxx
Subject: Re: [fam] possible imon bug?
From: "Rusty Ballinger" <rusty@xxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Oct 2000 01:46:33 -0700
Cc: fam@xxxxxxxxxxx
In-reply-to: "E. Brian Gast" <gasteb@xxxxxxxxxxxx> "Re: [fam] possible imon bug?" (Oct 10, 9:42pm)
References: <20001006232335.A18179@xxxxxxxxxxxxxxxx> <gasteb@xxxxxxxxxxxx> <10010091838.ZM9594@xxxxxxxxxxxxxxxxxx> <20001010163703.A11013@xxxxxxxxxxxxxxxx> <10010101758.ZM11564@xxxxxxxxxxxxxxxxxx> <20001010214214.B1015@xxxxxxxxxxxxxxxx>
Reply-to: rusty@xxxxxxx
Sender: owner-fam@xxxxxxxxxxx
> > Anyway, an interesting thing to think about.  Unless imon's hooks into the
> > filesystem code are rewritten, in 2.4 kernels I think fam will probably
> > have to live with the fcntl(directory, F_NOTIFY) mechanism.
>
> Yeah, I was looking through it yesterday.  (That's part of what caused the
> collision with the imon patch in -test9 that Philipp Baer fixed.)  I haven't
> written any code to try it out yet -- that's next on my list.  It looks like
> it only supports monitoring the contents of a directory;  there's nothing
> for monitoring a single file or watching execution(s).  I think I'll send
> an email to Stephen Rothwell (his name is at the top of the files) and ask
> him if there are any plans to expand it to include file only notification.
> Although I guess Fam could hide that from the client; when a request to
> monitor a file comes in, monitor the parent dir, and then ignore changes
> to the other files.

Yeah, that's the way I was figuring it would work too.  The only bummer is
having to use one fd per directory!  (But really, most clients probably only
monitor one directory or file anyway... and if they only monitor local files,
it might be just as well--or better--for libfam to use that fd for the
open/fcntl on the directory instead of communicating with fam... but for
applications which monitor lots of directories, or files mounted from remote
hosts, it's not so good.)

On the other hand, since that inode_dir_notify is in all (or most?) of the
places where IMON_EVENT wants to be, perhaps the imon patch gets a lot
simpler for 2.4 kernels: it just adds IMON_EVENT in __inode_dir_notify. :)

> As far as execution monitoring goes, how important is that?

Arguably "not very".  In IRIX, it's used by the desktop to change
executables' icons depending on whether they're running.  In fact that's
about all you can use it for; as long as one instance of an executable is
running, I'm pretty sure you don't get execute events when additional
instances of that executable start or stop.  (So for example you couldn't
use it for a security auditing tool or for analyzing usage patterns.)  But
it depends on who you talk to; some people really like it.  (I think it's
neat.)

--Rusty

--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>