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 les
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 pr
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 least
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 thi
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 imp
"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 symbol
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 remai
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 l
> 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 fixe
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
kernel-2.6.9-1.66
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 d
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
"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 ena
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 i
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 new
"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
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 .
stable_api_n
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 r
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 modu
25 matches
Mail list logo
