#2 Multiple rules in one config file

closed
None
5
2008-10-29
2002-11-09
Ian Morgan
No

This patch was previously sent directly to Tim Hockin
<thockin@sun.com>.

The old config file parser only allowed ONE rule to be
defined in each file. This was not documented, and even
the debugging didn't help figure out what was going on.
Only reading the code confirmed the behaviour appeared
to be by design. Tim confirmed that it was only because
the parser was written very quickly.

This patch allow each config file to define multiple
rules. It works like a charm, and does smart things
when a config file is borked (missing or out-of-order
directives). The debugging (>=3) reports each rule as
it is enlisted, the number of rules in each file, and a
total after all files are processed.

This brings the config file parsing into line with what
I (and probably most people) would have expected.

If you like this, please apply to your tree, or else
give me some feedback and I'll try to tweak it.

Discussion

  • Tim Hockin

    Tim Hockin - 2003-05-13

    Logged In: YES
    user_id=293704

    I'd rather see some config file format that is more robust
    and doesn't rely on arbitrary grouping.

    maybe:

    # This is a rule
    Rule "Foo Bar"
    event=foo
    action=bar
    EndRule

     
  • Tim Hockin

    Tim Hockin - 2003-05-13
    • assigned_to: nobody --> sunthockin
     
  • Tim Hockin

    Tim Hockin - 2003-11-15
    • status: open --> closed
     
  • Tim Hockin

    Tim Hockin - 2003-11-15

    Logged In: YES
    user_id=365227

    Never heard back

     
  • Ian Morgan

    Ian Morgan - 2003-11-15

    Logged In: YES
    user_id=645697

    I could have sworn I had replied, but maybe not. Your desire
    to see amore robust format seemed rather hypocritical, to me
    anyways.

    My original patch provided enhanced functionality without
    affecting backwards compatibility. It's not a perfect config
    system, but certainly better than the original.

    Your suggestion for even-more-improved config file format
    would (I believe) break backward compatibility, unless the
    code were bloated to be able to parse both old and new
    formats. Ick.

    Unfortunately, I haven't used acpid for quite some time,
    since all my recent motherboards have piece-of-sh** ACPI
    support. I'll dig out my notebook, the only one remaining
    with a good enough ACPI implementation to be useful, and see
    if I can't come up with a config system for acpid more to
    your liking.

    Do you have any suggestions for an improved format that will
    not break backward compatibility? I could detect an old
    format config file and point people to an included script
    for batch-converting all their old config files. Would that
    be suitable?

     
  • Tim Hockin

    Tim Hockin - 2003-11-15

    Logged In: YES
    user_id=365227

    I'm not sure how 'hypocrisy' figures in, but I'll let that go.

    Yes, backwards compat is an issue. Perhaps this:
    * If you find a rule-start delimiter first, it is a new
    format file with multiple rules.
    * If you find a raw 'event=' or 'action=' first, it is an
    onl format file with one rule. Warn about old-format rules.

    I don't "expect" anything from you. You presented a patch
    that scratches your own itch. If you want to scratch other
    people's itches, I think it can be done better, that's all.
    I appreciate your help, but I can't reasonably "expect"
    anything, eh?

    Tim

     
  • Tim Hockin

    Tim Hockin - 2003-11-15
    • status: closed --> open
     
  • Ian Morgan

    Ian Morgan - 2003-11-15

    Logged In: YES
    user_id=645697

    Here is an improved patch against 1.0.2 that implements a
    form of multi-rule config file you suggested.

    rule "<rule name>" {
    event=<regex>
    action=<cmd>
    }

    An old-style config file will cause a warning to be issued,
    but the rules will not be parsed.

    Patch includes updated documentation for the new format.

     
  • Ian Morgan

    Ian Morgan - 2003-11-15

    Multi-rule config file parsing patch against acpid 1.0.2

     
  • Tim Hockin

    Tim Hockin - 2003-11-17

    Logged In: YES
    user_id=293704

    Looks much better. A few things.

    I was hoping it would still parse old files, but issue the
    warning, not just give up on them.

    Can you break it into some subroutines? It's too deeply nested.

    Can you make sure it linewraps at before 80 characters? And
    for some reason your patch un-wraps some of the manual line
    wraps.

    The RULE_CLIENT path does not initialize the ->name member,
    but you added places to print it out. Initialize it to
    "client" or something like that, please. And make sure the
    free_rule code gets it right.

    Thanks!

    Tim

     
  • Tim Hockin

    Tim Hockin - 2008-10-29
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks