[PATCH 06/14] xfree86: bus: move macros from common PCI header to private file
Vignatti Tiago (Nokia-D/Helsinki)
tiago.vignatti at nokia.com
Tue Jun 1 11:34:22 PDT 2010
On Tue, Jun 01, 2010 at 05:43:10PM +0200, ext Mark Kettenis wrote:
> I really, really don't see the point if this diff, and a lot of others
> you're sending. Yes, this is only used in the int10 module at this
> moment. But obviously Pci.h is the right place for these macros. It
> seems to me that you're just randomly shifting code around. I don't
> get the big picture, and your terse explanations don't give me any
> insight. So all I'm left with is the fear that this will break the
> platform and/or drivers I care about.
If you pay attention in the X server code base, it still contains very old and
complex PCI handling code that does things that only the kernel should do:
moreover has some left over of ISA code, has int10's ugly and mostly not
functional, the 16-bit x86 emulator enormous code, remnants from the dead
Resource Access mechanism, it's mixed with the pciaccess library and so on.
You will see that all PCI code is a recipe for disaster!
Pciaccess library, which came for the good, was introduced in a very dubious
way because implemented half of the functionally we needed on the server. The
most apparent effect was the multi-card support, which is broken until today!
And this is part of the practical situation we live nowadays.
Now, in one perspective your reviews are very good, because you scrutinize
very well each modification is done. I do really appreciate. On the other
hand, in each patch I sent you criticize aspects of compatibility, that you're
trying to keep, dating before 2006 when libpciaccess was introduced. I
understand your conservative philosophy, but this really slows the overall
process of development.
Now the proper answer: OF COURSE I'M SHIFTING CODE AROUND, HONEY! int10's the
only component needs that right now. AND IT'S NOT RANDOMLY! Pci.h file has the
private definitions and won't break your jurrasic drivers.
More information about the xorg-devel