File Descriptor Table

Im working on writing a small operating system. I am currently working on implementing dup, dup2, pipe, and close and I need to implement some type of file descriptor table in my PCB.

I was wondering if there is anyone who is familiar with linux/unix implementation of these tables who could explain to me a little about how they are implemented. I know basically how it works, what I am really having a little trouble with now is how file descriptors are mapped to input/output streams. Are their pointers to the pipe / device, or is there some other way its done? Thanks.

-shane

Basically a file descriptor table is a kernel mantained array of pointers to kernel objects representing open files of some kind.

Imagine for a moment that these were C++ object...

int read(int fd,char *buf,size_t len)
{
    return fds[fd]->read(buf,len);
}

int write(int fd,char *buf,size_t len)
{
    return fds[fd]->write(buf,len);
}

int close(int fd,char *buf,size_t len)
{
    fds[fd]->close();
    fds[fd]=NULL;
}

But as kernels are generally written in C, other mechanisms, (pointers to jump tables etc) are used to provide the polymorphism.

Also reference counting is heavily used, so "close" for instance only really drops a reference count, if it gets to zero then the true close occurs.

What you need to consider in the model is where flags such as whether a file descriptor is blocking or not, and where the file-offset should live. Ask yourself, if I use "dup()" do both file descriptors have the same file offset?

If you do look inside the Linux kernel for instance you will notice that the BSD sockets API is handled quite differently to normal ioctl/read/write.

Streams must necessarily have a file descriptor as one of their attributes. Streams are a higher level processing construct than the driver level open/close/read/write/ioctl entry points. Generally they at least manage a buffering logic that works "above" what's actually going on in the kernel's queueing mechanisms.

You can email me direct email address removed if you want a more rapid dialogue.

S.

Depends if you are referering to Sys V STREAMS or stdio Streams....

Please read the rules. No email replies are encouraged.

Perhaps this is THE BOOK for you:

Andrew S. Tanenbaum
Operating Systems Design and Implementation
Prentice Hall, 1997
ISBN-10: 0136386776
ISBN-13: 978-0136386773

If you can't find answers to your questions in there you won't probably find any answers at all. In my copy (2 vol german translation, Hanser, 1990) there is the complete and commented source code for Minix included.

bakunin

Agreed to Porter, and apologies to the moderator on the email thing.