Re: [gamin] global config file

[John McCutchan <ttb tentacle dhs org>]

On Thu, 2005-08-04 at 11:29 -0400, Daniel Veillard wrote:
> On Thu, Aug 04, 2005 at 11:00:18AM -0400, John McCutchan wrote:
> > > > fsset <fsname> <method> <poll_timeout>
> > > > 
> > > > fsname is "ext3", "nfs", etc..
> > > > method is "KERNEL" or "POLL" or "NONE"
> > > > poll timeout is a number >= 0. 
> > > 
> > >   what does 
> > >   fsset ext3 KERNEL 100
> > >   means ?  having a kernel handling and a poll timeout is conflicting. Does this
> > > mean 100 is signantly ignored ? Does this mean that 100 is used when resources
> > > are busy and we fall back to poll ? 
> > 
> > Yes, in the case that kernel monitoring is selected, the timeout is for
> > when we fall back to poll. I should have been more clear.
> 
>   Okay, we will need to augment the documentation section 
>     http://www.gnome.org/~veillard/gamin/config.html
> 

Nod

> > > To me this is ambiguous ! Having an 
> > > argument *mandatory* and *silently ignored* is wrong. In that case it should
> > > be optional. To me poll_timeout should be optional if one of the config file
> > > do not want to override the default. Also is has absolutely no meaning for 
> > > "NONE" (why uppercase ? checkall the other config files in your machine for
> > > uppercase words, you will find very little)
> > 
> > Okay, lets make it lowercase. And in the case when none is selected, we
> > won't pass a poll timeout. Sound good?
> 
>   I would prefer timeout to be optional. If defined and not "none" then it
> overrides the current value, otherwise it is left unchanged (one second by
> default).

The default is actually 0 seconds so that we maintain the old behaviour.

> 
> > >   You didn't express anything about the value for the poll_timeout, is it
> > > milliseconds, seconds, or something else ?
> > 
> > Seconds. Do you think we should go to milliseconds?
> 
>   Milliseconds are clearly too short but I could understand going lower
> than seconds in the order of the tenth of second, to be lower than the delay
> noticeable by an user when doing UI interaction, I'm not 100% sure what's the
> best, maybe tenth of second is right.

Okay, lets make it 1/10th of a second.

> 
> > > What is the behaviour ? Poll or not ? assuming /home is a cifs fs.
> > > See, to me there is a lot of undefined behaviour, behaviour which may
> > > be expected by users, and behaviour which is hard to check without starting
> > > a debugging session.
> > 
> > Yes, you are right about the two sets of config statements (fsset vs.
> > poll/notify) causing ambiguity. I was delaying looking into that until
> > we got the infrastructure in place. I feel that the per filesystem
> > preferences should override the path specific ones. But this is a tough
> > decision to make.
> 
>   It seems to me that the path is more specific so should have priority
> over the file system type which is a generic setting. the problem would rather
> be as in my example if the specific setting of the user disagree with the
> global setting system wide <grin/>. I hate burning policies into libraries.
>   

??

> 
> > kernel monitoring is used. I can think of only one situation, and that
> > is where the underlying filesystem is not appropriate for kernel
> > monitoring (or poll monitoring). Considering that, I think we should
> > deprecate the old config options for the new one. Possibly making a
> > policy that if there are any fsset's, the old options are ignored.
> > Thoughts?
> 
>    I think that path based settings are very important. One need to be able
> to exclude a part of a file system, for example just because we know it 
> is full of temporary files, think about a spooling system for example.

Good example. So, the control will look like:

if (gam_exclude_check (path)) {
	// enable poll at gam_fs_get_poll_timeout (path) frequency
} else {
	if (gam_fs_get_get_mon_type (path) == GFS_MT_KERNEL)
		// enable kernel monitoring with fallback poll frequency
		// set by gam_fs_get_poll_timeout (path)
	else if (gam_fs_get_mon_type (path) == GFS_MT_POLL)
		// enable poll at gam_fs_get_poll_timeout (path) freq
}

> 
> > > > If there are conflicting declarations, the last one to be processed is
> > > > the one followed. In gam_conf I parse the user gaminrc first, than the
> > > > system one, so that system administrators can over ride user
> > > > preferences.
> > > 
> > >   This makes sense, though usually user configuration override systeme wide
> > > so this will nee to be reflected in the documentation because this is 
> > > against common expectations.
> > 
> > Since choosing kernel monitoring on the wrong filesystem can cause
> > serious performance problems, I thought it was a better choice to go
> > with the system wide options last. I felt it would be a security concern
> > if we the let the user insist on using kernel monitoring on cifs or
> > novfs.
> 
>    Seems we can't make the policy ourself, it's too complex.
> Maybe the system wide config file need 2 sections, one being default
> overwritable by the user, and one mandatory which can't be overriden.
> This would actually reflects what we see in GConf, so it's probably the
> right thing to do.

Maybe we should have a /etc/gamin/

2 files:

gaminrc
mandatory_gaminrc

Then we load files in this order:
/etc/gamin/gaminrc
~/.gaminrc
/etc/gamin/mandatory_gaminrc


-- 
John McCutchan <ttb tentacle dhs org>