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

List:       wine-devel
Subject:    Re: [PATCH 2/2] Programs: Load device drivers of the same group into the same winedevice process
From:       Aric Stewart <aric () codeweavers ! com>
Date:       2016-02-26 12:50:56
Message-ID: 56D04A30.5050802 () codeweavers ! com
[Download RAW message or body]

Thank you for looking over my patches.


On 2/25/16 11:30 PM, Sebastian Lackner wrote:
> On 24.02.2016 15:16, Aric Stewart wrote:
> > Signed-off-by: Aric Stewart <aric@codeweavers.com>
> > ---
> > programs/services/services.c | 124 ++++++++++++++++++++++++++++
> > programs/winedevice/device.c | 191 ++++++++++++++++++++++++++++++++++++-------
> > 2 files changed, 286 insertions(+), 29 deletions(-)
> > 
> 
> Although the general idea seems fine, the patches are still very hacky, and I fear
> we need a better method to communicate between services and winedevices - a \
> separate mailslot communication doesn't seem like a good idea. The main issues I \
> still see: 
> * Instead of two separate communication channels, we should implement marshalling \
> of data structures, and return them for example in the ServiceCtrlHandler callback.
> Depending on the exact mechanism, special care has to be taken to ensure the
> process is up and running before sending control commands.
> 
> * Currently wine supports loading of both 32-bit and 64-bit drivers. This needs
> special care in both patch 1 and patch 2. A winedevice process with the wrong
> architecture will not be able to load the driver.
> 
> * programs/services should be able to track the services correctly. Unfortunately
> it seems like the advapi32 functions do not offer any nice method to add additional
> services after startup. Maybe we could add a wine-specific extension here?

I have a few follow-up patches that I have not sent yet that basically do this.

I modified winedevice to use IoCreateDriver instead of creating the DRIVER_OBJECT \
itself. Then ntoskrnl.exe can track all drivers created by IoCreateDriver and \
programs can use ObReferenceObjectByName using the '\Driver\<something>' path to find \
loaded drivers. 

> 
> * Proper locking is required before accessing the database or services structures.
> Those are technical issues though, and can be fixed of course.
> 
> I'm currently trying a couple of own ideas, and will share them as soon as they do
> something useful. ;)
> 
> Regards,
> Sebastian
> 

My basic requirements are that I need to be able to load a number of .sys drivers \
into the same process space, and Plug and Play drivers are installed with a start \
type of 3 (On Demand) So the plug and play manager needs to be able to do a \
StartService or something similar on the no currently loaded driver and have it go \
into the right process.

Alexandre was the one who suggested doing it by LoadOrderGroup, which I like.

-aric


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