Date: Tue, 22 Mar 2016 19:11:05 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: "cem@FreeBSD.org" <cem@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r297201 - in head: share/man/man4 sys/dev/filemon Message-ID: <D2476F6F-8C58-489D-9654-DFF2AEB9941F@FreeBSD.org> In-Reply-To: <CAG6CVpUxC6Nov7ocy5eEpcQFLd%2BQdXUxZWs49kTesWZo_VqncQ@mail.gmail.com> References: <201603222241.u2MMf7ub090070@repo.freebsd.org> <CAG6CVpUxC6Nov7ocy5eEpcQFLd%2BQdXUxZWs49kTesWZo_VqncQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 22, 2016, at 17:41, Conrad Meyer <cem@FreeBSD.org> wrote: > >> On Tue, Mar 22, 2016 at 3:41 PM, Bryan Drewery <bdrewery@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D2476F6F-8C58-489D-9654-DFF2AEB9941F>