Horst von Brand wrote:
> FORT David <epopo@onetelnet.fr> said:
> > Horst von Brand wrote:
>
> [...]
>
> > > Dream on, as it won't happen. Just think of either:
> > >
> > > - All pieces _have_ to be the same version: What is the use then? Just ship
> > > them together and be done. Splitting it up is extra work, plus the
> > > complaints that core-2.8.3 now doesn't work with ia32-2.6.9 and foo, bar,
> > > baz drivers of assorted other versions.
> > > - You can mix and match: Great! Just who will do the testing and documentatio
> > n
> > > of what works with what?
> > >
> > > Major pain and much extra work to developers (remember, Linux' objective is
> > > being fun to hack on, the "World domination. Fast." thing is just FUD ;)
> > > for minor convenience to some users and major pain to all the rest.
>
> > Isn't it what API have been made for?
>
> Yes. But the API isn't set in stone, as that would slow down
> development. Plus you need the machinery to build whatever pieces are
> extant and ignore the rest, you have to carve up the whole into separate
> pieces, ... This is a *lot* of work for very minimal gain and many future
> problems.
>
> > I think nobody would complain if
> > "being fun to hack on(TM)" could also be "Fast developped(TM)".
>
> I don't see how chopping up the kernel will speed up development. Quite to
> the contrary, any change has to be propagated to all pieces, and that will
> take more time, and create a nightmare of "drivers bar-0.37.2 to 0.39.6 go
> with kernel-core 2.9.45 to 2.9.76, but work only with foo-3.65.x".
> Syncronization issues arise by the distributed development, which are now
> trivially solved by "this is _the_ official version of _all_ there is".
>
I don't think API are changing so much, and documenting the way drivers SHOULD
interact with the kernel is a good thing. This also make things easier for people to
write
new drivers.
You'd also agree that as time will go by, we'll have more and more drivers, and
we'll have to wait
for ALL to be stable to release anything.
>
> > Anyway
> > the developpement of the kernel is already modular, as teams are working
> > quite independantly, and send theirs diff when a release is about to
> > come.
>
> *Very* bad practice, I may add.
Anybody wanting to create something with a certain size proceed this way.
>
>
> > I take a simple example: i got an USB webcam which stopped working
> > at test9-pre2, I'd like to have a 2.4.0test10-pre3 kernel but with the
> > last working USB.
>
> So what? 2.4.0-test is experimental, you can't assume stuff will work at
> all. This is not just "drop working 2.4.0-test9 <foo> into
> 2.4.0-test10-pre3", if it broke there is a reason that makes it not work
> anymore. I tend to doubt the USB people submmited a patch to break
> it... When 2.4.0 ships, everything should work; then you can complain. But
> to get there, folks _must_ make an effort to fold the latest working,
> tested patches into the kernel ASAP. Then again, they are all volunteers...
>
When developping a part of the kernel, developpers may wish to focus to that
particulary part, without
caring about other bugs......
-- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-----------------% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France epopo@onetelnet.fr % % ICU:78064991 AIM: enlighted popo fort@irin.univ-nantes.fr % %--LINUX-HTTPD-PIOGENE----------------------------------------------------% % -datamining <-/ | .~. % % -networking/flashed PHP3 coming soon | /V\ L I N U X % % -opensource | // \\ >Fear the Penguin< % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted.... | ^^-^^ % % http://ibonneace.dnsalias.org/ when connected % %-------------------------------------------------------------------------%- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:14 EST