Messages in this thread | | | Date | Thu, 14 Apr 2005 17:26:51 -0500 | From | "Franco \"Sensei\"" <> | Subject | Re: [INFO] Kernel strict versioning |
| |
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> [unhandled content-type:application/pgp-signature] | |