Adrian Bunk wrote:
Are you sure you know what you are talking about?
ABI stability requires API stability [1].
Of course it requires API stability... as I said ``API and data
structure stability should be something in mind''. I really meant that
API shouldn't change suddenly. And from the moment
Horst von Brand wrote:
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
Nope.
I don't understand. The .config drives the kernel build, I don't get XFS
functions and names if I don't compile it. I have different symbol
names... At
Arjan van de Ven wrote:
this is a joke right? If you really think this you have no idea what ABI
stability means and how extremely hard it is to even sort of remotely
approach it.
I know it's really hard, the only way of possibly having ABI is plannig
things really carefully about every single
Adrian Bunk wrote:
Linux kernel development is working different.
Getting changes quickly to the users is considered more important than
API or even ABI compatibility.
I don't agree about API, but that's how it goes :) APIs are too
important to bring them down from my point of view.
Offering
David Lang wrote:
there are at least a half dozen options besides SMP that have similar
effects.
And of course if I take care of making them consistent... What I'd like
is stability. Not in the sense of having a rock-stable kernel, that of
course is already there. I'd like API stability, if API
Adrian Bunk wrote:
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.
Krzysztof Halasa wrote:
Yes, but you still can't change .config. You enable SMP, your binary
compatibility is history. You _have_to_ be able to enable SMP and
_you_have_ to be able to disable it.
The following kernel packages are parts of Fedora Core 3:
kernel-2.6.9-1.667.i586.rpm
David Lang wrote:
some config changes are additions, some redefine things.
you are mistakeing the .config file for a symbol table.
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
for example if you compile a kernel with SMP=y you get
David Lang wrote:
some config changes are additions, some redefine things.
you are mistakeing the .config file for a symbol table.
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
for example if you compile a kernel with SMP=y you get
Krzysztof Halasa wrote:
Yes, but you still can't change .config. You enable SMP, your binary
compatibility is history. You _have_to_ be able to enable SMP and
_you_have_ to be able to disable it.
The following kernel packages are parts of Fedora Core 3:
kernel-2.6.9-1.667.i586.rpm
Adrian Bunk wrote:
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.
David Lang wrote:
there are at least a half dozen options besides SMP that have similar
effects.
And of course if I take care of making them consistent... What I'd like
is stability. Not in the sense of having a rock-stable kernel, that of
course is already there. I'd like API stability, if API
Adrian Bunk wrote:
Linux kernel development is working different.
Getting changes quickly to the users is considered more important than
API or even ABI compatibility.
I don't agree about API, but that's how it goes :) APIs are too
important to bring them down from my point of view.
Offering
Arjan van de Ven wrote:
this is a joke right? If you really think this you have no idea what ABI
stability means and how extremely hard it is to even sort of remotely
approach it.
I know it's really hard, the only way of possibly having ABI is plannig
things really carefully about every single
Horst von Brand wrote:
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
Nope.
I don't understand. The .config drives the kernel build, I don't get XFS
functions and names if I don't compile it. I have different symbol
names... At
Adrian Bunk wrote:
Are you sure you know what you are talking about?
ABI stability requires API stability [1].
Of course it requires API stability... as I said ``API and data
structure stability should be something in mind''. I really meant that
API shouldn't change suddenly. And from the moment
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
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
Adrian Bunk wrote:
You say API but talk about ABI.
As long as we want to guarantee abi, we must use the same names. Api
names, not implementation should be the same. You can't substitute
get_namei with get_my_own_namei_version_I_know...
You said you've read stable_api_nonsense.txt .
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
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
Adrian Bunk wrote:
You say API but talk about ABI.
As long as we want to guarantee abi, we must use the same names. Api
names, not implementation should be the same. You can't substitute
get_namei with get_my_own_namei_version_I_know...
You said you've read stable_api_nonsense.txt .
Hi. I'm new in the list... please excuse me, I'm probably naive.
I'm using linux from 1997, and now I'm wondering why the kernel
versioning system has been so strict. I've been following the thread
``RFD: Kernel release numbering'', but still I have some concerns...
Earlier versions used the
Hi. I'm new in the list... please excuse me, I'm probably naive.
I'm using linux from 1997, and now I'm wondering why the kernel
versioning system has been so strict. I've been following the thread
``RFD: Kernel release numbering'', but still I have some concerns...
Earlier versions used the
24 matches
Mail list logo
