Re: [INFO] Kernel strict versioning
From: Franco \"Sensei\"
Date: Thu Apr 14 2005 - 17:31:52 EST
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@xxxxxx> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:sensei_sen@xxxxxxxxxxx>
Attachment:
signature.asc
Description: OpenPGP digital signature