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