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

[Aric Stewart]

On 9/17/18 1:39 PM, Zebediah Figura wrote:
> 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.
> 
> 

Agreed, I do not know how much it is worth doing. I think having them be parallel is just fine. 

-aric