On Sat, Mar 25, 2006 at 08:30:21AM +0200, MHD.Tayseer Alquoatli wrote: > Hi Greg, Mulyadi > > > > > > what are the CASE/Design tools that are used through Linux kernel > > > development ? > > > > There are none used by the kernel developers, sorry. > > I was expecting this, but i couldn't believe my expectations .. but now i > believe it ;-) You aren't alone, here's one of my favorite quotes: "Open-source development violates almost all known management theories." - Dr. Marietta Baba, Dean of the College of Social Science, Michigan State University > > i can't believe that the kernel was being developed since 1991 with only > > > code and the design in mind (i don't think it can fit in ones mind) or > > some > > > informal design specification on papers (although i couldn't even find > > such > > > papers) > > > > It's evolutionary design, not formal design. And it works. Really > > well. I'm sure you can agree. > > I agree .. but i don't understand how new ideas are shared between kernel > developers without a formal description .. if a new feature or a > modification to the kernel's internal design going to be done .. how this > can be specified ? just through sharing the idea in mailing lists ? Exactly. And usually there is no "design" other than a half baked idea. And even with a description of an idea, no one will take you seriously. You have to show code (hopefully working code) before anyone even pays attention. > what about design conflicts ? this is the most thing i'm astonished not to > happen . Happens at times, but pretty rarely. > can you explain please how this are not leading to design conflicts > without a big picture of the kernel design ? There is no "big picture" other than "A relativly POSIX style operating system" so we are pretty much free to do what we want to do within those boundries (which is quite large). Design conflicts don't happen because it is rare that two different groups of people show up with two different chunks of working code. But it gets interesting when code shows up. That's when people start evaluating how it works, what should be made better, how it can be done differently, and so on. Only after agreement happens over this, and the code is still working, is it accepted. Also, we don't usually take huge drops of code all at once. It's a slow evolutionary process with lots of little steps all along the way. So if you want to do something very big, you need to be able to break it down into small changes, that are easily understood to all. That's the only way to get things done, and is really an art in and of itself (and something that most people forget is required.) But for other "simple" things like new drivers, those get added quite easily. Hope this helps, greg k-h -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
