Martin Bochnig wrote:
> Therefore, why is it a problem to have something in ON depend on
> something provided by the X11 consolidation?
The problem is not depending on something in X, but on depending on
something that's Volatile and still actively under development with
no stability guarantee. If he writes code that works with pciaccess 0.10.5
that we currently ship, and the API changes in 0.20, then we can't
integrate 0.20 until the prtconf code is updated to match. That sort
of coordination is easier to do when both parts are in the same
consolidation, but doable across consolidations too, just results in
more flag days. ("ON developers will need to install X build foo before
building or running prtconf after the putback for CR YYYYYYYY.")
> IMO the only fix around this would be, to move libpciaccess down into
> ON. Maybe, if that makes more sense / looks less strange. I mean
> libpciaccess of of general purpose/usability. It doesn't have much to
> do with Xorg itself. What do others think?
That would simplify some coordination between prtconf & libpciaccess,
at the cost of making more work for X if we need a new libpciaccess
version for a future Xorg update. (I'd happily pay the cost if it
meant we got the kernel's PCI experts owning and fixing the code
though - it's still suffering in a number of areas from poor integration
with the Solaris kernel, which we've talked to them about, but not yet
completely solved.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
