xref: /minix/minix/fs/procfs/type.h (revision 7f5f010b)
1 #ifndef _PROCFS_TYPE_H
2 #define _PROCFS_TYPE_H
3 
4 typedef void *data_t;		/* abstract data type; can hold pointer */
5 
6 struct load {
7 	clock_t ticks;		/* in this umber of ticks: */
8 	long proc_load;		/* .. the CPU had this load */
9 };
10 
11 /* ProcFS supports two groups of files: dynamic files, which are created within
12  * process-specific (PID) directories, and static files, which are global. For
13  * both, the following structure is used to construct the files.
14  *
15  * For dynamic files, the rules are simple: only regular files are supported
16  * (although partial support for symbolic links is already present), and the
17  * 'data' field must be filled with a pointer to a function of the type:
18  *
19  *   void (*)(int slot)
20  *
21  * The function will be called whenever a read request for the file is made;
22  * 'slot' contains the kernel slot number of the process being queried (so for
23  * the PM and VFS process tables, NR_TASKS has to be subtracted from the slot
24  * number to find the right slot). The function is expected to produce
25  * appropriate output using the buf_printf() function.
26  *
27  * For static files, regular files and directories are supported. For
28  * directories, the 'data' field must be a pointer to another 'struct file'
29  * array that specifies the contents of the directory - this directory will
30  * the be created recursively. For regular files, the 'data' field must point
31  * to a function of the type:
32  *
33  *   void (*)(void)
34  *
35  * Here too, the function will be called upon a read request, and it is
36  * supposed to "fill" the file using buf_printf(). Obviously, for static files,
37  * there is no slot number.
38  *
39  * For both static and dynamic files, 'mode' must specify the file type as well
40  * as the access mode, and in both cases, each array is terminated with an
41  * entry that has its name set to NULL.
42  */
43 /* The internal link between static/dynamic files/directories and VTreeFS'
44  * indexes and cbdata values is as follows:
45  * - Dynamic directories are always PID directories in the root directory.
46  *   They are generated automatically, and are not specified using a "struct
47  *   file" structure. Their index is their slot number, so that getdents()
48  *   calls always return any PID at most once. Their cbdata value is the PID of
49  *   the process associated with that dynamic directory, for the purpose of
50  *   comparing old and new PIDs after updating process tables (without having
51  *   to atoi() the directory's name).
52  * - Dynamic files are always in such a dynamic directory. Their index is the
53  *   array index into the "struct file" array of pid files (pid_files[]). They
54  *   are indexed at all, because they may be deleted at any time due to inode
55  *   shortages, independently of other dynamic files in the same directory, and
56  *   recreating them without index would again risk possibly inconsistent
57  *   getdents() results, where for example the same file shows up twice.
58  *   VTreeFS currently does not distinguish between indexed and delatable files
59  *   and hence, all dynamic files must be indexed so as to be deletable anyway.
60  * - Static directories have no index (they are not and must not be deletable),
61  *   and although their cbdata is their associated 'data' field from their
62  *   "struct file" entries, their cbdata value is currently not relied on
63  *   anywhere. Then again, as of writing, there are no static directories at
64  *   all.
65  * - Static files have no index either (for the same reason). Their cbdata is
66  *   also their 'data' field from the "struct file" entry creating the file,
67  *   and this is used to actually call the callback function directly.
68  */
69 struct file {
70 	char *name;		/* file name, maximum length PNAME_MAX */
71 	mode_t mode;		/* file mode, including file type */
72 	data_t data;		/* custom data associated with this file */
73 };
74 
75 #endif /* _PROCFS_TYPE_H */
76