Messages in this thread | | | Date | Sat, 20 Jun 1998 07:22:11 -0400 | Subject | Header files and interfaces | From | tytso@mit ... |
| |
Like Linus, I'm at Usenix, so my response time to the header files debate is somewhat slow. My apologies for that.
It's true, as Linus pointed out, that e2fsprogs compiles on Non-Linux systems, and that means that we have to have a copy of linux/fs/ext2fs.h. This is true, because e2fsprogs is the one program which needs to be portable to many other platforms, primarily when bootstrapping Linux to another operating system.
However, I believe it's a bad idea to generalize from this to claim that only place to put definitions for kernel interface files is in the application. That's because there are many applications which need the same interface file. For example, in the case of the ext2 user mode tools, all of the following tools need the definition of the ext2 structures:
e2fsprogs defrag dump ext2ed
It would be absolutely insane to say that each time we make a change to the ext2fs structure, we need to modify a header file in each of the application files.
We could define the ext2fs structures in the glibc header files, but David Miller pointed out, glibc changes too slowly. It also doesn't make sense because glibc doesn't define the ext2fs interfaces --- neither the ioctl numbers nor the ext2 structures. So moving them there simply doesn't make sense either.
The same arguments generalize to other header files and applications. For example, multiple programs need linux/serial.h --- maintaining n different copies of the manifest constants for the n programs that need to make serial ioctl's simply makes no sense. And again, it doesn't seem to make any sense to copy them to the glibc header files since they are extremely Linux kernel specific, and the interface is defined by the Linux kernel, not by glibc.
Thus, I think the Linux kernel is the best place to define the header files for interfaces with are defined by the kernel. Sure, if the interface is in libc, then the interface should be defined by libc header files. But in the case of ioctl's, filesystem structures, etc., glibc really has nothing to do with things, so it makes no sense to put those definition in glibc header files. Granted, it would be good to avoid mixing definitions and typedefs which are kernel specific; but if the kernel is implementing the certain ioctl interface, then the kernel should export the header file to define that interface. Separating the two makes life much harder, not easier.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |