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