`usbipd policy state` command similar to `usbipd state`

[nickbeth]

Hey, I'm the author of the WSL USB Manager GUI for this tool.

I'm currently trying to implement more advanced auto attach functionalities in my app (currently only uses auto-attach command, but auto-attach profiles are forgotten on app relaunch), and I found that it would map pretty cleanly by implementing a "port auto-bind" feature by leveraging the new policy system.
My idea is to create a new policy for a port, store the GUID as the ID of that "auto-attach profile", and then use that GUID to remove it if the user doesn't want auto attach on that port anymore.

Here's the issue: I'm using ShellExecuteEx to launch an elevated usbipd process to run commands, but there isn't a straightforward way to capture stdout (where the GUID is printed). One would need to use CreateProcess, but that doesn't support running elevated AFAIK. Therefore, I'm stuck at doing all kinds of weird hacks just to capture the stdout of the policy add command via a child process, which passes it through some named pipe/mailslot so that it reaches back to the main process.
This is nasty and I'd like to avoid it. I'd also like to avoid needing to run my entire app as administrator, both because there's no need for that, and also for my own peace of mind (don't want any lingering bugs breaking people's PCs).

So my only option here would be to ignore the GUID printed to stdout (which honestly is fine, I already rely on state for other commands) and parse the policy list output, but:

1. It's not the most parsable format as it's made for human readibility
2. I don't think it's a stable format as it could change in the future (?)

TL;DR: Is there any chance we could get a parsable (JSON) formatted output for policies with a command like usbipd policy state, just like the usbipd state command?

P.S. If you believe there's an alternative solution to the issue I described that I'm not seeing, please let me know!

[dorssel]

I think I understand what you are trying to do. You are trying to piggyback on the policy information and attach "additional meaning" to it (as in: auto-bind is going to also mean auto-attach when your program is running). Right? That's fine, and entirely up to you. Whether this is the "right way to do it" I am not sure. But in any case, having a parsable output for policies in itself is useful, so I'll make that.

[nickbeth]

Yeah that's exactly what I'm doing, the reason being that it's the one that gets less in the way when trying to emulate auto attach for a given port (bus id), rather than a device (which is pretty straightforward, just gotta attach --auto-attach --guid).
I've tested with policy add --operation AutoBind --effect Allow --busid, then attach --auto-attach --unplugged --busid and it works quite well. No additional bind requests for new devices on that bus id need to be shown to the user, which is quite nice UX wise and also I don't have to deal with going back and forth with UI code to show some sort of message to the user to allow binding (I can't just show a random UAC with no explanation).

I'd need the policy state command to make it easier for my app to parse policies and present them to the user so that they can be removed if one wish to disable auto attach for that port.