問題描述
文件描述符中實際存儲了多少信息？ (How much information is actually stored in a file descriptor?)
This may sound like an odd question, but when I go and open a file:
int fd;
fd = open("/dev/somedevice", O_RDWR);
What exactly am I getting back? I can see the man page says: The open() function shall return a file descriptor for the named file that is the lowest file descriptor not currently open for that process
But is that it? Is it just an int or is there data attached to it behind the scenes? The reason I'm asking is I found some code (Linux/C) where we're opening the file from user space:
//User space code:
int fdC;
if ((fdC = open(DEVICE, O_RDWR)) < 0) {
printf("Error opening device %s (%s)\n", DEVICE, strerror(errno));
goto error_exit;
}
while (!fQuit) {
if ((nRet = read(fdC, &rx_message, 1)) > 0) {
then on the kernel end, the file operations for this module (which supplies the fd) map reads to the n_read() function:
struct file_operations can_fops = {
owner: THIS_MODULE,
lseek: NULL,
read: n_read,
Then the file descriptor is used in the n_read(), but it's being accessed to get data:
int n_read(struct file *file, char *buffer, size_t count, loff_t *loff)
{
data_t * dev;
dev = (data_t*)file->private_data;
So... I figure what's happening here is either:
A) a file descriptor returned from open() contains more data than just a descriptive integer value Or B)The mapping between a call to "read" in the user space isn't as simple as I'm making it out to be and there's some code missing in this equation.
Any input that might help direct me?
參考解法
方法 1:
File descriptor is just an int. The kernel uses it as an index to a table containing all the related information, including file position, file ops (kernel functions that provide the read(), write(), mmap() etc. syscalls), and so on.
When you open() a file or device, the kernel creates a new file descriptor entry for your process, and populates the internal data, including the file ops.
When you use read(), write(), mmap(), etc. with a valid file descriptor, the kernel simply looks up the correct in-kernel function to call based on the file ops in the file descriptor table it has (and which the file descriptor indexes). It really is that simple.
方法 2:
In addition to existing good answer by @Nominal Aminal it is an integer but it points to an entry of a structure in kernel called file descriptor table. That is at least the case with Linux. Of the several fields that are part of that struct, an interesting one is:
FILE * pointer; // descriptor to / from reference counts etc.
You might be interested in following api's which given one of FILE * or descriptor, return the other
How to obtain FILE * from fd and vice versa
方法 3:
I think that it is just an int. From Wikipedia:
Generally, a file descriptor is an index for an entry in a kernel-resident data structure containing the details of all open files. In POSIX this data structure is called a file descriptor table, and each process has its own file descriptor table.
(by Mike、Nominal Animal、fkl、Maria Ines Parnisari)