Re: [INFO] Kernel strict versioning

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

[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]