svn commit: r297201 - in head: share/man/man4 sys/dev/filemon

[Bryan Drewery]

> On Mar 22, 2016, at 17:41, Conrad Meyer <cem at FreeBSD.org> wrote:
> 
>> On Tue, Mar 22, 2016 at 3:41 PM, Bryan Drewery <bdrewery at freebsd.org> wrote:
>> Author: bdrewery
>> Date: Tue Mar 22 22:41:07 2016
>> New Revision: 297201
>> ...
>> --- head/share/man/man4/filemon.4       Tue Mar 22 22:41:03 2016        (r297200)
>> +++ head/share/man/man4/filemon.4       Tue Mar 22 22:41:07 2016        (r297201)
>> @@ -161,6 +161,12 @@ No process having the specified process
>> The process ID specified is already being traced and was not the current
>> process.
>> .El
>> +.Pp
>> +The
>> +.Fn close
>> +system call on the filemon file descriptor may fail with the errors from
>> +.Xr write 2
>> +if any error is encountered while writing the log.
>> .Sh FILES
>> .Bl -tag -width ".Pa /dev/filemon"
>> .It Pa /dev/filemon
> 
> Shouldn't this be documented in the close(2) manual page instead?  (I
> believe it is generally true for many kinds of fd where errors can
> occur between write and close.)  I thought close.2 would have a blurb
> like this and I see it doesn't in recent CURRENT.
> 
> 

The manpage for close(2) does document some errors, one being ENOSPC.  The close(2) behavior of returning write(2), really VOP_WRITE(9), errors though is specific to filemon since all of the writes are hidden and this is the only place to return an error.  I have a review open to resolve a similar issue in alq(9) as well since all of the writes are asynchronous and there's no API to retrieve any error from.

Bryan