[illumos-gate] 18166 Create header-tests package -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 18111 Want C++ header tests -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 18192 header-tests programs could be improved -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 18219 mdb: cmihdl dcmd actually does use slashes for -c -- Toomas Soome <tsoome⊙mc>

i don't suppose anyone has a system with SATA port multipliers by any chance?

they have a reputation of not working well so I think people tend to avoid them.

certainly on illumos, I think I've found some potential causes :)

so like, I can point at the spec and fix the code, but aside from 'yeah non-PM is fine with it'.. kinda stuck in making sure a PM would be ok with it

sort of a self-fulfilling prophecy. Though it looks like amazon has something that might implement that spec for cheap: amazon.com/Splitter-Adapter-Convert…r-Multiplier-Selector/dp/B0GR993TJG

or amazon.com/Cablecc-Splitter-Convert…r-Multiplier-Selector/dp/B0BYNFR2FC

so $25ish gets you a 1-5 expansion if you have the right upstream sata controller..

github.com/illumos/illumos-gate/blo…/io/sata/adapters/ahci/ahci.c#L9603 heh

(it also calls ahci_software_reset() w/ addr uninitialized, but AFAICT, ahci_software_reset() never actually uses the parameter)

somewhat related, for a > 1ms wait in an _attach routine, would delay(9F) be preferable over drv_usecwait()?

given how long that is, i'm thinking 'probably', but also not sure because we're attaching if there might be other considerations where 'no' might be better despite the length

I think the preferred approach is drv_usecwait()?

assuming you didn't disable mtc, we multi-thread all of that pretty widely

so if you're worrying about your thread sleeping, that probably doesn't matter much

hrm.. ok..

richlowe: I hope my fix for illumos.org/issues/18185 won't cause hearburn for the arm port..

→ BUG 18185: retire run_arch_tests.ksh in libc-tests (In Progress) | code.illumos.org/c/illumos-gate/+/4859

sommerfeld: probably makes things simpler, actually.

though what's in there right now is aimed at being easy to merge, not nice

jbk: Generally I'd use delay there.

Unless you're in a special case.

drv_usecwait is a spin loop, so unless you need to spin, you generally shouldn't for a ms.

gwr's change to split the header tests out of libc-test nicely sped up the (reduced-size) suite..

I'm excited to re-sort my list to run the libc tests sooner