public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Franco \"Sensei\"" <senseiwa@tin.it>
To: Adrian Bunk <bunk@stusta.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel strict versioning
Date: Mon, 11 Apr 2005 20:02:55 -0500	[thread overview]
Message-ID: <425B1E3F.5080202@tin.it> (raw)
In-Reply-To: <20050408190500.GF15688@stusta.de>

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

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 
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.

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 
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.

I find it an interesting point anyway. I know there would never be, as 
you said, but I don't find the document you've pointed me to, really 
convincing. Still have doubts...

-- 
Sensei <mailto:senseiwa@tin.it> <pgp:8998A2DB>
        <icqnum:241572242>
        <yahoo!:sensei_sen>
        <msn-id:sensei_sen@hotmail.com>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2005-04-12  1:04 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" [this message]
2005-04-12  1:50     ` Adrian Bunk
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=425B1E3F.5080202@tin.it \
    --to=senseiwa@tin.it \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    /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