I was curious what parts of our kernel already *receive* a proplib object
from userland and ran into drvctl.

I first wondered why it is passing a dictionary at all, but given the
arbitrary list of locators that can be passed, this does make sense.
Within the same directory it also passes the command - as a string.

Noting that the list of commands is fixed currently, this does not make
a lot sense to me.

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.

We should add an API to add more comand tables, shouldn't we?

Martin