Bug 85097

Fredrik Lindberg <fli+freebsd@shapeshifter.se> writes:

> +.It Ic notify
> +specifies various matching criteria and actions to perform when the kernel
> +sends an event notification to user land.

Your other item descriptions begin with a capital letter.

My grep of 5.4 manpages found no "user land" and many "userland".

>  .Pp
> +Each statement, except 
> +.Ql options

Some fonts don't show a single "`" well and .Dq seems to be more
popular (and I don't like either one).  That is, it's OK.

> +has a priority (arbitrary number) associated with it, where

"an arbitrary number"

> +0 is defined as the lowest priority.

I would quote "0"; can't say why.

> +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. 

"matches" > "match"
"carried out" > "used"  ?
"/" > " or "
"requires" > "require"

IIRC, two sentences should not share the same line.

> +.Pp
> +The general syntax to create a statement is as follows

"to create" > "of"
" as follows" > ":"  ?

> +.Pp
> +.Bd -literal
> +statement priority {
> +	substatement "value"; 
> +	...
> +	substatement "value"; 

Me and "aspell" say: "substatement" > "sub-statement", but maybe it's
OK as psuedo-code.

> +.Pp

Unneeded.

> +.Ss Substatements

"Sub-statements" ?

> +The following statements are supported within the 

OK, unless you forgot "sub".

> +.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

.Xr devd 8

> +configuration files. Any number of this directive is valid.

I'm fairly sure it should "these directives", but "is" is correct.
(I see that it's problematic, though.)

> +.It Ic pid-file \*q/var/run/devd.pid\*q;
> +Specifies pid file.
> +.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 

"," > ";"

Probably should use: .Va regexp-name ;

"through out" > "throughout"

> +the configuration file.
> +All regular expressions have an implicit ^$ around them.

Use .Li or .Dq Li or .Ql Li ?

> +Actually a shorthand to `match device-name'. Matches a device named string.

I see nothing wrong with in-line quoting, but I wonder if other would.

> +The variable $device-name is avaiable for later use with the action-statement.

Probably: .Va $device-name

It seems that "$" is not special char so doesn't need leading "\&".

> +.It Ic match \*qvariable\*q \*qvalue\*q;
> +Matches the content of value against variable. value can be a regular expression.

.Va value
.Va variable

(I just checked; .Va underlines in my term.  .It does nothing noticable.)

> +Matches the content of value against variable. value can be a regular expression.

.Va's

> +The variable
> +.Ql $notify

.Va $notify

> +is avaiable inside this statement and contains, possibly, a value depending
> +on which system and subsystem that delivered the event. 

"value depending" > "value, depending"

I would remove ",possibly, " as redundent with "depending".

> +Any number of match-statements can exists within a notify-statement.

I think "-" should be " " here and one similar place.

> +Below is a list of avaiable systems, subsystems and types.

I'm happy to say we have a standard on this: " and" > ", and".

> +Command to execute upon a successful match. For example 
> +/etc/rc.d/power_profile $notify

I'd use ".Ic ..." even if it's not interactive. Bold on my term.

> +.Ss Variables that can be used with the match-statement
> +Partial list of variables and their possible values that can be used together

"A partial"

> +Partial list of systems, subsystems and types used within the

Another comma.

> +Subsystem is the actual name of the network interface on which the event 

IMO, "Subsystem" needs special treatment beyond ".Li", probably quotes.

>  Comments may appear anywhere that whitespace may appear in a
>  configuration file.

I'll take the original manpage's word for it, but if it's really
a "shell construct" comment, then it can't appear at the beginning
of some whitespaces. For example try this with and without a
space before "#": sh -c 'aaa=bbb#ccc echo ddd$aaa'

>  .Ed
> +.Sh EXAMPLES 
> +The file

Maybe "The installed" or "The distributed", because it might
not have the examples when the manpage is read.

> +.Pa /etc/devd.conf
> +contains numerous of different examples.

"has many examples."

I wonder if that busy file doesn't belong in some "sample" directory.

Gary W. Swearingen wrote:
> Fredrik Lindberg <fli+freebsd@shapeshifter.se> writes:
> 
> 
>>+.It Ic notify
>>+specifies various matching criteria and actions to perform when the kernel
>>+sends an event notification to user land.
> 
> 
> Your other item descriptions begin with a capital letter.

This was unintentional, the "notify" statement were added to an
original part of the manual where non-capital letters were used.
In my opinion they should all begin with a captial letter.

> 
> My grep of 5.4 manpages found no "user land" and many "userland".

> 
> 
>> .Pp
>>+Each statement, except 
>>+.Ql options
> 
> 
> Some fonts don't show a single "`" well and .Dq seems to be more
> popular (and I don't like either one).  That is, it's OK.

I took a quick look at some other manuals, .Ql seems to be used
to quote single characters while .Dq is used to quote words.

> 
> 
>>+has a priority (arbitrary number) associated with it, where
> 
> 
> "an arbitrary number"
> 
> 
>>+0 is defined as the lowest priority.
> 
> 
> I would quote "0"; can't say why.

You're probably right.

> 
> 
>>+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. 
> 
> 
> "matches" > "match"
> "carried out" > "used"  ?

Maybe even "executed" ?

> "/" > " or "
> "requires" > "require"
> 
> IIRC, two sentences should not share the same line.

Inserting a hard break between those lines? even though they
are so closely related?

> 
> 
>>+.Pp
>>+The general syntax to create a statement is as follows
> 
> 
> "to create" > "of"
> " as follows" > ":"  ?
> 
> 
>>+.Pp
>>+.Bd -literal
>>+statement priority {
>>+	substatement "value"; 
>>+	...
>>+	substatement "value"; 
> 
> 
> Me and "aspell" say: "substatement" > "sub-statement", but maybe it's
> OK as psuedo-code.
> 
> 
>>+.Pp
> 
> 
> Unneeded.
> 
> 
>>+.Ss Substatements
> 
> 
> "Sub-statements" ?

The original manual used "substatements", I were about to change
it to "sub-statements" but I never did it.

> 
> 
>>+The following statements are supported within the 
> 
> 
> OK, unless you forgot "sub".

Well, a sub-statement is a statement and a statement can have 
sub-statements :)
But, you're right, it's probably better to use sub-statements for clarity.

> 
> 
>>+.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
> 
> 
> .Xr devd 8
> 
> 
>>+configuration files. Any number of this directive is valid.
> 
> 
> I'm fairly sure it should "these directives", but "is" is correct.
> (I see that it's problematic, though.)

I went over that sentence like a 100 times while writing, but since
english isn't my native language I really can't say which to use.

> 
> 
>>+.It Ic pid-file \*q/var/run/devd.pid\*q;
>>+Specifies pid file.
>>+.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 
> 
> 
> "," > ";"
> 
> Probably should use: .Va regexp-name ;
> 
> "through out" > "throughout"
> 
> 
>>+the configuration file.
>>+All regular expressions have an implicit ^$ around them.
> 
> 
> Use .Li or .Dq Li or .Ql Li ?
> 
> 
>>+Actually a shorthand to `match device-name'. Matches a device named string.
> 
> 
> I see nothing wrong with in-line quoting, but I wonder if other would.

> 
> 
>>+The variable $device-name is avaiable for later use with the action-statement.
> 
> 
> Probably: .Va $device-name
> 
> It seems that "$" is not special char so doesn't need leading "\&".
> 
> 
>>+.It Ic match \*qvariable\*q \*qvalue\*q;
>>+Matches the content of value against variable. value can be a regular expression.
> 
> 
> .Va value
> .Va variable
> 
> (I just checked; .Va underlines in my term.  .It does nothing noticable.)
> 
> 
>>+Matches the content of value against variable. value can be a regular expression.
> 
> 
> .Va's
> 
> 
>>+The variable
>>+.Ql $notify
> 
> 
> .Va $notify
> 
> 
>>+is avaiable inside this statement and contains, possibly, a value depending
>>+on which system and subsystem that delivered the event. 
> 
> 
> "value depending" > "value, depending"
> 
> I would remove ",possibly, " as redundent with "depending".
> 
> 
>>+Any number of match-statements can exists within a notify-statement.
> 
> 
> I think "-" should be " " here and one similar place.
> 
> 
>>+Below is a list of avaiable systems, subsystems and types.
> 
> 
> I'm happy to say we have a standard on this: " and" > ", and".
> 
> 
>>+Command to execute upon a successful match. For example 
>>+/etc/rc.d/power_profile $notify
> 
> 
> I'd use ".Ic ..." even if it's not interactive. Bold on my term.
> 
> 
>>+.Ss Variables that can be used with the match-statement
>>+Partial list of variables and their possible values that can be used together
> 
> 
> "A partial"
> 
> 
>>+Partial list of systems, subsystems and types used within the
> 
> 
> Another comma.
> 
> 
>>+Subsystem is the actual name of the network interface on which the event 
> 
> 
> IMO, "Subsystem" needs special treatment beyond ".Li", probably quotes.
> 
> 
>> Comments may appear anywhere that whitespace may appear in a
>> configuration file.
> 
> 
> I'll take the original manpage's word for it, but if it's really
> a "shell construct" comment, then it can't appear at the beginning
> of some whitespaces. For example try this with and without a
> space before "#": sh -c 'aaa=bbb#ccc echo ddd$aaa'

I confirmed this, devd(8) accepts " # foo" as a valid comment, so it's
not relly a "shell construct" comment, more of a "shell construct"-like 
comment.

> 
> 
>> .Ed
>>+.Sh EXAMPLES 
>>+The file
> 
> 
> Maybe "The installed" or "The distributed", because it might
> not have the examples when the manpage is read.

"The installed" sounds fine.

> 
> 
>>+.Pa /etc/devd.conf
>>+contains numerous of different examples.
> 
> 
> "has many examples."
> 
> I wonder if that busy file doesn't belong in some "sample" directory.
Yes, moving the obvious examples to sample file would probably be a good
idea, keeping only the statements that is in use in /etc/devd.conf


I have addressed all of the above issues (proper quoting, choice
of words, .Va's and so on), but I'll wait until all issues are cleared
before posting a second patch.

	Fredrik Lindberg

Comment 3 Giorgos Keramidas 2005-08-19 14:01:08 UTC

On 2005-08-18 21:13, Fredrik Lindberg <fli+freebsd@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

Comment 4 Giorgos Keramidas 2005-08-19 14:13:02 UTC

On 2005-08-19 10:40, Fredrik Lindberg <fli@shapeshifter.se> wrote:
>Gary W. Swearingen wrote:
>> Some fonts don't show a single "`" well and .Dq seems to be more
>> popular (and I don't like either one).  That is, it's OK.
>
> I took a quick look at some other manuals, .Ql seems to be used
> to quote single characters while .Dq is used to quote words.

Correct.

>>> +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.
>>
>> IIRC, two sentences should not share the same line.
>
>  Inserting a hard break between those lines? even though they
>  are so closely related?

Yes.

>  >>+configuration files. Any number of this directive is valid.
>  >
>  >
>  > I'm fairly sure it should "these directives", but "is" is correct.
>  > (I see that it's problematic, though.)
>
>  I went over that sentence like a 100 times while writing, but since
>  english isn't my native language I really can't say which to use.

``Any number of "foo" directives can be used.'' ?

>  > Use .Li or .Dq Li or .Ql Li ?

The ``.Ql'' request already makes its argument ``literal''.  The
canonical use of ``.Ql'' and ``.Dq Li'' is, AFAIK, one of the following:

	.Ql X
	.Dq Li XXX*

>  >>+The variable $device-name is avaiable for later use with the action-statement.
>  >
>  > Probably: .Va $device-name

And a bit of shuffling around.  This sounds more natural in English:

	The
	.Va device-name
	variable

>  >>+Command to execute upon a successful match. For example
>  >>+/etc/rc.d/power_profile $notify
>  >
>  > I'd use ".Ic ..." even if it's not interactive. Bold on my term.

I would prefer making this a real "display" of literal text that can be
copy-pasted to the devd.conf file:

	.Bd -literal -offset indent
	notify "/etc/rc.d/power_profile $notify";
	.Ed

but this is just a personal preference, I guess.

Giorgos Keramidas wrote:
> On 2005-08-19 10:40, Fredrik Lindberg <fli@shapeshifter.se> wrote:
> 
>>Gary W. Swearingen wrote:
>>
>>>Some fonts don't show a single "`" well and .Dq seems to be more
>>>popular (and I don't like either one).  That is, it's OK.
>>
>>I took a quick look at some other manuals, .Ql seems to be used
>>to quote single characters while .Dq is used to quote words.
> 
> 
> Correct.
> 
> 
>>>>+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.
>>>
>>>IIRC, two sentences should not share the same line.
>>
>> Inserting a hard break between those lines? even though they
>> are so closely related?
> 
> 
> Yes.
> 
> 
>> >>+configuration files. Any number of this directive is valid.
>> >
>> >
>> > I'm fairly sure it should "these directives", but "is" is correct.
>> > (I see that it's problematic, though.)
>>
>> I went over that sentence like a 100 times while writing, but since
>> english isn't my native language I really can't say which to use.
> 
> 
> ``Any number of "foo" directives can be used.'' ?
> 
> 
>> > Use .Li or .Dq Li or .Ql Li ?
> 
> 
> The ``.Ql'' request already makes its argument ``literal''.  The
> canonical use of ``.Ql'' and ``.Dq Li'' is, AFAIK, one of the following:
> 
> 	.Ql X
> 	.Dq Li XXX*
> 
> 
>> >>+The variable $device-name is avaiable for later use with the action-statement.
>> >
>> > Probably: .Va $device-name
> 
> 
> And a bit of shuffling around.  This sounds more natural in English:
> 
> 	The
> 	.Va device-name
> 	variable
> 
> 
>> >>+Command to execute upon a successful match. For example
>> >>+/etc/rc.d/power_profile $notify
>> >
>> > I'd use ".Ic ..." even if it's not interactive. Bold on my term.
> 
> 
> I would prefer making this a real "display" of literal text that can be
> copy-pasted to the devd.conf file:
> 
> 	.Bd -literal -offset indent
> 	notify "/etc/rc.d/power_profile $notify";
> 	.Ed
> 
> but this is just a personal preference, I guess.
> 

A new patch is attached, that hopefully addresses all issues with
the first.
I also added a some real examples to the EXAMPLES section instead of
just a reference to /etc/devd.conf.

	Fredrik Lindberg

If this is good to commit, then would someone please commit it.  
usbd/usbd.conf are now gone in CURRENT and have good documentation 
for people making the switch to devd would be helpful.


-- 
Anish Mistry

Comment 7 John-Mark Gurney 2006-10-07 21:29:12 UTC

Responsible Changed
From-To: freebsd-doc->jmg

I'll take this, I recently realized how crappy devd's docs are... 

Interested in updating the different busses man pages (pci(4), usb(4) 
along with others) w/ the keywords that you can match on?  (such as 
serial for usb)

Comment 8 John-Mark Gurney 2006-10-07 22:15:44 UTC

State Changed
From-To: open->patched

Thanks for the patch, sorry it took so long to get committed...  If you 
would like to flesh out the variables that can be matched on, I'll commit 
the changes...

Comment 9 dfilter service 2006-10-07 22:16:00 UTC

jmg         2006-10-07 21:15:41 UTC

  FreeBSD src repository

  Modified files:
    sbin/devd            devd.conf.5 
  Log:
  flesh out the devd.conf man page...  Mostly from the PR, but did a couple
  gramatical tweaks along w/ sorting the list, and adding that serial is
  available for USB....
  
  PR:             85097
  Submitted by:   Fredrik Lindberg
  MFC after:      1 week
  
  Revision  Changes    Path
  1.9       +298 -8    src/sbin/devd/devd.conf.5
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"

Comment 10 Pav Lucistnik 2007-05-13 00:02:38 UTC

State Changed
From-To: patched->closed

Was MFCed on 2006-10-17