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

[Chris Johns]

Joel Sherrill wrote:
> 
> 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 do not think this is all that needs to happen. The SUSv3 standard for the sync 
call meantions:

   The sync() function shall cause all information in memory that updates
   file systems to be scheduled for writing out to all file systems.

   The writing, although scheduled, is not necessarily complete upon
   return from sync().

What happens with 'mkdir' or 'unlink' calls ? The fsync call may not handle 
this. It will depend on the FS implementation.

I feel for RTEMS we should do more than shedule an update.

The fflush(NULL) call is defined as:

   If stream points to an output stream or an update stream in which
   the most recent operation was not input, fflush() shall cause any
   unwritten data for that stream to be written to the file, [CX] and
   the st_ctime and st_mtime fields of the underlying file shall be
   marked for update.

   If stream is a null pointer, fflush() shall perform this flushing
   action on all streams for which the behavior is defined above.

Does fflush(NULL) flush all streams or just the task's files get flushed ?

The fflush(NULL) does an fwalk.

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

I agreed with the system exit handler, but I am not sure about a task exit 
handler due to performance reasons. Once implemented the sync call can be used 
in an application where it is needed.

-- 
  Chris Johns, cjohns at cybertec.com.au