On Sun, Jan 07, 2007 at 11:27:07AM -0800, Michael Kerrisk wrote:
> Justin Pryzby wrote:
> > On Sat, Jan 06, 2007 at 03:57:30PM -0800, Michael Kerrisk wrote:
> >> Hello Justin,
> >>
> >>> Linux 2.6.5 fs/open.c source indicates that close() can return
> >>> essentially any
> >>> file error:
> >>>
> >>> |int filp_close(struct file *filp, fl_owner_t id)
> >>> | /* Report and clear outstanding errors */
> >>> |asmlinkage long sys_close(unsigned int fd)
> >>> | return filp_close(filp, files);
> >>>
> >>> manpages already alludes to this ("It is quite possible that errors on
> >>> a previous write(2) operation are first reported at the final
> >>> close()."); included is a patch making it explicit.
> >> I don't see this code in fs/open.c in 2.6.19. Can you clarify please.
> > 2.6.18 has comparable sys_close and filp_close, but the new filp_close does
> > an
> > fflush() on the file. fflush(3) indicates that this is where all the
> > previous
> > write() errors are picked up.
>
> fflush(3) is a library routine.
There is necessarily a kernel componenent too; drivers get to specify
their own implementation.
> There is a filp_close is in kernel. Your statement makes no
> sense...
Filp_close calls the flush operation specified by the relevant driver
structure:
if (filp->f_op && filp->f_op->flush)
retval = filp->f_op->flush(filp, id);
dnotify_flush(filp, id);
> > The error-reference text used for the following
> > should be consistent:
doedoedoesss>
> Two questions:
>
> * what does "consistent" mean in this context?
The phrase used to refer to other manpage's error conditions should be
as similar as possible.
> * how did you verify this for each of the functions below?
I did:
dpkg -L manpages{,-dev} |xargs zgrep 'for any'
which is as much of the phrase as I could remember, and seemed like a
natural component of such phrases.
>
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
