Thomas E. Spanjaard wrote:
> Garrett D'Amore wrote:
>> Thomas E. Spanjaard wrote:
>>> Steven M. Bellovin wrote:
>>>> On Sat, 01 Jul 2006 13:18:27 +0000, "Thomas E. Spanjaard"
>>>> <tgen@netphreax.net> wrote:
>>>>> Steven M. Bellovin wrote:
>>>>>>    temp=acpitemp     >70*2       /bin/shutdown -p now
>>>>>> where the *2 indicates that it has to happen twice in a row.  A few
>>>>>> more
>>>>>> frills, like shell variables for each config line -- the 'temp'
>>>>>> means that
>>>>>> a script would be run with envstatd_temp set to the value.  A |
>>>>>> at the
>>>>>> start of the command would create a pipeline that would be fed the
>>>>>> value
>>>>>> on stdin, to permit easy real-time graphing programs.
>>>>> Confusing, using mathematical symbols for other meanings. Isn't the
>>>>> how-many-times-or-how-long (as Jachym Holecek suggested) better off
>>>>> in a separate column (think inetd.conf syntax)? Come to think of it,
>>>>> inetd.conf is a viable example format for this.
>>>> I thought about that; it's certainly one perspective.  Here, though, I
>>>> assumed that it would rarely be used, in which case I'm imposing a
>>>> burden
>>>> on everything else.  The other option is something like '-n 2', but
>>>> that
>>>> might be even more confusing.
>>> Hmm, but a crontab is similar to this as well, but allows you to use *
>>> in separate columns (so no binary operator use is associated with the
>>> symbol due to obvious distance between columns) in the case where you
>>> don't want to specify anything specific.
>> Rather than go down the path of inventing a new format, why not just put
>> this in XML.  The code lives in userland, so an XML parser isn't too big
>> a deal.   Plus you get all the extensibility, etc.
>
> I find XML to be an awkward format for configuration files, like
> Chapman Flack and Jachym Holecek already said. It might be good if a
> human never directly edits it, but in this case I think it's safe to
> assume vi will be the firstmost tool to edit it (as it's in base).

I hate editing XML too.  But I hate even more having a bajillion
different config syntaxes, each one different, and usually impossible to
easily extend.  A quick review of a couple of different config syntaxes
we have:

    * passwd
    * group
    * inetd.conf
    * hosts
    * crontab
    * printcap
    * termcap

These are all generally not very extensible (though termcap isn't too
bad in this regard) and almost no file has a syntax like any of the
others.  Yet, there is no compelling reason why the syntaxes for these
files _have_ to be so different, other than historical accident.

For all the problems associated with XML, it at least doesn't suffer
from these problems.

A few ways to make editing XML more friendly:

    1) provide a vixml  wrapper which takes a DTD and checks for DTD
compliance before saving the file.  (It would work with a temporary
file, and could do file locking ala "vipw")

    2) we could provide other wrappers which do the xml check and assume
a specific DTD (vipower?)

    3) add some additional syntax highlighting to vi.  or better yet,
allow these tools to use $EDITOR

    4) switch almost all config files to XML-ish syntax.  while this
will be painful and generate many complaints at first, by moving _all_
files to XML-ish syntax, users/admins will generally become familiar
enough with XML that it won't bother them anymore and the consistency
will generally lead to _less_ confusion.

    5) publish DTDs for all config files in some common location, so
common XML tools can "just work".  (/usr/share/xml/dtds/ ?)

I'm not happy as an advocate of XML, but I've never seen anything else
which can lay claim to both being human editable, and being capable of
supporting pretty much any of the things that all these different files
have to do.

Or we can keep inventing new file syntaxes-of-the-week. :-)

I still would like a nice compact binary representation for property
lists for exchange across the kernel, btw.  XML is clearly wrong for use
in places where performance or compactness is a priority and human
editing is not expected to take place.

>
>> As far as extensible interface from sysmon to powerd, I rather like the
>> idea of sending property lists, but I would prefer to use some kind of
>> packed format.  I don't want to force the kernel to pack up XML just to
>> send messages to userland.
>
> Though I'm not clued on the property list jizz, what's the problem of
> using an ioctl like virtually every other application on BSD uses for
> these kind of interactions with the kernel?

This issue isn't whether to use an ioctl or not, but rather what the
format of data exchanged over the ioctl is to be.  So we use an ioctl
pass a packed property list rather than a fixed structure, with the
result that we get some "automatic" extensibility.

    -- Garrett
>
> Cheers,


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191