[PATCH 1/2] ntoskrnl.exe: Implement IoRegisterDeviceInterface

[Zebediah Figura]

On 17/09/18 13:20, Aric Stewart wrote:
> On 9/17/18 11:55 AM, Zebediah Figura wrote:
>> On 17/09/18 11:44, Aric Stewart wrote:
>>>
>>>
>>> On 9/14/18 2:02 PM, Zebediah Figura wrote:
>>>> On 14/09/18 13:59, Aric Stewart wrote:
>>>>> Signed-off-by: Aric Stewart <aric at codeweavers.com>
>>>>> ---
>>>>>    dlls/ntoskrnl.exe/ntoskrnl.c        | 216 ++++++++++++++++++++++++++++++++++++
>>>>>    dlls/ntoskrnl.exe/ntoskrnl.exe.spec |   2 +-
>>>>>    include/ddk/wdm.h                   |   1 +
>>>>>    3 files changed, 218 insertions(+), 1 deletion(-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Can this go directly through setupapi instead?
>>>>
>>>>
>>>
>>> Sorry, I dont know if I understand your question...
>>>
>>> What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
>>>
>>> -aric
>>>
>>>
>>
>> I mean that we could implement this on top of setupapi routines instead
>> of essentially reimplementing them here. I know that it's
>> architecturally upside-down, but we call call user-mode functions
>> elsewhere in ntoskrnl, and as long as we're going to keep drivers in
>> user-mode I don't see any reason to avoid that.
>>
>>
> 
> Yeah, Looking at the SetupDiCreateDeviceInterfaceW APIs in setupapi I can see how you think that. They where clearly the inspiration and base for my work. However the top level entry points vary quite a bit.
> BOOL WINAPI SetupDiCreateDeviceInterfaceW(HDEVINFO DeviceInfoSet,
>         PSP_DEVINFO_DATA DeviceInfoData,
>         const GUID *InterfaceClassGuid,
>         PCWSTR ReferenceString,
>         DWORD CreationFlags,
>         SP_DEVICE_INTERFACE_DATA *iface_data)
> vs
> NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device,
> 	const GUID *class_guid,
> 	UNICODE_STRING *reference_string,
> 	UNICODE_STRING *symbolic_link)
> 
> Because creating WINE custom entry points into existing dlls is frowned upon I felt it easier to reimplement instead of try to shoehorn. However if you are seeing something I did not then maybe it should be done differently!
> 
> -aric
> 
> 

Hmm, right, I see that setupapi doesn't expose a way to specify the
symbolic link.

Another alternative is to implement some of setupapi on top of ntoskrnl,
though I'm not sure to what degree that's worth doing.