Come join us! Triton DataCenter Office Hours will be happening this Thursday once again at 11PT/2ET/18:00 UTC on Discord discord.gg/v4NwA3HqayIt's a great way to engage with community members, developers and learn more about Triton DataCenter!

ok.. something isn't clicking

addr::walk xxx | ::print struct Foo fails with failed to dereference symbol

yet I can take the addresses from the walker

and do addr_from_walker::print struct Foo

::typelist -l fails to show struct Foo

err ::typedef -l

a schrödinger type apparently

it exists, yet doesnt'

Was it something you defined with ::typedef?

it was read from a module

so ::typedef -r

ctfdump on the module agrees that it exists

OK. I would still expect it to show up in typedef -l then.

and ::print struct Foo (no addr) also agrees.. just not in a pipeline

which is odd

If you use a different type in that context does it work?

Specifically one qualified with struct or similar.

oh gah... PEBKAC

nevermind :)

some debugging info from writing the walker was fouling things up

(probably means it's time to quit for the day)

though the ::typelist -l thing still remains.. but ::print works now

[illumos-gate] 15616 Add DISCARD/TRIM support to lofi(4D) -- Andy Fiddaman <illumos⊙fn>

toasterson: just curious, does the SPARC spin of hipster have CI builds setup or is it just whenever new commits get pulled into the branch manually?

also, is there maybe a more appropriate channel for OI SPARC related stuff? I realize this is kind of niche and is noise to most of #illumos

KungFuJesus: there is no CI for that no.

toasterson: you could get sparc adapted to the cross-build stuff

[illumos-gate] 15623 remove lingering sections of sun studio -- Richard Lowe <richlowe⊙rn>

and then you could CI it

richlowe: sparc still failed with unwind and it's not easy for cross builds - you have to prepare sysroot with libs

you'd be amazed how much detail I know about that in rn

and it's really not that bad.

richlowe: i't s possible to build final binary with static gcc libs - binary can be run on native sparc env. but with shared builds it failed to me a lot. need additional time for it

richlowe: Most likely option yes. Depends when people get to it.

does illumos actually support Router Advertisements with preferrred lifetime of 0?

anecdotal evidence would suggest no, but I wanted to ask :)

richlowe: Was sun studio ever actually a _good_ compiler? I've always wondered

back in the day (~2000) it was certainly prefereable to the gcc 3.4.3 shipped in sfw for most things

nbjoerg: there appears to be code to delete the route when preferred lifetime = 0: github.com/illumos/illumos-gate/blo…sr.lib/in.ndpd/tables.c#L2166-L2174

sommerfeld: reason I am asking is that Mikrotik finally fixed that in RouterOS and e.g. Linux correctly stops using the old addresses for outgoing traffic, but Illumos certainly des not

does not

not even sure how I can get the current lifetime to double check though

in.ndpd is the daemon you want to debug; the route lifetimes appear to be maintained by timers within that process.

it's entirely possible that something goes wrong when it tries to delete the route.

testing at the moment with these SPARC systems, I do wonder if Sun/Oracle Studio would produce more optimal code or if GCC or even clang do a better job

I wouldn't worry about it, honestly.

"more optimal code" is just another way to say "absolutely screwed by imperfections in your code"

and probably, largely, unless very performance sensitive, not actually going to be measurably affect your life

(if you think it might measurably affect your life, there's always benchmarking)

Studio was (marginally) a better compiler when it came out, but Studio for illumos is 10-15 years old now and the alternatives have been constantly improving

is there rust in illumos? the kernel, specifically.

no

Some of us have developed kernel modules that are all in rust, but they're for specific use cases and not upstream.

yeah, there's no reason, except nobody has written one yet.

it's not like people write brand new kernel modules that often, vs. updating existing ones

That's just because you're not cursed with new subsystem-itis.

updating an existing one would also upset me, at least temporarily.

but I mean, I have to be upset eventually.

I mean if I wanted to see rust in the kernel, I'd look for something fun like porting the graphics drivers for the ARM Macs

you are not helping, alan :)

my employer doesn't allow me to help 8-)

alanc: only if you fixup the rest of the graphics stack aswell :)

I already maintain half of it upstream, isn't that enough?

It's much more than we deserve.

It definetly is :)

someone even listed it in gitlab.freedesktop.org/xorg/doc/xor…docs/-/blob/master/MAINTAINERS#L588

honestly, something network-facing and full of untrusted data is probably the most immediately useful thing.

I'm surprised, like, wireshark or something isn't heading that way

given all the issues tcpdump, snoop, etc, have had in the past.

slurping arbitrary trash off the network, badly in the case of snoop at least, would sure feel better that way.

The network-facing bit was what we started with.

hrm.. just as a sanity check.. you _always_ need to ddi_dma_sync before reading memory that you're expecting to be modified by a driver (e.g. there's no flag to ddi_dma_mem_alloc or ddi_dma_addr_bind_handle that will elide the need to do a sync), right?

Correct.

ok..

Though x86's consistency can hide issues.

jbk: If you look at the DMA Related Functions of the updated Intro(9F) (unfortuantely not on illumos.org right now for some reason), it discusses that a bit more.

Look for a sentence that starts with "When performing I/O to and from a device"