[FFmpeg-devel] Fix Altivec detection on Linux.

[David Woodhouse]

On Wed, 2008-03-19 at 19:50 +0100, Reimar D?ffinger wrote:
> On Wed, Mar 19, 2008 at 06:33:20PM +0000, David Woodhouse wrote:
> > On Wed, 2008-03-19 at 16:30 +0100, Reimar D?ffinger wrote: 
> > > For Ubuntu the existing but disabled check via mfspr IMO is a very much
> > > better solution.
> > 
> > Why so?
> 
> Well, because the code is there and very simple.

And disabled by default, because it apparently causes SIGILL on kernels
older than 2.6.17 where mfspr isn't emulated by the kernel (although
wasn't that supported earlier than 2.6.17?)

And it also involves a hard-coded list of PVR values which is already
out of date (or just wrong). That kind of hardware knowledge doesn't
live in the library -- especially when the kernel may disable Altivec
for userspace anyway, even when the hardware supports it.

>  I am not a fan of computational libraries like libavcodec doing
> file-system accesses (even if to a virtual file system) behind the
> main application's back. 

It's not so bad. We open a file briefly, and close it again. I have
difficulty coming up with any way in which it could upset the
application. Maybe if it's threaded and calls open() twice in quick
succession in another thread and assumes that the filedescriptors will
be consecutive? But would be broken anyway, surely?

It's certainly a lot nicer than having to play with signal handlers.

> In addition this is something (contrary to /proc) that any operating
> system can implement trivially, though I don't know if the
> Debian/FreeBSD kernel combination is something that I just imagine or
> that actually exists...

If the environment doesn't provide /proc/$$/auxv, my code will err on
the side of caution and assume Altivec isn't present. Alternatively, we
could even make it fall through to whatever other check there is...
except that there _isn't_ another check which we were willing to enable,
so I didn't do that.

> > /proc/$$/auxv has been around for a long time, but I don't recall
> > offhand whether it was already in 2.4. It was a _long_ time ago that I
> > last cared about 2.4 kernels.
> 
> Sounds interesting, though I still wished for a really simple, OS-independent
> solution to this...

I want a pony. :)

-- 
dwmw2