[MPlayer-users] Compile with new kernel

[Tuukka Toivonen]

On Fri, 1 Aug 2003, D Richard Felker III wrote:

I
>> think that /usr/include/linux should _not_ be a symlink to the kernel
>> source tree, but include copy of (possibly) older kernel headers (or be a
>> symlink to such).
>And you have no rational basis on which to think this; you just cite
>authority of other people. Great foundation for a "strong" belief.

You are right, following other people blindly is not the smartest idea
(although if one _isn't_ smart, then it's better idea than to think oneself
;). Therefore, let me give a few arguments (which you might or might not
accept, they can not be _proved_ to be correct):
- Kernel and userspace should be strictly separated, and they should
  communicate with each other solely via the kernel ABI.
  [ABI=Application binary interface for less educated readers]
- The ABI should be ideally "fixed to stone", not to be changed ever.
  However, since new features keep being added, this is not possible.
  But it should nevertheless keep backwards compatibility.
- Including kernel headers from user space programs makes the programs
  to communicate directly with the kernel source, "bypassing" ABI.
  (Well, this might be quite controversial...). If the headers are changed,
  even if the ABI stays same, it may break the programs.
- Including kernel headers into programs makes the programs dependant on
  kernel headers. And dependencies are always bad (that's why Mplayer
  includes a big part from ffmpeg, to remove dependency to it!).
  Copying some important kernel headers should not waste too much space,
  just little.
- I don't think that including kernel headers into userspace programs
  is guaranteed (by the kernel maintainers) to work, especially for C++ or
  even other languages than C++/C.

And the last reason I can make up right now:

>> Now, it seems you're saying otherwise so that programs (mplayer) could
>> include the header files containing the latest kernel features. But what if
>> user is compiling the program with older kernel and copying it to another
>> computer with newer kernel? It wouldn't work.
>Yes it will work.

I mean that it will not use the features of the newer kernel; if you rely
that the kernel headers on the system while compiling include all the
kernel ABI features that you will use, it will break if you are compiling
with older kernel headers and running with newer kernel.  Now suppose that
Mplayer is included into some major distro. It will be compiled into
package with the distro's default kernel. But many users will undoubtedly
upgrade to newer kernel but don't want to compile user space programs from
scratch. So if Mplayer doesn't copy kernel headers, it couldn't use the
features of the newer kernel.

>necessary #defines and structs for calling its ioctl's!! Sure we could
>include such stuff for Linux if we wanted, but what then? Include
>headers for every other kernel as well?? No.

You could do what is customary for a particular OS; I think with Linux it's
customary to not use directly kernel headers (nowadays), if you disagree,
then you will just ignore this point (I can not give you proof that it
really is this way).

>> glibc should include a copy of kernel headers (or compatible headers
>> written from scratch, but that would be much more work). I believe recent
>These are DIFFERENT HEADERS we're talking about. Some headers are
>interfaces to syscalls. Others are interfaces to ioctl's for special
>devices. glibc has its own version of the former, but NOT THE LATTER,
>and should never have the latter because it's bad design.

I don't really see what's the practical difference between syscalls and
ioctl (and what is the definition for "special device"). glibc must know
about most system calls, but also about many ioctls, such as serial
(e.g. tcgetattr...).

P.S. I'm not trying getting you to change Mplayer in any way, currently it
works fine to me. I'm just expressing my opinions.