[Pixman] Submitting a larger patch for AmigaOS port / Fast path caches

[Søren Sandmann]

Hi,

> I have prepared a patch to generate an AmigaOS4 shared library from
> the pixman sources. My first question is whether you would, in
> principle, include something like this in the main git? And if, how
> can I best distribute the patch? The patch is quite large as it is
> about 300k is size. Apart from a patch that I submitted previously and
> a small style correction (which I will remove subsequently) it doesn't
> change anything to existing files. It, however, adds some new files to
> a new amiga directory, which hosts stubs and other related files
> necessary to build a real AmigaOS shared library, and some makefile in
> a similar fashion as the Win32 port does. A preliminary patch is
> accessible using the
> http://www.sebastianbauer.info/ex/pixman-amiga.diff URI.

I have pushed the const fix in pixman-matrix.c to master - thanks for
the patch. The style fix in pixman-region.c also looks good. If you send
it as a stand-alone patch, I'll push that as well.

Regarding the build system support for AmigaOS, I'm inclined to say
that we are not interested, simply because it's a very big chunk of code
that will benefit only a very small number of users, and that most
people working on pixman have no chance of maintaining. Since the patch
is relatively independent and only touches one new directory, I think it
shouldn't be a huge problem for you to maintain it as a separate branch
in a git repository somewhere - ie., rebasing to newer versions of
pixman wouldn't generate a lot of conflicts.

This doesn't mean that we wouldn't be interested in changes to the
actual pixman code that would benefit AmigaOS, such as new Altivec fast
paths, or if there are small extensions required to the various OS or
compiler specific parts of pixman.

> Another question is about fast path caches in pixman-utils.c. I didn't
> study what the fast path cache (nor what a fast path) is all about but
> as on AmigaOS TLS cannot be achieved that easily and all code and data
> is shared for all clients, I would like to extend that code portion by
> a compile-time optional data access arbitration method. Would you, in
> principle accept this change as well, assuming a suitable
> implementation is provided?

I'm not sure what you mean by "compile-time optional data access
arbitration method", but if you mean using mutexes instead of TLS, then
I wouldn't necessarily be opposed to a patch that did this in a suitable
way.


Thanks,
Soren