Speeding up wineserver (again)

Troy Rollo wine at troy.rollo.name
Tue Aug 5 17:50:19 CDT 2003


On Tue, 5 Aug 2003 15:38, Lars Segerlund wrote:
>>[Earlier stuff describing a kernel approach deleted]
>   This might be an approach to implement permissions and services in a
> consistent way, whitout needing to give admin rights to the admin
> account ( per user admin ? ).

I've been thinking this too. The kernel APIs I was suggesting are really just 
a new IPC mechanism that is sort of like shared memory, but with better 
access control facilities and better potential to set up a naming structure 
that cooperating processes can use. It seems to me it would have applications 
beyond just wine. Of course this is without sacrificing the principle that it 
needs to have value in improving the efficiency of wine.

I'm calling this mechanism "lockboxes" for now. Unfortunately I probably won't 
have much time to work on it until late November.

>   Basicly the kernel part could handle the services ( run as user <xxx>
> ), the question is how to handle interaction between users on the same
> machine ? shared folders ? network neighbourhood ?

The principle I'm starting from is to provide mechanisms so that what amount 
to subsystems can be implemented in user mode without compromising security 
or efficiency, and trying to figure out the minimum necessary set of new 
kernel functionality to support this.

I'm attaching the header file that constitutes the current definition of the 
lockbox API.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lockbox.h
Type: text/x-chdr
Size: 4471 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030806/9ffb1757/lockbox.h


More information about the wine-devel mailing list