Proposal for integrating Looking Glass Xorg Mods into
Xorg Release 7.1
Christoph Hellwig
hch at lst.de
Sun Dec 25 03:03:51 PST 2005
> > the last
> > thing X.org needs is any more #ifdef MYPROJECTHACKSTHISCODE.
>
> I am amenable to changing my code as the architecture committee
> sees fit, provided that the new code doesn't regress any
> LG functionality or performance. Paul Anderson suggested that
> we leave the code enclosed in #ifdefs so that future developers
> will know why a particular change was made (similar to what
> was done for XINPUT and XKB). This seems like a good idea to me.
I'm sure if you came with this statement to the linux kernel list you'd
get a happy entry into killfiles. If you integrate new optional code into
an existing larget codebase the first priority should be that it doesn't
make that codebase less maintainable. If that regresses your new
feature that's fine because it's never been part of a release before and
people don't have the high expectations as for the existing codebase.
Fixing bugs later on is easy, getting the architecture right is not.
Just compare the Linux scsi disk driver that contains just two ifdefs
and the solaris driver that behaves very different depending on whether
it's compiled on sparc or i386 and some other symbols becuase people
decided that they're not gonna change existing code just throw in more
ifdefs to keep the risk down. The end result is that sd in solaris is
an utter mess.
More information about the xorg-arch
mailing list