Sorry, let me try and clarify.

As I understand things: At the process level there exists an array of pointers to file structures indexed by file descriptor; a file descriptor is thus in some senses a per-process proxy for a richer data structure. Those file structures are collected into a single, global table. The question is why this latter table? One could rather imagine an implementation where open() allocates (e.g., via malloc()) a new 'struct file' that contains as a structure field an 'int refcnt' that is incremented when a descriptor is dup()'d or as a side-effect of a fork(), and is decremented as a result of a close(); when 'refcnt' drops to zero, the structure could be freed with e.g. 'mfree'. What is the benefit of 'struct file file[];'?

To give a concrete example, consider 7th Edition Unix. sys/h/file.h contains the definition of 'struct file', which already includes 'char f_count' which is documented as a 'reference count.' This is incremented as the result of fork() (really, in newproc() in sys/sys/slp.c) and dup() (sys/sys/sys3.c), or when a 'struct file' is allocated (sys/sys/fio.c). It's decremented when a file is closed; the ref count is also used to handle releasing inodes and so forth in closef() (sys/sys/fio.c); there's some minor use in the pipe code. But falloc() always iterates over the global 'file' (declared as 'extern struct file file[];' in sys/h/file.h, defined in the generated output of the 'mkconf' command in sys/conf; e.g. sys/conf/c.c).

The question is, why the global table named 'file'? Sure, it naturally bounds the total number of open files; is that the primary reason? Was it just expedient? Were there any other uses that made a global array particularly attractive as a design approach? I suppose the same question could be asked about the proc table, buffer structs, etc.

        - Dan C.