(Fwd) Re: DOSFS bug fixes, IDE drivers and sample released

[Ralf Corsepius]

Am Fre, 2003-05-23 um 15.11 schrieb Joel Sherrill:
> Chris Johns wrote:
> > 
> > Angelo Fraietta wrote:
> > > Ralf Corsepius wrote:
> > >
> > >> Have you tried using sync(2)?
> > >>
> > >> I.e. something similar to this:
> > >>
> > >> fwrite( ...);
> > >> fclose(..);
> > >>
> > >>
> > >> sync();
> > >>
> > > I get a link error -- undefined reference to sync
> 
> I see it in the OpenGroup specification but we don't have it.
> I don't remember it in POSIX 1003.1b but that doesn't mean much
> without me checking it. :)
> 
> > 
> > I do not see a 'sync' but I see:
> > 
> >    int fsync(int fd);
> >    int fdatasync(int fd);
> > 
> > are present. Maybe you could try these.
> >
> > Should these calls also flush the user-space buffered (libc) data ?
> 
> I don't know if they can since they are called with an int fd and 
> fsync wants a FILE *stream.
I think, you interchanged them:

fflush(FILE*)
fsync(int)

fsync is member of syscall-family (manpage section 2) and corresponds to
read, write, open, close, creat, ioctl etc. On some systems fsync is an
actual syscall.

fflush is member of the library-function-family (manpage section 3) and
corresponds to fread, fwrite, fopen, fclose etc.

>   The OpenGroup standard on both calls 
> makes no mention of libc type buffering.
>   It only mentions device
> queues.  The Linux man pages say the same thing.  
> 
> My gut feeling is that the scope of the call is implied by the
> argument being an int fd not a FILE *.
Agreed, i.e. my previous answer ("fsync shall imply fflush") probably is
wrong. 

But does this imply fflush to only flush a FILE*'s buffer and leave
flushing the to filesystems to the "kernel"? Or does an fflush(stream)
imply an fsync(stream->fd)? I currently think the former.

However, this then would imply that RTEMS must issue a sync(2), be it
explicit or implicit, at exit/shutdown.

Ralf