ollie lho <[EMAIL PROTECTED]> writes: > On Wed, 2002-07-03 at 16:05, Eric W. Biederman wrote: >> > > I am still in the thinking and drawing phase. I am reading > literatures about OOD and Design Pattern and trying to see > if there is anything we can apply to our architecture. Do > I get the "silver bullet syndrome" about OO stuff ??
>From one of the few cases studies ever done about software development there was a book written "The Mythical Man-Month" by Frederick P. Brooks, Jr. published by Addison Wesley. In there he makes the point, with which agree that there are no silver bullet solutions to software problems. By which he means there is no technique that will give the software development process an order of magnitude efficieny improvement. There are many techniques that give small little incremental improvements but nothing major. His primary point is addresses the managementment myth that if a project is going to take 8 hours you can get it done in 4 hours by assigning 2 programmers. And in fact has examples where exactly the opposite happened. > > I have four pci buses. For each bus I have > > a pci-pci bridge, and a ioapic. Plus another ioapic > > for the ISA bus, and any 33Mhz onboard pci devices I have. > > > > That's really complicated. Who designed this kind of HW ?? It's the Intel E7500 chipset. It has dual channel DDR SDRAM, and on the p4dc6 6 pci-X 133Mhz capable slots. So the bottle neck has been finally been lifted from the pci bus, for high performance applications. When we were validating the chipset were playing with things like bonding 4 gigabit ethernet cards to get more bandwidth. So for a system where you are I/O limited it is very nice. And roughly the first breath of fresh air I have seen in a long time. > BTW, I once draw some UML about PCI bus on paper as my would > be design of PCI layer. I will try to dig it out. Thanks god > that it is drawn on paper than in any e-media. > > > > > And given that this is a practical requirement I am more likely to get > > a gradual evolution path than sitting at a drawing board trying to > > anticipate this kind of thing. :) > > > > Since I don't have anything as terrible as your P4Dxx, all I can do is > "sitting at a drawing board trying to anticipate this kind of thing" :-) It isn't terrible it is just busy. There is just a large volume of code to be done. From working with the Linux kernel I have picked up the philosophy building code that works well and is simple today, and dealing with tommorrow when it comes. Except for a few rare circumstances when you need a fixed interface layer between software components this works very well. And even when you need an interface layer often you can make it expanable so you can extend it into tomorrow. The two closest approaches I have seen to silver bullets are. - KISS and build for today. - Having a large software library to draw upon. The first keeps you from spinning wheels on useless problems. Though a solid requirements doc will accomplish the same thing. The second the speed up comes from having to do nothing. My problem with a lot of OO stuff is that it implies that reuse comes for free. OO thinking does provide a good framework for building reuseable objects in. But it doesn't force you to build the object as reuseable. And I think typically that takes something like 3x more effort to ensure your code is actually reuseable. A LiunxBIOS example is raminit code that works for one set of DIMMS versus code that works with any set of DIMMS at the optimally supported speed. A lot more work but a lot more useful when you get done with the code as well. Although to a certain extent in LinuxBIOS we have enough varing circumstances that the code we can reuse really does pay for itself pretty quickly when we don't need to do things like write almost the same code for 3 different boards. Eric
