If I want to use `mdb -k` to walk through all the doors on a system... am I gonna have to write a walker for doors?

Not that I want to, necessarily, just trying to make sure I understand how mdb works. Like, each resource that can be walked has a separate walker function defined?

Or maybe there is a better way for me to achieve this: I thought it might be interesting to see, for a given door, what all processes have an open descriptor for it (since that descriptor could have been passed through other means that an open(2) call)

for no other purpose than I am trying to learn mdb and that seemed like something mdb would be good at

robertdfrench: The way I generally think about and try to answer that question is based on what the underlying implementation is and how it's structured.

So a lot of this comes down to how is this structured in the kernel and how do doors exist and are managed.

Let me try to put together a few other examples in terms of how I think about it. For example, every datalink has a mac_impl_t that corresponds to it. Those are allocated from a kmem cache so there's an automatic walker for them.

If I want to find all of say the nvme driver instances and their state, I know that it uses a ddi_soft_state_t called nvme_state. So I can do a '*nvme_state::walk softstate'.

Now, when it comes to doors things here are a little different because there's no canonical global state for them because they're implemented through the doorfs file system. So while you use a system call to create it, the actual door data is stored in a given vnode's v_data.

So I think really the first answer to question of how would you do it in mdb is to first ask how would you answer that question with the existing kernel's data structures.

But to talk examples of this, the ::dcmds and ::walkers commands print all the walkers and dcmds that exist (95%+ are all just plugins).

But as a simple starting point take a look at '::walk proc | ::pfiles'. And then '::walk proc | ::pfiles ! grep -i door'

ok so one issue with using native strip is that it breaks rust .rlib which are just archives, presumably other folks are just excluding those?

jperkin: I assume because it chucks out the metadata stuff they stick in there?

It would probably be good to file a ticket if we're doing something wrong there

tsoome: I'm putting illumos#15105 up for RTI, let me know if you don't want to be listed as a reviewer; the delta from when you last looked is, I think, code.illumos.org/c/illumos-gate/+/2566/3..9

→ CODE REVIEW 2566: 15105 ilstr should be usable outside boot banner code (NEW) | illumos.org/issues/15105

[illumos-gate] 15874 libshare: clean up warning suppressors -- Toomas Soome <tsoome⊙mc>

jclulow it is in my queue:) just cleaning up some first

tah

jperkin: it would be good to file a bug about what's happening there, ideally so we can learn what we're removing that is important.

jperkin: whether strip -x breaks, as well as strip, too

[illumos-gate] 15105 ilstr should be usable outside boot banner code -- Joshua M. Clulow <josh⊙so>