lkml.org 
[lkml]   [1998]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectHeader files and interfaces
From
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans