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