linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Joerg Schilling <schilling@fokus.fraunhofer.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel includefile bug not fixed after a year :-(
Date: Tue, 30 Sep 2003 14:06:29 +0200	[thread overview]
Message-ID: <20030930120629.GM2908@suse.de> (raw)
In-Reply-To: <200309301157.h8UBvOcd004345@burner.fokus.fraunhofer.de>

On Tue, Sep 30 2003, Joerg Schilling wrote:
> 
> >From axboe@suse.de  Tue Sep 30 13:54:12 2003
> 
> >> >> Is there no interest in user applications for kernel features or is there just
> >> >> no kernel maintainer left over who makes the needed work?
> >> 
> >> >/usr/include/scsi/scsi.h looks fine on my system, probably also on
> >> >yours. You should not include kernel headers in your user space program.
> >> 
> >> Looks like you did not understand the background :-(
> 
> >I think I do.
> 
> Sorry, but you just verified that you don't :-(

No, you continue to show you don't understand why you should not include
kernel headers in user space.

> >> In order to use kernel interfaces you _need_ to include kernel include
> >> files.
> 
> >False. You need to include the glibc kernel headers.
> 
> 
> False: as glibc kernel headers are not part of the kernel distribution.

How is that an argument? By your logic, you need one huge package with
basically everything in it, how else do you know your application works
with that given kernel?

I asked you one simple question: when did the kernel/user interface
break, and how? You happily chose to ignore that. A pity, since that
would be the core of your argument.

I'm not saying that situation _never_ happened, but it is an extremely
rare event and usually only happens for a very good reason. When did you
last need to recompile a program because you upgraded your kernel?

> >> This is in particular true as long as we are talking about
> >> beta/testing kernels.
> >> 
> >> 
> >> Background: on homogeneous platforms like e.g. Solaris or FreeBSD
> >> which are maintained and distributed as whole, an _enduser_ should
> >> include files from /usr/include only. 
> >> 
> >> 	This is not even true for people who do Solaris or FreeBSD
> >> 	kernel development and like to test new features with user level
> >> 	programs.  It is definitely not true for compilations against
> >> 	Linux kernel interfaces.
> >> 
> >> Linux is not a homogeneous system. There is a separately developed
> >> kernel and a separate base user level system. People often install a
> >> newer kernel and need to recompile software because the kernel/user
> >> interfaces are not stable between different Linux releases.
> 
> >That's a pretty bold claim, when did the kernel/user interface break? A
> >lot of care is usually taken to ensure that this does not happen.
> 
> >This subject has been debated to death lots of times before, I'm sure
> >the archives are more detailed and enlightening that I am.
> 
> If these debates have not been done in a serious way, or people without
> the needed kernel development background knowledge did decide, these
> debates are just void.

Did you search and find these debates? Or are you just assuming you know
better?

-- 
Jens Axboe


  reply	other threads:[~2003-09-30 12:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-30 11:57 Kernel includefile bug not fixed after a year :-( Joerg Schilling
2003-09-30 12:06 ` Jens Axboe [this message]
2003-09-30 12:28   ` David S. Miller
2003-09-30 12:38     ` Jens Axboe
2003-09-30 14:41       ` Krzysztof Halasa
2003-10-10  6:36     ` Sandy Harris
  -- strict thread matches above, loose matches on Subject: below --
2003-10-01  1:05 Albert Cahalan
2003-09-30 13:26 Joerg Schilling
2003-09-30 12:52 Joerg Schilling
2003-09-30 12:37 Joerg Schilling
2003-09-30 13:21 ` Tomas Szepe
2003-09-30 11:44 Joerg Schilling
2003-09-30 11:54 ` Jens Axboe
2003-09-30 12:12   ` Andreas Steinmetz
2003-09-30 12:21     ` Jens Axboe
2003-09-30 12:26       ` Andreas Steinmetz
2003-09-30 12:30         ` Jens Axboe
2003-09-30 12:32       ` David S. Miller
2003-09-30 12:40         ` Jens Axboe
2003-09-30 12:39           ` David S. Miller
2003-09-30 12:23     ` David S. Miller
2003-09-30 12:28       ` Jens Axboe
2003-09-30 12:34         ` David S. Miller
2003-09-30 12:42           ` Jens Axboe
2003-09-30 19:09         ` Erik Andersen
2003-10-01  8:48           ` Paul Rolland
2003-10-01  8:55             ` Arjan van de Ven
2003-10-01 17:49             ` Erik Andersen
2003-09-30 16:10       ` Sam Ravnborg
2003-10-01  6:39         ` David S. Miller
2003-10-02  6:42         ` Eric W. Biederman
2003-09-30 19:04       ` Erik Andersen
2003-09-30 12:25     ` Nick Piggin
2003-09-30 19:00     ` Erik Andersen
2003-10-01  8:47       ` Paul Rolland
2003-09-30 10:28 Joerg Schilling
2003-09-30 11:05 ` Jens Axboe

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=20030930120629.GM2908@suse.de \
    --to=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schilling@fokus.fraunhofer.de \
    /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;
as well as URLs for NNTP newsgroup(s).