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

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> 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.

Thanks for spotting that mistake.  But the spirit is correct.  One is
logically higher level than the other.  

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

I think you are correct.  A sync() call must be available.  The guts
of the logic are in libc_wrapup() in cpukit/libcsupport/newlibc.c.
This code fragment hints at the solution:

  /*
   * Try to drain output buffers.
   *
   * Should this be changed to do *all* file streams?
   *    _fwalk (_REENT, fclose);
   */

  fclose (stdin);
  fclose (stdout);
  fclose (stderr);

_fwalk() takes a (struct _reent *) as the 1st argument and
a function pointer as its second.  The function is passed the FILE *
for each open file on that reent structure. It looks like you 
could implement sync something like this:

sync:
  for each task
    _fwalk( my reent, flush_and_sync )
  

int flush_and_sync( FILE *fp ){
  fflush(fp);
  fsync(FILENO(fp);
}

Does that look close to right?

I am also thinking that the newlib per task exit handler and system
exit handler might need to be addressed as part of this.


> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985