Subject: Re: power management and related concerns
To: Garrett D'Amore <firstname.lastname@example.org>
From: Jachym Holecek <email@example.com>
Date: 07/01/2006 17:56:28
# Garrett D'Amore 2006-07-01:
> Thomas E. Spanjaard wrote:
> > Steven M. Bellovin wrote:
> >> On Sat, 01 Jul 2006 13:18:27 +0000, "Thomas E. Spanjaard"
> >> <firstname.lastname@example.org> 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.
Please note that this is _effectively_ exactly the same thing as
inventing a new format, except that you _disguise_ it as existing
one. One which is not necessarily well suited for the task. Take
a look at proplib's representation of dictionaries to see how
fragile it can get -- the fact that "keys" are paired with "values"
works by pure accident.
Plus I don't consider XML a human-friendly format, but granted,
that's matter of taste/habit.
> 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.
Yeah, that's exactly job for (some backend of) proplib. One inconvenient
thing is that, when you choose to use the XML (ie. the only existing)
backend, you can't easily internalize/externalize across buffer
boundaries. That's not a problem if you pass dictionaries as ioctl()
arguments, but becomes ugly once you want to present a stream of ASCII
text over a character device... (something you'd like to be able to
parse with awk, btw).