On Thu, Apr 14, 2005 at 10:23:46PM -0500, Franco Sensei wrote:
> Al Viro wrote:
> >Elegant. Very elegant. Admirable exercise in misdirection - the word
> >"third-party" used to conflate all things non-kernel with 3rd party
> >kernel modifications. Followed by appeals to civic obligations, no
On Thu, Apr 14, 2005 at 02:41:44PM -0500, Franco Sensei wrote:
> The global feeling about kernel is that it seems that you don't care
> about the purpose of your task, which of course is not the kernel by
> itself. It can't be. It's about what it does (and already does it well),
> and what it
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
"Franco \"Sensei\"" <[EMAIL PROTECTED]> said:
> 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
On Thu, Apr 14, 2005 at 12:40:09PM -0500, Franco Sensei wrote:
> 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
On Thu, Apr 14, 2005 at 11:52:50AM -0500, Franco Sensei wrote:
>...
> An advantage is the total freedom about the code. Ok, I know. But as
> long as the kernel grows, in size and in its use, something more should
> be considered. ABI is a step forward companies and people like me in
> handling
> I'd like API stability, if API stability is
> achieved, ABI is there.
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.
Trust me. It's *extremely* hard to impossible. Several security
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
On Thu, 14 Apr 2005, Franco "Sensei" wrote:
Date: Thu, 14 Apr 2005 11:52:50 -0500
From: Franco "Sensei" <[EMAIL PROTECTED]>
To: David Lang <[EMAIL PROTECTED]>
Cc: Krzysztof Halasa <[EMAIL PROTECTED]>, Adrian Bunk <[EMAIL PROTECTED]>,
linux-kerne
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.
On Thu, 14 Apr 2005, Franco Sensei wrote:
Date: Thu, 14 Apr 2005 11:52:50 -0500
From: Franco Sensei [EMAIL PROTECTED]
To: David Lang [EMAIL PROTECTED]
Cc: Krzysztof Halasa [EMAIL PROTECTED], Adrian Bunk [EMAIL PROTECTED],
linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel strict
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
I'd like API stability, if API stability is
achieved, ABI is there.
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.
Trust me. It's *extremely* hard to impossible. Several security fixes
On Thu, Apr 14, 2005 at 11:52:50AM -0500, Franco Sensei wrote:
...
An advantage is the total freedom about the code. Ok, I know. But as
long as the kernel grows, in size and in its use, something more should
be considered. ABI is a step forward companies and people like me in
handling linux
On Thu, Apr 14, 2005 at 12:40:09PM -0500, Franco Sensei wrote:
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
Franco \Sensei\ [EMAIL PROTECTED] said:
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.
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
On Thu, Apr 14, 2005 at 02:41:44PM -0500, Franco Sensei wrote:
The global feeling about kernel is that it seems that you don't care
about the purpose of your task, which of course is not the kernel by
itself. It can't be. It's about what it does (and already does it well),
and what it
On Thu, Apr 14, 2005 at 10:23:46PM -0500, Franco Sensei wrote:
Al Viro wrote:
Elegant. Very elegant. Admirable exercise in misdirection - the word
third-party used to conflate all things non-kernel with 3rd party
kernel modifications. Followed by appeals to civic obligations, no less.
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.
>
>
"Franco \"Sensei\"" <[EMAIL PROTECTED]> writes:
> 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?
Yes, but you still can't change .config. You
Franco "Sensei" <[EMAIL PROTECTED]> 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
On Tue, 12 Apr 2005, Franco "Sensei" wrote:
Date: Tue, 12 Apr 2005 12:22:30 -0500
From: Franco "Sensei" <[EMAIL PROTECTED]>
To: Krzysztof Halasa <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel st
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
"Franco \"Sensei\"" <[EMAIL PROTECTED]> writes:
> Major kernel changes should probably result in major version
> change... I'm supposing it. Of course, note that ABI can be achieved
> stating that all the binaries must be compiled with the same gcc.
It isn't enough. The same compiler and the
Franco \Sensei\ [EMAIL PROTECTED] writes:
Major kernel changes should probably result in major version
change... I'm supposing it. Of course, note that ABI can be achieved
stating that all the binaries must be compiled with the same gcc.
It isn't enough. The same compiler and the same .config
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
On Tue, 12 Apr 2005, Franco Sensei wrote:
Date: Tue, 12 Apr 2005 12:22:30 -0500
From: Franco Sensei [EMAIL PROTECTED]
To: Krzysztof Halasa [EMAIL PROTECTED]
Cc: Adrian Bunk [EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject: Re: [INFO] Kernel strict versioning
Krzysztof Halasa wrote:
It isn't
Franco Sensei [EMAIL PROTECTED] 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.
Franco \Sensei\ [EMAIL PROTECTED] writes:
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?
Yes, but you still can't change .config. You enable SMP,
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
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 .
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
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
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
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 .
On Fri, Apr 08, 2005 at 01:08:28PM -0500, Franco Sensei wrote:
>...
> Actually changing a kernel results in creating a /lib/modules/version
> directory, creating a heavy confusion for a user, especially when
> compiling other modules outside the official kernel release: he juts
> looses 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
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
On Fri, Apr 08, 2005 at 01:08:28PM -0500, Franco Sensei wrote:
...
Actually changing a kernel results in creating a /lib/modules/version
directory, creating a heavy confusion for a user, especially when
compiling other modules outside the official kernel release: he juts
looses the modules
52 matches
Mail list logo
