public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: raul@viadomus.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Why 'linux/fs.h' cannot be included? I *can*...
Date: Wed, 30 Jan 2002 13:24:22 -0500	[thread overview]
Message-ID: <200201301824.g0UIOMO32639@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1012391761.28301.linux-kernel2news@redhat.com>
In-Reply-To: <mailman.1012391761.28301.linux-kernel2news@redhat.com>

>     The problem is that I don't want to copy the definitions I need
> from linux/fs.h, because this will lead to problems if those
> definitions change.

This is a common misconception. Traditional UNIX operates
this way, indeed. They do "make world" and build everything
in one go, so programs are automatically compatible with
the kernel (in theory, anyways). Once programs outside
of "make world" start to need access to these interfaces,
the scheme crumbles to the ground.

Linus (and thus Linux) consciously decided that this
so-called "souce compatibility" is a mirage. Only binary
compatibility matters. So, you must copy headers that
you wish to use, including linux/fs.h. Then, your program
is binary compatible with the kernel from which you took
them. New kernels may support your program by providing
the same interface, and they may have NO linux/fs.h
at all. If you included headers, you would not be
able to compile your program at all, but the old binary
would continue to work, and copied headers would continue
to work.

Those who come from UNIX background keep insisting to
include kernel headers, especially when they write
drivers with ioctl argument structures. But there is
no other way for them, but to educate themselves in
the Linux lore. Kernel headers are not to be included
in applications.

-- Pete

       reply	other threads:[~2002-01-30 18:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1012391761.28301.linux-kernel2news@redhat.com>
2002-01-30 18:24 ` Pete Zaitcev [this message]
2002-01-30 23:33   ` Why 'linux/fs.h' cannot be included? I *can* Keith Owens
2002-01-31  1:17     ` Jeff Garzik
2002-01-31  1:51       ` Keith Owens
2002-01-31  1:57         ` Jeff Garzik
2002-01-31  2:06           ` Keith Owens
2002-01-31  2:35             ` Jeff Garzik
2002-01-30 12:07 DervishD
2002-01-30 14:27 ` Eric W. Biederman
2002-01-30 16:12 ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2002-01-29 10:20 DervishD
2002-01-29 14:30 ` Jeff Garzik
2002-01-29 14:51   ` Alan Cox
2002-01-29 14:42     ` Jeff Garzik
2002-01-28 19:31 DervishD
2002-01-28 19:44 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200201301824.g0UIOMO32639@devserv.devel.redhat.com \
    --to=zaitcev@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raul@viadomus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox