Re: [INFO] Kernel strict versioning

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

 



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:[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