I have a simple answer to your concerns:
* Most application programs/utilities are written to POSIX, or at least
standard Sun, interfaces. Applications and utilities which don't depend
on specific extensions in the kernel or libc, should be able to be
compiled in a separate tree.
While I believe Frank's thoughts about drivers and DDI have some merit,
the reality is very, very few device drivers in ON are DDI compliant.
(I can't think of any off hand -- especially given that GLDv3 is not
part of the public DDI.) Until we have a rich enough DDI that we don't
need to break the rules for typical Sun drivers, I don't think we can
plan on truly separating the drivers from the main part of ON.
-- Garrett
Roland Mainz wrote:
> [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
>
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
