lkml.org 
[lkml]   [2005]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [INFO] Kernel strict versioning
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-13 01:00    [from the cache]
©2003-2011 Jasper Spaans