hmm, I have a pcie device that seems to have 2 PCIE_EXT_CAP_ID_VS entries, is it possible to somehow get the second one using PCI_CAP_LOCATE(), pci_xcap_locate(), or by any other *simple* means without rolling out enumeration myself?

I don't see something right this moment for this case. But there probably is something we could add.

I do agree that the main cap functions don't work well today for vendor-specific or DVSEC caps.

got it, thanks Robert

(I already have enumeration code stolen from other tree part, was just wondering if I'm missing something obvious)

In this case doo both of them have different vendor-specific IDs?

That is in your ideal world would you want to do a search by vsec id?

For the dvsec it'd be by vendor id and dvsec id.

It wouldn't be too bad to prototype something if it'd help, Yuri.

rmustacc: I'm not sure, just following what driver for another OS does there, and the second entry seems to contain offset further into configuration space for yet more undocumented registers.

and it does something like ext_cap_offset(..., PCIE_EXT_CAP_ID_VS, 1), where 1 is likely meaning "get the second one"

[illumos-gate] 16806 Some services unexpectedly start in /root -- Andy Fiddaman <illumos⊙fn>

it is annoying that `__attribute__((deprecated))` isn't `__attribute__((deprecated("use the new one")))`

Indeed

C23 deprecated allows that.

It's an entirely different syntax, alas: [[deprecate("message")]].

that seems exciting to wodge through the preprocessor

I have an example of it for noreturn!

It's great.

I was just thinking of what the error message will look like if the parser gets confused

i'd imagine the preprocessor would need to know to ignore [[...]] attributes

or just pass them through unchanged i guess...

It's ifdef's all the way down.

my problem with testing what I wondered is finding something we've deprecated but also don't use extensively

hello does anyone know if daily driving ilumos for security is a good idea