Thread: where is struct file_operations???

I've been reading up on how to write linux device drivers. All the material I have refers to struct file_operations as defined in /usr/include/linux/fs.h. I do not rummage through system includes very often, but occasionally I do, and when someone says "struct file_operations is defined in linux.fs.h" I presume they mean therein I will find something like

Code:

struct file_operations {
        blah blah blah

as in the past, that has always been true. But my ls.h does not even contain the word file_operations. In fact, my entire /usr/include only contains five references to "file_operations" and none of those is a definition, eg.

Code:

const struct file_operations *someptr;

The kernel source, not surprisingly, refers to it hundreds of times.

So I've reached the conclusion that I am misunderstanding something elementary, because I do not get how this struct cannot be defined somewhere in /usr/include, and yet is in use all over the place.

Can anyone explain? I don't really need to look at the original definition as I have lots of example code using it, but I do really need to know "what is the nature of my misapprehension" in believing that "struct file_operations in defined in linux/fs.h" means there should be at least some kind of reference to "struct file_operations" in linux/fs.h.

It is part of the kernel code, it is meaningless in user-mode, as the struct is used to define a file-based driver interface - only useful in a kernel mode driver/module.

Here's the definition in the current kernel:
LXR linux/include/linux/fs.h


--
Mats

Originally Posted by matsp

It is part of the kernel code, it is meaningless in user-mode, as the struct is used to define a file-based driver interface - only useful in a kernel mode driver/module.

Alright, so this is really [KERNELSRC]/include/linux/fs.h, a different file from (/usr)/include/linux/fs.h. Fine. But it is beyond comprehension (again) to me why people (as far as I can tell, all of them) who purport to be writing introductory material for other people to kernel programming (which, at that point, it might be safe to assume that those "other people", aka your readership, are new to kernel programming) feel this distinction should just be left implicit and requires absolutely no explanation*, because as an experienced kernel programmer you will already be familiar with all this anyway (leading me to wonder if anyone ever bothered to read this stuff before).

And I've actually read a few hundred pages to prepare myself before I start coding (which usually I read as little as possible); I would not have let this slip by. It may seem minor or insignificant, but it wasted close to an hour. Now I can't stop groaning and smacking my face as I contemplate my future in the hands of these authors...as I notice someone else noticed in the kernel source:

Code:

/* Some people are morons... */

I'm becoming of the opinion that many experienced, ostensibly benevolent senior programmers are actually protecting their franchise by playing the role of Mick Jagger's protagonist in "Sympathy for the Devil":

We lay traps for troubadours...

Thanks matsp

*and what does require explanation?: How 'bout this piece of irrelevancy: "The Linux Base Specification requires that init scripts be in /etc/init, but some distributions do not do this" -- more important than explaining where the includes are???? Nuts.

Have you installed "kernel headers"? I'm pretty sure that goes somewhere under /usr/include.

--
Mats

Originally Posted by matsp

Have you installed "kernel headers"? I'm pretty sure that goes somewhere under /usr/include.

--
Mats

My understanding from the aforementioned reading (which I'm hoping it wasn't all a waste) is that the process now requires the actual source tree (hmmm....) although the "why?"* connection was left implicit. Anyway, I'm using 2.6.28.7 from source.

Actually (expanding the "hmmm"), I was just looking at the headers package for my distro (FC10-64), because of course AFAIK that is /usr/include/linux. Yep (I would have installed those early). And the fs.h is a truncated version of the one in the real tree (only a tenth the size and no mention of file_operations). I have no idea how this works (via INCLUDE in a Makefile?**), but I have built a couple of things (probably drivers) this year where the need for the actual tree has been spelled out, not just the header pack. So that's some kind of policy change, I guess. There is also a "kernel-dev" package which contains the whole tree to go under /usr/src. Since there is (supposed to be) a link to the source tree in /lib/modules as appropriate, I think that is used in places where "the new" /usr/include won't work. Perhaps this was to prevent people from compiling a new kernel and then using the old distro headers when building modules, out of ignorance?

Hopefully the nitty gritty details of these mysteries are about to be thrown in my face (is that what's happening?)

*I have heard all computer programmers in their "terrible two" year are prone to asking everyone this about everything, repeatedly.
** confirmed by me

Right, some of the linux kernel header files also have a stripped down "public" version. This can be confusing, I suppose.

I haven't dealt with Linux kernel for some time, but in general, there is a "kernel headers" or "kernel devel" rpm that contains the kernel headers.

From this link, it appears that fedora's kernele headers are not complete:
The Complete Fedora Kernel Headers

But I expect there to be a fs.h that is complete - it may not be in /usr/include/linux - it may be in /usr/src/kernel/.../include?

--
Mats

Originally Posted by matsp

But I expect there to be a fs.h that is complete - it may not be in /usr/include/linux - it may be in /usr/src/kernel/.../include?

It can be anywhere. As per that last post, what module makefiles use currently is this:

Code:

INCLUDE := -isystem /lib/modules/`uname -r`/build/include

because when you build a kernel, you almost certainly did a "make modules_install" that guarantees that link (which might usually be /usr/include/linux).

I don't know if Fedora is the only one to truncate /usr/include/linux but I guess it is actually a good idea. I would say it's also a "good excuse" for those horrible authors not to bother explaining, except that they are using that Makefile method themselves, so should not be unaware of the difference.

For posterity, this means the makefile included with, eg, the LDP "Linux Kernel Module Programming Guide" (2001,2003) for helloworld will not work. This does:

Code:

obj-m += helloworld.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

apparently the "obj-m" is new fallutin'. Notice also the line addressing the kernel build tree directory is not the traditional INCLUDE line from above (that's what's in the original), and this seems to be the key to get the headers in the tree linking to the other headers correctly. Don't ask me what the difference is, I don't understand "make"...