[EMAIL PROTECTED] wrote: > On Fri, 16 May 2008, Darren J Moffat wrote: > > Cyril Plisko wrote: [snip] > > Not being in ON doesn't automatically make the DDI clean they can still > > use non DDI functions - it just means they might break when someone > > changes one of them (where as when in ON they would be more likely to > > get fixed). > > > > All device drivers ? > > Argh. Blanket "thou shalt <not> ..." is bad. > > > Just some of them ? > > And now for the nitty-gritty details. > > > Why device drivers ? What is so special about them ? How is ON holding > > them back from development ? Or how are they holding ON back ? > > Not necessarily holding back development - but sometimes maintenance. > > Having a separate driver gate means you _can_, if you so choose, write > your driver that the same module works fine on, say, S9, S10, onnv, ... > hence only ever creating _one_ release of it.
... and who is going to maintain/test all the "#ifdef version_a ... #else ... #endif" stuff ? > No backporting, synchronous patch releases. > > sounds too good to be true. <RANT mode="generalised" submode="jumping_to_random_worstcase_conclusions"> Sounds awfull lot like the ideas behind the X.org modularisation project. Lets take a look - "before" (e.g. X11R6.8.2 (for which I was the release manager)) and "after" (e.g. X11R7.2) - what happend there: * Build time (Ultra5/270Mhz): - Before: 2-3 hours - After: >= ~~21hours (<--- no joke (Ok... that's a result of massive use of "autoconf"&co. and the lack of a parallel build (which won't work for the current modular X11 tree))) * Driver compatibilty: - Before: One monolithic build creates all drivers, no interoperabilty problems - After: Lots of syncronoisation problems, maintainers release driver source which may or may not work with our version of the Xserver. The various codebases are sometimes highly out-of-sync and are a nightmare for those who have to do binary packages for distributions * Code portabilty: - Before: One monolithic tree for all platforms and modules - After: "Modular tree" with lots of version #ifdef/#else/#endif code to deal with various module/Xserver/libX11 versions. The HEAD sources are maintained but for older versions you're at the mercy of the maintainers. All applications+drievrs are spread over multiple modules and you have to run around to find them all. Code may or may not work on your platform (pre-modular world all people had to compile all the code, eliminating any problems in this area). * Engineering cooperation: - Before: All had to work together and play nicely with other people's code - After: "Unwanted code" or code which some people do not understand is kicked around or moved into "branches". Tree fights. The weak perish. (...the only reason why it didn't became even worse was that alanc stopped the worst ideas to creep in...) ... just to point out where it _may_ end after some time (and please don't say "the rules will prevent this" - that's what Keith Packard and others "promised" to those who opposed/objected the modularisation). </RANT> <!-- P.S.: See atributes of the RANT tag - the text above is a "overdrawn" and is jumping to conclusions where it shouldn't do it... but still... please think about it... --> ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
