On 2012-12-18 15:25, Gabriele Bulfon wrote:
Yes :) I was the one who built that library, while working on XStreamOS
userland :) For some reason there was a commented action in the patches
that excluded aes support.......now it's ok. Thanks!
I remember that among OpenSolaris Hub projects there was one regarding
"Unified Binary Executable" or somesuch. In essence, this produced a
single binary which "concatenated" several binaries built with various
optimizations for different hardware, and a loader code, the correct
piece of code was selected at runtime - including, allegedly, the
ability to provide SPARC and x86 code both in a single binary file.
On one hand, this probably solved the problem we discussed recently
about i86/amd64 or sparcv7/sparcv9 (i.e. 32-bit vs 64-bit) code and
isaexec, and on another hand - this provided a means to build programs
with even more CPU-accelerated features to be used if available (or
allow to use a generic i686 code otherwise) without requiring users
to think about it or install a particular build of the package.
I am not sure this project covered libraries, but a few years back
I saw Intel's similar project of math libraries for programs built
with intelcc, where the most matching CPU supported build of math
was selected at runtime.
Solaris actually does similar effect by lofs-mounting a particular
HW-cap selected /lib/libc.so.1. Similarly, I was told that most of
32 vs. 64 bitness in Solaris is provided by libraries, while the
vast majority of programs are 32-bit ones which load one or another
shared lib for current CPU's bitness, and as of Sol10 only some 700
executables out of several thousand actually needed to be built in
both bitness variants (and cheated for by isaexec). On my constrained
Sol, SXCE and OI boxes I see just 60 to 90 links to isaexec.
Overall, such projects can allow to produce singular distros (perhaps
with some bloat in certain places that can benefit from intimacy with
hardware) that would perform at best capability utilization for every
CPU catered for during the build, while being able to install and work
anywhere.
I think, with proper API between programs and libraries, or perhaps
by initializer like libmain() to be invoked by dynamic lib loader,
selection of binary code for the particular hardware - such as with
the CPU AES support and without it, in this thread's case - can be
done with just pointers to functions provided by a library binary.
Selection of SPARC vs. x86 (vs. ARM...) might be tricky though, but
within an instruction set family the initializer can be built as
a lowest common denominator (i.e. 32-bit i386 for the intel/amd
platform).
Likewise, with IPS I believe it is possible to provide facets for
"lowest common denominator" and for particular instruction sets, and
thus provide several binaries of libs and ("unified" or separate)
programs - generic and optimized; the latter should be loaded if
they exist and if they match the current hardware. In terms of IPS
this would be a single published package, but on particular hardware
it would install only what's needed without extra bloat of code on
the server or desktop installation, for other optimizations. However,
if this OS image is loaded on another hardware, the generic binary
could always be used. And, I think, this is one feature that IPS
could actually be useful for ;)
What do you think? :)
//Jim Klimov
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
