richlowe: FWIIW. I usually use iks.cs.ovgu.de/~elkner/tmp/template.sh as a starting point ...

hrm.. it looks like busstat only works (today) on sparc... would x86 HW have anything that might make sense to wire up to the command?

jbk: Kind of, maybe?

Right now on both Intel and AMD we really only do mostly CPU core based perf counters.

There are perf counters for the memory controller and data fabric.

that's what i was wondering...

sad thing is, our ehci is still not working with UTM (qemu).

They have a slightly different interface than the core counters.

So there's a bit of enablemen work we need to do. Less certain what intel currently looks like.

jperkin: the glib thing talked about mastodon.social/@ebassi/110039041635210901 here, and in something alanc mentioned I think also on mastodon too, seems like it might hit you really hard, since in your case the "system allocator" it'll now use is umem

which as we know, is sometimes too fussy for random code as it is.

(it's the right amount of fussy, random code is bad, but you know what I mean)

I had just boosted that post from ebassi

oh, maybe it was on the distribution list thing you put in #oi-dev

glib is linked with libumem instead of libc malloc?

alanc: pkgsrc uses umem as much as it possibly can

which doesn't sound fun for this

yes, there was a post in lore.kernel.org/distributions about it, which I first saw in a reply to @ebassi's and then went to look at the archives of the rest of the list

ah, I didn't know pkgsrc did that

(there are other posts in lore.kernel.org/distributions which may be of interest to other distro makers and package builders as well)

and I forsee lots of bugfixes by tsoome due to ancient K&R style code due to lore.kernel.org/distributions/2354211.7hzS34FegO@nimes when it's time to start porting to gcc 14/15/whenever-C23-lands

I've been trying to encourage people to do that now, but I keep failing.

similar to what fedoraproject.org/wiki/Changes/PortingToModernC is doing with other packages

the problem is that (and -Wno-implicit-function-declaration) lead you into some horrific code

finding people who want to fix the mess it finds is easier until they see the mess, and realize they need to test it

though having said that, sommerfeld, if you were looking at printf-y warnings, you might also be interested in places we add -Wno-implicit-function-declaration. Some of them are very bad.

yeah, I tried to make people convert K&R-> ANSI as part of all our LP64 conversions, but we've still got some left to do to

I specifically remember udfs being worse than very bad.

but there were others.

thought I guess the places I made them change () -> (void) in function declarations aren't needed for C23 now

richlowe: yeh we'll have to see what falls out, good thing that they're seeing issues on primary platforms, gives us hope they'll fix upstream

alanc yep (I do hope I wont be alone in this, however:D)

you won't, I hope

'cos fixing those things would help me too, as far as having faith in stuff having to all be 64bit

sorry to interject but what is not 64 bit these days except emulators

we can't even support sparc because noone has the hardware

most of the programs shipped in illumos

they still build 32-bit because Solaris & illumos used to run on 32-bit CPUs and no one has put in the work to make sure they're 64-bit clean and build them that way, even when running on a 64-bit CPU/kernel

my friend asks if bcantrell is still a part of this project

please don't ban be for asking

dangergrrl: We have working hardware and are keeping sparc alive in OpenIndiana with the same frequency as x86