Re: [gamin] global config file

[John McCutchan <ttb tentacle dhs org>]

On Wed, 2005-08-03 at 17:36 -0400, Daniel Veillard wrote:
> On Wed, Aug 03, 2005 at 01:45:11PM -0400, John McCutchan wrote:
> > On Wed, 2005-08-03 at 13:31 -0400, Daniel Veillard wrote:
> > > > fsset <filesystem type as appears in mtab/fstab>
> > > > <"KERNEL"|"POLL"|"NONE"> <unsigned int poll timer>
> > > > 
> > > > This would set the two preferences on the filesystem type. You can set
> > > > that you want KERNEL or POLL or NONE watching. You also set the minimum
> > > > time between polls.
> > > 
> > >   Your description is ambiguous. Can your timer be missing ? If yes what's
> > >   the semantic ? If no howdo you make an entry not changing the default.
> > >   What happends when multiple conflicting declarations are present ?
> > > 
> > 
> > It's not ambiguous at all.
> 
>   for you maybe, for me it is, see below !
> 
> > Everything is required. Maybe the line wrap
> > caused confusion.
> 
>   I said "semantic", i.e. what is the meaning, to me the meaning is ambiguous.
> 
> > 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.

> 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?

>   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?

>   This also conflict with existing config files, *deployed* existing config
>   files what happens if there is
>     /home poll
> in the configuration file (which I expect for example for people using CIFS
> because they reported problems otherwise) and 
>     fsset ext3 cifs NONE 100

I assume you mean: fsset civs none 1000

> 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.

> 
>   I express reserve on some part of your proposition, I say their meaning is
> ambiguous, please at least give me the benefit of the doubt, I have quite a few
> line of codes and projects behind me, I'm not just an old fart trying to
> stop you, you asked for feedback and I am giving some. 

I really do take your comments seriously. They are valuable and I don't
want you to get the impression that I am trying to brush you off. I'm
just arguing for my side :) You have convinced me that there are
ambiguities that need dealing with. I'm curious how you think we should
resolve the conflicts between the old and the new config options. I
think that they are both trying to accomplish the same thing. Let's ask
ourselves, in what situation do people want to control whether or not
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?

> Yes the per fstype
> configuration information is needed, it should be designed to be clear,
> and as much as possible not conflict with existing options already in use,
> gam_server being started automatically and transparently we can't just
> raise a warning at startup, that would not even reach the user attention.
> 

Of course.

> > 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.

-- 
John McCutchan <ttb tentacle dhs org>