OSDev.org

i was planning my os's file api and realised that i can probably get away with only having read and write functions in the api without having file descriptor tables in the process control block and functions for opening/closing files. i just need to know if there's something that i've missed here or if this is a perfectly reasonable design

What you are talking about is akin to applying the datagram concept to files. Reading and writing data to them ad hoc. However, that has several limitations, not only functionality wise, but also performance wise.

When you want to access a file, you need to search the drive for its structures and load/write the specific parts. If you need to do a lot of access to the files, you'll have a considerable overhead in repeating that search. With a file descriptor, you can keep an in memory reference to that file. File descriptors need not be just an integer like in many OSs, but they are important if you want performance.

Also if you need to somehow lock the file for your process to prevent other processes from messing it up while you use it, if you don't have a file descriptor referring to an open file, it will make your life much more difficult, as well as it will increase the chances of problems. Imagine you have the ability to lock the file system without the lock being tied to a specific process. If your program has a bug in it and forgets to unlock it explicitly or crashes before unlock it for some other reason, then it will remain locked. These mistakes may be difficult to track.

If, on the other hand, you have a file descriptor associated with your process, when the process ends (regardless of reason), the OS knows what your program was messing around with and will be able to release any locks that might still be tied to your process.

On the other hand, if your take is not about not using ANY descriptor but about not using an integer descriptor of some sort or similar, but using something like the file name, then not only you'll have a very inefficient lookup in the open files, but, since in most OSs the file can be renamed or moved from one directory to another while open (and this is a feature that I'd recommend you keep), depending on how you're organizing it the name will lose meaning as soon as that happens and you'll lose track of it anyway. This will also happen if the file location changes between operations if you don't have a file descriptor, as you won't be able to track that same file if you need to perform many operations, which is the most likely behavior to expect from an application.

Another aspect is inheritance. File descriptors and file handles are trivially easy to inherit, so you can do things like Note that having this be this easy was one of the reasons for Unix winning out against Multics. Anyway, this works by having a "stdout" that is inherited from the shell, and so the shell can set it up to point to the terminal or to a file, or to a pipe, and the program doesn't have to know or care. If you do your read/write APIs only on file names, this will not be this simple.