[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc - capaibility control mechanism



On Sat, Apr 02, 2005 at 09:37:54PM +0900, GOTO Masanori wrote:
> > > I think the simple shell script wrapper controlling HWCAP_MASK can
> > > achieve the original request by Bastian.
> > No, it does not. You have to replace any binary with this wrapper, even
> > /sbin/init.
> Hmm, I have not understood why you want to use such mechanism.  What's
> the merit of your proposal?  Which application are you focusing in
> this proposal?

Okay, lets show some scenarios:

1. Enable specific optimizations: for example SSE.
2. Disable tls: run XenLinux or UML, both supports linux 2.6 but no TLS.
3. Disable i686 optimization: testing of the other libs.
4. Enable tls: RedHat shipped 2.4 kernels with TLS-Support.

1 and 4 can be done with LD_LIBRARY_PATH, as it is not critical.
3 can be done with LD_LIBRARY_PATH which pulls the unoptimized libs
before the optimzed.
2 is missing, LD_ASSUME_KERNEL needs to be _always_ defined, it is not
even possible to start a shell without.

The current glibc defines a generic interface for 1 and 3 but noone is
able to show me how to use it and my checks of the source showed that 3
is not able with the hwcap machanism. 2 and 4 is done via an explicit
check for the kernel version.

>                                      if you have experience to modify
> the code for specific architecture's capability to get performance
> improvement like HPC application, you would nod some parts of my
> previous mail.

I have none, I only raised that as an example because people asked for a
generic solution for that problem.

We have even some library packages in the archive which provides such
optimized libs, they use its one hack to enable optimized libs.

My proposal just uses the available things, unifys them and makes it
possible to ask the glibc to change the behaviour in a way the user
want not what the glibc means that the user want.

Bastian

-- 
Vulcans believe peace should not depend on force.
		-- Amanda, "Journey to Babel", stardate 3842.3

Attachment: signature.asc
Description: Digital signature


Reply to: