docs/85097: [patch] devd.conf.5 lacks a lot of vital information.
Giorgos Keramidas
keramida at FreeBSD.org
Fri Aug 19 13:10:25 UTC 2005
The following reply was made to PR docs/85097; it has been noted by GNATS.
From: Giorgos Keramidas <keramida at FreeBSD.org>
To: Fredrik Lindberg <fli+freebsd at shapeshifter.se>
Cc: bug-followup at FreeBSD.org
Subject: Re: docs/85097: [patch] devd.conf.5 lacks a lot of vital information.
Date: Fri, 19 Aug 2005 16:01:08 +0300
On 2005-08-18 21:13, Fredrik Lindberg <fli+freebsd at shapeshifter.se> wrote:
> The manual page for devd.conf(5) is very sparse. This patch adds
> information on how you actually configure devd and explains the syntax
> and meaning of the avaiable substatements.
Good idea. The patch has some minor details that we may have to fix
before it's committed:
* EOL spaces must be removed from the "new" lines
* Some syntax and grammar mistakes have to be fixed (see below)
% +If two statements matches the same event, only the action of the statement with
% +highest priority will be carried out. In this way generic statements can be
% +overridden for devices/notifications that requires special attention.
"If two statements match the same event, only the action of the
statement with the highest priority will be carried out. This way
generic statements can be overriden for events that require special
attention."
% +.Pp
% +The general syntax to create a statement is as follows
Missing ':' at the end of the line.
% +.Ss Substatements
% +The following statements are supported within the
% +.Ql options
% +statement.
% +.Bl -tag -width ".Ic directory"
% +.It Ic directory \*q/some/path\*q;
% +Adds the given directory to the list of directories from which devd will read
% +configuration files. Any number of this directive is valid.
We should replace inline "devd" text with an .Xr reference to the
devd(8) manpage:
from which
.Xr devd 8
will read
% +.It Ic pid-file \*q/var/run/devd.pid\*q;
% +Specifies pid file.
This is too terse. What pid file? Why pid file? Whose pidfile? It
may be obvious by looking at the filename of the sample pidfile, but
it's ok to expand this description a little, I think.
% +.It Ic set regexp-name \*q(some|regexp)\*q;
% +Creates a regular expression and assigns it to the variable
% +regexp-name, this variable is then avaiable through out the rest of
% +the configuration file.
% +All regular expressions have an implicit ^$ around them.
The "regexp-name" string should be tagged with .Va (variable). The two
sentences that are joined now by a comma are not really a single
sentence, but two complete, distinct sentences. "Throughout" is only
one word. The above should probably be rewritten as:
.It Ic set regexp-name \*q(some|regexp)\*q;
Creates a regular expression and assigns it to the variable
.Va regexp-name .
This variable is then available through out the rest of the
.Pa devd.conf
file.
All regular expressions have an implicit
.Dq Li ^$
around them.
% +.El
% +.Pp
% +The following statements are supported within the
% +.Ql attach
% +and
% +.Ql detach
% +statements.
The final fullstop should really be a ':' character here.
% +.Bl -tag -width ".Ic directory"
% +.It Ic device-name \*qstring\*q;
% +Actually a shorthand to `match device-name'. Matches a device named string.
Literal quote characters shouldn't be present in mdoc manuals. The word
'actually' sounds a bit superficial.
.It Ic device-name \*qstring\*q;
A shorthand for
.Dq Li "match device-name" .
This matches a device named
.Dq Li string .
It may even be worth the effort to tag "string" with an .Ar macro.
A shorthand for
.Dq Li "match device-name" .
This matches a device named
.Ar string .
% +string is allowed to be a regular expression or a variable previously created
% +containing a regular expression.
The
.Ar string
argument is allowed to be a regular expression...
% +The variable $device-name is avaiable for later use with the action-statement.
This has a typo (avaiable) and lacks some markup:
The
.Va "$device-name"
variable can latter be used within the argument of the
.Dq Li action
statement and it will be replaced by the actual name of the device
that matched the
.Dq Li device-name
argument.
% +.It Ic match \*qvariable\*q \*qvalue\*q;
% +Matches the content of value against variable. value can be a regular expression.
% +Not really needed during attach/detach events since the device-name statement
% +takes care of all device matching.
% +For a partial list of variables, see below.
Some formatting is missing here too.
Matches the content of
.Ar value
against
.Ar variable .
The
.Ar value
argument may be a regular expression (see
.Xr re_format 7 ).
.Ic match
statements are not very useful for setting up handlers for device
attach or detach events, since this can be handled by
.Ic device-name
statements.
See below for a partial list of available variable names.
We might also want to replace "below" with a section or subsection name.
% +.It Ic action \*qcommand\*q;
% +Command to execute upon a successful match.
% +Example /etc/pccard_ether $device-name start
A lot of formatting is missing here too:
Execute
.Ar command
upon a successful match.
An example of such a command is:
.Bd -literal -offset indent
action "/etc/pccard_ether $device-name start";
.Ed
% +.El
% +.Pp
% +The following statements are supported within the
% +.Ql nomatch
% +statement.
EOL spaces should be removed and the '.' character right before a list
should be replaced with ':'.
% +.Bl -tag -width ".Ic directory"
% +.It Ic match \*qvariable\*q \*qvalue\*q;
% +Matches the content of value against variable. value can be a regular expression.
% +For a partial list of variables, see below.
Match the content of
.Ar value
against
.Ar variable .
The
.Ar value
argument can be a regular expression (see
.Xr re_format 7 ).
See below for a partial list of available variable names.
% +.It Ic action \*qcommand\*q;
% +Same as above.
Same as what 'above'? This is a duplicate of an existing description of
the "action" element, so it may be removed IMHO.
% +.Pp
% +The following statements are supported within the
% +.Ql notify
% +statement.
Colon instead of a fullstop before the beginning of a list, please.
It's also a good idea to use .Dq Li for multicharacter arguments,
instead of .Ql:
The
.Dq Li notify
statement supports the following substatements:
% +The variable
% +.Ql $notify
% +is avaiable inside this statement and contains, possibly, a value depending
% +on which system and subsystem that delivered the event.
This is misplaced, it has a typo, it uses .Ql with a multi-character
word (there's a tendency to use .Ql for single character arguments and
``.Dq Li foo'' for arguments that have more than 1 character), and does
not protect `$' (which may be a good idea).. When the reader sees:
The supported options of ``foo'' are:
then it's obvious that a list of the supported options follows. Seeing
a second sentence is a bit unexpected and introduces an unwanted pause
between the announcement of a list and the list itself. How about?
Depending on the system and subsystem that delivers an event, the
.Va notify
% +.Bl -tag -width ".Ic directory"
% +.It Ic match \*qsystem|subsystem|type\*q \*qvalue\*q;
% +Any number of match-statements can exists within a notify-statement.
% +value can be either a fixed string or a regular expression.
% +Below is a list of avaiable systems, subsystems and types.
% +.It Ic action \*qcommand\*q;
% +Command to execute upon a successful match. For example
% +/etc/rc.d/power_profile $notify
% +.El
% +.Ss Variables that can be used with the match-statement
Too long title. How about?
.Ss Predefined match-statement variable names
% +Partial list of variables and their possible values that can be used together
% +with the
% +.Ql match
% +statement.
"together with the match statement" seems a bit strange. It's also
pretty useless to duplicate the title in slightly different words, just
to make sure that a short decription precedes the list. If we add a
description at all, we might as well go all the way and write something
like this:
The arguments of a
.Dq Li match
statement support expansion of variable names starting with a dollar
sign
.Pq Ql \$ .
The predefined variable names are:
.Bl -tag -width "manufacturer"
...
.El
% +.Pp
% +.Bl -tag -width "manufacturer" -compact
There's no need for a .Pp before the .Bl request here.
% +.It Ic Variable
% +.Ic Possible value
.Ic is an "interactive command". I'm sure this is not the right tag for
either the list item or the item description here.
% +.It bus
% +pccard[0-9]+, cardbus[0-9]+
It would be nice if regexps are tagged as "literal text" or quoted, or
both.
% +.Ss Notify matching
% +Partial list of systems, subsystems and types used within the
% +.Ql notify
% +mechanism.
As above, .Ql is not good for quoting multicharacter strings. It's
better to use ``.Dq Li foo'' in this case.
% +.It ACAD
% +AC Line state ($notify=0 is offline, 1 is online)
Since ``$notify'' is a variable, it should be tagged as one. The
capitalization of "Line" seems strange too.
.It ACAD
AC line state. Offline when
.Dq Li \$notify
is 0, online when
.Dq Li \$notify
is 1.
% +.It Button
% +Button state ($notify=0 is power, 1 is sleep)
% +.It CMBAT
% +Battery events.
% +.It Lid
% +Lid state ($notify=0 is closed, 1 is open)
% +.It Thermal
% +Thermal zone events.
% +.El
See above for ``.Dq Li \$notify'' changes.
% +.El
% +.El
% +.El
Triply nested lists are usually a sign that this may be split in at
least two sections. This may not be the case here, but I didn't get a
chance to patch the manpage locally and see now the output looks like in
nroff with 80-column terminals. I suspect the lines of the innermost
list are far too narrow to be readable.
% +.Sh EXAMPLES
% +The file
% +.Pa /etc/devd.conf
% +contains numerous of different examples.
It's probably better to write:
The "foo" file contains...
I'm not sure about this one, though. It's just a vague feeling that
placing the "file" after the filename reads more natural.
You have made significant and very useful additions to the original
manpage, but there's still some mdoc work that needs to be done before
we can commit this. Other, more experienced mdoc people from
freebsd-doc may have to look at the comments I made too, in case I
missed or misunderstood something.
- Giorgos
More information about the freebsd-doc
mailing list