[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Plug and Play and Wine
From:       Aric Stewart <aric () codeweavers ! com>
Date:       2015-12-30 16:43:07
Message-ID: 5684099B.9020605 () codeweavers ! com
[Download RAW message or body]

Thanks for the reply! Sorry for my delay I am on vacation so e-mail and think about \
complicated things like this time is more scarce.


On 12/22/15 12:13 PM, Damjan Jovanovic wrote:
> 
> I've already done that. Attached are 2 patches that make driver loading independent \
> of global variables, and move driver loading code from winedevice.exe to \
> ntoskrnl.exe where it can be reused to load drivers from anything that links to \
> ntoskrnl.exe. 


That is pretty cool!  Have you submitted these for review and comment? It would be \
nice to move the driver loading somewhere like ntoskrnl

> 
> My work on USB uses a similar idea.
> 
> In my design, usbhub.sys (my "bus driver") is loaded at Wine start-up. It is loaded \
> by winedevice.exe, in its own separate winedevice.exe process just like every \
> driver currently is, but it is able to (using my previously mentioned patches) load \
> USB device drivers into its own process, and leading to a hybrid driver \
> architecture where copy protection drivers should continue to work as they get \
> loaded into their own winedevice processes and crashes won't affect other drivers, \
> while usbhub.sys can load USB drivers into its own process as needed to provide \
> hardware support.

That should plug into this structure pretty easily, that is good to know. the \
usbhub.sys will no longer be loaded by winedevice.exe but instead it will be \
integrated into plugplay.exe, still in driver style for later pull out if we want. 

> 
> Also I planned to detect device additions and removals by listing all USB devices \
> every second, and detecting what changed since the previous listing. This is \
> because there is no other portable way to read device addition/removal events: \
> there used to be HAL but now we've degenerated to the Linux-only udev :-(. I was \
> planning to hack the plug and play side of things ;-). A background thread in \
> usbhub.sys would do this polling for USB devices and build device objects and load \
> drivers. 

If you are using udev then you should be able to to listen for device removal and \
insertion without having to poll. In my proof of concept Plug and Play setup I have a \
udev setup that does this for hidraw devices and it quite straight forward. 


> We should probably develop the plug and play system before USB though?

I agree. So far I am looking at the lack of much comment as people not having any \
problem with this, and since it works with your concept and artecheture I will start \
cleaning it up and try to submit patches soon after the new year. 


-aric


[prev in list] [next in list] [prev in thread] [next in thread]