Thanks for the reply.
On Sun, 24 Feb 2002, Michael Wardle wrote:
> > 1) What's the status on kernel acceptance?
>
> IMon is unlikely to be included in the standard kernel distribution.
>
> The latest IMon patch we have is for 2.4.7 if I remember correctly.
>
> An alternative to IMon on Linux is DNotify. This seems to be the best
> option for the future, rather than having us maintain Linux IMon
> patches. You can find a patch adding DNotify support to FAM in our
> downloads area.
Great, I'll look into it.
> > 2) Can you disable the network use as a configuration option, i.e. if you
> > want to turn off the remote FAM use?
>
> We had been looking at an option to not monitor any file systems that
> were too slow (e.g. some remote NFS mounts) to monitor. If a list of
> file systems could be specified as a configuration option, would this
> provide what you want? What exactly did you want? Did you want FAM to
> not generate *any* traffic at all (remember this means we have to turn
> of a lot of things, such as NIS lookups)?
Well, I was looking for an option to not generate any kind of network
traffic at all. I read in the FAQ about in the case of NFS
filesystems, FAM will try to contact a remote FAM to get
notifications. Also, there was something about how FAM/IMon will
consider clients untrusted if they do not come from a local Unix
socket owned/readable by the process's UID. Basically, I'd like for it
to be that a Unix socket is the ONLY way to connect to the FAM
information. This is for security concerns, disregarding the obvious
firewalling solution. Is there any kind of white paper or documentation on
how the network part is implemented?
> > 3) What is the internal API like? The reason I am wondering is, I was
> > thinking about looking into support for device driver notification, as in
> > Windows 2000, where if you unplug your network cable it lets you know. Is
> > this supported, first of all, and how hard would it be to hack in? I was
> > thinking along the lines of a /proc entry for the device driver which
> > a userspace process could then use FAM on... obviously I'd need to hack
> > the device driver, but how feasible is this?
>
> At first this sounded like it'd be pretty difficult, but maybe it would
> be feasible to simply monitor the /proc entry, and FAM would send a
> Changed event, so the client could check what changed and act
> accordingly. On the other hand, if the /proc entry frequently changed
> (with information such as packets transmitted, packets dropped, etc.),
> then you'd get an overwhelming number of Changed events, making the
> whole idea a bit more difficult.
>
> Sorry I can't be more helpful on this one.
No, that was quite encouraging actually :)
Basically, I'd have the drivers split up all the information into separate
/proc files - for example, a network driver will publish information about
whether or not its adapter is "plugged in" in a file, say
/proc/sys/net/whatever/eth0/plugged. Any other kinds of information can be
split into another file, allowing some granularity in determining what
events have occurred. In any case, the specific idea I had was to write a
dock applet to say whether an interface was unplugged, which now seems
feasible.
> I hope this helped.
It did, thank you very much for the information.
-Andy
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|