Martin Husemann <martin@duskware.de> writes:

> But if the drvctl_command_table would be extendable, it allows third party
> LKMs to come with their own, private, drvctl commands. One could use a GUID
> as command identifier, but that would mean the userland program needs
> knowledge of all supported commands. Besides, with the whole dictionary
> already copied in, a strcmp() is not a lot different to the memcmp() needed
> for the GUID variant.

Can you elaborate a bit on the kinds of commands you're considering
here? drvctl, to date, seems to mostly be about the driver
infrastructure - attaching, detaching, and otherwise working with the
device tree. One way to interpret what you're considering is a broad
"ioctl via proplib". That might not be a bad thing, but I'm curious if
that's what you had in mind.

       - Nathan