source: rtems/doc/filesystem/fsrequirements.t @ de0711ec

4.104.114.84.95
Last change on this file since de0711ec was de0711ec, checked in by Joel Sherrill <joel.sherrill@…>, on 10/13/99 at 19:48:17

Reorganized a lot per Jennifer's suggestions.

  • Property mode set to 100644
File size: 22.8 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-1998.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9
10@chapter Filesystem Implementation Requirements
11
12This chapter details the behavioral requirements that all filesystem
13implementations must adhere to.
14
15@section General
16
17The RTEMS filesystem framework was intended to be compliant with the
18POSIX Files and Directories interface standard. The following filesystem
19characteristics resulted in a functional switching layer.
20
21@example
22Figure of the Filesystem Functional Layering goes here.
23This figure includes networking and disk caching layering.
24@end example
25
26@ifset use-ascii
27@example
28@group
29@end group
30@end example
31@end ifset
32
33@ifset use-tex
34@c @image{FunctionalLayerCake,6in,4in}
35@end ifset
36
37@ifset use-html
38@end ifset
39
40@enumerate
41
42@item Application programs are presented with a standard set of POSIX
43compliant functions that allow them to interface with the files, devices
44and directories in the filesystem. The interfaces to these routines do
45not reflect the type of subordinate filesystem implementation in which
46the file will be found.
47
48@item The filesystem framework developed under RTEMS allows for mounting
49filesystem of different types under the base filesystem.
50
51@item The mechanics of locating file information may be quite different
52between filesystem types.
53
54@item The process of locating a file may require crossing filesystem
55boundaries.
56
57@item The transitions between filesystem and the processing required to
58access information in different filesystem is not visible at the level
59of the POSIX function call.
60
61@item The POSIX interface standard provides file access by character
62pathname to the file in some functions and through an integer file
63descriptor in other functions.
64
65@item The nature of the integer file descriptor and its associated
66processing is operating system and filesystem specific.
67
68@item Directory and device information must be processed with some of the
69same routines that apply to files.
70
71@item The form and content of directory and device information differs
72greatly from that of a regular file.
73
74@item Files, directories and devices represent elements (nodes) of a tree
75hierarchy.
76
77@item The rules for processing each of the node types that exist under the
78filesystem are node specific but are still not reflected in the POSIX
79interface routines.
80
81@end enumerate
82
83
84@example
85Figure of the Filesystem Functional Layering goes here.
86This figure focuses on the Base Filesystem and IMFS.
87@end example
88
89@example
90Figure of the IMFS Memfile control blocks
91@end example
92
93@section File and Directory Removal Constraints
94
95The following POSIX constraints must be honored by all filesystems.
96
97@itemize @bullet
98
99@item If a node is a directory with children it cannot be removed.
100
101@item The root node of any filesystem, whether the base filesystem or a
102mounted filesystem, cannot be removed.
103
104@item A node that is a directory that is acting as the mount point of a file
105system cannot be removed.
106
107@item On filesystems supporting hard links, a link count is maintained.
108Prior to node removal, the node's link count is decremented by one.  The
109link count must be less than one to allow for removal of the node.
110
111@end itemize
112
113@c
114@c
115@c
116@section API Layering
117
118@subsection Mapping of Generic System Calls to Filesystem Specific Functions
119
120The list of generic system calls includes the routines open(), read(),
121write(), close(), etc..
122
123The Files and Directories section of the POSIX Application Programs
124Interface specifies a set of functions with calling arguments that are
125used to gain access to the information in a filesystem. To the
126application program, these functions allow access to information in any
127mounted filesystem without explicit knowledge of the filesystem type or
128the filesystem mount configuration. The following are functions that are
129provided to the application:
130
131@enumerate
132@item access()
133@item chdir()
134@item chmod()
135@item chown()
136@item close()
137@item closedir()
138@item fchmod()
139@item fcntl()
140@item fdatasync()
141@item fpathconf()
142@item fstat()
143@item fsync()
144@item ftruncate()
145@item link()
146@item lseek()
147@item mkdir()
148@item mknod()
149@item mount()
150@item open()
151@item opendir()
152@item pathconf()
153@item read()
154@item readdir()
155@item rewinddir()
156@item rmdir()
157@item rmnod()
158@item scandir()
159@item seekdir()
160@item stat()
161@item telldir()
162@item umask()
163@item unlink()
164@item unmount()
165@item utime()
166@item write()
167@end enumerate
168
169The filesystem's type as well as the node type within the filesystem
170determine the nature of the processing that must be performed for each of
171the functions above. The RTEMS filesystem provides a framework that
172allows new filesystem to be developed and integrated without alteration
173to the basic framework.
174
175To provide the functional switching that is required, each of the POSIX
176file and directory functions have been implemented as a shell function.
177The shell function adheres to the POSIX interface standard. Within this
178functional shell, filesystem and node type information is accessed which
179is then used to invoke the appropriate filesystem and node type specific
180routine to process the POSIX function call.
181
182@subsection File/Device/Directory function access via file control block - rtems_libio_t structure
183
184The POSIX open() function returns an integer file descriptor that is used
185as a reference to file control block information for a specific file. The
186file control block contains information that is used to locate node, file
187system, mount table and functional handler information. The diagram in
188Figure 8 depicts the relationship between and among the following
189components.
190
191@enumerate
192
193@item File Descriptor Table
194
195This is an internal RTEMS structure that tracks all currently defined file
196descriptors in the system. The index that is returned by the file open()
197operation references a slot in this table. The slot contains a pointer to
198the file descriptor table entry for this file. The rtems_libio_t structure
199represents the file control block.
200
201@item Allocation of entry in the File Descriptor Table
202
203Access to the file descriptor table is controlled through a semaphore that
204is implemented using the rtems_libio_allocate() function. This routine
205will grab a semaphore and then scan the file control blocks to determine
206which slot is free for use. The first free slot is marked as used and the
207index to this slot is returned as the file descriptor for the open()
208request. After the alterations have been made to the file control block
209table, the semaphore is released to allow further operations on the table.
210
211@item Maximum number of entries in the file descriptor table is
212configurable through the src/exec/sapi/headers/confdefs.h file. If the
213CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS constant is defined its value
214will represent the maximum number of file descriptors that are allowed. 
215If CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is not specified a default
216value of 20 will be used as the maximum number of file descriptors
217allowed.
218
219@item File control block - rtems_libio_t structure
220
221@example
222struct rtems_libio_tt @{
223  rtems_driver_name_t               *driver;
224  off_t                              size;      /* size of file */
225  off_t                              offset;    /* current offset into file */
226  unsigned32                         flags;
227  rtems_filesystem_location_info_t   pathinfo;
228  Objects_Id                         sem;
229  unsigned32                         data0;     /* private to "driver" */
230  void                               data1;     / . */
231  void                               file_info; /used by file handlers/
232  rtems_filesystem_file_handlers_r   handlers;  /type specific handlers/
233@};
234@end example
235
236A file control block can exist for regular files, devices and directories.
237The following fields are important for regular file and directory access:
238
239@itemize @bullet
240
241@item Size - For a file this represents the number of bytes currently
242stored in a file. For a directory this field is not filled in.
243
244@item Offset - For a file this is the byte file position index relative to
245the start of the file. For a directory this is the byte offset into a
246sequence of dirent structures.
247
248@item Pathinfo - This is a structure that provides a pointer to node
249information, OPS table functions, Handler functions and the mount table
250entry associated with this node.
251
252@item file_info - A pointer to node information that is used by Handler
253functions
254
255@item handlers - A pointer to a table of handler functions that operate on
256a file, device or directory through a file descriptor index
257
258@end itemize
259
260@end enumerate
261
262@subsection File/Directory function access via rtems_filesystem_location_info_t structure
263
264The rtems_filesystem_location_info_tt structure below provides sufficient
265information to process nodes under a mounted filesystem.
266
267@example
268struct rtems_filesystem_location_info_tt @{
269    void                                         *node_access;
270    rtems_filesystem_file_handlers_r         *handlers;
271    rtems_filesystem_operations_table        *ops;
272    rtems_filesystem_mount_table_entry_t     *mt_entry;
273@};
274@end example
275
276It contains a void pointer to filesystem specific nodal structure,
277pointers to the OPS table for the filesystem that contains the node, the
278node type specific handlers for the node and a reference pointer to the
279mount table entry associated with the filesystem containing the node
280
281@section Operation Tables
282
283Filesystem specific operations are invoked indirectly.  The set of
284routines that implement the filesystem are configured into two tables.
285The Filesystem Handler Table has routines that are specific to a
286filesystem but remain constant regardless of the actual file type.
287The File Handler Table has routines that are both filesystem and file type
288specific.
289
290@subsection Filesystem Handler Table Functions
291
292OPS table functions are defined in a @code{rtems_filesystem_operations_table}
293structure.  It defines functions that are specific to a given filesystem.
294One table exists for each filesystem that is supported in the RTEMS
295configuration. The structure definition appears below and is followed by
296general developmental information on each of the functions contained in this
297function management structure.
298
299@example
300typedef struct @{
301  rtems_filesystem_evalpath_t        evalpath;
302  rtems_filesystem_evalmake_t        evalformake;
303  rtems_filesystem_link_t            link;
304  rtems_filesystem_unlink_t          unlink;
305  rtems_filesystem_node_type_t       node_type;
306  rtems_filesystem_mknod_t           mknod;
307  rtems_filesystem_rmnod_t           rmnod;
308  rtems_filesystem_chown_t           chown;
309  rtems_filesystem_freenode_t        freenod;
310  rtems_filesystem_mount_t           mount;
311  rtems_filesystem_fsmount_me_t      fsmount_me;
312  rtems_filesystem_unmount_t         unmount;
313  rtems_filesystem_fsunmount_me_t    fsunmount_me;
314  rtems_filesystem_utime_t           utime;
315  rtems_filesystem_evaluate_link_t   eval_link;
316  rtems_filesystem_symlink_t         symlink;
317@} rtems_filesystem_operations_table;
318@end example
319
320@c
321@c
322@c
323@c @page
324
325@subsubsection evalpath Handler
326
327@subheading Corresponding Structure Element:
328
329XXX
330
331@subheading Arguments:
332
333XXX
334
335@subheading File:
336
337XXX
338
339@subheading Description:
340
341XXX
342
343
344@c
345@c
346@c
347@c @page
348
349@subsubsection evalformake Handler
350
351@subheading Corresponding Structure Element:
352
353XXX
354
355@subheading Arguments:
356
357XXX
358
359@subheading File:
360
361XXX
362
363@subheading Description:
364
365XXX
366
367
368@c
369@c
370@c
371@c @page
372
373@subsubsection link Handler
374
375@subheading Corresponding Structure Element:
376
377link
378
379@subheading Arguments:
380
381
382@example
383rtems_filesystem_location_info_t    *to_loc,      /* IN */
384rtems_filesystem_location_info_t    *parent_loc,  /* IN */
385const char                          *token        /* IN */
386@end example
387
388@subheading File:
389
390imfs_link.c
391
392@subheading Description:
393
394
395This routine is used to create a hard-link.
396
397It will first examine the st_nlink count of the node that we are trying to.
398If the link count exceeds LINK_MAX an error will be returned.
399
400The name of the link will be normalized to remove extraneous separators from
401the end of the name.
402
403@c
404@c
405@c
406@c @page
407
408@subsubsection unlink Handler
409
410@subheading Corresponding Structure Element:
411
412XXX
413
414@subheading Arguments:
415
416XXX
417
418@subheading File:
419
420XXX
421
422@subheading Description:
423
424XXX
425
426
427@c
428@c
429@c
430@c @page
431
432@subsubsection node_type Handler
433
434@subheading Corresponding Structure Element:
435
436node_type()
437
438@subheading Arguments:
439
440@example
441rtems_filesystem_location_info_t    *pathloc        /* IN */
442@end example
443
444@subheading File:
445
446imfs_ntype.c
447
448@subheading Description:
449
450XXX
451
452@c
453@c
454@c
455@c @page
456
457@subsubsection mknod Handler
458
459@subheading Corresponding Structure Element:
460
461mknod()
462
463@subheading Arguments:
464
465@example
466const char                          *token,        /* IN */
467mode_t                               mode,         /* IN */
468dev_t                                dev,          /* IN */
469rtems_filesystem_location_info_t    *pathloc       /* IN/OUT */
470@end example
471
472@subheading File:
473
474mknod.c
475
476@subheading Description:
477
478XXX
479
480@c
481@c
482@c
483@c @page
484
485@subsubsection rmnod Handler
486
487@subheading Corresponding Structure Element:
488
489XXX
490
491@subheading Arguments:
492
493XXX
494
495@subheading File:
496
497XXX
498
499@subheading Description:
500
501XXX
502
503
504@c
505@c
506@c
507@c @page
508
509@subsubsection chown Handler
510
511@subheading Corresponding Structure Element:
512
513chown()
514
515@subheading Arguments:
516
517@example
518rtems_filesystem_location_info_t    *pathloc        /* IN */
519uid_t                                owner          /* IN */
520gid_t                                group          /* IN */
521@end example
522
523@subheading File:
524
525imfs_chown.c
526
527@subheading Description:
528
529XXX
530
531@c
532@c
533@c
534@c @page
535
536@subsubsection freenod Handler
537
538@subheading Corresponding Structure Element:
539
540XXX
541
542@subheading Arguments:
543
544XXX
545
546@subheading File:
547
548XXX
549
550@subheading Description:
551
552XXX
553
554
555@c
556@c
557@c
558@c @page
559
560@subsubsection mount Handler
561
562@subheading Corresponding Structure Element:
563
564mount()
565
566@subheading Arguments:
567
568@example
569rtems_filesystem_mount_table_entry_t   *mt_entry
570@end example
571
572@subheading File:
573
574mount.c
575
576@subheading Description:
577
578XXX
579
580@c
581@c
582@c
583@c @page
584
585@subsubsection fsmount_me Handler
586
587@subheading Corresponding Structure Element:
588
589XXX
590
591@subheading Arguments:
592
593@example
594rtems_filesystem_mount_table_entry_t   *mt_entry   
595@end example
596
597@subheading File:
598
599XXX
600
601@subheading Description:
602
603This function is provided with a filesystem to take care of the internal
604filesystem management details associated with mounting that filesystem
605under the RTEMS environment.
606
607It is not responsible for the mounting details associated the filesystem
608containing the mount point.
609
610The rtems_filesystem_mount_table_entry_t structure contains the key elements
611below:
612
613rtems_filesystem_location_info_t         *mt_point_node,
614
615This structure contains information about the mount point. This
616allows us to find the ops-table and the handling functions
617associated with the filesystem containing the mount point.
618
619rtems_filesystem_location_info_t         *fs_root_node,
620
621This structure contains information about the root node in the file
622system to be mounted. It allows us to find the ops-table and the
623handling functions associated with the filesystem to be mounted.
624
625rtems_filesystem_options_t                 options,
626
627Read only or read/write access
628
629void                                         *fs_info,
630
631This points to an allocated block of memory the will be used to
632hold any filesystem specific information of a global nature. This
633allocated region if important because it allows us to mount the
634same filesystem type more than once under the RTEMS system.
635Each instance of the mounted filesystem has its own set of global
636management information that is separate from the global
637management information associated with the other instances of the
638mounted filesystem type.
639
640rtems_filesystem_limits_and_options_t    pathconf_info,
641
642The table contains the following set of values associated with the
643mounted filesystem:
644
645@itemize @bullet
646
647@item link_max
648
649@item max_canon
650
651@item max_input
652
653@item name_max
654
655@item path_max
656
657@item pipe_buf
658
659@item posix_async_io
660
661@item posix_chown_restrictions
662
663@item posix_no_trunc
664
665@item posix_prio_io
666
667@item posix_sync_io
668
669@item posix_vdisable
670
671@end itemize
672
673These values are accessed with the pathconf() and the fpathconf () 
674functions.
675
676const char                                   *dev
677
678The is intended to contain a string that identifies the device that contains
679the filesystem information. The filesystems that are currently implemented
680are memory based and don't require a device specification.
681
682If the mt_point_node.node_access is NULL then we are mounting the base file
683system.
684
685The routine will create a directory node for the root of the IMFS file
686system.
687
688The node will have read, write and execute permissions for owner, group and
689others.
690
691The node's name will be a null string.
692
693A filesystem information structure(fs_info) will be allocated and
694initialized for the IMFS filesystem. The fs_info pointer in the mount table
695entry will be set to point the filesystem information structure.
696
697The pathconf_info element of the mount table will be set to the appropriate
698table of path configuration constants (LIMITS_AND_OPTIONS).
699
700The fs_root_node structure will be filled in with the following:
701
702@itemize @bullet
703
704@item pointer to the allocated root node of the filesystem
705
706@item directory handlers for a directory node under the IMFS filesystem
707
708@item OPS table functions for the IMFS
709
710@end itemize
711
712A 0 will be returned to the calling routine if the process succeeded,
713otherwise a 1 will be returned.
714
715
716@c
717@c
718@c
719@c @page
720
721@subsubsection unmount Handler
722
723@subheading Corresponding Structure Element:
724
725XXX
726
727@subheading Arguments:
728
729XXX
730
731@subheading File:
732
733XXX
734
735@subheading Description:
736
737XXX
738
739
740@c
741@c
742@c
743@c @page
744
745@subsubsection fsunmount_me Handler
746
747@subheading Corresponding Structure Element:
748
749imfs_fsunmount_me()
750
751@subheading Arguments:
752
753@example
754rtems_filesystem_mount_table_entry_t   *mt_entry   
755@end example
756
757@subheading File:
758
759imfs_fsunmount_me.c
760
761@subheading Description:
762
763XXX
764
765
766@c
767@c
768@c
769@c @page
770
771@subsubsection utime Handler
772
773@subheading Corresponding Structure Element:
774
775XXX
776
777@subheading Arguments:
778
779XXX
780
781@subheading File:
782
783XXX
784
785@subheading Description:
786
787XXX
788
789@c
790@c
791@c
792@c @page
793
794@subsubsection eval_link Handler
795
796@subheading Corresponding Structure Element:
797
798XXX
799
800@subheading Arguments:
801
802XXX
803
804@subheading File:
805
806XXX
807
808@subheading Description:
809
810XXX
811
812@c
813@c
814@c
815@c @page
816
817@subsubsection symlink Handler
818
819@subheading Corresponding Structure Element:
820
821XXX
822
823@subheading Arguments:
824
825XXX
826
827@subheading File:
828
829XXX
830
831@subheading Description:
832
833XXX
834
835@c
836@c
837@c
838@c @page
839@subsection File Handler Table Functions
840
841Handler table functions are defined in a @code{rtems_filesystem_file_handlers_r}
842structure. It defines functions that are specific to a node type in a given
843filesystem. One table exists for each of the filesystem's node types. The
844structure definition appears below. It is followed by general developmental
845information on each of the functions associated with regular files contained
846in this function management structure.
847
848@example
849typedef struct @{
850    rtems_filesystem_open_t           open;
851    rtems_filesystem_close_t          close;
852    rtems_filesystem_read_t           read;
853    rtems_filesystem_write_t          write;
854    rtems_filesystem_ioctl_t          ioctl;
855    rtems_filesystem_lseek_t          lseek;
856    rtems_filesystem_fstat_t          fstat;
857    rtems_filesystem_fchmod_t         fchmod;
858    rtems_filesystem_ftruncate_t      ftruncate;
859    rtems_filesystem_fpathconf_t      fpathconf;
860    rtems_filesystem_fsync_t          fsync;
861    rtems_filesystem_fdatasync_t      fdatasync;
862    rtems_filesystem_fcntl_t          fcntl;
863@} rtems_filesystem_file_handlers_r;
864@end example
865
866@c
867@c
868@c
869@c @page
870
871@subsubsection open Handler
872
873@subheading Corresponding Structure Element:
874
875open()
876
877@subheading Arguments:
878
879@example
880rtems_libio_t   *iop,
881const char      *pathname,
882unsigned32       flag,
883unsigned32       mode
884@end example
885
886@subheading File:
887
888XXX
889
890@subheading Description:
891
892XXX
893
894@c
895@c
896@c
897@c @page
898
899@subsubsection close Handler
900
901@subheading Corresponding Structure Element:
902
903close()
904
905@subheading Arguments:
906
907@example
908rtems_libio_t     *iop
909@end example
910
911@subheading File:
912
913XXX
914
915@subheading Description:
916
917XXX
918
919@subheading NOTES:
920
921XXX
922
923
924
925@c
926@c
927@c
928@c @page
929
930@subsubsection read Handler
931
932@subheading Corresponding Structure Element:
933
934read()
935
936@subheading Arguments:
937
938@example
939rtems_libio_t     *iop,
940void              *buffer,
941unsigned32         count
942@end example
943
944@subheading File:
945
946XXX
947
948@subheading Description:
949
950XXX
951
952@subheading NOTES:
953
954XXX
955
956
957@c
958@c
959@c
960@c @page
961
962@subsubsection write Handler
963
964@subheading Corresponding Structure Element:
965
966XXX
967
968@subheading Arguments:
969
970XXX
971@subheading File:
972
973XXX
974
975@subheading Description:
976
977XXX
978
979@subheading NOTES:
980
981XXX
982
983
984@c
985@c
986@c
987@c @page
988
989@subsubsection ioctl Handler
990
991@subheading Corresponding Structure Element:
992
993XXX
994
995@subheading Arguments:
996
997@example
998rtems_libio_t     *iop,
999unsigned32       command,
1000void              *buffer
1001@end example
1002
1003@subheading File:
1004
1005XXX
1006
1007@subheading Description:
1008
1009XXX
1010
1011@subheading NOTES:
1012
1013XXX
1014
1015
1016@c
1017@c
1018@c
1019@c @page
1020
1021@subsubsection lseek Handler
1022
1023@subheading Corresponding Structure Element:
1024
1025lseek()
1026
1027@subheading Arguments:
1028
1029@example
1030rtems_libio_t     *iop,
1031off_t              offset,
1032int                whence
1033@end example
1034
1035@subheading File:
1036
1037XXX
1038
1039@subheading Description:
1040
1041XXX
1042
1043@subheading NOTES:
1044
1045XXX
1046
1047
1048@c
1049@c
1050@c
1051@c @page
1052
1053@subsubsection fstat Handler
1054
1055@subheading Corresponding Structure Element:
1056
1057fstat()
1058
1059@subheading Arguments:
1060
1061@example
1062rtems_filesystem_location_info_t   *loc,
1063struct stat                        *buf
1064@end example
1065
1066@subheading File:
1067
1068XXX
1069
1070@subheading Description:
1071
1072The following information is extracted from the filesystem
1073specific node and placed in the @code{stat} structure:
1074
1075@itemize @bullet
1076
1077@item st_mode
1078
1079@item st_nlink
1080
1081@item st_ino
1082
1083@item st_uid
1084
1085@item st_gid
1086
1087@item st_atime
1088
1089@item st_mtime
1090
1091@item st_ctime
1092
1093@end itemize
1094
1095
1096@subheading NOTES:
1097
1098XXX
1099
1100@c
1101@c
1102@c
1103@c @page
1104
1105@subsubsection fchmod Handler
1106
1107@subheading Corresponding Structure Element:
1108
1109fchmod()
1110
1111@subheading Arguments:
1112
1113@example
1114rtems_libio_t     *iop
1115mode_t              mode
1116@end example
1117
1118@subheading File:
1119
1120imfs_fchmod.c
1121
1122@subheading Description:
1123
1124XXX
1125
1126
1127@subheading NOTES:
1128
1129XXX
1130
1131@c
1132@c
1133@c
1134@c @page
1135
1136@subsubsection ftruncate Handler
1137
1138@subheading Corresponding Structure Element:
1139
1140XXX
1141
1142@subheading Arguments:
1143
1144XXX
1145@subheading File:
1146
1147XXX
1148
1149@subheading Description:
1150
1151XXX
1152
1153@subheading NOTES:
1154
1155XXX
1156
1157@subsubsection fpathconf Handler
1158
1159@subheading Corresponding Structure Element:
1160
1161XXX
1162
1163@subheading Arguments:
1164
1165XXX
1166
1167@subheading File:
1168
1169XXX
1170
1171@subheading Description:
1172
1173XXX
1174
1175@subheading NOTES:
1176
1177XXX
1178
1179@c
1180@c
1181@c
1182@c @page
1183
1184@subsubsection fsync Handler
1185
1186@subheading Corresponding Structure Element:
1187
1188XXX
1189
1190@subheading Arguments:
1191
1192XXX
1193@subheading File:
1194
1195XXX
1196
1197@subheading Description:
1198
1199XXX
1200
1201@subheading NOTES:
1202
1203XXX
1204
1205@c
1206@c
1207@c
1208@c @page
1209
1210@subsubsection fdatasync Handler
1211
1212@subheading Corresponding Structure Element:
1213
1214XXX
1215
1216@subheading Arguments:
1217
1218XXX
1219
1220@subheading File:
1221
1222XXX
1223
1224@subheading Description:
1225
1226XXX
1227
1228@subheading NOTES:
1229
1230XXX
1231
1232@c
1233@c
1234@c
1235@c @page
1236
1237@subsubsection fcntl Handler
1238
1239@subheading Corresponding Structure Element:
1240
1241XXX
1242
1243@subheading Arguments:
1244
1245XXX
1246
1247@subheading File:
1248
1249XXX
1250
1251@subheading Description:
1252
1253XXX
1254
1255@subheading NOTES:
1256
1257XXX
Note: See TracBrowser for help on using the repository browser.