sommerfeld, jbk, tsoome, jclulow: thank you very much for the advice

I will re-design the appliance and its performance base line, thank you very much

yw:)

Is there any reason to use isnand() or isnanf() rather than the generic isnan()?

This is for applications (I was wondering why it had to #include <ieeefp.h>)

I think, you get the answer from looking the code:)

but I guess, there are always some historical reasons:)

Yes, it's the history part that I suspect is the issue. In that the history involves Studio compilers on antique Solaris versions...

I don't think there is history and studio. I think isnan is just c99

either way, it's a compiler builtin to do the magic, there's no promotion risks or anything.

out of curiosity, are there any amd ryzen-suporting MBs that are known to be problematic running illumos? or are they generally fine?

I have a question with fenix IPD 14 ramifications.

IPD 14: illumos and Y2038 (predraft)

↳ github.com/illumos/ipd/tree/master/ipd/0014/README.md

Let's say I want to 64-bit an application that hasn't been yet. Do I install it alongside its 32-bit sibling and use isaexec? Or, assuming it's properly tested, etc, etc, do I have its usr/src/cmd/TOOL directory Makefile just compile the 64-bit version in place?

Asking for zoneadmd, which in SmartOS compiles BOTH today, but only ships 64-bit, and does isaexec things. I'm thinking:

1.) illumos-joyent zoneadmd should get rid of i386/ and amd64/ subdirs and just compile 64-bit straight into /usr/lib/zones/zoneadmd again, instead of having isaexec there.

2.) Since ours (which admittedly is a lot different from upstream, but still...) has been running 64-bit for quite some time, maybe -gate's can also?

Also, since I don't have Oracle Solaris handy, @alanc may be instructive about what Oracle did when moving away from 32-bit apps.

I think I would just ship the 64-bit binary, and avoid isaexec

I think that's what happened with the zpool and zfs commands, for instance

In Tribblix I'm almost at the point where isaexec becomes unused

We have been removing isaexec consumers, because they have no purpose

I don't remember how many I left, but it's very few

don't add more, all they do is cause one extra exec

unless you have an LP128 CPU you care about

I think we just have adb/mdb, where you have to ship both and it reexecs depending on whether the target is 32 or 64 bit

And in.iked, but that's it

Looking at an S11.4 box, it does have isaexec, but its link count is 1

iked I can't fix because of how closed-bins

we have other things that re-exec, but not via isaexec

ptribble: I'm sure they still have platexec too :)

(so do we, for that matter)

Hm, no such file as /usr/lib/platexec, and `pkg search platexec` comes up empty

Yeah, I "fix" iked when I mangle IPS to SVR4 packages

I fixed it in my "ship closed-bins in src with makefiles" wad

alanc: when did y'all EOF platexec? :)

hrm.. is there a way in dtrace to convert a clock_t value to (milli/micro/nano)secs ?

@ptribble Might we be able to fix in.iked using stupid packaging tricks? I'd like to think so but I am naive about these things sometimes.

You can, but it's not worth it

the challenge is making protocmp happy

not worth it to save one exec per instance running a closed daemon

@jbk if dtrace can access `hz` I expect it could?

mdb -ke "hz/D"

after the gitignore thing, I removed my setting to not list untracked files

I've caught a couple of missing, but now I have a weird one.

have any of you seen ttydefs.cleanup linger untracked, or is it only during a build it happens, or?

anyway, I'd be interested if anyone else sees it

sigh, annoying mis merge on my part :\

richlowe: amazing, a new thing I've never heard of: platexec: not implemented on i86pc

jbk, danmcd: pfexec dtrace -qn 'BEGIN { trace(`hz); exit(0); }' --> 1000

danmcd: we mostly did in-place replacements of 32-bit programs with 64-bit ones, unless there were special issues like a public loadable module interface, but we were also doing that in the Solaris 12/11.4 development branch, so had many biweekly builds of testing before shipping as production-ready

richlowe: we removed platexec in 11.4 GA

which was the first release where we only supported sun4v and not sun4u

rip