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 <[EMAIL PROTECTED]> _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
