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 odd/even numbering, unstable/stable
versioning. That was quite good from a user's point of view, since it
carried significant meaning immediately.
The fact that we face a multilevel versioning number, say
2.6.11-14.4.whatever-2 is quite a pain. I'm saying not that it's a bad
idea that a product has more versions, my product follow the even/odd
and subversion numbering. I'm saying that the scripts used in the kernel
building should be quite smarter.
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 and has to recompile them.
I was wondering about the feasibility of handling just a MAJOR.MINOR
versioning. This would be quite an increment for a user to mantain his
kernel. Modules can still be loaded and found. We would have a single
/lib/modules/2.6 being much compatible with other modules, working with
2.6.x and 2.6.y without any difficulty. Also the source tree from a
user's point of view is much cleaner, identifying the ongoing kernel
much easily.
I'm not talking about the developing process, which still uses 2.6.x,
and it's good as it identifies the current subversion, but there's no
use in collecting so many other kernels when considering them ``stable''.
I'm just wondering...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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 and has to recompile them.
>
> I was wondering about the feasibility of handling just a MAJOR.MINOR
> versioning. This would be quite an increment for a user to mantain his
> kernel. Modules can still be loaded and found. We would have a single
> /lib/modules/2.6 being much compatible with other modules, working with
> 2.6.x and 2.6.y without any difficulty. Also the source tree from a
> user's point of view is much cleaner, identifying the ongoing kernel
> much easily.
>...
This has nothing to do with versioning.
You are asking for ABI compatibility between different kernel versions.
There is no stable ABI between different kernel versions and there will
never be one. Please read Documentation/stable_api_nonsense.txt for
details.
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
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 read Documentation/stable_api_nonsense.txt for
> details.
I've read it.
Assuming the fact that a kernel can be considered stable, my point of
view implies an assumption: kernel and modules are distributed by a
distro, and compiled with the same gcc. Of course, I'm not talking about
different architectures and so on, since I'm talking about something
different, I'm talking about the api involved in the developement.
Distributions have to use a great care about compiler changes, and it's
not kernel developers' problem.
A kernel stable 2.X version should not differ much in the
subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be
possibly avoided by using a release versioning different from the one
used now. Structues and exported functions should be almost the same,
the implementation should be, and of course, must be different: bugs,
improvements and so on.
I see the point about continuous developement, that's why I'm using
linux since 97, but I find interesting also the design of a stable
infrastructure, that can be achieved. A data structure no longer in use
by anyone, functions being unused for a long time, can be made harmless.
Providing a binary compatibility makes recompiling all external modules
(external to the official kernel I mean) not necessary, making life
easier for any other person using linux (e.g. pwc module for my logitech
pro 4000 webcam, every new kernel, new module compilation. Stability
makes in this sense a real big improvement. An example of this care can
be found in trolltech qt library. I use them since 1.x and it's a really
good thing assuring the binary compatibility... of course they just
screw it some day to day :) Everybody can be wrong.
I find it an interesting point anyway. I know there would never be, as
you said, but I don't find the document you've pointed me to, really
convincing. Still have doubts...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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 ABI between different kernel versions and there will
> >never be one. Please read Documentation/stable_api_nonsense.txt for
> >details.
>
> I've read it.
>
> Assuming the fact that a kernel can be considered stable, my point of
> view implies an assumption: kernel and modules are distributed by a
> distro, and compiled with the same gcc. Of course, I'm not talking about
> different architectures and so on, since I'm talking about something
> different, I'm talking about the api involved in the developement.
> Distributions have to use a great care about compiler changes, and it's
> not kernel developers' problem.
>
> A kernel stable 2.X version should not differ much in the
> subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be
You say API but talk about ABI.
> possibly avoided by using a release versioning different from the one
> used now. Structues and exported functions should be almost the same,
> the implementation should be, and of course, must be different: bugs,
> improvements and so on.
You said you've read stable_api_nonsense.txt .
stable_api_nonsense.txt talks about exactly these issues.
> I see the point about continuous developement, that's why I'm using
> linux since 97, but I find interesting also the design of a stable
> infrastructure, that can be achieved. A data structure no longer in use
> by anyone, functions being unused for a long time, can be made harmless.
> Providing a binary compatibility makes recompiling all external modules
> (external to the official kernel I mean) not necessary, making life
> easier for any other person using linux (e.g. pwc module for my logitech
> pro 4000 webcam, every new kernel, new module compilation. Stability
> makes in this sense a real big improvement. An example of this care can
The right solution for this issue is simple:
Get the module into the kernel.
Not that e.g. your pwc module will be in kernel 2.6.12.
> be found in trolltech qt library. I use them since 1.x and it's a really
> good thing assuring the binary compatibility... of course they just
> screw it some day to day :) Everybody can be wrong.
>...
Please check the facts:
QT 1 is _not_ binary compatible with QT 3.
There's a reason why the library changed the so-name...
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
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_nonsense.txt talks about exactly these issues.
Yes.
> The right solution for this issue is simple:
>
> Get the module into the kernel.
>
> Not that e.g. your pwc module will be in kernel 2.6.12.
Of course not... I don't expect nobody doing that! :)
> Please check the facts:
>
> QT 1 is _not_ binary compatible with QT 3.
>
> There's a reason why the library changed the so-name...
Yes! That's my point. I didn't mean to say that the library has the same
classes as the first version. Qt 3 is *not* compatible with Qt 1. Qt
3.3.0 is binary compatible with qt 3.3.1, 3.3.2, and so on... unless
someone makes an error.
My point is that versioning should be, in come cases, less restrictive,
letting the 2.4 kernel being not compatible with 2.6, but all 2.6.x
series being binary compatible with each other. If versioning means
something, the last number should be a revision, additions, but since
they belong to 2.6 version, they would be compatible.
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. So, the kernel
module library could possibly be simply /lib/modules/2.6/.
I'm probably (surely) not getting the point about this issue. It's not
that bad... I don't see awkward issues in guaranteeing 2.6, 2.8 and so
on compatibility with the ``major second number''.
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
"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 - 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.
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.
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.
> So,
> the kernel module library could possibly be simply /lib/modules/2.6/.
Asking for one modules dir only is similar to asking for only one
/boot/vmlinuz-2.6 kernel file.
> I'm probably (surely) not getting the point about this issue. It's not
> that bad... I don't see awkward issues in guaranteeing 2.6, 2.8 and so
> on compatibility with the ``major second number''.
First, each 2.6.X would have to be binary-compatible with itself.
--
Krzysztof Halasa
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.
> 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?
I'm really curious about it. How abi can be made actual, and how would
it be if we had a completely modular kernel (not micro, but something
alike, modular in kernel-space, not in user-space).
> 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.
> Asking for one modules dir only is similar to asking for only one
> /boot/vmlinuz-2.6 kernel file.
Quite the same, yes. You can still have different kernels of course! By
the way, another stupid curiosity is why /lib/modules instead of /boot?
Because boot can be a partition and not be mounted? The same thing for
/lib (crazy, but you can do it). I would expect a kernel and all its
parts all in one place, not different locations...
> First, each 2.6.X would have to be binary-compatible with itself.
That's the only point for me. I wouldn't make 2.6 and 2.8 kernels binary
compatibles.
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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]>, [email protected]
> Subject: Re: [INFO] Kernel strict versioning
>
> 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.
some config changes are additions, some redefine things.
you are mistakeing the .config file for a symbol table.
for example if you compile a kernel with SMP=y you get different code then
if you compile with SMP=n
if you have the same kernel version on identical machines, but with the
SMP option different on the two different machines you cannot use the same
module binary on both of them.
>> 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?
you would have an ABI for that kernel image, compiled with those options,
and with that compiler. if you change any of those things then your
modules won't work (you have a different ABI
> I'm really curious about it. How abi can be made actual, and how would it be
> if we had a completely modular kernel (not micro, but something alike,
> modular in kernel-space, not in user-space).
what you are missing is that nobody has any interest in supporting a
kernel ABI, even within a single kernel version. there are just too many
advantages to changeing fundamantal things in the kernel depending on the
config options.
>> 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.
>
>> Asking for one modules dir only is similar to asking for only one
>> /boot/vmlinuz-2.6 kernel file.
>
> Quite the same, yes. You can still have different kernels of course! By the
> way, another stupid curiosity is why /lib/modules instead of /boot? Because
> boot can be a partition and not be mounted? The same thing for /lib (crazy,
> but you can do it). I would expect a kernel and all its parts all in one
> place, not different locations...
I don't know why the default location for the modules, but again you are
assuming that you CAN have a single vmlinuz-2.6 kernel file for all
machines of a given arch.
you can't.
there are just too many config options that change the internals of the
kernel (locking, function call formats, CPU type optmizations, etc) for
you to just have one.
>> First, each 2.6.X would have to be binary-compatible with itself.
>
> That's the only point for me. I wouldn't make 2.6 and 2.8 kernels binary
> compatibles.
but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let alone
something drasticly different (say 2.6.11.6)
David Lang
> --
> Sensei <mailto:[email protected]> <pgp:8998A2DB>
> <icqnum:241572242>
> <yahoo!:sensei_sen>
> <msn-id:[email protected]>
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
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. 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.
A kernel feature may require a different (bigger, slower, ...) internal data
structure, which isn't desired unless you use that feature. Or it will
change the semantics of some functions, e.g. functions being a noop (and
optimized away) for uniprocessor with no highmem will do some important
task on a SMP machine with 4 GB.
>> Asking for one modules dir only is similar to asking for only one
>> /boot/vmlinuz-2.6 kernel file.
>
> Quite the same, yes. You can still have different kernels of course! By
> the way, another stupid curiosity is why /lib/modules instead of /boot?
Boot vs. bootloader. The same reason that allows lilo.conf to be in /etc
See http://www.pathname.com/fhs/ , too
--
Top 100 things you don't want the sysadmin to say:
81. The drive ate the tape but that's OK, I brought my screwdriver.
Fri?, Spammer: [email protected] [email protected]
"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, 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.667.i686.rpm
kernel-smp-2.6.9-1.667.i586.rpm
kernel-smp-2.6.9-1.667.i686.rpm
4 of them, each with a different ABI. And this is all the same kernel
major-minor-version-subversion and the same compiler - only the settings
differ.
> I'm really curious about it. How abi can be made actual, and how would
> it be if we had a completely modular kernel (not micro, but something
> alike, modular in kernel-space, not in user-space).
Being modular has nothing to do with the "problem" (except it's probably
required, but Linux _is_ modular for some time now).
> Quite the same, yes. You can still have different kernels of course!
Not "can". You have to. You don't want the kernel running on your dual
Athlon MP to power your old Pentium MMX test machine. The modules are
irrelevant.
> By the way, another stupid curiosity is why /lib/modules instead of
> /boot?
You can have it in /boot. In fact, it's not a kernel issue.
> Because boot can be a partition and not be mounted?
Actually, because boot can be a small partition, and may lack support
for, say, long filenames.
Actually, I put the kernels in /lib/modules/* as well. I have no /boot
file systems and I like the idea of rm -rf /lib/modules/something
deleting all files related to a particular kernel.
--
Krzysztof Halasa
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
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 different code
> then if you compile with SMP=n
>
> if you have the same kernel version on identical machines, but with the
> SMP option different on the two different machines you cannot use the
> same module binary on both of them.
Of course, but It's cleare that machines with SMP are different from a
simple mono-cpu.
It's not an issue talking about smp vs. not-smp. Let's talk about a
machine: it's useless arguing about Cray while I'm talking about a
simple environment.
Every kernel has always the distinction about smp. So it's not a big
problem.
> you would have an ABI for that kernel image, compiled with those
> options, and with that compiler. if you change any of those things then
> your modules won't work (you have a different ABI
Of course, as I stated, it's a distro's care to use the same gcc and
same switches....
> what you are missing is that nobody has any interest in supporting a
> kernel ABI, even within a single kernel version. there are just too many
> advantages to changeing fundamantal things in the kernel depending on
> the config options.
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 easily. API and data structure stability should be
something in mind, since breaking compatibility from 2.6.8 to 2.6.8.1
causes big troubles to anyone who's mantaining many machines. And if you
are in big environments, you probably use modules which are not in
vanilla, and will never be, like OpenAFS.
Finding a bug in the kernel source and patching it, must be a careful
step, because if I have to mantain 100 machines, and I know that
applying the patch will result in a broken kernel modules, I'm not happy
with it. I must go manually on each machine, apply the patch, recompile
the modules... Makes me think about NOT applying the patch.
> I don't know why the default location for the modules, but again you are
> assuming that you CAN have a single vmlinuz-2.6 kernel file for all
> machines of a given arch.
>
> you can't.
I think we can. Freedom in developing source code is not necessarily
stealing bricks from someone's feet :)
> there are just too many config options that change the internals of the
> kernel (locking, function call formats, CPU type optmizations, etc) for
> you to just have one.
Source compatibility is there. Now, you're talking about issues which
are not your buisness: a binary distribution must take care of how the
kernel it's compiled. As long as it uses the same gcc and switches, it's ok.
Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows
how they're compiled, and they work everywhere. Of course, it has also
kernel-2.6.A-SMP and its modules.
When 2.6.B is released, using ABI will just result in another
compilation, creating the kernel with additions and patches, and
distributing them. Modules .A should work on .B, like I do with OpenAFS,
Every kernel update shouldn't break the magic :)
> but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let
> alone something drasticly different (say 2.6.11.6)
Sure, because it's not designed to be so.
I just see advantages on ABI, and I think it's not bad talking about it...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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.667.i686.rpm
> kernel-smp-2.6.9-1.667.i586.rpm
> kernel-smp-2.6.9-1.667.i686.rpm
That's because SMP makes a different architecture. So, let's not talk
about SMP, beacuse it's not a problem.
> 4 of them, each with a different ABI. And this is all the same kernel
> major-minor-version-subversion and the same compiler - only the settings
> differ.
Of course. When upgrading to kernel-2.6.10.i586.rpm? Why should you
screw up the modules you've compiled? They all belong to 2.6 series.
> Being modular has nothing to do with the "problem" (except it's probably
> required, but Linux _is_ modular for some time now).
It gives more freedom to change the implementation resulting in a easy
mantainance. Modularity make things easy... little things that work,
isn't it a unix motto? :)
> Not "can". You have to. You don't want the kernel running on your dual
> Athlon MP to power your old Pentium MMX test machine. The modules are
> irrelevant.
Why always SMP! You are talking about porting a SPARC kernel on a 386!
I'm talking about having the same binary kernel distribution for your
achitecture, let's say i586, and being able to upgrade the kernel
without hassles. No person on earth can imagine using a kernel for
x86_64 on a i486! :)
> You can have it in /boot. In fact, it's not a kernel issue.
I know, I was just wondering why kernel and modules were on different
locations.
> Actually, because boot can be a small partition, and may lack support
> for, say, long filenames.
> Actually, I put the kernels in /lib/modules/* as well. I have no /boot
> file systems and I like the idea of rm -rf /lib/modules/something
> deleting all files related to a particular kernel.
I always use a /boot partition. Anyway, /boot will always exist as /lib,
and you can always do a rm -rf /boot/kernel/modules :)
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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.
>
> 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.
The example says that the usb layer changed from synchronous to
asynchronous and changed the data model. I'd say changing drastically is
a big issue. I'd say it would be a change from 2.4 to 2.6 series. It
does not mean that in a year we have to stick with the same version, in
a year things can change drastically and so should be the version.
I see one big thing: developement should be careful about who uses the
kernel and not caring about it alone, since it's not something useful by
itself :)
> If you upgrade your kernel, you'll also upgrade the modules shipped with
> the kernel.
Yes! You said it yourself: shipped with the kernel. The world does not
rely only on the kernel. I have to administer a department, and I use
other modules that won't be in the kernel, such as afs.
> -> it doesn't matter whether the code shipped with the kernel is
> compiled static or modular
Static fills the memory, modular is better :) If I don't use a module,
that should be unloaded from the memory automatically. Modular things
makes them less complex to mantain if properly designed.
> What's an "optimal kernel"?
I don't know... in the thread someone said sub-optimal. Probably he
referred to a kernel with lots of useless things, while I can compile
only the things I need (optimal).
> 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.
Not only in closed-source.
> 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.
That's not entirely true. Kernel does not have all the modules someone
can use, and I made an example with my own department. The kernel should
make the machine work, providing means to operate the hardware. So, in
no case one can imagine having every single driver on this earth built
in the kernel...
> ABI compatibility between kernel versions costs the following:
> - space for all users of the kernel
I don't understand. Space of what?
> - speed of the kernel
Mmh... why should it be? Optimizing the kernel is possible, speeding it
up, without affecting ABI. Adding new components can't affect speed as
long as it won't affect it wihout ABI (adding parts does of course
affect the speed, but it's not different from ABI to non-ABI).
> - much extra work and checking when doing any changes
Of course! You're developing a kernel to be used by other people! It's
quite... straightforward to be really careful about 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.
I don't know. As linux spreads, things should be simply changing.
Carefulness, API stability and of course ABI helps in that sense. Kernel
by itself is just useless. A kernel with other layers is an os. The core
of an OS should have special care.
If IDE driver is completely rewritten breaking my ability to use all the
other modules, it's a shame... nothing I had made (modules) will work,
and I know. If cdrecord is completely rewritten, I don't care, as long
as it works.
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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]>,
> [email protected]
> Subject: Re: [INFO] Kernel strict versioning
>
> 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 different code then
>> if you compile with SMP=n
>>
>> if you have the same kernel version on identical machines, but with the SMP
>> option different on the two different machines you cannot use the same
>> module binary on both of them.
>
> Of course, but It's cleare that machines with SMP are different from a simple
> mono-cpu.
>
> It's not an issue talking about smp vs. not-smp. Let's talk about a machine:
> it's useless arguing about Cray while I'm talking about a simple environment.
>
> Every kernel has always the distinction about smp. So it's not a big problem.
there are at least a half dozen options besides SMP that have similar
effects.
>> you would have an ABI for that kernel image, compiled with those options,
>> and with that compiler. if you change any of those things then your modules
>> won't work (you have a different ABI
>
> Of course, as I stated, it's a distro's care to use the same gcc and same
> switches....
Ok, now you are talking a distro, not linux itself. different subject,
belongs on different lists (and by the way distros already tend to do this
type of thing)
>> what you are missing is that nobody has any interest in supporting a kernel
>> ABI, even within a single kernel version. there are just too many
>> advantages to changeing fundamantal things in the kernel depending on the
>> config options.
>
> 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 easily. API and data structure stability should be something in mind,
> since breaking compatibility from 2.6.8 to 2.6.8.1 causes big troubles to
> anyone who's mantaining many machines. And if you are in big environments,
> you probably use modules which are not in vanilla, and will never be, like
> OpenAFS.
>
> Finding a bug in the kernel source and patching it, must be a careful step,
> because if I have to mantain 100 machines, and I know that applying the patch
> will result in a broken kernel modules, I'm not happy with it. I must go
> manually on each machine, apply the patch, recompile the modules... Makes me
> think about NOT applying the patch.
first off, if you can deploy a new kernel across 100 machines you can
deploy new modules along with it.
second, if you are applying the patch and know that it doesn't affect
anything that the modules use you don't have to recompile the modules, but
if you want to be safe becouse you don't know what the patch affects then
you replace the modules as well (for all you know the patch affects just a
module, not the base kernel.
>> I don't know why the default location for the modules, but again you are
>> assuming that you CAN have a single vmlinuz-2.6 kernel file for all
>> machines of a given arch.
>>
>> you can't.
>
> I think we can. Freedom in developing source code is not necessarily stealing
> bricks from someone's feet :)
>
>> there are just too many config options that change the internals of the
>> kernel (locking, function call formats, CPU type optmizations, etc) for you
>> to just have one.
>
> Source compatibility is there. Now, you're talking about issues which are not
> your buisness: a binary distribution must take care of how the kernel it's
> compiled. As long as it uses the same gcc and switches, it's ok.
>
> Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows how
> they're compiled, and they work everywhere. Of course, it has also
> kernel-2.6.A-SMP and its modules.
>
> When 2.6.B is released, using ABI will just result in another compilation,
> creating the kernel with additions and patches, and distributing them.
> Modules .A should work on .B, like I do with OpenAFS, Every kernel update
> shouldn't break the magic :)
again you are talking about what a distro chooses to do, go ahead and do
this if you want, but it has no relevance to the kernel mailing list.
This will be my last message on this subject, hopefully you will let this
die or take the conversation to the mailing lists of the distros that you
choose to use.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
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 stability is
achieved, ABI is there.
> Ok, now you are talking a distro, not linux itself. different subject,
> belongs on different lists (and by the way distros already tend to do
> this type of thing)
No. I have compiled everything from scratch, every single package. Now,
every vanilla kernel brings the problem of recompiling modules for that
particular version.
> first off, if you can deploy a new kernel across 100 machines you can
> deploy new modules along with it.
>
> second, if you are applying the patch and know that it doesn't affect
> anything that the modules use you don't have to recompile the modules,
> but if you want to be safe becouse you don't know what the patch affects
> then you replace the modules as well (for all you know the patch affects
> just a module, not the base kernel.
Applying a patch to 2.6.11 making it 2.6.12 brings one thing: all
modules external to the vanilla kernel are no longer there and I have to
recompile them every time...
> again you are talking about what a distro chooses to do, go ahead and do
> this if you want, but it has no relevance to the kernel mailing list.
>
> This will be my last message on this subject, hopefully you will let
> this die or take the conversation to the mailing lists of the distros
> that you choose to use.
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 provides to third-parties: the kernel and the API given to
the outside world, since the kernel is not alone... and will never be of
course! ;)
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
> 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
can only be fixed this way. And it's REALLY fragile even if for other
fixes. And I am very glad that the linux kernel people in general decide
to not go for abi stability, the hacks that would be needed would be so
obscene and the gains very very minimal. (it's open source, you have the
source after all!)
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 easily. API and data structure stability should be
> something in mind, since breaking compatibility from 2.6.8 to 2.6.8.1
> causes big troubles to anyone who's mantaining many machines. And if you
>...
Are you sure you know what you are talking about?
ABI stability requires API stability [1].
cu
Adrian
[1] you can break the API without breaking the ABI, but these are
mostly pathological examples
--
"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
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 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.
>
> The example says that the usb layer changed from synchronous to
> asynchronous and changed the data model. I'd say changing drastically is
> a big issue. I'd say it would be a change from 2.4 to 2.6 series. It
> does not mean that in a year we have to stick with the same version, in
> a year things can change drastically and so should be the version.
Linux kernel development is working different.
Getting changes quickly to the users is considered more important than
API or even ABI compatibility.
> I see one big thing: developement should be careful about who uses the
> kernel and not caring about it alone, since it's not something useful by
> itself :)
Offering improvements and new drivers to the users quickly is one way to
care about the users.
I do not claim to agree with all details of kernel development - but
that's how it works.
> >If you upgrade your kernel, you'll also upgrade the modules shipped with
> >the kernel.
>
> Yes! You said it yourself: shipped with the kernel. The world does not
> rely only on the kernel. I have to administer a department, and I use
> other modules that won't be in the kernel, such as afs.
If you upgrade the kernel, simply get a version of your external modules
that support your new kernel, compile them against the new kernel, and
ship the external modules as part of the rollout of the new kernel.
>...
> >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.
>
> That's not entirely true. Kernel does not have all the modules someone
> can use, and I made an example with my own department. The kernel should
> make the machine work, providing means to operate the hardware. So, in
> no case one can imagine having every single driver on this earth built
> in the kernel...
Kernel development is based on the fact that all drivers should be
shipped with the kernel.
If you buy hardware where no open source driver exists (often because
the hardware manufacturer doesn't publish the hardware specifications)
that's your problem.
> >ABI compatibility between kernel versions costs the following:
> >- space for all users of the kernel
>
> I don't understand. Space of what?
Space for the code behind all the obsolete interfaces.
> >- speed of the kernel
>
> Mmh... why should it be? Optimizing the kernel is possible, speeding it
> up, without affecting ABI. Adding new components can't affect speed as
> long as it won't affect it wihout ABI (adding parts does of course
> affect the speed, but it's not different from ABI to non-ABI).
There are optimizations that are not possible without breaking
compatibility.
Documentation/stable_api_nonsense.txt contains examples.
> >- much extra work and checking when doing any changes
>
> Of course! You're developing a kernel to be used by other people! It's
> quite... straightforward to be really careful about changes.
>...
You can't care about everything.
What you propose has both advantages and disadvantages for users of the
kernel. It's general consensus among the kernel developers that the
advantages are not worth the disadvantages.
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
"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.
Nope.
> > for example if you compile a kernel with SMP=y you get different code
> > then if you compile with SMP=n
> >
> > if you have the same kernel version on identical machines, but with the
> > SMP option different on the two different machines you cannot use the
> > same module binary on both of them.
> Of course, but It's cleare that machines with SMP are different from a
> simple mono-cpu.
And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.
> It's not an issue talking about smp vs. not-smp. Let's talk about a
> machine: it's useless arguing about Cray while I'm talking about a
> simple environment.
Define "simple environment". Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.
> Every kernel has always the distinction about smp. So it's not a big
> problem.
And it has distinctions on dozens of other configuration options too.
[...]
> Finding a bug in the kernel source and patching it, must be a careful
> step, because if I have to mantain 100 machines, and I know that
> applying the patch will result in a broken kernel modules, I'm not happy
> with it. I must go manually on each machine, apply the patch, recompile
> the modules... Makes me think about NOT applying the patch.
Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.
[...]
> Source compatibility is there.
Sort of.
> Now, you're talking about issues which
> are not your buisness: a binary distribution must take care of how the
> kernel it's compiled. As long as it uses the same gcc and switches, it's
> ok.
Yes, it is their bussiness.
> Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows
> how they're compiled, and they work everywhere. Of course, it has also
> kernel-2.6.A-SMP and its modules.
And A doesn't have some options I'd like, and others you loathe.
> When 2.6.B is released, using ABI will just result in another
> compilation,
Right.
> creating the kernel with additions and patches, and
> distributing them. Modules .A should work on .B,
Iff nothing changes. That isn't usually the case.
> like I do with OpenAFS,
> Every kernel update shouldn't break the magic :)
The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.
> > but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let
> > alone something drasticly different (say 2.6.11.6)
> Sure, because it's not designed to be so.
And the decision to design thusly is completely conscicious, it is not a
random "it just turned out this way by mistake".
> I just see advantages on ABI, and I think it's not bad talking about it...
I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
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 improvements and new drivers to the users quickly is one way to
> care about the users.
Of course!
> I do not claim to agree with all details of kernel development - but
> that's how it works.
I know, I can bring ideas but I think most of them are already somewhere :)
> If you upgrade the kernel, simply get a version of your external modules
> that support your new kernel, compile them against the new kernel, and
> ship the external modules as part of the rollout of the new kernel.
That should be an option.
> Kernel development is based on the fact that all drivers should be
> shipped with the kernel.
That can be partly true. There are many things which are gpl (so no
licence problems) but are not in the kernel (see the pwc module).
> If you buy hardware where no open source driver exists (often because
> the hardware manufacturer doesn't publish the hardware specifications)
> that's your problem.
I don't buy hardware not already tested with linux...
> Space for the code behind all the obsolete interfaces.
I see.
> There are optimizations that are not possible without breaking
> compatibility.
>
> Documentation/stable_api_nonsense.txt contains examples.
Mh. Good thing to know.
> You can't care about everything.
>
> What you propose has both advantages and disadvantages for users of the
> kernel. It's general consensus among the kernel developers that the
> advantages are not worth the disadvantages.
That's why I was thinking about high modularity. Increasing the
modularity and of course, having the same api gives extreme flexibility
in changing the internal representation.
You know what? I was amazed about the /dev directory. When in 96 I first
approached linux, I simply said: that's a smart thing, handling every
kind of device the same way. Writing in a console is not different from
writing in /dev/hda. Amazing.
I was just thinking about something like that for kernel developing.
Having an external representation which is stabe like it's /dev, but
flexible internally (I don't mean that the kernel shoud provide a
``devfs'' for module!). When a new piece should be added, it doesn't
matter the version, the way of accessing things are still the same. How
it works may differ a lot.
I strongly believe in high modularity. No questions about micro/macro
kernel. Both have pros and cons. But I strongly believe that a very
small kernel providing means for modules to work (in kernel space) is
something at least easier to mantain, other than having a single piece.
Modules were very nice when I began to write some of them (it was kernel
2.0.x though --- slack 3.0) just for fun. Just add a new piece and
you'll be able to use a new device, and they can be provided by anyone.
New file systems, new sound cards, everything, just adding a ``small''
piece of code --- it was painful using isapnp package and have my weird
soundcard work! Ah, good memories... :)
Cheers
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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 thing, so knowing every
single piece... It's freakin' hard.
> Trust me. It's *extremely* hard to impossible. Several security fixes
> can only be fixed this way. And it's REALLY fragile even if for other
> fixes. And I am very glad that the linux kernel people in general decide
> to not go for abi stability, the hacks that would be needed would be so
> obscene and the gains very very minimal. (it's open source, you have the
> source after all!)
The gains are simply a rough reuse of older modules! Just joking...
I was simply wondering how guys like beos/haiku (it's a microkernel... i
know... don't even think about starting a flame) could get ABI/API... I
mean, if it's true that they have... I don't think it's because of c++
instead of plain c...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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, that's what I understand... and that's what
happens... Never the same names on different kernels.
> And kernels compiled with one compiler are different than those compiled
> with another. And if you have preemption they are different. Don't forget
> about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
> code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
> in assorted debugging options. On some architectures you have several
> possible (reasonable!) page sizes.
Yes, ok.
> Define "simple environment". Even Red Hat (they are /very/ interested in a
> single kernel image, as it cuts down testing and bug tracking etc!) ships
> half a dozen different kernels, tailored for different configurations. And
> you'll find external modules (like for NTFS) compiled separately for each
> of them.
Yes, but as long as you keep with the same configuration, no problem
should arise in changing the kernel version.
> Or having /your/ standard kernel on all 100 machines, compile once and copy
> around. No need for /me/ to run your exact same configuration.
I probably expressed myself badly. I don't mean anyone having the same
configuration... why on earth should it be?
>>Source compatibility is there.
>
> Sort of.
I hope! :)
> And A doesn't have some options I'd like, and others you loathe.
That's why you recompile, but why should you throw your other modules
not included in the kernel release?
>> creating the kernel with additions and patches, and
>>distributing them. Modules .A should work on .B,
>
> Iff nothing changes. That isn't usually the case.
That's weird... why should things really change so drastically if the
external interface still remains the same? It's probably a matter of
abstraction...
> The problem is that giving that guarantee costs developer time and
> flexibility. The gain (given that source for recompilation is freely
> available) is so minuscule that the consensus is that it just isn't worth
> any extra hassle /at all/.
Ok.
> And the decision to design thusly is completely conscicious, it is not a
> random "it just turned out this way by mistake".
>
>>I just see advantages on ABI, and I think it's not bad talking about it...
>
> I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
I'd really like to know... I'm naive? Yes :) Of course, other than
``more work'', but technical disadvantages...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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 in which API are
stable, still having even different implementations, *then* (not before)
probably ABI can be taken in consideration.
> [1] you can break the API without breaking the ABI, but these are
> mostly pathological examples
I don't want to even think about an incredible coincidence of having a
_working_ ABI with different API... different function calls, different
data structures, different behaviors, and still working in binary mode...
--
Sensei <mailto:[email protected]> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:[email protected]>
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 provides to third-parties: the kernel and the API given to
> the outside world, since the kernel is not alone... and will never be of
> course! ;)
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.
Of course, that doesn't change the simple fact: "outside world" is not
a single entity. There are API warranties for userland. There's no
API warranties for 3rd-party kernel modifications.
Moreover, unless you manage to get the list of functions and data
types exported to modules somewhere within an order of magnitude
from the corresponding userland list (i.e. syscalls and types involved),
you are asking everybody to increase the size of API being preserved
at least tenfold. As it is, that would be "by factor of 200-300".
If you manage to convince module authors to live with the export list
cut down by that much - come back and we'll have something to talk
about.
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.
>
> Don't you think you're a little bit... disappointing?
No, just allergic to that kind of rethorics.
> >Of course, that doesn't change the simple fact: "outside world" is not
> >a single entity. There are API warranties for userland. There's no
> >API warranties for 3rd-party kernel modifications.
>
> My question is, why?
See below.
> Technical reasons? Unaffordable efforts? I bet on the last.
The simple fact that authors of 3rd-party modules do not *want* a sane
API. Current set of objects available to them is huge and most of that
pile had been exported only because
1) somebody couldn't be bothered by thinking and just exported
whatever random kernel functions they happened to use. Many of these
exports could be avoided by using an already exported function instead
of reimplementing it and exporting low-level functions used in that
reimplementation. Many had been result of copying an already existing
stuff and doing local modifications in a copy, instead of figuring out
the sane way to do it in generic code. And almost always these guys
did not say "we want to do this and that for this and that; let's see
how to do it sanely". It was "here's a patch adding exports we need
for our module".
2) such patches had met very low resistance for quite a while.
So what we have right now is a random slice of kernel objects that had
been exported for hell knows what reasons. It's not an interface in any
sane meaning of thw word and preserving that set is both hopeless and
crippling. And 3rd-party module writers will *not* be happy with managable
set of exports, if the past experience is anything to judge by.
> >Moreover, unless you manage to get the list of functions and data
> >types exported to modules somewhere within an order of magnitude
> >from the corresponding userland list (i.e. syscalls and types involved),
> >you are asking everybody to increase the size of API being preserved
> >at least tenfold. As it is, that would be "by factor of 200-300".
>
> I'm probably talking about the design of api.
And I am talking about the existing modules depending on something that
is not and never had been an API. We can design whatever API we want,
but keeping it stable won't help you at all - modules are using the mess
they are using. And any attempt to rip that crap out doesn't make them
happy or willing to cooperate, even when saner replacements are already
there and had been around for longer than the exports that get removed.
> >If you manage to convince module authors to live with the export list
> >cut down by that much - come back and we'll have something to talk
> >about.
>
> An elegant way of saying ``shut your mouth''?
No. "You are talking to wrong people; we can't help you until you pull off
a miracle and convince module authors to sanitize their codebase wrt set
of objects being used by it".