Allen Briggs <briggs@wasabisystems.com> writes:
> So (assuming that there is enough to be gained from doing this,
> which it seems there may well be for some archs) instead of
> hw.cpu_isa, it sounds like you really want to abstract from the
> ISA to a set of optimizations.

There certainly is, for Alpha.

(I am a bit concerned about what people are considering an "ISA".  For
instance, I consider the basic Alpha Instruction set to be the "ISA"
for Alpha.  There are various extensions to it, but they extend the
ISA, and don't really create new ISAs.  Different people (and
different CPU families 8-) have different notions of what it means...)


> This leads me to consider something more like a hw.cpu_optimization_type
> (or whatever) that would have a MACHINE_ARCH-specific set of values.
> This could be set based on the CPU's model, the CPU's capability
> set (if separate from the model), and whatever else (e.g., a GENERIC
> or INSTALL kernel might set it to a conservative value if there's
> any chance that a dangerous choice could be made).

My thought on this is, why hard-wire all that gunk into the kernel?

The kernel should provide the basic capability information,
specifically:

	* CPU model (if appropriate/relevant)
	* flags for individual extensions (if appropriate/relevant)

etc.  Userland configuration, i.e. ld.so.conf, should then combine
them to pick appropriate libraries.

it might be nice if there were some shorthand way of naming
combinations, for easier picking of libraries.  but i don't think that
_any_ decision about this should be made in, or in any way wired into,
the kernel.

It's quite reasonable that Joe Bob would want to create a tricked out
version of libfoo.a for a specific extension, that doesn't fit any
kernel "optimization type" however you want to define it, and they
should be able to use it reasonably.


The existing ELF ld.so.conf format cannot handle the generality needed
for this.  (And I've thought that, and I believe mentioned that it was
deficient, since pretty much as soon as i noticed it.)

At minimum, it needs the ability to combine multiple sysctl values
into a single test, e.g. to say "if bwx_present and precise_fp then
use this library".

It would be better if it also had a primitive assignment facility to
allow a shorthand notation of "optimization types" to be defined.

it would probably be even better if there were a more complex
structure.

in a better world, it would allow flexibility like:

	bwx=(<sysctl hw.isa_ext_bwx> == 1)
	prfp=(<sysctl hw.isa_ext_precise_fp_traps> == 1)
	cix=(<sysctl hw.isa_ext_cix> == 1)

	if (bwx && prfp && cix) {
		for libc.so use libc-wonderful.so
		for libm.so use libm-wonderful.so
	} elif (bwx) {
		# e.g. if some bwx cpus that aren't "wonderful" do
		# have cix, but some don't.		
		if (cix) {
			# give me the fastest ffs() known to man!!!
			for libc.so add libc-cix-stubs.so
		}
		for libc.so use libc-bwx.so
		for libm.so use libm-bwx.so
	}

etc.  (where, 'use' stops processing, 'add' includes a library at the
current point.)

You could even do something like:

    disable_opt=0
    if (!disable_opt) {
	[ ... all that above ]
    }

then switch it to 1 to turn off the special substitutions.


if you think you need to invent specific sysctl variables just to
allow you to trigger ELF ld.so.conf for certain optimization targets
... that to me indicates that (like i've felt for a while) the way
library substitution is done there is much to simplistic to be useful.



cgd