mirror of
https://git.openafs.org/openafs.git
synced 2025-01-19 07:20:11 +00:00
eb5190eb4a
The actual behavior of FDH_SYNC has changed a bit over the years, and some people want one behavior, and some want another. Make it possible to make this choice at runtime with the new -sync option, instead of making this decision by running with different patches. Note that FDH_SYNC is not a macro anymore, nor is it an inline function. While it could be a macro, it would look a bit complex, and there are some oddities with trying to use vol_io_params inside the FDH_SYNC expansion (vol_io_params is not declared for LWP, for example). And having it be an inline function causes problems with some odd linking dependencies. For example, vlib.a contains volume.o, but does not contain a definition for DFlushVolume (dir/buffer.c), which is referenced in volume.o. 'vos' uses vlib.a, but does not bring in anything that defines DFlushVolume. Currently this appears to not cause a problem because 'vos' uses nothing from volume.o, so the dependencies of volume.o don't matter. Adding an inline FDH_SYNC for platforms that don't support 'static inline' would add a dependency to volume.o (via vol_io_params), which causes an error for the lack of a DFlushVolume. Those are possibly just some problems, and may not be all. So instead, make it so we don't have to deal with that and just have a normal function. While FDH_SYNC may be called in a performance-critical section, the overhead of a real function call is nowhere near the delay of an actual fsync(), so presumably any overhead doesn't matter. Change-Id: I23620bd8ac31b9019e9d55cb46ec9f3a75f5675c Reviewed-on: http://gerrit.openafs.org/9694 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com> |
||
|---|---|---|
| .. | ||
| arch | ||
| doxygen/input | ||
| examples | ||
| man-pages | ||
| protocol | ||
| txt | ||
| xml | ||
| LICENSE | ||
| README | ||
What's in the "doc" subdirectory ** doc/html original IBM html doc, no longer used ** doc/man-pages pod sources for man pages (converted from original IBM html source). ** doc/xml xml sources for manuals (converted from original IBM html source). there is some generated pdf/html content as well for the curious. Note that doc/xml/AdminReference uses doc/xml/AdminReference/pod2refentry to convert the pod man pages to xml for printing. pod goes directly to html just fine. The reference guide is now built by converting the existing pod documentation to xml. however, the indexing information was lost during the initial pod conversion. Someone we will need to try to get that back. ** doc/pdf old Transarc (and possibly pre-Transarc) protocol and API documentation for which we have no other source ** doc/txt doc/examples a few other miscellaneous files. From: Russ Allbery The Administrative Reference has been converted into separate POD man pages for each command, since that's basically what it already was (just in HTML). Considerable work remains to update that POD documentation to reflect the current behavior of OpenAFS (for example, there's no documentation of dynroot, no mention of Kerberos v5, many fileserver options are undocumented, the afsd switch documentation is out of date, and so forth). I've collected as many of those deficiencies as I know of in doc/man-pages/README. Any contributions to correct any of those deficiencies are very welcome. This is one easy place to start. The other reference manuals (the Administrator's Guide, the Quick Start Guide, and the User's Guide) are more manual-like in their structure. After some on-list discussion, we picked DocBook as the format to use going forward and the existing HTML files have been converted to DocBook with a script. This means that the markup could use a lot of cleaning up and the content is even less updated than the man pages. I did some *very* initial work on the Quick Start Guide, just to get the makefile working and to try some simple modifications. Simon Wilkinson is currently working on making more extensive modifications. If you want to work on the Quick Start Guide, please coordinate with him to avoid duplicate work. The Administrator's Guide and User's Guide have not yet been touched. Of those, the latter is probably in the best shape, in that the user commands and behavior haven't changed as much. If you'd like to start working on one of those, that would also be great.