The end of the fcntl() method

Some kernel interfaces last longer than others. The fcntl() method is one of the others. It was added to the file_operations structure in 2.6.6 with the purpose of giving low-level filesystems and device drivers an opportunity to look at the command being executed from an fcntl() system call and, possibly, do something different. The immediate motivation was allowing the NFS code to disallow the combination of the O_APPEND and O_DIRECT flags, since those two modes cannot work together in that filesystem. Since then, the CIFS filesystem also has made use of it to better handle the F_NOTIFY command by getting directory notifications from the remote server.

In 2.6.8, that operation is gone again. The thinking is that the file_operations structure did not really need another general-purpose, multiplexed operation like fcntl(). So the method was replaced with two new, carefully-focused methods. The first is:

    int (*check_flags)(int flags);

This operation, if present, will be called in response to an fcntl(F_SETFL,...) system call. It can look at the flags passed in from user space and ensure that they make sense for the device or filesystem in question.

The other new operation is:

    int (*dir_notify)(struct file *filp, unsigned long arg);

This is the new method used by CIFS to handle F_NOTIFY requests. All other fcntl() operations are handled in the core VFS code, as usual.

The patch as merged by Linus fixed the NFS and CIFS code to use the new methods. Unfortunately, nobody tested the NFS changes before the patch was merged, and this change went in just before the final 2.6.8 release came out. The result was an NFS implementation which crashed the kernel, and the need for a quick 2.6.8.1 release.

Index entries for this article
Kernel	fcntl() method
Kernel	struct file_operations

---

to post comments

The end of the fcntl() method

Posted Aug 19, 2004 9:39 UTC (Thu) by Tet (guest, #5433) [Link] (5 responses)

I've noticed that LWN has started calling functions "methods" of late. Any particular reason? The kernel is still written in C, not C++ or Java. Therefore they should be called functions. Just MHO...

The end of the fcntl() method

Posted Aug 19, 2004 11:04 UTC (Thu) by jamesh (guest, #1159) [Link]

But they are methods. The kernel makes heavy use of object oriented programming techniques, so why not use the commonly accepted terms when talking about the code?

Just because the C language does not provide any specialised syntax for object oriented programming doesn't mean that you can't make use of the techniques.

The end of the fcntl() method

Posted Aug 19, 2004 15:18 UTC (Thu) by iabervon (subscriber, #722) [Link] (3 responses)

What LWN refers to as "methods" aren't functions, but rather function pointer fields of structures. "check_flags" isn't an actual particular function. The context is:

struct file_operations {
...
int (*check_flags)(int flags);
...
};

It's actually wrong to call it a function, and calling it a method is simpler than calling it a function pointer field, which, in the context of C, is what a method is.

methods and functions

Posted Aug 20, 2004 23:08 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

Every time I've heard someone talk about a method, he was talking about the function, not the pointer to it. It's like, "when the dir_notify method executes..." Pointers don't execute. The functions to which they point do.

It's true that "dir_notify" isn't usually the name of the function, but it's clearly a description of one, like "the garbage collector function."

methods and functions

Posted Aug 21, 2004 0:04 UTC (Sat) by iabervon (subscriber, #722) [Link] (1 responses)

But "dir_notify" isn't an English description like "the garbage collector function"; it's a description in terms of the structure member that it is suitable for. "The dir_notify method" means "the function that the dir_notify field points to", which is what "method" usually means in programming language terms (although the details of how you find the method are often hidden a bit). "The dir_notify function" would be something entirely different, and "the dir_notify pointer" would be something else again. Clearly, then, the term "method" is a useful description of the actual situation. It would be just as wrong to talk about the "dir_notify function" as it would be to talk about the "vfs_create method".

Actually, in C, you can execute a function pointer; file->f_op->flush(file) is a perfectly good equivalent for (*file->f_op->flush)(file).

methods and functions

Posted Aug 21, 2004 2:14 UTC (Sat) by giraffedata (guest, #1954) [Link]

I think "dir_notify" is as good a word as any English dictionary word, notwithstanding its weird spelling. It's as descriptive as "int" and "errno," two other words found in English conversations about kernel programming. It's as legitimate as "directory change notification." So I can't see any problem with describing a certain function as a "dir_notify" function.

In the paradigm in which you make an OOP language out of C, you represent an object with a struct and a method with a function, and put a function pointer in the struct to declare the binding. It's the fact that the function is used like an OOP method that makes it a method, not the fact that it's called through a C function pointer. I wouldn't talk about the "vfs_create method" because there isn't a type of function called in the OOP paradigm that fits that description.

I/O request descriptors usually have a function pointer to an "endio" function in them. The endio function is not a method (neither is the pointer to it). This is a much more primitive technology than OOP.

I would accept that the "method" is actually the combination of both the function and the pointer to it in the "object" struct. But I can't accept that the pointer itself is the method.

NFS bug

Posted Aug 19, 2004 13:56 UTC (Thu) by jeremiah (subscriber, #1221) [Link] (3 responses)

Anyone ever try to get unit testing into the kernel, or some of it's more critical subsystems? Seems like it wouldn't be such a bad thing. 10 years ago, I could handle the kernel pretty well, but every year I watch it get alot bigger and more complex and wonder when it's going to hit a critical size at which it just can't be maintained without some sort of automated testing.

NFS bug

Posted Aug 19, 2004 20:10 UTC (Thu) by NAR (subscriber, #1313) [Link] (2 responses)

Anyone ever try to get unit testing into the kernel, or some of it's more critical subsystems?

It depends on what you call "more critical". It can really slow down the release process, if you add lots of unit testing. On the commercial project where I work, the running of the automated tests take more time than the actual compilation. An in my opinion, we have way too few tests.

Bye,NAR

NFS bug

Posted Aug 20, 2004 14:02 UTC (Fri) by jeremiah (subscriber, #1221) [Link] (1 responses)

True, but the question is, what is causing us to relase more updates/patches. bug fixes or enhancements. To me it seems that there are ussally some nice enhancments that add a few bugs, and a much bigger amount of bug fixes. Would most of these bugs that are being addressed never have made it into the mainline kernel if unit testing was in place. Would it save developer time? I think it would help is some areas where people are tring out large patches, or reworking whole subsystems, VM etc. You can run the test, and know that what ever you did didn't screw anything up. As to the really slow down releases thing, I know time to run the test would be slower, but not every one needs to run the test, just the maintainer and the original developer, and perhaps Linus right before it goes out.

To argue against myself here though, the amount of effort required to set up testing would drive me insane quite quickly. Much less backfit that much testing onto a moving target like the kernel.

NFS bug

Posted Aug 21, 2004 0:22 UTC (Sat) by khim (subscriber, #9252) [Link]

There are more oportant thing.

"Brown paper bug" releases do happen from time to time, no doubt about it - but most bug-fixes are covering some previously unknown case! Some improper flags combination, or some obscure version of system call, etc. Any automated testing is useless against it.