Re: [INFO] Kernel strict versioning

["Franco \"Sensei\"" <senseiwa@tin.it>]

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:senseiwa@tin.it> <pgp:8998A2DB>
       <icqnum:241572242>
       <yahoo!:sensei_sen>
       <msn-id:sensei_sen@hotmail.com>

Attachment: signature.asc
Description: OpenPGP digital signature