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: Krzysztof Halasa <khc@pm.waw.pl>, linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel strict versioning
Date: Wed, 13 Apr 2005 00:43:57 +0200	[thread overview]
Message-ID: <20050412224357.GE3631@stusta.de> (raw)
In-Reply-To: <425C03D6.2070107@tin.it>

On Tue, Apr 12, 2005 at 12:22:30PM -0500, Franco Sensei wrote:
> Krzysztof Halasa wrote:
> >It isn't enough. The same compiler and the same .config - yes. But that
> >means you'd have no progress within, say, 2.6. Only bug fixes.
> >There _is_ a tree like that - 2.6.11.Xs are only bugfixes.
> 
> Ok, this adds a new information. Let me explain what I understand now.
> 
> When a new component is added to the kernel, let's say support for a new 
> file system, a .config entry is created (CONFIG_MYFS=y|m). Why is this 
> entry breaking compatibility? I mean, symbols still remains the same. 
> The addition of symbols is not a breaking point.

That's clear.

You said you've read Documentation/stable_api_nonsense.txt .
Please read the USB example in this document as an example when even API 
compatibility was a problem.

> >But remember that changing a single config option may make your kernel
> >incompatible. You can't avoid that without making the kernel suboptimal
> >for most situations - basically you'd have to disable non-SMP builds,
> >disable (or permanently enable) 4KB pages etc.
> 
> What about making extensive use of modules? If everything (acceptable) 
> is built on modules, can you still have abi, can you still change 
> modules and api implementation without breaking anything? What are the 
> requisites to abi?
>...

If you upgrade your kernel, you'll also upgrade the modules shipped with 
the kernel.

-> it doesn't matter whether the code shipped with the kernel is 
   compiled static or modular

> >If you make a proprietary closed-sourse system (with kernel modules), you
> >probably have to make the system suboptimal. But with open source there
> >is a better alternative.
> 
> No, I wouldn't. Closed source is out of discussion. Optimal kernel, even 
> in open source can be achieved.
>...

What's an "optimal kernel"?

In a closed-sourse system, there's usually the OS plus API+ABI for 
driver writers and the drivers are often shipped with the hardware.
Therefore API+ABI compatibility is required.

In an open source system, it's usually more common that all drivers are 
shipped with the kernel. Therefore, there isn't such a big need for 
API+ABI compatibility since you can change all modules using an API when 
changing an API. And ABI compatibility isn't required because you can 
recompile the modules every time you recompile the kernel.

ABI compatibility between kernel versions costs the following:
- space for all users of the kernel
- speed of the kernel
- much extra work and checking when doing any changes

Nobody claims API+ABI compatibility was technically impossible in the 
Linux kernel. It's simply a consensus among the kernel developers that 
the small advantages of ABI compatibility are not worth the costs.

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


  parent reply	other threads:[~2005-04-12 22: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
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 [this message]
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=20050412224357.GE3631@stusta.de \
    --to=bunk@stusta.de \
    --cc=khc@pm.waw.pl \
    --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