Re: three kernel trees?
Horst von Brand wrote: > FORT David <[EMAIL PROTECTED]> 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 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[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
On Tue, Oct 17, 2000 at 06:13:34PM -0600, Jeff V. Merkey wrote: > Kenneth Johansson wrote: > > "Jeff V. Merkey" wrote: > > > This does not solve the problem of integration testing, but eh solution > > > here is to create an integration test group whose sole charter is to > > > test modules in an integrated framework as they roll off the assembly > > > line. I am speaking from my commercial software development experienes > > > > Good luck finding anyone doing this job. It's hard to make people write > > documentation this is going to be impossible. This is a solution that works if you > > can pay people but I don't think it's going to work when volunteers is doing it. > > Well. It gets done today, so who is doing this today? To what extent? Integration testing with as much hardware as possible? The community as a whole does that. Automated integration testing? Please step forward for recognition if you are. Automated functional testing of the kernel? Yes, SGI is working on that. We still have a lot of work to do to get reasonable coverage, but we do have employees testing Linux. We have released some tests and a simple test driver under the Linux Test Project. If anyone has tests they would like to contribute to LTP, please send them to me. I will try to get the tests integrated into an automated system. The way I see it, if we can pull all of the home grown tests out of the wood work, we will have a better testing system than the defacto "build the kernel" system. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Projecthttp://oss.sgi.com/projects/ltp/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Stephen Tweedie wrote: > > Hi, > > On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote: > > > > Were Linux to go totally modular in 2.5, development cycles will be > > reduced by 1/2 to 1/3. This is because you could always roll back to > > known good modules to post a release. > > Most of the big 2.4 module changes involved totally rethinking the > interactions between the modules. If you're changing the APIs between > modules, rolling one back is hard. Well, within reason if that makes sense. Sooner or later we are going to have to bite the bullet on this one, though and sooner is better than later -- we really need to start thinking about it for 2.5. :-) Jeff > > --Stephen > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
FORT David <[EMAIL PROTECTED]> 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". > 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. > 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 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... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Hi, On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote: > > Were Linux to go totally modular in 2.5, development cycles will be > reduced by 1/2 to 1/3. This is because you could always roll back to > known good modules to post a release. Most of the big 2.4 module changes involved totally rethinking the interactions between the modules. If you're changing the APIs between modules, rolling one back is hard. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Horst von Brand wrote: > FORT David <[EMAIL PROTECTED]> said: > > > I totally agree, I'm really wondering if the current API would allow to > > create a tree which would contain only files needed on > > machine. Typically i never use sparc or mips file in kernel > > compilation. I'm dreaming of a day when i could download these different > > parts: > > Kernel core source > > x86 specific part > > any driver i need > > 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 documentation > 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 ? I think nobody would complain if "being fun to hack on(TM)" could also be "Fast developped(TM)". 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. 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. > > A few tar -xvzf later i'd got a working kernel, with no space lost on my > > HD. > > Have you really looked at the size of the other architectures? Here I have > 2.2.18pre15: > > arch + include/asm-*: 14929 > All : 88121 > > A 16% of the total is architecture-dependent. Sure, much of the drivers you > don't use. But then again, how much did your HDD cost? How much for the > space the sources take up? How much did the sources cost you? > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 I've got a quick look, at my own tree and i've figured that arch-dependant is really small compared to FS or drivers. -- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
FORT David <[EMAIL PROTECTED]> said: > I totally agree, I'm really wondering if the current API would allow to > create a tree which would contain only files needed on > machine. Typically i never use sparc or mips file in kernel > compilation. I'm dreaming of a day when i could download these different > parts: > Kernel core source > x86 specific part > any driver i need 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 documentation 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. > A few tar -xvzf later i'd got a working kernel, with no space lost on my > HD. Have you really looked at the size of the other architectures? Here I have 2.2.18pre15: arch + include/asm-*: 14929 All : 88121 A 16% of the total is architecture-dependent. Sure, much of the drivers you don't use. But then again, how much did your HDD cost? How much for the space the sources take up? How much did the sources cost you? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
FORT David [EMAIL PROTECTED] said: I totally agree, I'm really wondering if the current API would allow to create a tree which would contain only files needed on machine. Typically i never use sparc or mips file in kernel compilation. I'm dreaming of a day when i could download these different parts: Kernel core source x86 specific part any driver i need 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 documentation 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. A few tar -xvzf later i'd got a working kernel, with no space lost on my HD. Have you really looked at the size of the other architectures? Here I have 2.2.18pre15: arch + include/asm-*: 14929 All : 88121 A 16% of the total is architecture-dependent. Sure, much of the drivers you don't use. But then again, how much did your HDD cost? How much for the space the sources take up? How much did the sources cost you? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Hi, On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote: Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. Most of the big 2.4 module changes involved totally rethinking the interactions between the modules. If you're changing the APIs between modules, rolling one back is hard. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
FORT David [EMAIL PROTECTED] 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". 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. 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... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Stephen Tweedie wrote: Hi, On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote: Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. Most of the big 2.4 module changes involved totally rethinking the interactions between the modules. If you're changing the APIs between modules, rolling one back is hard. Well, within reason if that makes sense. Sooner or later we are going to have to bite the bullet on this one, though and sooner is better than later -- we really need to start thinking about it for 2.5. :-) Jeff --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
On Tue, Oct 17, 2000 at 06:13:34PM -0600, Jeff V. Merkey wrote: Kenneth Johansson wrote: "Jeff V. Merkey" wrote: This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. Well. It gets done today, so who is doing this today? To what extent? Integration testing with as much hardware as possible? The community as a whole does that. Automated integration testing? Please step forward for recognition if you are. Automated functional testing of the kernel? Yes, SGI is working on that. We still have a lot of work to do to get reasonable coverage, but we do have employees testing Linux. We have released some tests and a simple test driver under the Linux Test Project. If anyone has tests they would like to contribute to LTP, please send them to me. I will try to get the tests integrated into an automated system. The way I see it, if we can pull all of the home grown tests out of the wood work, we will have a better testing system than the defacto "build the kernel" system. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Projecthttp://oss.sgi.com/projects/ltp/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Let's see if Linus creates a modular 2.5 tree. If he does, merging MANOS back into Linux will be a pleasant experience Jeff FORT David wrote: > > "Jeff V. Merkey" wrote: > > > Kenneth Johansson wrote: > > > > > > "Jeff V. Merkey" wrote: > > > > > > > Alan, > > > > > > > > Were Linux to go totally modular in 2.5, development cycles will be > > > > > changes creap into the kernel that increase the time to a stable version. Making > > > the TODO list before instead of at the end would probably make people concentrate > > > on the same thing. > > > > Linus stated in an email a month or so back modularity was something he > > really would like to see happen. Let's see just how serious he really > > is when 2.5 comes down the pipe. > > > > > > > > Just another thought. > > > > Jeff > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > I totally agree, I'm really wondering if the current API would allow to create a tree > which would contain only > files needed on machine. Typically i never use sparc or mips file in kernel > compilation. I'm dreaming of a day > when i could download these different parts: > Kernel core source > x86 specific part > any driver i need > > A few tar -xvzf later i'd got a working kernel, with no space lost on my HD. > > -- > %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% > % FORT David, % > % 7 avenue de la morvandière 0240726275 % > % 44470 Thouare, France[EMAIL PROTECTED] % > % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % > %--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 [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
"Jeff V. Merkey" wrote: > Kenneth Johansson wrote: > > > > "Jeff V. Merkey" wrote: > > > > > Alan, > > > > > > Were Linux to go totally modular in 2.5, development cycles will be > > > changes creap into the kernel that increase the time to a stable version. Making > > the TODO list before instead of at the end would probably make people concentrate > > on the same thing. > > Linus stated in an email a month or so back modularity was something he > really would like to see happen. Let's see just how serious he really > is when 2.5 comes down the pipe. > > > > > Just another thought. > > Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ I totally agree, I'm really wondering if the current API would allow to create a tree which would contain only files needed on machine. Typically i never use sparc or mips file in kernel compilation. I'm dreaming of a day when i could download these different parts: Kernel core source x86 specific part any driver i need A few tar -xvzf later i'd got a working kernel, with no space lost on my HD. -- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Kenneth Johansson wrote: > > "Jeff V. Merkey" wrote: > > > Alan, > > > > Were Linux to go totally modular in 2.5, development cycles will be > > reduced by 1/2 to 1/3. This is because you could always roll back to > > known good modules to post a release. The way you guys are going, if > > Linux stays monolithic, your cycles will get longer and longer. > > Modularity will allow multiple people to proceed in parallel without > > every patch and bug going through you and Linus all the time (which > > would mean you could enjoy more free time). > > > > I don't really see what class of problems this would solve. It could be that we > mean different things with modular. Do you mean distribute the driver source > separately from the kernel source or do you mean going none monolitic by creating a > stable binary interface?? I think the second one is going to be hard to get pass > Linus and the first one is going to result in alot of drivers not uptodate with > kernel changes. > Whether drivers have bugs or not should never hold up a release. The way Linux is today, since drivers are in the main tree (true they can be built as modules), this means Linux has to wait for every single driver to function before a kernel can be considered stable. If MS or Novell did their development this, W2K release cycles would be 5-6 years since they have a huge base of drivers. A stable binary interface. There already is one with the register_blkdev() functions, etc. The drivers are already doing this part, but they should not be lock step syncrhonized with the kernel. The kernel proper could be separate. Same with the LAN and Disk sybsystems -- they also could be instrumented as modules. A lot of this is already there today, it's just a question of procedures and how stuff gets managed. The driver function table has not changed for years, and there's still the freedom to change stuff. Easy -- add a version number to these function tables so when the kernel loads, it will know which version table to swap in -- then you can change kernel/driver interaction all you want and still support all the drivers. 2.4 has fewer Level I and Level II bugs at this momemtn than either W2K or NetWare typically do when they ship. WHat's different about Linux is that the source code is public so the whole planet knows about these bugs. I think 2.4.0 is ready now to ship -- it's in better shape than most commercial W2K releases are > The problem with a binary interface is that if it was easy to do one we did not > need one in the first place as that would suggest that the source code interface > also was stable. > > > > > This does not solve the problem of integration testing, but eh solution > > here is to create an integration test group whose sole charter is to > > test modules in an integrated framework as they roll off the assembly > > line. I am speaking from my commercial software development experienes > > Good luck finding anyone doing this job. It's hard to make people write > documentation this is going to be impossible. This is a solution that works if you > can pay people but I don't think it's going to work when volunteers is doing it. Well. It gets done today, so who is doing this today? > > > > > here. Linux is falling into the same rut NetWare did as it became > > successful -- too much work for mere mortals without some new structures > > put in place. > > > > Just a thought. > > > > Yes but is anyone taking notes on what work really is taking up all the time? Is it > really drivers that is the problem? To me it lookes more like a problem with > deciding what really is the goal of every new version that make all sort of late > changes creap into the kernel that increase the time to a stable version. Making > the TODO list before instead of at the end would probably make people concentrate > on the same thing. Linus stated in an email a month or so back modularity was something he really would like to see happen. Let's see just how serious he really is when 2.5 comes down the pipe. > > Just another thought. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
"Jeff V. Merkey" wrote: > Alan, > > Were Linux to go totally modular in 2.5, development cycles will be > reduced by 1/2 to 1/3. This is because you could always roll back to > known good modules to post a release. The way you guys are going, if > Linux stays monolithic, your cycles will get longer and longer. > Modularity will allow multiple people to proceed in parallel without > every patch and bug going through you and Linus all the time (which > would mean you could enjoy more free time). > I don't really see what class of problems this would solve. It could be that we mean different things with modular. Do you mean distribute the driver source separately from the kernel source or do you mean going none monolitic by creating a stable binary interface?? I think the second one is going to be hard to get pass Linus and the first one is going to result in alot of drivers not uptodate with kernel changes. The problem with a binary interface is that if it was easy to do one we did not need one in the first place as that would suggest that the source code interface also was stable. > > This does not solve the problem of integration testing, but eh solution > here is to create an integration test group whose sole charter is to > test modules in an integrated framework as they roll off the assembly > line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. > > here. Linux is falling into the same rut NetWare did as it became > successful -- too much work for mere mortals without some new structures > put in place. > > Just a thought. > Yes but is anyone taking notes on what work really is taking up all the time? Is it really drivers that is the problem? To me it lookes more like a problem with deciding what really is the goal of every new version that make all sort of late changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Just another thought. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Alan, Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. The way you guys are going, if Linux stays monolithic, your cycles will get longer and longer. Modularity will allow multiple people to proceed in parallel without every patch and bug going through you and Linus all the time (which would mean you could enjoy more free time). This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes here. Linux is falling into the same rut NetWare did as it became successful -- too much work for mere mortals without some new structures put in place. Just a thought. :-) Jeff Alan Cox wrote: > > > As soon as 2.4 comes out, 2.7 is created, 2.6test > > will be feature frozen. > > Development time would be shorter, and > > the nuisance with "this important feature has tz slip > > in" would be finished. > > It requires too much people overhead. I have proposed another idea which is at > about 10 months in or when seems appropriate we say 'ok which bits can we > fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5->2.7 and > stabilise the big changes as 2.8 > > That would mean driver features and the like get a yearly cycle but deep magic > gets what seems to be needed as a 2 year cycle > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
> As soon as 2.4 comes out, 2.7 is created, 2.6test > will be feature frozen. > Development time would be shorter, and > the nuisance with "this important feature has tz slip > in" would be finished. It requires too much people overhead. I have proposed another idea which is at about 10 months in or when seems appropriate we say 'ok which bits can we fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5->2.7 and stabilise the big changes as 2.8 That would mean driver features and the like get a yearly cycle but deep magic gets what seems to be needed as a 2 year cycle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
three kernel trees?
What about creating three kernel series: 2.2. stable 2.4. feature frozen 2.5 development? As soon as 2.4 comes out, 2.7 is created, 2.6test will be feature frozen. Development time would be shorter, and the nuisance with "this important feature has tz slip in" would be finished. Mirko Kloppstech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
three kernel trees?
What about creating three kernel series: 2.2. stable 2.4. feature frozen 2.5 development? As soon as 2.4 comes out, 2.7 is created, 2.6test will be feature frozen. Development time would be shorter, and the nuisance with "this important feature has tz slip in" would be finished. Mirko Kloppstech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
As soon as 2.4 comes out, 2.7 is created, 2.6test will be feature frozen. Development time would be shorter, and the nuisance with "this important feature has tz slip in" would be finished. It requires too much people overhead. I have proposed another idea which is at about 10 months in or when seems appropriate we say 'ok which bits can we fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5-2.7 and stabilise the big changes as 2.8 That would mean driver features and the like get a yearly cycle but deep magic gets what seems to be needed as a 2 year cycle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Alan, Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. The way you guys are going, if Linux stays monolithic, your cycles will get longer and longer. Modularity will allow multiple people to proceed in parallel without every patch and bug going through you and Linus all the time (which would mean you could enjoy more free time). This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes here. Linux is falling into the same rut NetWare did as it became successful -- too much work for mere mortals without some new structures put in place. Just a thought. :-) Jeff Alan Cox wrote: As soon as 2.4 comes out, 2.7 is created, 2.6test will be feature frozen. Development time would be shorter, and the nuisance with "this important feature has tz slip in" would be finished. It requires too much people overhead. I have proposed another idea which is at about 10 months in or when seems appropriate we say 'ok which bits can we fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5-2.7 and stabilise the big changes as 2.8 That would mean driver features and the like get a yearly cycle but deep magic gets what seems to be needed as a 2 year cycle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
"Jeff V. Merkey" wrote: Alan, Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. The way you guys are going, if Linux stays monolithic, your cycles will get longer and longer. Modularity will allow multiple people to proceed in parallel without every patch and bug going through you and Linus all the time (which would mean you could enjoy more free time). I don't really see what class of problems this would solve. It could be that we mean different things with modular. Do you mean distribute the driver source separately from the kernel source or do you mean going none monolitic by creating a stable binary interface?? I think the second one is going to be hard to get pass Linus and the first one is going to result in alot of drivers not uptodate with kernel changes. The problem with a binary interface is that if it was easy to do one we did not need one in the first place as that would suggest that the source code interface also was stable. This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. here. Linux is falling into the same rut NetWare did as it became successful -- too much work for mere mortals without some new structures put in place. Just a thought. Yes but is anyone taking notes on what work really is taking up all the time? Is it really drivers that is the problem? To me it lookes more like a problem with deciding what really is the goal of every new version that make all sort of late changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Just another thought. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Kenneth Johansson wrote: "Jeff V. Merkey" wrote: Alan, Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. The way you guys are going, if Linux stays monolithic, your cycles will get longer and longer. Modularity will allow multiple people to proceed in parallel without every patch and bug going through you and Linus all the time (which would mean you could enjoy more free time). I don't really see what class of problems this would solve. It could be that we mean different things with modular. Do you mean distribute the driver source separately from the kernel source or do you mean going none monolitic by creating a stable binary interface?? I think the second one is going to be hard to get pass Linus and the first one is going to result in alot of drivers not uptodate with kernel changes. Whether drivers have bugs or not should never hold up a release. The way Linux is today, since drivers are in the main tree (true they can be built as modules), this means Linux has to wait for every single driver to function before a kernel can be considered stable. If MS or Novell did their development this, W2K release cycles would be 5-6 years since they have a huge base of drivers. A stable binary interface. There already is one with the register_blkdev() functions, etc. The drivers are already doing this part, but they should not be lock step syncrhonized with the kernel. The kernel proper could be separate. Same with the LAN and Disk sybsystems -- they also could be instrumented as modules. A lot of this is already there today, it's just a question of procedures and how stuff gets managed. The driver function table has not changed for years, and there's still the freedom to change stuff. Easy -- add a version number to these function tables so when the kernel loads, it will know which version table to swap in -- then you can change kernel/driver interaction all you want and still support all the drivers. 2.4 has fewer Level I and Level II bugs at this momemtn than either W2K or NetWare typically do when they ship. WHat's different about Linux is that the source code is public so the whole planet knows about these bugs. I think 2.4.0 is ready now to ship -- it's in better shape than most commercial W2K releases are The problem with a binary interface is that if it was easy to do one we did not need one in the first place as that would suggest that the source code interface also was stable. This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. Well. It gets done today, so who is doing this today? here. Linux is falling into the same rut NetWare did as it became successful -- too much work for mere mortals without some new structures put in place. Just a thought. Yes but is anyone taking notes on what work really is taking up all the time? Is it really drivers that is the problem? To me it lookes more like a problem with deciding what really is the goal of every new version that make all sort of late changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Linus stated in an email a month or so back modularity was something he really would like to see happen. Let's see just how serious he really is when 2.5 comes down the pipe. Just another thought. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
"Jeff V. Merkey" wrote: Kenneth Johansson wrote: "Jeff V. Merkey" wrote: Alan, Were Linux to go totally modular in 2.5, development cycles will be changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Linus stated in an email a month or so back modularity was something he really would like to see happen. Let's see just how serious he really is when 2.5 comes down the pipe. Just another thought. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ I totally agree, I'm really wondering if the current API would allow to create a tree which would contain only files needed on machine. Typically i never use sparc or mips file in kernel compilation. I'm dreaming of a day when i could download these different parts: Kernel core source x86 specific part any driver i need A few tar -xvzf later i'd got a working kernel, with no space lost on my HD. -- %--IRIN--Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
Let's see if Linus creates a modular 2.5 tree. If he does, merging MANOS back into Linux will be a pleasant experience Jeff FORT David wrote: "Jeff V. Merkey" wrote: Kenneth Johansson wrote: "Jeff V. Merkey" wrote: Alan, Were Linux to go totally modular in 2.5, development cycles will be changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Linus stated in an email a month or so back modularity was something he really would like to see happen. Let's see just how serious he really is when 2.5 comes down the pipe. Just another thought. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ I totally agree, I'm really wondering if the current API would allow to create a tree which would contain only files needed on machine. Typically i never use sparc or mips file in kernel compilation. I'm dreaming of a day when i could download these different parts: Kernel core source x86 specific part any driver i need A few tar -xvzf later i'd got a working kernel, with no space lost on my HD. -- %--IRIN--Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
