lkml.org 
[lkml]   [2005]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2005-04-15 00:34    [W:0.069 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site