Greetings! I agree as well. Lets add 6) to the policy proposal.
Thanks for your input!
Michel LESPINASSE <[EMAIL PROTECTED]> writes:
> Camm,
>
> I still like your proposal a lot, but I'd like to add this to it:
>
> 6) Libraries containing CISEs are exempted from the usual requirement
> to build all other libraries with -fPIC. If the package maintainer
> decides to take advantage of this on architectures that do not
> require -fPIC, it is still his/her responsibility to make sure that
> the library will correctly build on all currently-supported debian
> architectures, including those that do require -fPIC for correct
> runtime behaviour. As a suggestion, one possible way to do this is
> to use libtool with the --without-pic option. One other possibility
> is to have the library's build system use some special-case for
> architectures known to not require the -fPIC option, and default to
> -fPIC for the other ones.
>
> The rationale for this proposed addition is that -fPIC adds a
> noticeable overhead on some architectures (about 5-10% on
> processor-intensive code on x86, due to the %ebx register being
> unuseable in -fPIC code). For most libraries it still makes most sense
> to use -fPIC so that the code can actually be shared between all users
> of this library, but for some of the CISE libraries (possibly very
> thight, hand-optimized modules for each subarchitecture), that are
> expected to be very CPU intensive, the tradeof is different. I think
> we should leave some freedom to individual package maintainers to make
> the right decision on a case by case basis.
>
> Also in the case of CISE libraries, I suppose that most maintainers
> will need subarchitecture-specific build rules anyway, to enable the
> various CISEs, so the cost of adding special-case -fPIC handling is
> not very big actually.
>
> On Mon, Nov 26, 2001 at 07:24:29PM -0500, Camm Maguire wrote:
> > Greetings! I posted this proposal to debian-policy for discussion in
> > June, but am only now formally requesting its inclusion in the
> > policy. I've taken the liberty of including recommendations from
> > various submitters.
> >
> > The goal of this proposal is to provide a mechanism whereby packages
> > can safely make use of cpu instruction set extensions
> > (e.g. sse1,sse2,3dnow,3dnowext, etc.) In this scheme, packages can
> > install on any machine of the general architecture, and extension
> > instructions only get executed on appropriately capable cpus, even if
> > /usr is served up over NFS.
> >
> > Proposal outline:
> >
> > 1) All packages providing programs and/or libraries which make use of
> > CPU instruction set extensions (CISEs) must provide identical
> > functionality on all machines of the given general architecture.
> > One way to achieve this is for the code to be protected by runtime
> > probes of the cpu, followed by appropriate branching to correctly
> > executable sections. Alternatively, packages can separate routines
> > using CISEs into shared libraries. This section of the policy
> > details the machanism whereby ldso will load appropriate versions
> > of such libraries according to the capabilities of the runtime cpu.
> >
> > 2) Libraries containing CSIEs should be placed in a designated subdir
> > of /usr/lib specialized for code requiring the cpu extension in
> > question. All such directories should be agreed upon and sanctioned
> > by the policy committee. As a suggestion, the directory might be
> > named after the cpu capability (as reported in /proc/cpuinfo) required
> > to run the code, (e.g. /usr/lib/{sse,sse2,3dnow,3dnowext} on i386,
> > /usr/lib/ev5 on alpha, and perhaps /usr/lib/sparc64 on sparc, etc.)
> >
> > 3) All functionality provided by this code should also be provided by
> > a binary-equivalent generic shared lib of the same name and soname
> > in /usr/lib.
> >
> > 4) Ideally, ldso should be smart enough to search the special
> > directories first given the running cpu characteristics. Barring
> > this, a system script, update-ld.so.conf, should be created, which
> > packages can call at install/remove time, to add/remove the
> > specialized paths appropriate to the running cpu to /etc/ld.so.conf
> > and then run ldconfig. Optionally (and preferably), this script
> > could also be run at boot time to catch cpu-upgrades and/or kernel
> > upgrades (SSE requires kernel support). Paths need not be added,
> > and can be removed, if no libraries exist in the directory. The
> > package providing this script should be in the 'base' section if
> > invoked at boot time. Otherwise, packages using this functionality
> > should depend upon the update-ld.so.conf package.
> >
> > 5) For this scheme to work, it is necessary to ensure that ldso loads
> > libraries in the directories specified in /etc/ld.so.conf in
> > preference to identically named versions in /lib or /usr/lib, as is
> > currently the case with Debian's ldso. It is part of this policy
> > that such behavior remain standard on Debian systems.
> >
> > The Debian atlas packages currently use this scheme. I believe that
> > at least gmp can currently make use of it as well. I've provided a
> > sample update-ld.so.conf below. If this proposal is accepted, I'd be
> > happy to package it or something similar.
>
> --
> Michel "Walken" LESPINASSE
> Is this the best that god can do ? Then I'm not impressed.
>
>
--
Camm Maguire [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
