Re: [INFO] Kernel strict versioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]>

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux