public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Franco Sensei <senseiwa@tin.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel strict versioning
Date: Tue, 12 Apr 2005 03:50:18 +0200	[thread overview]
Message-ID: <20050412015018.GA3828@stusta.de> (raw)
In-Reply-To: <425B1E3F.5080202@tin.it>

On Mon, Apr 11, 2005 at 08:02:55PM -0500, Franco Sensei wrote:
> Adrian Bunk wrote:
> >This has nothing to do with versioning.
> >
> >You are asking for ABI compatibility between different kernel versions.
> 
> The problem is probably misunderstanding about what I intend by version.
> 
> >There is no stable ABI between different kernel versions and there will 
> >never be one. Please read Documentation/stable_api_nonsense.txt for 
> >details.
> 
> I've read it.
> 
> Assuming the fact that a kernel can be considered stable, my point of
> view implies an assumption: kernel and modules are distributed by a
> distro, and compiled with the same gcc. Of course, I'm not talking about
> different architectures and so on, since I'm talking about something
> different, I'm talking about the api involved in the developement. 
> Distributions have to use a great care about compiler changes, and it's 
> not kernel developers' problem.
> 
> A kernel stable 2.X  version should not differ much in the
> subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be 

You say API but talk about ABI.

> possibly avoided by using a release versioning different from the one 
> used now. Structues and exported functions should be almost the same, 
> the implementation should be, and of course, must be different: bugs, 
> improvements and so on.

You said you've read stable_api_nonsense.txt .

stable_api_nonsense.txt talks about exactly these issues.

> I see the point about continuous developement, that's why I'm using 
> linux since 97, but I find interesting also the design of a stable 
> infrastructure, that can be achieved. A data structure no longer in use 
> by anyone, functions being unused for a long time, can be made harmless. 
> Providing a binary compatibility makes recompiling all external modules 
> (external to the official kernel I mean) not necessary, making life 
> easier for any other person using linux (e.g. pwc module for my logitech 
> pro 4000 webcam, every new kernel, new module compilation. Stability 
> makes in this sense a real big improvement. An example of this care can 

The right solution for this issue is simple:

Get the module into the kernel.

Not that e.g. your pwc module will be in kernel 2.6.12.

> be found in trolltech qt library. I use them since 1.x and it's a really 
> good thing assuring the binary compatibility... of course they just 
> screw it some day to day :) Everybody can be wrong.
>...

Please check the facts:

QT 1 is _not_ binary compatible with QT 3.

There's a reason why the library changed the so-name...


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2005-04-12  1:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08 18:08 [INFO] Kernel strict versioning Franco "Sensei"
2005-04-08 19:05 ` Adrian Bunk
2005-04-12  1:02   ` Franco "Sensei"
2005-04-12  1:50     ` Adrian Bunk [this message]
2005-04-12  2:54       ` Franco "Sensei"
2005-04-12 11:28         ` Krzysztof Halasa
2005-04-12 17:22           ` Franco "Sensei"
2005-04-12 18:03             ` David Lang
2005-04-14 16:52               ` Franco "Sensei"
2005-04-14 17:57                 ` David Lang
2005-04-14 19:41                   ` Franco "Sensei"
2005-04-14 19:55                     ` Arjan van de Ven
2005-04-14 22:33                       ` Franco "Sensei"
2005-04-14 23:29                     ` Al Viro
     [not found]                       ` <425F33C2.8020301@tin.it>
2005-04-15  5:02                         ` Al Viro
2005-04-14 20:01                 ` Adrian Bunk
2005-04-14 22:51                   ` Franco "Sensei"
2005-04-14 20:34                 ` Horst von Brand
2005-04-14 22:45                   ` Franco "Sensei"
2005-04-12 22:04             ` Krzysztof Halasa
2005-04-14 17:04               ` Franco "Sensei"
2005-04-12 22:43             ` Adrian Bunk
2005-04-14 17:40               ` Franco "Sensei"
2005-04-14 20:15                 ` Adrian Bunk
2005-04-14 22:26                   ` Franco "Sensei"
     [not found] <3R6fp-7Qs-15@gated-at.bofh.it>
     [not found] ` <3R71T-4S-15@gated-at.bofh.it>
     [not found]   ` <3Si4Q-Nh-21@gated-at.bofh.it>
     [not found]     ` <3SiRe-1eq-9@gated-at.bofh.it>
     [not found]       ` <3SjNh-1Yq-3@gated-at.bofh.it>
     [not found]         ` <3Ss48-qG-1@gated-at.bofh.it>
     [not found]           ` <3SxGA-5mR-29@gated-at.bofh.it>
2005-04-12 21:52             ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>

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=20050412015018.GA3828@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=senseiwa@tin.it \
    /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